Aggregating Findings With Security Hub

The situation

An org has grown organically to the point where security findings land in five different places:

• GuardDuty, threat detection, firing ~30 findings/day across the estate.
• Inspector, vulnerability findings on EC2, containers, and Lambda; backlog of ~4,800 from an earlier cleanup.
• Macie, sensitive-data discovery, running weekly jobs on compliance-scoped buckets.
• IAM Access Analyzer, external-access findings on S3 buckets, IAM roles, KMS keys.
• Config rules, compliance-style findings for rule failures across 85 rules.

Every service has its own console, its own JSON shape, its own severity model. The security team has a rota and a shared Slack channel; half the findings they actually care about are slipping through because nobody has a complete picture. They want:

• One place to see every finding from every service.
• A normalised severity model so a CRITICAL in Inspector means the same thing as a HIGH in GuardDuty.
• Automated suppression of known-false-positives so the queue isn’t 90% noise.
• Tag-based routing to product teams who own the affected resources.
• Compliance scoring against a recognised framework (CIS AWS Foundations, NIST 800-53, PCI DSS 3.2.1, AWS Foundational Security Best Practices).

One service does all of this: AWS Security Hub.

What actually matters

A finding aggregator is solving an information-architecture problem. The security team’s job is not “find more things”. AWS and the third-party scanners are finding plenty, it’s “triage, route, and close the things that were found.” That means the team needs a single queue with a normalised schema, persistence across scanners, and hooks into the team’s existing ticketing and automation.

The first thing such an aggregator needs is a normalised format. Every source writes to it in one schema, regardless of what they wrote natively. Without that, “CRITICAL” and “9” and “Severity: High” all mean different things and the queue is a mess.

The second is aggregation scope. Findings arrive per-account, per-Region. A useful aggregator collects across every Region and, in an Organizations setting, every member account, so the security team has a single view of the entire org from one place.

The third is standards and controls. Auditors care about recognised frameworks. The aggregator should ship with curated control sets, evaluated continuously, emitting findings on failure, so compliance score becomes a top-level number the team can compare against the framework an auditor names.

The fourth is workflow state. A finding isn’t just “seen/unseen”; it needs status transitions (new, notified, resolved, suppressed) so the team can manage the queue and findings that don’t move get noticed.

The fifth is automation. Findings have to fire events so downstream pipelines can react. The aggregator itself should also be able to transform findings based on match patterns, auto-suppress known false positives, auto-escalate high-severity on sensitive accounts, without the team running a Lambda for every rule.

What we’ll filter on

1. Source coverage, which services feed it natively?
2. Aggregation scope, single account, Region, or org-wide?
3. Normalised severity, does a 70 mean the same thing everywhere?
4. Compliance standards, can we score against CIS / PCI / NIST / AFSBP?
5. Routing hooks. EventBridge, SSM Automation, third-party ticketing?

The aggregator landscape

1. AWS Security Hub. Managed aggregator for AWS-native and partner findings. Ingests from GuardDuty, Inspector, Macie, IAM Access Analyzer, Config, Firewall Manager, Systems Manager Patch Manager, Health, and dozens of third parties via BatchImportFindings. Standards: CIS AWS Foundations Benchmark (v1.4 and v3.0), PCI DSS 3.2.1 and 4.0.1, NIST 800-53 Rev 5, AWS Foundational Security Best Practices, ServiceNow SecOps ↔ Hub. Priced on finding ingestion volume plus per-control evaluation in enabled standards.

2. Third-party SIEM (Splunk, Sumo, Elastic, Datadog). Cross-cloud, cross-source, custom correlation rules. Ingest cost scales with log volume; licence cost per-user or per-ingest-GB. Strong for organisations with non-AWS workloads to correlate against. Often a sink from Security Hub rather than a replacement for it.

3. DIY aggregation on Athena/Glue. Send every source’s findings to S3, stand up Glue tables, query with Athena. Works; maintenance burden is real, no normalised schema out of the box, no compliance standards.

4. ServiceNow Security Operations / Jira Service Management. Ticketing systems with security-specific modules. They consume findings (typically from Security Hub) and present them as tickets with SLAs and workflow. The ticketing system and the aggregator are complementary, not alternatives.

5. Cloud security posture management (CSPM) tools. Wiz, Orca, Prisma Cloud. Third-party scanners that both detect and aggregate. Priced per-workload. Stronger at cross-account, cross-cloud posture visualisation; overlap significantly with the AWS-native stack. Usually deployed alongside rather than replacing Hub.

Side by side

Option	Source coverage	Scope	Normalised severity	Standards	Routing
Security Hub	AWS + partner (BatchImportFindings)	Org-wide via delegated admin	ASFF 0-100	CIS, PCI, NIST, AFSBP	EventBridge, SSM, custom
SIEM	Anything you pipe in	Cross-cloud	Custom schema	Custom	SIEM workflows
DIY Athena	Whatever’s in S3	Per-table	None	None	DIY
ServiceNow / Jira	Via upstream aggregator	Ticketing	Custom	Custom	Ticketing workflow
CSPM (Wiz etc.)	Scans directly	Cross-cloud	Vendor-defined	Vendor-mapped	Vendor integrations

Reading the table: Security Hub is the AWS-native answer for the aggregation layer, and the other options are either adjacent (ticketing, SIEM) or alternative (CSPM) rather than like-for-like replacements. For an AWS-heavy estate, Hub is the default; for cross-cloud, Hub plus a CSPM or SIEM is the common shape.

