The earlier sections of this part describe how to make attacks less likely, and 0004.e ended by admitting that some will succeed anyway. Organizations prepare for that moment with an incident response plan, and the stages of such a plan give this section its structure. The plan covers preparation, which happens before anything goes wrong; identification, recognizing that an incident is under way; containment, limiting the damage; eradication, removing the threat; recovery, restoring normal operation; and lessons learned, improving so that it doesn't happen again. Alongside these stages runs a legal obligation that doesn't fit neatly into any one of them, notifying the people affected. The section follows the stages in order, with notification taken up after recovery.

Preparation#

The best preparation reduces what a breach can expose in the first place, so it begins with design. A service can encrypt personal data so that the company itself doesn't hold the means to read it, for example by encrypting each client's notes under a key derived from the client's password that is never stored. If the service can't read the data, a breach or a dishonest insider exposes much less. The cost is the trade-off familiar from 0004.c: if the company can't read the data, it also can't help a customer who forgets the password recover it, so the files may be lost permanently. Other design choices limit exposure in the same spirit. Least privilege, described under 0004.b, gives each account only the access it needs, which limits the harm from a stolen account. Data minimization means collecting only the data a service needs, since data that isn't collected can't be exposed: a form that has no reason to ask for a Social Security number should drop the field, so that the number is never collected or stored. And a store can keep a token from its payment processor in place of each card number, a stand-in value that is useless anywhere else, so a breach of the store yields no card numbers.

Preparation also means writing the plan before it is needed. A good plan assigns roles and decision authority before any incident occurs, so that nobody has to debate during a crisis who may take a server offline or who speaks to families. It should include contact information and clear responsibilities, and copies of the plan and its contacts should be kept outside the systems at risk, since a plan stored only on the network that ransomware has just encrypted can't be opened when it is needed.

A plan that has never been tried will have gaps, and a tabletop exercise finds them. Staff walk through a simulated incident in discussion, without touching real systems, deciding what they would do at each step, and the exercise exposes gaps in the response plan and in communication among staff before a real event. A good scenario is plausible and high-stakes enough to force decisions across roles, such as ransomware encrypting the grading system during the final exam period. Because an incident crosses departments, participants should include leaders, communications staff, legal counsel, and school staff as well as technical staff. Finding gaps is the purpose of the exercise, so the plan should be updated afterward with whatever was missing.

Identification#

A breach can't be contained until someone notices it, and much of that noticing happens in logs, the records that systems keep of logins, connections, and other events. Particular patterns in logs serve as indicators of compromise, evidence that a system has been attacked. Repeated failed logins on an account suggest a password attack, and if a success follows the failures, the attack has probably worked. Small, regular outbound connections from a machine to the same outside server, each answered with a short confirmation reply, suggest beaconing, a compromised machine checking in with a command-and-control server that can send it instructions; this is the sign of an advanced persistent threat described in 0004.a. Activity at an unusual time, in an unusual volume, and to an unusual destination, such as a large transfer from a staff account to an unfamiliar server at 3 a.m., suggests that the account has been compromised and data is being stolen. Logs help only if someone or something is watching them, so automated alerts on unusual patterns bring these signs to attention as they occur. Attackers often try to cover their tracks by editing logs, so copying each entry to a separate, protected log server keeps evidence where a compromised machine can't change it.

Containment#

Once an incident is identified, the first goal is to keep it from spreading, and the first responder is often an ordinary user. When a device appears infected, the right steps are to disconnect it from the network to limit the spread, to avoid paying or interacting with the attacker, and to notify the IT department right away. A user who receives a ransom demand in a chat window should leave it unanswered and report it, so that IT staff can decide on the response with full information. Pop-ups claiming that a computer is infected and offering "help" by phone are often scams, a form of social engineering, so the user should close the page without calling and contact IT through its usual channel. For students, the rule is simpler: stop using the computer and tell a teacher or IT staff immediately, since prompt reporting lets staff contain the problem. Responders sometimes surprise users by keeping an infected machine powered on, though disconnected. Data held in memory may show what happened, and memory contents disappear at shutdown, so leaving the machine running preserves that evidence.

