Root cause analysis
Lesson 5 of 5 in Responding to Security Events.
The SCS-C03 exam guide names one service for root cause analysis: Amazon Detective. Learn what it is structurally, because that is what the questions test.
Detective continuously ingests CloudTrail management events, VPC Flow Logs, GuardDuty findings, and Amazon EKS audit logs — pulled from the services themselves, with no agent to deploy and no per-source configuration — and assembles them into a behaviour graph: entities (principals, roles, instances, IP addresses, findings, accounts) connected by what they did to each other, retained over a long window, up to about a year of history. On top of the graph it builds baselines: what this principal normally calls, from where, at what volume, at what hour. That is the thing raw logs cannot give you. A log query answers "did this happen?"; the graph answers "is this unusual for this principal, and what else is connected to it?"
Two practical consequences. First, Detective is a retrospective tool whose value depends on history, so it must be enabled before the incident — which is also why it requires GuardDuty to have been enabled for at least 48 hours before you can turn it on. Second, it is organizational: you enable it per Region with an administrator account (delegated through AWS Organizations) and member accounts feeding one behaviour graph, so a traversal can cross account boundaries the way an attacker does.
A five-layer stack describing Amazon Detective, read bottom-up. Layer one: the log sources, which must already be collecting — AWS CloudTrail management events, Amazon VPC Flow Logs, Amazon GuardDuty findings, and Amazon EKS audit logs. Layer two: continuous ingestion, performed by Detective pulling from those services directly, with no agent to install and no per-source configuration, which is why enabling it is quick but gives it no retrospective reach before the day it was switched on. Layer three, emphasized: the behaviour graph itself, in which entities such as IAM principals, role sessions, EC2 instances, IP addresses, findings and accounts are linked by their interactions and retained over a long window of up to roughly a year. Layer four: baselines and profiles computed on that graph — what is normal for this specific principal in terms of which APIs it calls, from where, at what volume and at what time of day. Layer five: the investigation surfaces built on all of it — finding groups that cluster related findings into one story, profile panels per entity, and relationship traversal that lets a responder walk from a finding to a principal to every resource that principal touched, across accounts.
Two playbooks carry most of the exam’s root-cause scenarios, and they are worth knowing as sequences rather than facts. Watch the first one play out across the services.
Playbook — compromised long-term access key, as a step list
1. Validate. Confirm from CloudTrail that the key made calls from an unexpected source address or made APIs it has never made. 2. Scope. Every call by that key in the window; every resource reached; every principal created or modified; does the source address appear elsewhere. 3. Preserve. Copy the CloudTrail window and the Detective findings into the evidence store with the queries used. 4. Contain. UpdateAccessKey to Inactive (not delete — keep the record), then disable the IAM user, then remove any access key, user, or role the attacker created. 5. Assess exposure. Treat everything the key could reach as exposed, not only what it demonstrably read. 6. Rotate. Every secret the key could fetch, every database credential, every dependent API key. 7. Eradicate persistence. Check for new identity providers, modified trust policies, new Lambda functions and EventBridge rules. 8. Prevent. Replace the long-term key with roles, IAM Roles Anywhere, or Identity Center; add detection for new access key creation; and if the key leaked through a repository, add secret scanning to the pipeline.
Playbook — crypto-mining on EC2, as a step list
1. Validate. A GuardDuty finding such as CryptoCurrency:EC2/BitcoinTool.B!DNS plus corroboration: sustained CPU, outbound connections to a mining pool in VPC Flow Logs, an unfamiliar process. 2. Scope. Which other instances show the same traffic, and does the instance profile’s session appear doing anything else — mining is often the visible symptom of a broader compromise. 3. Contain. Isolation security group; detach the instance profile; revoke the role’s sessions by issue time if credentials may have left. 4. Capture. Memory first, then snapshots of every volume, into the forensics account. 5. Find the way in. Nearly always one of: an unpatched internet-facing service, exposed management ports, a compromised container image, leaked credentials, or a vulnerable application dependency — cross-check Inspector findings for the instance and the Config timeline for a recent security group change. 6. Eradicate and rebuild. New instance from a hardened AMI with the vulnerability patched; never clean in place. 7. Prevent. Patch management, require IMDSv2, close the ingress, add egress filtering or DNS Firewall against mining pools, and set a cost anomaly alarm — the bill is often the second detector.
What Detective answers that a log query does not
"Is this unusual for this principal?" — the baseline is precomputed over months, so you are not eyeballing a histogram under pressure. "What else is connected?" — traversal from finding to principal to resource to IP to other accounts, without writing joins. "When did this start?" — the first deviation from baseline, which is the timestamp your recovery point depends on. "Are these findings one story?" — finding groups cluster related findings so five alerts become one incident with a shape. The trade: Detective is for investigation, not for precise citable queries. When the report needs "at 14:03:22 UTC, principal X called Y from Z, request id R", that is CloudTrail Lake or Athena. Use the graph to scope and the logs to prove.
Detective’s prerequisites and multi-account model
Enabled per Region, with an administrator account — set up as a delegated administrator through AWS Organizations — and member accounts whose data joins one behaviour graph, so a traversal crosses account boundaries. GuardDuty must have been enabled for at least 48 hours before you can enable Detective, because the graph is built from data that already exists. The consequence for an exam scenario: Detective cannot answer questions about a period before it was enabled, which makes it part of the incident-response plan you write in advance, not a tool you reach for once an investigation has started. Put it in the same security-tooling bundle as organization CloudTrail, GuardDuty and Security Hub, enabled everywhere by default.
Key terms: Amazon Detective, Behaviour graph, Finding validation
Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.