Major documentation rework -- Entities and Ubiqtorate still need cleanup.

This commit is contained in:
2020-10-09 04:19:07 -05:00
parent f506025c54
commit a118037532
76 changed files with 1011 additions and 1246 deletions

View File

@@ -1,45 +1,35 @@
# CERT Grab-bag
CERT, or Computing Emergency Response Team, is an acronym for first-responders to cybersecurity and computing incidents.
[CERT][1], or Computing Emergency Response Team, is an acronym for first-responders to cybersecurity and computing incidents.
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 [https://www.fbi.gov/file-repository/law-enforcement-cyber-incident-reporting.pdf/view this whitepaper] for a breakdown of how to report.
CERT individuals should keep a copy of the following things at all times in a grab-bag:
* The above whitepaper for FBI contacts
* The [https://aninix.net/mediawiki/index.php?title=Template:Incident_Report&printable=yes AniNIX CERT Form]
* Copies of [[Category:Layouts|AniNIX layouts]]
* An up-to-date Git clone of this Wiki
* Laptop and mobile phone
* Any phyical-security tools
* Kali Linux and ArchLinux ISOs in ready-to-boot format
* Scratch paper and thumb drives for evidentiary capture, along with chain of custody labels
<ref name=cisspcertskillset>[https://www.youtube.com/watch?v=PhROeWMPBqU Skillset via YouTube], accessed 1/4/18</ref>
# Incident vs. Disaster
An incident is an unplanned event affecting a service or agency, where a disaster reflects multiple services or agencies.<ref name="linkedinethicalintro">[https://www.linkedin.com/learning/introduction-to-ethical-hacking/information-security LinkedIn Intro to Ethical Hacking Course] by Lisa Bock</ref> 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.
An incident is an unplanned event affecting a service or agency, where a disaster reflects multiple services or agencies.</ref> 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.
# Required Follow-ups
: See TOGAF, COBIT, and ITIL standards for design methods for incident response. Also available is documentation from [https://duckduckgo.com/?q=NIST+Creating+security+plans+for+federal+information+systems&ia=web NIST] on how to formulate security plans.
If any disruption of service is caused, an [[RCAs|root-cause analysis (RCA)]] will be filed and users will be notified via [[Singularity|RSS]] and [[IRC]]. Alternatively, cybersecurity incidents will be documented as [[Incident Reports]] and deep-dives can be requested of AniNIX staff.
If any significant disruption of service is caused (more than 8 hours), 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.
As the AniNIX learns of better configuration processes or usage methodology, this Wiki will be updated, which will automatically notify users subscribed to [[Special:RecentChanges]] via RSS.
As the AniNIX learns of better configuration processes or usage methodology, this Wiki will be updated, which will automatically notify users via IRC.
Critical patches to AniNIX software and scripts should be added to [[Foundation|AniNIX::Foundation]] immediately with a proper commit message and notifications sent.
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.
# Service-level incident response
The AniNIX maintains onsite [[Security_Layout#Backups|backups]] -- the affected service will be stopped, repaired from best-effort backups, and restarted. Unaffected services will not be disrupted.
The AniNIX maintains onsite backups -- the affected service will be stopped, repaired from best-effort backups, and restarted. Unaffected services will not be disrupted.
# Software Disaster Recovery
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.
## ISP events
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 send the following:
:Hello, all,
:Internet access to the network is currently unavailable. To meet with an admin or check on the status, please visit the AniNIX Discord Channel. We will let you know when services are back.
::**Attach Discord static invite here**
:Thank you for your patience.
:AniNIX Admins
Admins should also keep a list of [[Sora|registered users]]' emails in a local location -- we recommend storing them in an [[Tricorder|AniNIX::Tricorder]] along with the last known good IP of the AniNIX.
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.
# Hardware Incident Response
In the event of the failure of a redundant or unnecessary hardware component, an admin will:
@@ -56,12 +46,13 @@ Should hardware critically fail, the AniNIX does not currently have a support ag
If necessary, restoration from the safety-deposit backup will be utilized.
# Complete Disaster Recovery
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 [[Core|AniNIX::Core]] VM, which includes the source code to rebuild all other machines.
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.
# Catastrophic Loss Or Attack
Should all else have been compromised, a large number of [[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.
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.
# References
[[Category:Operation]]
<!-- References -->
[1]: https://www.youtube.com/watch?v=PhROeWMPBqU "Skillset via YouTube, accessed 1/4/18"
[2]: https://www.linkedin.com/learning/introduction-to-ethical-hacking/information-security "LinkedIn 'Intro to Ethical Hacking Course' by Lisa Bock"