The Security Hub ingestion graph

The picks in depth

Enable Security Hub from a delegated admin, aggregated to one Region. From the Organizations management account, designate a security-audit account as the Security Hub delegated administrator. Enable Hub in that account in every active Region. Pick one Region as the aggregation Region (usually us-east-1 or the team’s home Region) and link every other Region to it, this is the UpdateFindingAggregator call. From that point, the delegated admin’s aggregation Region shows every finding from every Region in every account. Auto-enable new accounts when they join the org via the Hub configuration policy.

Pick the right standards. The defaults include CIS and AFSBP, which is usually a good floor. For PCI-scoped accounts enable PCI DSS 4.0.1; for US federal-facing workloads, NIST 800-53 Rev 5. Don’t enable every standard on every account, controls overlap significantly between frameworks, which bloats the evaluation cost and doubles up findings. Scope PCI to only the PCI accounts, NIST to only the compliance-scoped ones. AFSBP is the sane default for everything else. Per-control overrides within a standard let you disable controls that aren’t applicable to the environment (e.g. EC2-specific controls in a Lambda-only account).

Write automation rules for the noise floor. Two common patterns. Pattern one: auto-suppress INFORMATIONAL-severity findings on specific resource types (say, Config findings for untagged development resources that aren’t worth a real ticket). Rule condition: Severity.Label = INFORMATIONAL AND Resources.Type = AwsEc2Instance AND Tags.Environment = development. Action: set Workflow.Status = SUPPRESSED. Pattern two: auto-escalate CRITICAL findings in PCI accounts to Slack and Jira. Rule condition: Severity.Label = CRITICAL AND AwsAccountId IN [pci-account-list]. Action: note field to "escalate=true"; EventBridge downstream rule matches on the note and pages.

Route by resource tag. Inspector, GuardDuty, and Config findings preserve the resource’s tags on the ASFF finding. An EventBridge rule on detail.findings[0].Resources[0].Tags.Team dispatches to per-team Jira queues via a Lambda. The Lambda extracts the team, maps it to a Jira project, creates a ticket with the finding URL and key metadata, and writes the ticket ID back into the finding’s UserDefinedFields. On finding close the same rule transitions the ticket to Done. Two components: a tag discipline (every resource has a Team= tag) and a small dispatcher Lambda.

A worked automation rule

An organisation decides that HIGH-severity GuardDuty findings on non-production accounts should auto-resolve after 7 days if no activity. In Hub, create an automation rule:

• Criteria: ProductName = GuardDuty AND Severity.Label = HIGH AND Tags.Environment != production AND CreatedAt < now() - 7 days AND Workflow.Status = NEW
• Actions: set Workflow.Status = RESOLVED, add note “Auto-resolved: no activity in 7 days on non-production resource.”

The rule runs on every finding update. For an active finding in production, the rule’s Tags.Environment condition filters it out and nothing happens. For a stale non-production finding it fires, the finding transitions to RESOLVED, the downstream EventBridge pipeline updates the Jira ticket to Done, and nobody opened the finding twice.

A worked compliance report

An auditor asks “show me the CIS AWS Foundations Benchmark v3 compliance score across the organisation.” In the delegated admin account, aggregation Region, navigate to Security Standards → CIS AWS Foundations Benchmark v3.0.0. The score appears as a single percentage (say, 87%). Failed controls are listed with counts of affected resources across the org.

Click a failed control (e.g. CIS 3.1 “Ensure CloudTrail is enabled in all Regions”). The control’s page lists every resource currently failing, grouped by account. Link out from a failing resource to the Hub finding, which has the ASFF-formatted full context (resource ARN, failure reason, remediation steps in the control’s standard text).

Export: aws securityhub get-findings --filters '{"ComplianceSecurityControlId":[{"Value":"CIS.3.1","Comparison":"EQUALS"}]}' --output json. Produces the full list for the auditor in their preferred format. Total time from request to artifact: ten minutes.

What’s worth remembering

1. Security Hub is the aggregator, not a detector. It ingests findings from GuardDuty, Inspector, Macie, IAM Access Analyzer, Config, Firewall Manager, and partners, and presents them in one ASFF-normalised queue.
2. Enable via delegated administrator for org-wide scope. One aggregation Region in one admin account collects findings from every Region in every account.
3. ASFF is the finding format. Native AWS services produce it automatically; partners integrate via BatchImportFindings. Severity is normalised to 0-100.
4. Security standards are curated control sets with compliance scoring. CIS AWS Foundations, AFSBP, PCI DSS, NIST 800-53. Per-standard and per-control enable/disable avoids double-counting.
5. Workflow.Status (NEW, NOTIFIED, RESOLVED, SUPPRESSED) is how the team manages the queue. Findings that don’t move go stale; automation rules transition status to keep the queue clean.
6. Automation rules are the in-Hub noise filter. Match on ASFF fields, transform status/severity/notes, run on every finding update.
7. Routing out is via EventBridge. Hub publishes every finding state change as an event; downstream rules dispatch to Lambda, SNS, Step Functions, SSM Automation, Jira integrations.
8. Tag-based ownership is the cheap routing key. Resource tags propagate onto findings; dispatchers read them to decide which team owns the ticket.

One place, one format, one queue. The work is mostly about keeping the queue honest, standards scoped to what applies, automation rules filtering the noise, tag-based routing so findings become tickets on the right project, and workflow state moving as the team acts on them.