A Finding Is A Lead, Not A Finished Incident
Security services in many accounts and Regions produce different signals. Sending every finding to one urgent chat channel creates duplicates, missing owners, alert fatigue, and unsafe reactions based on severity alone.
The architecture needs a pipeline: cover → detect → aggregate → route → investigate → contain → recover. Finding security problems and operating the response are separate jobs.
Give Each Service One Exact Job
- Amazon GuardDuty creates findings about suspicious threat behavior from supported AWS signals.
- Amazon Inspector creates supported workload vulnerability and exposure findings.
- Amazon Macie creates findings about sensitive-data and data-security risk in S3.
- AWS Security Hub ingests supported findings, normalizes them into a common format, aggregates visibility, maintains workflow state, and reports supported security-posture controls. It does not perform every source detection.
- Amazon EventBridge matches new or updated finding events and routes them to the appropriate incident page, ticket, queue, notification, or tightly guarded automation. It creates no finding itself.
- CloudTrail, configuration history, network logs, and workload logs provide investigation evidence. A finding directs attention; evidence establishes what happened.
Move From Regional Signal To Owned Action
- The Organizations management account designates a security tooling account as delegated administrator for supported services. Delegation centralizes administration; it does not enable every detector everywhere.
- Verify enrollment for each required account × Region × service or plan. A detector disabled in a source Region creates no finding for the central view to discover.
- Source services create structured findings in their Regions. Security Hub integrations ingest and normalize supported findings there.
- Security Hub cross-Region aggregation copies finding visibility to an aggregation Region. It does not manufacture missing source coverage and does not remediate the finding.
- EventBridge matches available or enriched fields such as product, finding type, account, Region, resource, workflow state, owner, and risk. High-confidence production threats can page an incident responder; owned vulnerabilities can become tickets; lower-risk work can enter an SQS review queue. Retries and a dead-letter queue keep delivery failures visible.
- The responder combines severity with confidence, exploitability, exposure, privilege, resource criticality, sensitive-data impact, ownership, current changes, and related findings. Severity is an input, not the decision.
- Preserved evidence turns the lead into a defensible incident story. Only then should the team contain, remediate, recover, and update finding state and preventive controls.
Keep Automation Inside A Safe Boundary
Automatic action is appropriate only for a precise, well-understood finding type with a narrow role, bounded scope, idempotency, visible results, and a documented reversal. High-impact containment should require approval where uncertainty or business impact is material.
For example, revoking one confirmed compromised session can be bounded. Quarantining every high-severity EC2 finding could detach a critical production dependency before evidence is reviewed. After containment, remediation fixes the cause and recovery restores service; those are distinct states.
Read deeper into guarded response automationSAA Recognition And Traps
- “Threat detection for suspicious AWS activity” points to GuardDuty; “supported vulnerability and exposure assessment” points to Inspector; “discover sensitive data in S3” points to Macie.
- “Centralize and normalize supported findings and security posture across accounts” points to Security Hub because it is the aggregation and workflow layer, not the universal detector.
- “Route different finding types to pages, tickets, queues, or automation” points to EventBridge because rules match structured events and select targets.
- “Find who made the API change during an investigation” points to CloudTrail evidence, not Security Hub workflow metadata.
- Do not assume delegated administration proves source-service coverage in every account and Region.
- Do not assume cross-Region aggregation can copy a finding that no enabled detector created.
- Do not prioritize or automate from severity alone, suppress a finding without owner and expiry, or close workflow state before reality is resolved.
One-Minute Review
verify account x Region detector coverage
-> GuardDuty / Inspector / Macie create specialized findings
-> Security Hub normalizes and aggregates supported findings
-> EventBridge routes by risk and owner into durable work
-> responders correlate the lead with ownership and evidence
-> contain narrowly, remediate the cause, recover service
-> update workflow state and improve prevention
If you remember only one thing: detectors create signals; Security Hub organizes them; EventBridge routes them; evidence and ownership make the response safe.