AWS Security Hub findings explained in plain English
AWS Security Hub findings are written for security specialists. A title such as ‘S3 general purpose buckets should block public access’ is precise, but it does not tell a founder or a busy engineer what is wrong, how worried to be or what to do next. This guide translates ten findings you are likely to see into plain English.
How Security Hub scores severity
Every Security Hub control has a severity label: Critical, High, Medium, Low or Informational. AWS assigns it from two questions: how easy the weakness is to exploit, and how likely it is to lead to a compromise. Findings also carry a normalised score from 0 to 100, although AWS now treats the label as the preferred field.
| Label | Normalised score | What AWS says it means |
|---|---|---|
| Critical | 90–100 | Remediate immediately to avoid it escalating |
| High | 70–89 | A near-term priority |
| Medium | 40–69 | A mid-term priority |
| Low | 1–39 | Does not require action on its own |
| Informational | 0 | For information only |
One thing the severity does not consider is how important the affected resource is. A public test bucket and a public bucket of customer records get the same label, so you still need to judge which to fix first.
Ten findings, translated
Each finding below shows the Security Hub control ID and title, its severity, what it means in plain English, why it matters and how to fix it. All ten are part of the AWS Foundational Security Best Practices standard. Which ones appear in your account depends on the standards you have enabled.
-
S3.8S3 general purpose buckets should block public accessSeverity: High
In plain English: Keep your online storage private to protect your important files.
Why it matters: One of your S3 buckets does not have Block Public Access turned on, so a policy or ACL change could expose its contents to the internet.
How to fix it: Turn on all four Block Public Access settings for the bucket, after checking that nothing relies on it being public.
-
S3.1S3 general purpose buckets should have block public access settings enabledSeverity: Medium
In plain English: Switch on the safety net that stops any bucket in your account going public.
Why it matters: Account-level Block Public Access is not fully on, so each bucket relies on its own settings being right.
How to fix it: Turn on all four Block Public Access settings at account level in the S3 console.
-
IAM.4IAM root user access key should not existSeverity: Critical
In plain English: Your account’s master login has a key that can be used from anywhere. Delete it.
Why it matters: Root access keys grant unrestricted access that IAM policies cannot limit. If one leaks, the whole account is compromised.
How to fix it: Delete the root access key and use IAM roles or IAM Identity Center for programmatic access.
-
IAM.6Hardware MFA should be enabled for the root userSeverity: Critical
In plain English: Protect your account’s master login with a physical security key.
Why it matters: The root user can do anything in your account. Hardware MFA is the strongest protection for it, because a physical key cannot be copied the way a password or a one-time code can be phished.
How to fix it: Register a hardware MFA device for the root user, and store it somewhere safe.
-
IAM.3IAM users’ access keys should be rotated every 90 days or lessSeverity: Medium
In plain English: Some login keys have not been changed for over three months. Replace them.
Why it matters: Old keys have had more time to end up in scripts, laptops and repositories, which raises the chance that one has leaked.
How to fix it: Create a new key, update anything that uses the old one, then deactivate and delete the old key. Prefer roles over long-lived keys.
-
IAM.1IAM policies should not allow full "*" administrative privilegesSeverity: High
In plain English: One of your permission policies lets someone do absolutely anything. Narrow it down.
Why it matters: A customer managed policy allows every action on every resource, so anyone with it can change or delete anything.
How to fix it: Replace the policy with one scoped to the actions and resources that person or service actually needs.
-
EC2.19Security groups should not allow unrestricted access to ports with high riskSeverity: Critical
In plain English: A network rule leaves a sensitive door, such as SSH, RDP or a database port, open to the whole internet.
Why it matters: Ports such as 22, 3389, 3306 and 5432 are scanned constantly. Leaving them open invites break-in attempts.
How to fix it: Remove the rule, or restrict it to known IP addresses. Use Systems Manager Session Manager instead of open SSH.
-
EC2.2VPC default security groups should not allow inbound or outbound trafficSeverity: High
In plain English: Lock the default network door so new resources are not accidentally left open.
Why it matters: Resources launched without a specific security group get the default one. If it allows traffic, they may be exposed without anyone noticing.
How to fix it: Remove all inbound and outbound rules from each VPC’s default security group, and use purpose-built groups instead.
-
CloudTrail.1CloudTrail should be enabled and configured with at least one multi-Region trail that includes read and write management eventsSeverity: High
In plain English: Turn on the record of who did what in your account, in every region.
Why it matters: Without a multi-Region trail, activity in regions you do not normally use can go unrecorded, and incidents become very hard to investigate.
How to fix it: Create a multi-Region trail that logs read and write management events to a private, encrypted S3 bucket.
-
RDS.2RDS DB Instances should prohibit public access, as determined by the PubliclyAccessible configurationSeverity: Critical
In plain English: One of your databases is set to be publicly accessible, so it has a public address. Make it private.
Why it matters: A public address means the database can be reached from the internet if its security group and network rules allow it. From there, one weak password or unpatched flaw is all an attacker needs.
How to fix it: Set the instance to not publicly accessible, and allow connections only from your application’s security group.
Where to start
Start with the Critical findings, because they are the ones most likely to lead to a compromise: root access keys, missing root MFA, sensitive ports open to the internet and publicly accessible databases. Then work through the High findings, especially public buckets and missing CloudTrail logging.
If you want to check a few of these by hand first, our guide to five AWS security checks you can run right now shows how, with console steps and CLI commands.
Let bearhug do the translating
bearhug builds on Security Hub and shows every finding in plain English by default, with the original control ID and title one click away. Common fixes, such as blocking public access on a bucket or closing an open port, take one click with rollback. See how plain-English AWS security findings work, or read our comparison of AWS Security Hub and bearhug.