Skip to content

AWS Updated 2026-07-04

AWS Security Hub setup: turning a wall of findings into a workable queue

A default AWS Security Hub setup produces hundreds of findings and no plan. Here is how to enable it across accounts and regions, pick standards, suppress the noise, and end up with a queue a real team can work.

Enable Security Hub with the defaults and you get several hundred findings by tomorrow morning — a wall of red that convinces most teams the tool is unusable, after which it becomes an expensive dashboard nobody opens. The tool is fine; the setup is wrong. A working Security Hub deployment makes three deliberate choices the wizard does not make for you: which standards to run, how findings from every account and region funnel to one place, and which findings are genuinely yours to fix versus noise to suppress with a documented reason. Done right, you end up with a queue of tens, not hundreds, and a number that trends down.

What’s happening

Security Hub does two distinct jobs that people conflate. First, it runs controls — automated configuration checks from standards like AWS Foundational Security Best Practices (FSBP) and the CIS AWS Foundations Benchmark — against your resources, generating pass/fail findings. Second, it aggregates findings from other services (GuardDuty, Inspector, Macie, IAM Access Analyzer) into one normalized format and one place. The wall-of-findings problem comes almost entirely from the first job: every unencrypted dev volume, every default-VPC artifact, every log group without retention becomes a finding, all mixed together regardless of whether the resource matters.

One naming note so the console does not confuse you: AWS reorganized this product family in 2025, and the original service described here now appears as Security Hub CSPM in the console, alongside a newer Security Hub dashboard experience built on top of it. The mechanics below — standards, controls, findings, cross-region aggregation — concern that findings-and-standards layer, and the Security Hub documentation covers both.

The other thing to understand before setup: Security Hub is regional and per-account by default. Without delegated administration and a finding aggregator, you get one silo per account per region, which in a ten-account organization is a coverage illusion. Pricing follows the checks and ingested findings, so enabling both major standards in every account is a real (if usually modest) line item — another reason to choose standards instead of enabling everything.

What to check first

  • Prerequisites. Security Hub’s controls lean on AWS Config; the recorder must be on in every account and region you want checked, and Config has its own per-item cost.
  • What is feeding it. GuardDuty and Inspector findings only appear if those services are enabled — Security Hub aggregates, it does not detect. The detection layer comes first: see the CloudTrail and GuardDuty baseline.
  • Organization structure. Confirm which account will be the delegated administrator — it should be your security/audit account, never the management account.
  • Regions in actual use. Aggregation needs a home region chosen deliberately.
  • Who will work the queue. If no name is attached, stop here — setup without an operator just builds a bigger wall.

How to verify

For an existing deployment, establish what is really enabled where:

# Is Security Hub on in this region, and which standards run?
aws securityhub describe-hub
aws securityhub get-enabled-standards

# Is cross-region aggregation configured?
aws securityhub list-finding-aggregators

# The queue that matters: critical/high, active, unresolved
aws securityhub get-findings \
  --filters '{"SeverityLabel":[{"Value":"CRITICAL","Comparison":"EQUALS"},{"Value":"HIGH","Comparison":"EQUALS"}],"WorkflowStatus":[{"Value":"NEW","Comparison":"EQUALS"}],"RecordState":[{"Value":"ACTIVE","Comparison":"EQUALS"}]}' \
  --max-items 25

In the console, Security Hub > Findings with the filter Workflow status: NEW, Severity: CRITICAL is the honest view. If that filtered list has months-old entries, the deployment is a dashboard, not a queue.

The runbook

  1. Designate the delegated administrator from the management account. aws securityhub enable-organization-admin-account --admin-account-id 444455556666, pointing at the audit account. Then enable Security Hub for the organization from that account with auto-enable for new accounts, so vended accounts are covered at birth.
  2. Pick one standard to start: FSBP. It is AWS-maintained, current, and overlaps heavily with CIS. Run both later if an auditor requires CIS by name; running both from day one roughly doubles the wall for little added signal.
  3. Set up cross-region aggregation. From the delegated admin in your home region: aws securityhub create-finding-aggregator --region-linking-mode ALL_REGIONS. One pane, all regions — this is the difference between coverage and the illusion of it.
  4. Disable controls that do not apply, with reasons. Every disabled control takes a written justification (“no Lambda in these accounts”, “covered by the SCP that denies region use” — the guardrail layer in the Organizations SCP baseline legitimately retires some checks). Disabling a control everywhere is honest; suppressing its findings forever without a reason is hiding.
  5. Triage what remains using workflow status. Work severity-descending: fix it (then verify the finding moves to RESOLVED on the next check), or suppress it with a recorded reason (aws securityhub batch-update-findings --workflow-status SUPPRESSED plus a note). Automation rules can handle the mechanical cases — auto-suppress a known-accepted finding pattern on sandbox accounts, auto-elevate anything touching production data stores.
  6. Route the top of the queue outward. EventBridge rule on new CRITICAL findings to the paging path; everything else stays in the weekly review. The wall becomes a queue precisely when arrival routing exists.
  7. Baseline, then trend. Record open counts by severity on day one, then track weekly. The useful graph is direction, not absolute number.

When this is the wrong move

If GuardDuty is not on yet, do that first — behavioural threat detection beats configuration checks for early warning, and Security Hub without sources is a frame without a picture. If you run one small account, the console pages of the individual services may serve you fine without the aggregation layer; Security Hub earns its cost when accounts and regions multiply. And if the organization already standardized on an external SIEM or CSPM, run Security Hub as the AWS-side collector feeding it rather than a second triage surface — two queues means two half-worked queues.

Common mistakes

  • Enabling every standard on day one. FSBP plus CIS plus PCI on an unprepared estate produces thousands of findings and a numbed team. Standards are chosen, not collected.
  • Skipping AWS Config, then trusting the scores. Many controls silently cannot evaluate without the recorder; the compliance score looks better than reality.
  • Suppressing without written reasons. Six months later nobody knows whether S3.8 was suppressed from analysis or fatigue, so nobody dares unsuppress it.
  • Treating the security score as the deliverable. The percentage moves by disabling controls; the open-critical trend and days-to-close are the numbers that reflect actual risk work.

Keeping it under control

  • Weekly queue review with a named owner; criticals page immediately via EventBridge.
  • Every suppression carries a reason and an expiry-style revisit date.
  • New accounts inherit Security Hub automatically via organization auto-enable — verify quarterly.
  • Re-check disabled controls twice a year; “does not apply” has a way of becoming “applies since the new workload.”
  • Watch the Security Hub and Config cost lines as the estate grows; rising check counts are also an inventory signal.

A Security Hub that works is boring: a short queue, a downward trend, and suppressions someone can defend in an audit. If nobody on your team truly owns the AWS environment end to end, that is the root of most of these problems — Stack Harbor runs AWS accounts daily under AWS Operations, and you can book an AWS review.