Security Incident Response
Responding to a compromise — where the architecture determines whether you can detect it, contain it, and prove what happened.
Definition
Security incident response differs from operational incident response in three ways: an adversary is present and may react, evidence must be preserved, and legal and regulatory obligations attach, often with a clock measured in hours.
The phases and their architectural prerequisites
Detect. You cannot respond to what you cannot see. Requires centralised, tamper-resistant logging; alerting on authentication anomalies, privilege escalation and unusual egress; and — most valuable — egress monitoring, because exfiltration is what turns an intrusion into a breach.
Contain. The ability to revoke credentials, isolate a workload, or block a network path within minutes. This is where architecture is decisive: an estate with short-lived credentials, workload identity and network segmentation can contain in minutes; one with long-lived shared credentials and a flat network cannot contain at all without taking everything down.
Preserve evidence before remediating. The instinct is to restart the compromised instance. That destroys memory, process state and attacker artefacts, and it may make the incident unattributable — which matters for both the investigation and the regulatory position. Snapshot first, then remediate.
Eradicate and recover. Which requires knowing what the attacker touched, which requires logs with sufficient retention. Recovery to a known-good state requires immutable infrastructure — rebuilding from source rather than cleaning a host.
Notify. Many regimes require notification within 72 hours of becoming aware. Determining scope quickly is therefore a legal requirement, not just good practice, and it depends entirely on the quality of the logging that already existed.
What the architecture must provide in advance
- Immutable, centralised logs in an account or system the compromised environment cannot write to. An attacker's first action is often to delete logs.
- Short-lived credentials, so revocation is fast and the blast radius of a leak is bounded.
- Segmentation, so containment does not mean shutting down the business.
- Egress control, both to prevent exfiltration and to detect it.
- Immutable infrastructure, so recovery is a rebuild rather than a clean-up of unknown completeness.
- An inventory, so "which systems held this data" has an answer.
Failure scenarios
- Logs deleted by the attacker, because they were writable from the compromised environment.
- Instance restarted before evidence capture.
- No way to revoke a credential without an outage, so containment is delayed.
- Retention too short to determine when the intrusion began — so you must assume the worst.
- Backups compromised too, because they were reachable with the same credentials.
Interview question
"You discover an attacker has valid credentials in your environment. What are your first three actions and what must already exist for them to be possible?"