From 5,000 Security Hub Findings to a Backlog Your Team Can Finish

Turning on Security Hub across an AWS organisation produces thousands of findings on day one. How we triage them into a short backlog, fixed mostly at the account level rather than one resource at a time.

Turn on Security Hub with the AWS Foundational Security Best Practices and CIS AWS Foundations Benchmark standards across a real AWS organisation and the first dashboard is demoralising: thousands of failed checks, a security score in the low double digits, and no obvious place to start. Most teams react in one of two ways. They try to fix findings one resource at a time and give up after a sprint, or they stop looking. Neither improves security. This post is how we turn that first dashboard into a backlog a team can actually finish.

Set it up so the numbers mean something

Triage is pointless if the data is incomplete or duplicated. Before reading a single finding:

• Delegate administration to a dedicated security account rather than running Security Hub from the management account, and use central configuration so standards and controls are applied consistently to every account and region, including new ones.
• Aggregate findings into one home region, so you are looking at one list, not one per region.
• Turn on consolidated control findings, so a control that is checked by two standards produces one finding, not two.
• Disable controls that do not apply to your estate (for example, checks for services you do not use, or global resource checks in every region but one), centrally and with a documented reason.

After this, the finding count usually drops noticeably without fixing anything, and what remains is real.

Triage by control, not by finding

The key move: stop counting findings and start counting controls. Five thousand findings typically come from a few dozen failing controls, each repeated across hundreds of resources. One decision per control, applied everywhere, is the only approach that scales.

For each failing control, record four things:

Then sort. Our ordering is consistent across most estates:

1. High severity, exposed, fixable at the account level. Do these this week.
2. High severity, exposed, per-resource. Fix the exposed resources first, then the rest.
3. Anything fixable at the account or organisation level, regardless of severity, because one change closes hundreds of findings.
4. Per-resource findings in non-production, handed to workload teams with a deadline.
5. Accepted risks, suppressed with a documented reason and a review date.

The controls that fail almost everywhere

Every estate is different, but the same controls dominate first runs. Many of them are fixed with a single account-level setting:

• S3.1 - account-level S3 Block Public Access. One setting per account blocks public buckets for everything in it:

  aws s3control put-public-access-block \
    --account-id 111122223333 \
    --public-access-block-configuration \
      BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true
  

• EC2.7 - EBS encryption by default. One setting per account per region, applying to every new volume:

  aws ec2 enable-ebs-encryption-by-default --region eu-central-1
  

• EC2.8 - IMDSv2 required. Set the account default so new instances require IMDSv2, then fix running instances by owner:

  aws ec2 modify-instance-metadata-defaults --http-tokens required --region eu-central-1
  

• EC2.2 - default security groups allow traffic. Remove all rules from the default security group in every VPC; nothing should be using it.

• CloudTrail.1 - multi-region trail. One organisation trail from the management account covers every account and region.

• IAM.6 / root account controls. Hardware MFA on root for every account, and no root access keys. With centralised root access management in AWS Organizations, root credentials on member accounts can be removed entirely.

• Security groups open to 0.0.0.0/0 on SSH or RDP. Usually a handful of resources, high exposure, and fixed by moving administrative access to Systems Manager Session Manager.

Settings like these also belong in your account baseline, applied automatically when an account is created, so the findings do not come back with every new account. AWS Organizations declarative policies can enforce some of them, such as IMDSv2 defaults and blocking public sharing of AMIs and snapshots, across the whole organisation in a way member accounts cannot override.

Prevent instead of detect

Security Hub tells you what is wrong after it is deployed. For the high-severity controls, add prevention so the finding cannot recur:

• Service control policies to deny turning off CloudTrail, GuardDuty or Security Hub, deny leaving the organisation, and deny unapproved regions.
• Policy checks in the pipeline (cfn-guard, Checkov or similar) so infrastructure as code that would fail a Security Hub control fails the build instead.
• Secure module defaults, so the team's standard S3, RDS or EC2 module is compliant unless someone deliberately changes it.

A finding that is prevented never needs triage again.

Handle exceptions honestly

Some findings are acceptable risks: a bucket that is public on purpose to host a website, a legacy system that cannot run IMDSv2 until it is replaced. Hiding them, or leaving them failing forever, both erode trust in the dashboard.

Use Security Hub automation rules to suppress or change the workflow status of specific findings based on resource tags or IDs, and require each suppression to carry a reason, an owner and a review date, ideally as tags on the resource itself. Review the suppression list quarterly. An exception with no owner is just an unfixed finding.

Route findings to owners

The platform team cannot fix every workload's resources, and should not try. Once the account-level fixes are done:

• Send findings to the owning team using EventBridge rules on Security Hub findings, routed by account or by owner tag, into the tool that team already works in.
• Report per team, not per organisation. A team-level score with the top five failing controls is actionable; an organisation-wide score is not.
• Set a service level per severity (for example, critical within days, high within weeks) and track it, so remediation does not depend on goodwill.

What good looks like after one quarter

• Findings are aggregated, deduplicated and scoped to controls that apply.
• Account-level fixes are in the baseline for every account, existing and new.
• High-severity, internet-exposed findings are zero or have a documented exception.
• Each workload team receives its own findings and works them against a service level.
• New deployments are checked in the pipeline before they reach Security Hub.

What this looks like at ccX

This is the core of our Cloud Security Posture Review: a gap analysis against the CIS AWS Foundations Benchmark and AWS Foundational Security Best Practices, triaged into a prioritised remediation plan, with IAM and guardrail standards and a Terraform baseline your team can apply to every account. We delivered this baseline on an EU institution's multi-account programme before taking on its cost optimisation. One to two weeks, fixed fee.

If your Security Hub score has not moved in months, book a 30-minute scoping call.

Where to go from here

• Cloud Security Posture Review - the full engagement.
• Amazon GuardDuty Malware Protection for S3 at scale
• Contact us

Security Hub control IDs, standards and organisation-level features change as AWS updates them. Check the current Security Hub controls reference before applying these fixes.

Sitemap

• Read this post on the web
• All blog posts
• Full site map
• Home
• Services
• EU AI Act Compliance
• AWS GenAI Production Readiness
• Glossary
• Contact