Centralized Security Findings And Incident Triage

1. Situation

A company has fifty AWS accounts. GuardDuty reports suspicious credential use, Inspector reports vulnerable packages, and Macie reports sensitive data in S3. Findings appear in different accounts and Regions.

The security team does not need one more email inbox. It needs a path from signal to decision:

coverage -> finding -> prioritize -> route -> investigate -> contain -> recover

2. Naive Design

Tap to exploreOpen diagram

Every finding becomes an urgent notification. Responders become numb, duplicate work is opened, and nobody knows the affected application's owner.

Another mistake is enabling services in one Region and assuming global coverage. Many security services and their delegated-administrator relationships—the member account designated to manage that service centrally—are Regional.

3. What Breaks

1. In the alert-to-chat starting design above, a new account joins but is not enrolled in a Regional detector.
2. A high-severity finding arrives without an application owner.
3. Automation immediately quarantines a critical server based only on severity.
4. The business loses service, while responders still lack CloudTrail and workload context.
5. The finding is archived to quiet the dashboard without correcting its cause.

Aggregation reduces searching. It does not supply coverage, business context, or safe response automatically.

4. AWS Architecture

Step 1: separate service jobs

Security Hub does not replace the detector that produced a finding. Its security posture results report whether supported resources satisfy configured security controls; they are different from evidence that an attack occurred. CloudTrail also is not a threat detector; it records AWS API activity for investigation.

Tap to exploreOpen diagram

Step 2: delegate administration out of the management account

Use the same deliberate security account as delegated administrator for supported services where appropriate. This reduces daily use of the highly privileged management account.

Delegation is service-specific and often Regional. Configure organization auto-enable behavior for new and existing members as supported, then verify actual enrollment rather than assuming Organizations membership is enough.

Step 3: prove Regional coverage

Maintain an inventory of allowed Regions, accounts, detector status, optional protection plans, and newly created resources. An SCP restricting unused Regions can reduce the monitoring surface, but the organization still needs evidence that the restriction and exceptions work.

Tap to exploreOpen diagram

Step 4: aggregate findings in Security Hub

Tap to exploreOpen diagram

Security Hub ingests supported findings in a common format and supports cross-Region aggregation. Aggregation copies visibility to the chosen operational view; the underlying services still need to be enabled in the source accounts and Regions.

Step 5: route structured work with EventBridge

Tap to exploreOpen diagram

Filter on service, finding type, account, Region, severity, resource, workflow state, and ownership data. Use queues and retries when losing a notification would matter. A dead-letter queue (DLQ) keeps events that repeatedly fail delivery so operators can inspect and replay them instead of losing the work silently.

Step 6: triage risk, not severity alone

Combine:

• finding confidence and severity;
• asset criticality and environment—what business function fails if the resource is affected;
• internet exposure and exploitability—whether an attacker can reach and practically use the weakness;
• identity privilege;
• sensitive-data impact;
• corroborating findings; and
• business owner and current change activity.

A critical finding on an unused test resource and a medium finding on the payment control plane may require different priorities.

Step 7: investigate with preserved evidence

Tap to exploreOpen diagram

The finding is the lead. CloudTrail, configuration history, network evidence, application logs, and identity context establish what actually happened.

Step 8: automate only bounded actions

Safe early automation can enrich a ticket, tag a resource, preserve a snapshot, or revoke one known exposed credential. Quarantining networks, disabling accounts, or deleting resources can cause major outages. Such actions need precise finding types, narrowly scoped roles, approval where appropriate, a reversal path, and idempotency so replaying the same event does not repeat the destructive change.

Completed architecture

Tap to exploreOpen diagram

5. Request Or Data Flow

1. A detector observes threat behavior, vulnerability, or sensitive-data risk.
2. It produces a structured finding in the source account and Region.
3. Organization administration and Security Hub integrations expose the finding centrally.
4. Cross-Region aggregation makes it visible in the selected operational Region.
5. EventBridge matches an owned response rule.
6. The workflow creates durable work before optional enrichment or automation.
7. Responders correlate the finding with CloudTrail and workload evidence.
8. They contain, remediate, recover, document, and update the finding workflow state.

6. Security Controls

• protect the security tooling account and minimize management-account use;
• use least-privilege read, investigation, containment, and administration roles;
• separate finding viewing from destructive response authority;
• protect central evidence from workload administrators;
• alert on detector disablement and configuration changes; and
• require ownership metadata so findings reach accountable teams.

7. Resilience Controls

Audit account and Region enrollment continuously. Send important EventBridge targets through durable queues or incident systems with retries and dead-letter visibility. Test sample findings and delivery paths.

Preserve evidence before destructive containment where possible. Maintain a manual response path if automation, the ticket system, or identity integration fails.

8. Performance Controls

Filter before expensive enrichment. High finding volume can exhaust Lambda concurrency, the number of function invocations allowed to run at the same time, or overload ticket APIs and a security information and event management (SIEM) platform that correlates security signals. Queue nonurgent work and deduplicate repeated updates using stable finding identifiers.

Suppress only understood, documented noise with owner and expiry. Suppression reduces routing; it does not remove the underlying risk.

9. Cost Controls

Costs vary by protected resource, event or data volume, scan coverage, finding ingestion, log storage, enrichment compute, and external SIEM volume.

Tune optional protection plans, Macie discovery jobs, retention, and downstream routing from risk. Do not disable foundational detection blindly. Track the cost change when enabling a new Region or organization-wide feature.

10. Exam Variants

11. Common Traps

• Do not confuse a detector with an aggregator.
• Do not assume one Region covers every Region.
• Do not confuse aggregation with source-service enablement.
• Do not route every finding to the urgent channel.
• Do not prioritize from severity without asset context.
• Do not automate destructive containment without guardrails and reversal.
• Do not archive or suppress a finding as a substitute for remediation.
• Do not investigate without central evidence and ownership data.

Final Mental Model: One-Minute Review

Tap to exploreOpen diagram

Detectors create signals; Security Hub organizes them; EventBridge routes them; evidence and ownership turn them into safe action.

12. Related Topics

Review Amazon GuardDuty, AWS Security Hub, Amazon Inspector, Amazon Macie, AWS CloudTrail, and GuardDuty vs Inspector vs Macie vs Security Hub.

Official references: Managing GuardDuty with Organizations, Security Hub cross-Region aggregation, and GuardDuty findings with EventBridge.