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

flowchart LR
  A["Account A alerts"] --> Chat["One chat channel"]
  B["Account B alerts"] --> Chat
  C["Account C alerts"] --> Chat

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 are Regional.

3. What Breaks

1. 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. CloudTrail also is not a threat detector; it is evidence of AWS API activity.

Step 2: delegate administration out of the management account

flowchart LR
  Management["Organizations management account<br/>designation only"] --> Security["Security tooling account<br/>delegated administrator"]
  Security --> Members["Member accounts"]

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

flowchart TD
  Security["Security account"] --> R1["Region A<br/>admin + members enabled"]
  Security --> R2["Region B<br/>admin + members enabled"]
  Security --> R3["Opt-in Region<br/>explicit decision"]

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.

Step 4: aggregate findings in Security Hub

flowchart LR
  GuardDuty["GuardDuty findings"] --> Hub["Security Hub<br/>central finding view"]
  Inspector["Inspector findings"] --> Hub
  Macie["Macie findings"] --> Hub
  Standards["Security control findings"] --> Hub
  Hub --> Home["Aggregation / home Region"]

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

flowchart LR
  Hub["New or updated finding"] --> Bus["EventBridge rule"]
  Bus -->|"Critical + production"| Incident["Page / incident workflow"]
  Bus -->|"Medium vulnerability"| Ticket["Owned remediation ticket"]
  Bus -->|"Low priority"| Queue["Review queue"]
  Bus -->|"Approved finding type"| Auto["Guarded automation"]

Filter on service, finding type, account, Region, severity, resource, workflow state, and ownership data. Use queues, retries, and dead-letter handling when losing a notification would matter.

Step 6: triage risk, not severity alone

Combine:

• finding confidence and severity;
• asset criticality and environment;
• internet exposure and exploitability;
• 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

flowchart LR
  Finding["Security finding"] --> Context["Account, owner, resource,<br/>changes, related findings"]
  Trail["Central CloudTrail"] --> Context
  Logs["VPC / workload / service logs"] --> Context
  Context --> Decision["False positive, remediate,<br/>contain, or escalate"]

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 and should require precise finding types, narrowly scoped roles, idempotency, approval where appropriate, and a reversal path.

Completed architecture

flowchart LR
  Accounts["Accounts + Regions"] --> Detectors["GuardDuty / Inspector / Macie"]
  Detectors --> Hub["Security Hub aggregation"]
  Hub --> Events["EventBridge filtering"]
  Events --> Response["Incident, ticket, queue,<br/>or guarded automation"]
  Evidence["CloudTrail + resource logs"] --> Response
  Owners["Account and application ownership"] --> Response

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, ticket APIs, or SIEM ingestion. 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

flowchart LR
  Detect["Detect"] --> Aggregate["Aggregate"]
  Aggregate --> Route["Route by risk + owner"]
  Route --> Investigate["Investigate evidence"]
  Investigate --> Respond["Contain + recover"]

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.