What's changed: Deepened SCS-C02 Chapter 1 (added comparison tables, scenarios, FAQs, exam traps, deep-dive paragraphs to each section; localized figures to Japanese)
1.2Aggregating Findings and Automated Response
Understand detection-to-response—Security Hub, EventBridge, auto-remediation (Lambda/SSM Automation), and isolation. Centralize findings and respond fast and mechanically.
After detection, connect to aggregation and response. Centralize in Security Hub and auto-remediate/isolate via EventBridge.
1.2.1Aggregation and automated response
- Security Hub: aggregate and score findings across services to visualize posture.
- EventBridge: react to findings to trigger Lambda/SSM Automation.
- Isolation: isolate a compromised instance via security-group swap or a quarantine VPC.
- Credential response: disable/rotate possibly leaked keys/credentials.
Common on SCS-C02: central aggregation = Security Hub, detect → EventBridge → Lambda/SSM Automation for response, isolate compromised instance = SG swap/quarantine VPC, leaked keys = disable AND rotate. A leaked key must be invalidated, not just removed from history.
SCS-C02 tests designing an automation pipeline that reliably connects detection to response. Security Hub normalizes and aggregates findings from GuardDuty, Inspector, Macie, Config, IAM Access Analyzer, etc. in ASFF (AWS Security Finding Format), computes a security score against CIS / AWS Foundational Security Best Practices / PCI DSS, and can raise severity or suppress via automation rules. Findings flow as EventBridge events, filtered by rules and routed to Lambda (custom logic), SSM Automation runbooks (routine response), or Step Functions (multi-step workflows). Typical automated responses: (1) isolate a suspect EC2 (swap to a deny-all security group, move to a quarantine VPC/subnet, detach from the ASG); (2) disable and rotate possibly leaked access keys/roles (a once-public credential must be invalidated); (3) make a public S3 private; (4) notify responders via SNS. Across an org, aggregate to the delegated administrator’s Security Hub to manage member findings centrally. Crucially, give automated responses idempotency and guardrails (severity thresholds, tag conditions, approval steps) to prevent runaway actions on false positives. The key is to aggregate in Security Hub → route by severity in EventBridge → isolate/disable/notify via Lambda/SSM, idempotently and safely.
| Role | Means | Key point |
|---|---|---|
| Aggregate/score findings | Security Hub (ASFF) | Compliance score; automation rules |
| Route findings | EventBridge | Filter by severity → target |
| Execute response | Lambda / SSM Automation | Isolate/disable/make-private/notify |
| Containment | SG swap / key disable | Idempotency + guardrails |
Scenario: GuardDuty detects "EC2 communicating with a crypto-mining C2." Contain it automatically. → Aggregate the finding in Security Hub, and route HIGH severity via an EventBridge rule to an SSM Automation runbook. The runbook isolates the EC2 by swapping to a deny-all SG, preserves evidence with an EBS snapshot, and notifies the SOC via SNS. If the instance role’s credentials may be leaked, disable and rotate them. Use an approval step to gate high-impact production actions.
FAQ: Is "delete immediately" the right response to a compromised instance? No. Immediate deletion loses evidence (memory/disk/logs), preventing root-cause analysis and prevention. The correct order is isolate (cut off comms to contain) → preserve evidence (EBS snapshots) → analyze (on isolated copies) → recover/rebuild if needed. If credentials are involved, disable and rotate them in parallel.
Exam trap: Treating a possibly leaked access key as "just remove it from history/code" is wrong—once exposed it is already leaked, so you must disable (rotate) it. Also, without idempotency or guardrails (thresholds/tags/approvals), automated responses may wrongly isolate/delete production resources on a false positive. Don’t forget to preserve evidence before containment.
1.2.2Section summary
- Aggregate = Security Hub / respond = EventBridge → Lambda/SSM
- Containment = instance isolation + credential disable/rotation
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. Aggregate security findings across accounts/services and score posture. What?
Q2. On a GuardDuty threat, auto-isolate a possibly compromised instance. What is the trigger source?
Q3. An access key may be leaked. What is the top-priority response?