Incident Response and Risk Management

Why this matters

Systems get attacked even when they are well defended. What separates a bad day from a disaster is whether the response is ordered or improvised. Doing the right things in the wrong order is one of the most common ways an incident gets worse, and it is easily avoided.

The idea

A security incident is a situation where real damage happens from a security problem. The usual shapes: information leaked, data tampered with, or a service knocked offline.

Response runs through six stages, in order:

The order carries real weight. Containment comes before eradication because while you are working out how to remove the malware, it is still spreading; pulling the machine off the network costs nothing and buys you the time. Recovery comes after eradication because restoring a service while the cause is still present just reproduces the incident. And skipping stage 6 is how the same breach happens twice.

Deciding what to defend before anything happens is risk assessment. A risk's size comes from two things multiplied:

Risk size = Impact x Likelihood

Impact is how bad it would be; likelihood is how probable it is. Either alone is misleading: a catastrophic event that essentially never happens and a trivial one that happens daily can both be low priority, for opposite reasons. Things that score high on both get fixed first, because no team can address everything at once.

Picture it

flowchart LR
  P[1 Preparation] --> D[2 Detection]
  D --> C[3 Containment]
  C --> E[4 Eradication]
  E --> R[5 Recovery]
  R --> V[6 Prevention of recurrence]
  V -.->|feeds back into| P

Worked example

A staff laptop is found to be infected with malware.

Detection has happened. The tempting next move is to start cleaning the laptop, and it is the wrong one: while you work, the malware is talking to the rest of the network. Containment first, so unplug it, take it off the wireless, and check whether anything else is showing the same signs.

Now eradication: remove the malware and work out how it arrived. Only then recovery, restoring a clean system from backup. If you had gone straight from detection to recovery, you would have reimaged a machine that got infected through a route still wide open, and it would be back within the week.

Finally prevention of recurrence. If it arrived through an email attachment, the answer is some mix of filtering, training and blocking that file type. That analysis is also what feeds preparation for next time, which is why the six stages are really a loop.

Your turn

Try the practice questions for this lesson. Judge statements about incident response and risk, match each action to the stage it belongs to, and work out what determines the size of a risk.

Take it further

A school's student-records system is hit by ransomware. Files are encrypted and staff cannot log in. Should the school restore from backup immediately, or work through the six stages in order?

1. Respond from here. The incident has just been detected. List the stages still to carry out and say what each means for this specific incident.
2. Assess the risks. For another ransomware attack and for a brief power cut, estimate impact and likelihood, and say which to address first.
3. Decide. Recommend the first three actions, and give one reason why the order matters.

Restoring before eradicating puts a clean system back on a network where the cause is still present.

Recap

• The six stages in order: preparation, detection, containment, eradication, recovery, prevention of recurrence.
• Contain before you eradicate; eradicate before you recover.
• Risk size = impact x likelihood, and both matter.
• Address high-impact, high-likelihood risks first, because nothing can be fixed all at once.