Validating findings and scoping impact
Triaging GuardDuty, Security Hub, Macie and Inspector findings, telling true positives from expected activity, handling noise safely, and using Detective and log correlation to scope blast radius and root cause.
Exam tasks: 2.2.2 (search and correlate logs), 2.2.3 (validate findings to assess scope and impact), 2.2.5 (root cause analysis, for example with Detective)
The decision: is this finding real, how far could it and did it spread, and if it's expected, how do you quiet it without blinding yourself to the next real one?
The triage path
Questions to answer for every finding, in this order:
- Who is the actor? An IAM principal, an IP, a container, a process. Is it one of yours?
- What did it do, and did it succeed? A finding about denied calls is reconnaissance; successful calls are impact.
- Where: which account, Region, resource, and is that resource production and holding sensitive data (look at tags and Macie results)?
- When did it start? The first-seen time in the finding is when GuardDuty noticed, not necessarily when the attacker arrived.
- What else is related? Other findings on the same principal, IP or instance.
Reading each service's findings
| Service | What the finding tells you | Severity scale | How you validate it |
|---|---|---|---|
| GuardDuty | Threat behaviour: an actor did something suspicious to or from a resource | Low, Medium, High, and Critical for attack sequences | Check the actor IP and ASN, the principal's usual behaviour, CloudTrail for the named API calls, Flow Logs and DNS logs for the network ones |
| Inspector | A vulnerability exists (CVE, network exposure, code issue) | Inspector score: CVSS adjusted for network reachability and exploit availability | Is the package really installed and loaded? Is the port reachable? Is there a fix? |
| Macie | Sensitive data found in S3, or a bucket's policy weakened | Low, Medium, High | Open the sample occurrences, check the object's purpose and owner |
| Security Hub CSPM | A control failed, plus imported findings from the others in ASFF | Normalized labels (INFORMATIONAL to CRITICAL) | Check the resource's configuration and whether an exception is approved |
| Security Hub | Correlated exposure findings (misconfiguration + vulnerability + reachability) with an attack path graph, in OCSF | Critical to informational | Walk the attack path: which step can you break most cheaply? |
- A posture finding (Inspector, Security Hub control) says "this could happen". A threat finding (GuardDuty) says "this is happening". Threat findings go to the incident path; posture findings usually go to the vulnerability backlog.
- GuardDuty attack sequence findings already correlate several signals across data sources and time into one story, such as credential misuse followed by S3 exfiltration. Treat them as high-confidence starting points.
- Security Hub and AWS Security Incident Response both help with the correlation, but neither replaces knowing what the underlying finding means.
Exam signal
"Which finding should the team investigate first?" Prefer an active threat on a production resource holding sensitive data over a critical CVE on an unreachable test instance. Context changes priority more than the raw severity number does.
Handling noise without going blind
| Service | Mechanism | What it does |
|---|---|---|
| GuardDuty | Suppression rules | Auto-archive new findings that match filter criteria. Findings are still generated and exported, just archived |
| GuardDuty | Trusted IP lists | No findings for traffic to or from listed IPs, such as your own scanner |
| Security Hub CSPM | Automation rules (admin account, per Region) | Set workflow status to SUPPRESSED, change severity, add notes, as findings arrive |
| Security Hub CSPM | Disable a control | Stop checking something that doesn't apply at all |
| Macie | Allow lists, suppression rules | Ignore specific text or patterns (a test card number); auto-archive matching findings |
| Inspector | Suppression rules | Hide findings that match criteria from the default view |
- Make every rule narrow: a specific finding type and a specific resource, account, tag or IP. "Suppress all
Reconfindings" hides real attackers too. - Record the reason and an owner. Review rules on a schedule.
- GuardDuty Extended Threat Detection ignores archived findings when it builds attack sequences, so an over-broad suppression rule also weakens attack sequence detection.
Disable the detector to stop the noise
Answers that turn off GuardDuty, a Macie job or a Security Hub standard to deal with expected alerts are wrong. Suppress the specific expected pattern, and keep detection on.
Scoping with Amazon Detective
Detective builds a behavior graph from CloudTrail management events, VPC Flow Logs and GuardDuty findings, plus optional EKS audit logs and Security Hub findings, and keeps up to a year of history.
- Entity profiles for IAM users and roles, IPs, EC2 instances, S3 buckets, EKS clusters and pods: API volume over time, new geolocations, new user agents, resources accessed, compared with the entity's baseline.
- Finding groups gather related findings and entities into one view of a probable attack, across accounts.
- Detective investigations for an IAM user or role summarize indicators of compromise and map activity to MITRE ATT&CK tactics and techniques.
- Pivot straight from a GuardDuty or Security Hub finding with Investigate in Detective, and archive GuardDuty false positives from there.
- Detective only knows what happened after it was enabled, so enable it (with GuardDuty) before you need it, across the organization with a delegated administrator.
| Question | Tool |
|---|---|
| "Show me what this role did over the last 3 weeks compared with normal" | Detective |
| "Find every event from this IP across 70 accounts and 4 years" | Athena over the org trail, or CloudTrail Lake |
| "Correlate CloudTrail, Flow Logs, DNS and third-party logs in one schema" | Security Lake (OCSF) with Athena or a SIEM |
| "Which API calls did this access key make yesterday in this account?" | CloudTrail Event history |
Detective as a detector or a blocker
Detective doesn't raise new alerts on its own and doesn't contain anything. It helps you understand findings from GuardDuty and others. If a question asks what generated the finding or what stops the attack, it's not Detective.
Assessing blast radius
Scope is what happened. Blast radius is what could happen with the access the attacker has.
- Identity: what can the compromised principal do? Look at its policies, permissions boundary and the SCPs above it; test with the policy simulator; check which roles it can assume (trust policies naming it or its account). IAM Access Analyzer shows what's shared outside the account or organization.
- Data: which buckets, tables and keys can it reach, and do Macie results show sensitive data there? KMS key policies and grants decide whether it could actually decrypt.
- Network: from a compromised instance, what's reachable? Network Access Analyzer and Reachability Analyzer answer that without sending traffic (see Network segmentation and analysis).
- Accounts: does the principal exist or have trust in other accounts? Look for its access key IDs and session names across the organization's trail.
Root cause
- Work backwards from the first malicious event to the entry point: a leaked key (where was it stored?), an exploited CVE (Inspector finding on the host), an open security group, an over-broad trust policy.
- Build the timeline from logs you control and that the attacker couldn't edit: the org trail in the log archive account, Flow Logs, DNS query logs.
- The fix for the root cause becomes a preventive control: an SCP, a Config rule with remediation, a pipeline check. That's the lessons-learned step of the response plan.
Scenarios
A trusted IP list stops findings for those specific addresses and leaves detection on for everyone else. Suppressing the whole finding type would hide real scans. Disabling GuardDuty creates a blind window attackers could use. A day-based rule over all GuardDuty findings suppresses unrelated threats too.
Detective already has a year of CloudTrail and network data in its behavior graph and shows the role's activity against its baseline, with related IPs and resources. Athena works but means writing and tuning queries under time pressure. Inspector scans workloads for vulnerabilities, not roles. Macie would say what data is in the buckets, not what the role did.
The exposure is serious (reachable, exploitable, with a path to sensitive data) but there's no evidence of compromise yet, so fix the weakest link quickly and look for exploitation. Treating it as a confirmed incident jumps ahead of the evidence. The absence of a GuardDuty finding doesn't make a real vulnerability false, and posture findings with a clear attack path deserve high priority.
Further reading
Automated response
Wiring findings to action with EventBridge, Lambda, Step Functions and Systems Manager Automation, Security Hub automation rules and custom actions, Config remediation, and keeping automation safe with approvals and idempotency.
Compromised credentials
Responding to exposed access keys, stolen role and instance credentials, compromised Identity Center users and root credentials, tracing activity in CloudTrail, and handling AWS abuse reports.