Stolen credentials call for their own containment, because the account itself has become the intruder's way in. After credentials are exposed, change the password promptly, and change it everywhere else it was reused, since stolen pairs are tried on other sites as they are. End active sessions too, because changing a password may not end a session the attacker already has open. Enable MFA, which makes a return harder. Check account settings, since an intruder may leave a rule that forwards mail to an outside address and keeps working after the password changes. And report the incident, even if nothing seems wrong, because stolen credentials may not be used right away and early notice lets IT check and act. Using a different password for every site is what keeps one breach from spreading in the first place.

Eradication and recovery#

Containment stops the spread, and eradication removes the threat itself, such as deleting the malware, closing the attacker's accounts, and fixing the flaw they used. The order matters: the threat must be removed before systems are restored, because restoring service before the cause has been removed leaves the same route open for the attacker to return.

Recovery then restores service and confirms that systems work normally, usually by restoring data from backups. The backup must be clean and tested, and it must have been made before the infection began, since a backup taken after the infection may bring the malware back. Offline backups are essential, because ransomware can reach and encrypt any copy that stays connected to the network, while an isolated copy is beyond its reach. When many systems are down, restoring the most critical services first limits the harm from the outage. How much recent work is lost depends on backup frequency: a grade system backed up nightly can lose up to a day of entries, so the remedy for that gap is running backups more often, since testing and off-site copies, though important, don't close it. Finally, a clean backup restores the flawed software along with the data, so recovery must include patching the original cause, or attackers can return through the flaw that remains.

Notification#

Responding to a breach isn't only a technical matter, because the people whose data was exposed have a stake in it, and the law often requires telling them. Organizations may be legally required to notify affected people and authorities after a breach. In New York, these laws include the SHIELD Act, which requires breach notice and reasonable data security for private information about state residents, and, for schools, Education Law 2-d, which protects student data. A school that suffers a breach of student data must follow the notification requirements of Education Law 2-d and related state law. Using a vendor doesn't remove a school's duties: if a vendor holding student data is breached, the school must still carry out its own notification and response duties while working with the vendor. The purpose of notice is practical, since it lets people take steps to protect themselves, such as watching their accounts or changing passwords. The details depend on the circumstances. Some laws treat properly encrypted data differently, so an organization that lost an encrypted laptop should review the facts with legal counsel instead of assuming it must, or need not, notify.

Lessons learned#

The final stage turns an incident into improvement. A post-incident review examines how the incident occurred and what should change as a result, then updates safeguards, policies, and training to keep it from happening again. A review should lead to specific changes. If a breach went unnoticed because intrusion alerts went to a mailbox nobody read, the fix is routing alerts to staff who are responsible for reviewing them. Blameless reviews, which focus on causes instead of on punishing individuals, make people more likely to give honest accounts of what happened, and honest accounts reveal the causes that need to change. And a review helps only if its findings are acted on, so its recommendations must be tracked through to completion. The lessons then feed back into preparation, the first stage, which is what makes incident response a cycle instead of a one-time event. Cybersecurity, like everything else in this guide, is also something you will teach, and how to teach computing content well is the subject of the next part.

• incident response plan: a plan covering preparation, identification, containment, eradication, recovery, and lessons learned, with roles assigned in advance
• data minimization: collecting only the data a service needs
• token: a stand-in value, such as one from a payment processor, stored in place of sensitive data
• tabletop exercise: a discussion-based walk-through of a simulated incident
• log: a record of system events such as logins and connections
• indicator of compromise: evidence that a system has been attacked
• beaconing: small, regular outbound connections from a compromised machine
• command-and-control server: a server that sends instructions to compromised machines
• offline backup: a backup copy disconnected from the network
• backup frequency: how often backups are made, which determines how much recent data can be lost
• SHIELD Act: New York law requiring breach notice and reasonable security for residents' private information
• Education Law 2-d: New York law protecting student data, including breach notification
• post-incident review: an examination of how an incident occurred and what should change
• blameless review: a review focused on causes instead of individual fault

Practice: practice questions for 0004.f