Memory hook: Prepare, detect, contain, preserve evidence, eradicate, recover and learn.
Must remember
- Define owners, severity, escalation, communication and legal/evidence requirements before an incident. Pre-authorise scoped response roles, prepare a forensic account and test runbooks through simulations. Isolation should contain the threat without needlessly destroying evidence.
- An organisation trail centralises supported CloudTrail activity. Select needed data events explicitly; management events alone do not record every object access. Protect log storage with restrictive policies, encryption, retention and integrity validation appropriate to the evidence requirement.
- GuardDuty, Inspector, Macie and Security Hub findings answer different questions. Route findings through EventBridge to a deduplicated workflow. Tune severity and suppression carefully; a finding is a lead requiring context, not automatic proof of compromise.
- For suspected credential theft, identify the affected principal and sessions, scope exposure, revoke/contain access using supported mechanisms, rotate compromised secrets and investigate persistence. Deleting one access key does not necessarily invalidate every previously issued temporary session.
- For compute compromise, isolate network access using prepared controls, preserve relevant disk snapshots/logs and collect volatile evidence when required. Terminating immediately can lose memory and local data. Use dedicated forensic tooling and documented chain of custody; do not run arbitrary suspect binaries.
- Validate containment against existing connections, not only new ones. Security-group connection tracking can allow tracked flows to continue after rule changes; a replacement restrictive group alone is not universal proof that a compromised host has lost every active path. Select documented network/session controls appropriate to the incident while preserving the access needed for evidence collection.
- For exposed data, contain access, determine affected objects/versions and callers, inspect encryption and key use, and preserve the access evidence. Recovery needs a clean trusted baseline and validation that the attacker's persistence is gone.
- Troubleshoot missing detections by checking event scope, Region, organisation membership, service enablement, delivery permissions, KMS policy, retention and event-rule filters. A disabled log pipeline can look deceptively quiet. Monitor the monitoring system.
Choose under exam pressure
| Requirement | Choice and reason |
|---|---|
| Suspected compromised EC2 with valuable evidence | Isolate and preserve before destructive remediation. |
| No S3 object API records in a trail | Check data-event selection and delivery, not only management logging. |
| Same finding repeatedly triggers remediation | Use durable deduplication/idempotency and state checks. |
Traps
- Rotation alone may not invalidate previously issued sessions.
- An empty dashboard can mean broken telemetry.
- Automated containment can disrupt evidence collection unless planned.
Active recall
1. Why practise incident response before an incident?
To validate access, runbooks, communication and recovery under controlled conditions.
2. What is lost by terminating a compromised instance immediately?
Potential volatile evidence and instance-local data, depending on the resource.
3. Why protect the security-log KMS key separately?
An attacker who can disable or misuse it may affect log confidentiality or availability.
4. Which service finds sensitive S3 data rather than general threat activity?
Macie.
5. What completes an incident after recovery?
Validate clean operation, document lessons, address root causes and test preventive improvements.