Logging, Monitoring, Detection, and Incident Response
Domain 6: Logging, Monitoring, Detection, and Incident Response
This domain tests whether you can collect trustworthy telemetry, detect meaningful events, and run a defensible incident response. Expect log sources, retention, integrity, detection tuning, and cloud forensics.
Core rules
- Centralize logs in a dedicated security account or log archive; restrict write and delete permissions; enable object lock or immutable storage where required.
- Know the difference between control-plane logs (CloudTrail management events, Azure Activity Log) and data-plane logs (S3 data events, blob read/write). Data events are often extra cost but critical for investigations.
- Detection needs tuned rules and context: identity, asset criticality, threat intelligence, and baseline behavior.
- Incident response phases: prepare, identify, contain, eradicate, recover, lessons learned. In cloud, containment often means revoking credentials, isolating a security group, or disabling a key, not unplugging a server.
- Preserve evidence before remediation: snapshots, memory if possible, logs, and chain of custody.
Worked example
GuardDuty reports cryptocurrency mining on an EC2 instance. The responder confirms the finding, isolates the instance with a quarantine security group, snapshots the volume, captures metadata and CloudTrail events, rotates any instance-profile credentials, and only then terminates. Reasoning: immediate termination destroys volatile evidence and may hide persistence. The quarantine group blocks egress while allowing forensic access.
Traps
- Enabling only management events and assuming you can investigate data access.
- Storing logs only in the compromised account.
- Deleting the instance before snapshotting.
- Ignoring time synchronization and log time zones during timeline reconstruction.
- Treating detection as prevention.