Objective 3.2 · Lesson 2 of 2

Restore service without restoring the intrusion

Stopping visible activity is only one milestone. Safe recovery requires removal of the cause, validation of the rebuilt service, and a deliberate decision about when normal access can resume.

Containment limits damage

Containment reduces the opportunity for continuing harm while responders establish the full scope. Options include isolating endpoints, restricting network paths, disabling affected accounts, revoking sessions, or quarantining messages. Choose controls that address the observed access path. Isolating a laptop does not necessarily stop an attacker who already holds a valid cloud session or a separate service credential.

Assess the operational consequences before a disruptive action, using the authority established in the response plan. Preserve useful evidence where practical, but do not allow ongoing serious harm merely to pursue an ideal collection sequence. Document what was changed, why, who authorised it, and how the team will verify the containment. A successful command response is not the same as proof that access ended.

Eradication removes the cause and foothold

Eradication addresses malicious artifacts and the conditions that allowed the intrusion to persist. The work may include rebuilding an affected host, correcting a configuration, removing unauthorised access, and rotating exposed secrets. Scope matters: cleaning one endpoint while leaving a compromised deployment account active can reintroduce the same problem. Use the investigation findings to identify related systems that need the same corrective work.

Recovery returns services through an agreed sequence of checks. A backup should be assessed for integrity and suitability, and the restored system needs the relevant fixes before normal exposure resumes. Test both security and business behaviour. Define rollback conditions, monitoring, ownership, and the approval required to release isolation. A clean malware scan is useful evidence, but it is not a complete recovery decision.

Post-incident work changes the next response

Post-incident review explains what enabled the event, how it was detected, and where response decisions succeeded or stalled. Root cause analysis asks how a condition developed, rather than stopping at the first human mistake or malicious file. Distinguish the triggering action from contributing control weaknesses. A retained administrator account might connect to an incomplete offboarding process and an absent ownership review.

Turn findings into corrective actions with an accountable owner, priority, due date, and validation method. Improvements can involve logging, access design, supplier coordination, detection logic, or a clearer playbook. Feed verified changes back into preparation and rehearse them where useful. Closing the incident record should preserve open improvement commitments instead of making them disappear with the restoration of service.

Keep these points in mind

  • Contain the access path, including sessions and identities beyond the initial device.
  • Require security and service validation before release from isolation.
  • Give every corrective action an owner and a method for proving completion.

Pause and practise

An isolated workstation has been rebuilt, but its exposed account still has active cloud sessions. The owner requests immediate reconnection. What remains before release?

Show a worked response

Address the affected identity as well as the rebuilt device: revoke relevant sessions, reset or rotate exposed credentials, and review access changes according to the response plan. Verify the rebuilt host, confirm the original weakness is corrected, and obtain the required release approval with enhanced monitoring. Reconnection alone would leave a separate access path unresolved.

← Previous lesson