How does AWS Security Hub aggregate findings across a multi-account, multi-Region AWS Organization, and what has to be enabled before its standards controls evaluate anything?
answer
- one admin account, one Region to look at
- findings share a schema, not a source
- the controls borrow another service's engine
- enabled per Region, aggregated after
- suppress at ingestion, not in your head
basics
~20 sSecurity Hub uses an Organizations delegated administrator with member accounts auto-enabled, plus a designated aggregation Region that collects findings from linked Regions. Its standards controls are largely evaluated through AWS Config, so Config recording must be on.
solid answer
~50 sYou designate a **delegated administrator** account in AWS Organizations — normally a dedicated security account, not the management account — and auto-enable Security Hub for existing and new members, which saves you from chasing every new account. Then you pick one **aggregation Region** and link the others, so findings from every linked Region flow into a single queue instead of you opening one console per Region. Findings arrive in the **AWS Security Finding Format**, a normalised JSON schema, whether they come from GuardDuty, Inspector, Macie, IAM Access Analyzer or a third-party tool via `BatchImportFindings`. The dependency people trip over is that Security Hub's own **standards controls** — the AWS Foundational Security Best Practices and CIS benchmarks — mostly run on AWS Config service-linked rules, so without Config recording enabled in a Region those controls never evaluate and the standard's score is meaningless. Use automation rules to suppress or re-prioritise findings at ingestion.
go deeper
Know that Security Hub is the place all AWS security findings collect, and that it is enabled per account and per Region.
Explain ASFF as the common finding schema, the delegated administrator plus auto-enable model, and the aggregation Region that gives one cross-Region view.
Lead with the AWS Config dependency behind standards controls, and show how automation rules and EventBridge turn an aggregated queue into an actual response path rather than a dashboard.
Decide which standards are mandatory org-wide, who owns exceptions and how they are recorded, and account for the combined Security Hub plus Config cost of the baseline you are imposing on every account.
## The problem Security Hub exists to solve Run GuardDuty, Inspector, Macie and Config across 40 accounts and 4 Regions and you have 640 places to look, each with a different finding shape. Security Hub collapses that into one normalised stream, and adds packaged compliance standards on top. ## ASFF: the normalised schema Every finding is expressed in the **AWS Security Finding Format (ASFF)** — a JSON schema with fields including `SchemaVersion`, `Id`, `ProductArn`, `GeneratorId`, `AwsAccountId`, `Types`, `Severity`, `Resources`, `Compliance` and `Workflow`. Because severity, resource identity and account are in fixed positions, you can write one EventBridge rule or one triage query that treats a GuardDuty crypto-mining finding and an Inspector CVE the same way. Third-party and home-grown tools integrate by calling `BatchImportFindings` with ASFF documents, and `BatchUpdateFindings` moves a finding's workflow state (NEW, NOTIFIED, SUPPRESSED, RESOLVED). ## Multi-account: delegated administrator In an Organization you nominate a delegated administrator account for Security Hub. Best practice is a dedicated security-tooling account rather than the management account, so day-to-day security work does not require credentials in the most privileged account in the org. The delegated admin can enable Security Hub across members and switch on **auto-enable for new accounts**, which matters because accounts are created continuously and manual enablement always drifts. Member findings become visible to the administrator; members still see their own. ## Multi-Region: the aggregation Region Security Hub is regional. You designate one Region as the **aggregation Region** and link the others (optionally including new Regions automatically). Findings from linked Regions are replicated to the aggregation Region, and updates you make there propagate back to the origin Region. Two things to keep straight: the service must still be *enabled* in each Region you want covered — linking a Region where Security Hub is off collects nothing — and cross-Region replication of finding data may have residency implications worth checking against your compliance requirements. ## The Config dependency This is the part that separates people who have deployed it from people who have read about it. Security Hub's **security standards** — for example the AWS Foundational Security Best Practices standard, the CIS AWS Foundations Benchmark, and the PCI DSS and NIST standards — are sets of **controls**, and the large majority of those controls are implemented as AWS Config service-linked rules that Security Hub creates and manages. Consequences: - If the AWS Config recorder is off in a Region, those controls have nothing to evaluate; they report no data, and the standard's security score is not a statement about your posture. - Config's own costs (configuration items and rule evaluations) are part of the true cost of enabling a standard, on top of Security Hub's per-check and per-finding charges. - Turning off a single control disables its underlying rule, which is the supported way to silence a control you have consciously accepted the risk on — better than ignoring it in a dashboard. Security Hub also supports **consolidated control findings**, where a control that appears in several standards produces one finding rather than one per standard, which materially reduces duplicate volume. ## Turning aggregation into action Aggregation without triage discipline just centralises the noise. The mechanisms Security Hub gives you are: - **Automation rules** — evaluate findings at ingestion and change fields, for example suppressing findings on a known-exception resource, or raising severity when the resource carries a `production` tag. - **Insights** — saved grouped queries ("findings by resource, highest severity first") for triage. - **EventBridge** — every finding is emitted as a `Security Hub Findings - Imported` event, so routing to a ticket system, chat or a Lambda responder is a rule away. This is the standard integration point once more than one detector feeds the hub. ## The failure modes worth naming Enabling Security Hub in one Region and assuming org-wide coverage; enabling standards with Config off and reading the score as real; enabling every standard at once so overlapping controls swamp the team; and leaving auto-enable off so new accounts are silently uncovered. A senior answer names at least the Config dependency and the per-Region enablement, because both silently produce a green dashboard over an unmonitored estate.
- Why designate a separate security account as delegated administrator instead of using the Organizations management account?So that routine security triage does not require credentials in the account that can create accounts, attach SCPs and change the org structure. A dedicated security-tooling account limits blast radius if those operator credentials are compromised, and lets you grant read-heavy access to a wider group. It is the same rationale AWS applies to delegated administration generally.
- A team says a Security Hub control is not applicable to their workload. What is the right way to handle that?Disable the specific control in the standard, with a recorded justification, rather than letting it fail forever and teaching everyone to ignore red. If it is only some resources that are exempt, keep the control on and use an automation rule to suppress findings matching those resources, so a new non-exempt violation still surfaces.
- How do you feed findings from a third-party scanner into the same queue?Convert them to the AWS Security Finding Format and call `BatchImportFindings` against Security Hub in the right account and Region; many vendors ship an integration that does this. Once inside, they carry the same severity and resource fields, so existing automation rules and EventBridge routing apply without special-casing the source.
saying these in an interview costs you the question
- Believes Security Hub performs its own scanning of resources
- Reads a standard's score as valid with AWS Config recording off
- Assumes enabling one Region covers the whole Organization
- Uses the management account as the security operations account
- Turns on every standard at once and drowns in duplicate controls