The FBI maintains a cyber incident reporting service -- should the incident be of a sufficiently malicious nature, it should be reported to the authorities. See [this whitepaper](https://www.fbi.gov/file-repository/law-enforcement-cyber-incident-reporting.pdf/view) for a breakdown of how to report.
An [incident][2] is an unplanned event affecting a service or agency, where a disaster reflects multiple services or agencies. A catastrophe is defined as one-step worse -- a destruction of AniNIX software and hardware necessitating rebuilding the same and likely a relocation of any operations and facilities.
See TOGAF, COBIT, and ITIL standards for design methods for incident response. Also available is documentation from [NIST](https://duckduckgo.com/?q=NIST+Creating+security+plans+for+federal+information+systems&ia=web) on how to formulate security plans.
Network operators should follow the `#sharingan` IRC & Discord channels for a redundant method of being alerted when there are issues. While we have no mean-time-to-acknowledge (MTTA) or mean-time-to-recover (MTTR) service-level agreements (SLA), on-call operators should attempt to respond with all available expediency to issues.
Significant non-disruptive incidents detected by [AniNIX/Sharingan](https://sharingan.aninix.net) will be recorded as part of our [OSINT feed](https://aninix.net/AniNIX/Wiki/raw/branch/main/rss/osint.xml). This feed is intended to be a public service to help improve the general community. Those watching this feed are encouraged to examine their own incoming traffic for the adversaries listed and take appropriate protective action.
## Disruptive Incidents' Follow-up
If any significant disruption of service is caused (more than 8 hours), additionally an [Incident Report](./Incident_Reports.md) will be filed and users will be notified via [RSS](https://singularity.aninix.net), [IRC](https://irc.aninix.net), and all relevant social media.
Critical patches to AniNIX software and scripts should be added to [AniNIX/Foundation](https://foundation.aninix.net/) immediately with a proper commit message -- with the right webhooks set, this will send a notification via IRC.
The AniNIX maintains onsite backups -- the affected service will be stopped, repaired from best-effort backups, and restarted. Unaffected services will not be disrupted.
Should a collective failure of software occur, all services will be stopped until the damage can be repaired. The AniNIX has onsite backups to this end.
In the event of an ISP event, a redundant method of providing access is available, but some services will be significantly limited or disabled to limit bandwidth usage. If ISP's are unavailable, admins should notify @everyone on Discord and stay available until access is restored.
In the event of the failure of a redundant or unnecessary hardware component, an admin will:
* Review if the hardware needs to be removed. If not, it will be scheduled to be removed on the next downtime and review ends.
* Review if the hardware can be removed online. If so, the hardware will be removed as soon as safely possible; all reasonable effort will be made to keep maintenance off-hours.
* If none of the above criteria are met and time is available, a notice will be issued at the discovery of the problem and the hardware replaced or repaired off-hours.
* If there is no time, hardware will be replaced ASAP and service-providing components restarted. A notice and apology will be issued immediately thereafter.
Some redundant storage, for example, will be exchanged for failing components.
Should hardware critically fail, the AniNIX does not currently have a support agreement with any hardware provider -- overnight shipping and package tracking will be used to offer a best-effort at restoration of hardware. Users should be aware that some non-redundant, expensive hardware may halt service from the AniNIX for up to 48 hours. Should this happen, the AniNIX will re-evaluate the cost of the downtime against the cost of the hardware component.
If necessary, restoration from the safety-deposit backup will be utilized.
In the event of a complete disaster, the first line of defense is a hard-drive stored in a safety deposit box with a complete backup of the AniNIX/Core VM, which includes the source code to rebuild all other machines.
Should all else have been compromised, a large number of [AniNIX/Aether](/AniNIX/Aether) nodes will allow rebuilding the system from source code, though there will be a massive loss of data. Some of this will be recoverable over time through file lists stored in the Aether packages, but other data will be lost. This is the last-ditch recovery method.
AniNIX admins maintain "bug-out" bags for massive environmental, political, or criminal disturbances, with copies of the Aether package on encrypted storage. They are trained to safely self-evacuate and rebuild the network in a safe location. This recovery method will take a long time to effect; users should watch the aninix.net domain name for a return of some IRC daemon with which to use to communicate with admins. As soon as possible, admins will reach out to the userbase to announce when services will be restored, the reason for loss of service, and the extent of data loss.
