3.2.3. Validating and Assessing Security Findings
First Principle: Not every security finding represents a real threat. Validating findings — confirming they're genuine and assessing their scope and impact — prevents both under-reaction (ignoring real threats) and over-reaction (disrupting operations for false positives).
Finding Validation Process:
- Confirm the finding is genuine — Is this a real threat or a known behavior? (e.g., a penetration test triggering GuardDuty)
- Assess severity — What's the potential impact? (data exposure, credential compromise, service disruption)
- Determine scope — How many accounts, resources, and data stores are affected?
- Evaluate blast radius — What could the attacker access from the compromised resource?
AWS Tools for Finding Validation:
- GuardDuty provides confidence levels and evidence details for each finding type
- Security Hub normalizes findings from multiple services, enabling cross-service validation
- Amazon Detective automatically correlates findings with underlying log data, showing relationships between resources, IP addresses, and identities involved in a finding
- IAM Access Analyzer validates whether identified permissions are actually exploitable
Scope Assessment Questions:
| Question | How to Answer |
|---|---|
| How long has the attacker had access? | CloudTrail: earliest API call with the compromised credential |
| What resources were accessed? | CloudTrail: all API calls filtered by the compromised identity |
| Was data exfiltrated? | CloudTrail data events + VPC Flow Logs (outbound data transfer) |
| Did the attacker establish persistence? | CloudTrail: look for CreateUser, CreateAccessKey, CreateRole |
| Are other accounts affected? | CloudTrail across all organization accounts via organization trail |
⚠️ Exam Trap: GuardDuty findings have severity levels but don't assess blast radius. Amazon Detective builds investigation graphs that show relationships between entities. If a question asks about "understanding the scope and impact" of a finding, Detective is likely the answer.
Scenario: GuardDuty generates a Medium-severity finding for unusual S3 API calls. Before escalating, you use Detective to visualize the finding's context: the API calls were made by a CI/CD pipeline role during a scheduled deployment. You suppress the finding and create a suppression rule for this known pattern.
Reflection Question: Why is finding validation essential before triggering remediation, and what's the cost of automated remediation without validation?
