Evaluate Findings with Security Hub

Your cloud environment is constantly generating security alerts — from misconfigured S3 buckets to overly permissive IAM roles — but raw alerts are noise. Without a way to evaluate findings with Security Hub, you can't tell a critical exploit from a minor misconfiguration, and your team drowns in false positives. This lesson turns that alert firehose into a prioritized, actionable triage workflow so you can focus on what actually threatens your AWS account.

The problem this lesson solves

When you enable AWS Security Hub, it aggregates findings from services like GuardDuty, Inspector, and IAM Access Analyzer, plus its own checks against the AWS Foundational Security Best Practices standard. The result is a flood of thousands of findings, each marked LOW, MEDIUM, HIGH, or CRITICAL. The problem? Severity alone doesn't tell you what to fix first. A MEDIUM finding on a public S3 bucket might be a bigger risk than a CRITICAL finding on an internal test resource.

Without a disciplined approach, you'll chase the loudest alerts, burn hours on non-issues, and miss the one misconfiguration that leads to a breach. This lesson teaches you to evaluate findings with Security Hub systematically so every alert gets the right attention at the right time.

Core concept / mental model

Think of Security Hub as your cloud's security control tower. Raw signals from multiple AWS services flow in, but the tower's value isn't the alerts themselves — it's the consolidation, contextualization, and prioritization that happens before a human ever looks.

A finding is Security Hub's standardized representation of a potential security issue. Every finding has:

• Severity — CRITICAL, HIGH, MEDIUM, LOW
• Title and description — what the issue is
• Resource — which AWS resource is affected
• Compliance status — which controls failed (e.g., IAM, S3, EC2)
• Workflow status — NEW, NOTIFIED, SUPPRESSED, RESOLVED

To evaluate findings is to decide two things: Is this real? and What should I do about it? That decision happens across three layers:

1. Context — Is the resource exposed? Does it contain sensitive data? Is it in production?
2. Impact — What would happen if this were exploited?
3. Actionability — Can you fix it easily, or does it require deeper investigation?

Pro tip: Treat severity as a starting suggestion, not a verdict. A HIGH finding on an internal staging bucket may be less urgent than a MEDIUM finding on a production database with public read access.

How it works step by step

Here's the mental flow you'll run through for every finding you examine:

1. Centralize — Ensure Security Hub is enabled and finding aggregation is on across accounts (in Organization management or delegated admin).
2. Filter — Use filters to narrow by severity, compliance standard, resource type, or workflow status.
3. Investigate — Open a finding's details: affected resource, related findings, and the failed control.
4. Assign priority — Combine severity with contextual factors (exposure, data sensitivity, business criticality).
5. Take action — Either remediate directly, suppress as a false positive, or mark as NOTIFIED for a known issue.
6. Track — Update the workflow status so your team has an accurate view of what's open.

This process ensures you evaluate findings with Security Hub in a repeatable way, not as an ad-hoc hunt.

Hands-on walkthrough

Let's put this into practice. We'll use the AWS CLI to list, filter, and evaluate findings. First, make sure you have the securityhub CLI enabled and your access keys configured.

1. List recent findings

aws securityhub get-findings \
  --filters '{"SeverityLabel": [{"Value": "HIGH", "Comparison": "EQUALS"}]}' \
  --region us-east-1 \
  --max-items 5

Expected output (truncated):

{
  "Findings": [
    {
      "Id": "arn:aws:securityhub:us-east-1:123456789012:findings/...",
      "Title": "S3 bucket publicly accessible",
      "Severity": { "Label": "HIGH" },
      "Resources": [{"Id": "arn:aws:s3:::my-public-bucket"}],
      "WorkflowStatus": "NEW"
    }
  ]
}

2. Evaluate a finding with extra context

Let's pull details for a single finding and check if the affected resource is in production by tagging.

findings_json=$(aws securityhub get-findings --filters '{"Id": [{"Value": "arn:aws:securityhub:us-east-1:123456789012:findings/xyz123", "Comparison": "EQUALS"}]}' --region us-east-1)

# Extract resource ARN and check tags
target_arn=$(echo $findings_json | jq -r '.Findings[0].Resources[0].Id')
echo "Affected resource: $target_arn"
aws resourcegroupstaggingapi get-tags --resource-arn-list "$target_arn" --region us-east-1

If the tags show Environment: production, you know this HIGH finding demands immediate attention. If it's Environment: dev, you might defer it.

3. Update workflow status after evaluation

Once you've decided the finding is not a real risk, mark it as SUPPRESSED with a note.

aws securityhub batch-update-findings \
  --finding-identifiers '{"Id": "arn:aws:securityhub:us-east-1:123456789012:findings/xyz123", "ProductArn": "arn:aws:securityhub:us-east-1::product/aws/securityhub"}' \
  --workflow '{"Status": "SUPPRESSED"}' \
  --note '{"Text": "Resource is a test bucket. No sensitive data.", "UpdatedBy": "admin"}'

Expected response: "UnprocessedFindings": [] — meaning success.

Pro tip: Use batch-update-findings for bulk operations, but always include a note so your team knows why a finding was suppressed.

Compare options / when to choose what

When evaluating findings, you have several approaches. Here's how they compare:

Choose severity-based triage for your daily morning check, tag-based filtering when you push to production, and automated rules when you have hundreds of accounts. Manual review is for the few cases that matter most.

Variations worth knowing:

• Security Hub insights — Pre-built queries that group findings by resource type or severity, helping spot patterns.
• Custom actions with EventBridge — Trigger automated workflows (like sending a Slack message or creating a Jira ticket) when a new HIGH finding arrives.
• Third-party integrations — Tools like Splunk or Datadog can ingest findings for correlation with other telemetry.

Troubleshooting & edge cases

You'll rarely evaluate findings without hitting a snag. Here are the most common problems and how to solve them:

• Too many findings to care about — Use Filters with ComplianceStatus: FAILED to see only actionable issues, and WorkflowStatus: NEW to avoid re-reading old ones.
• Missing findings from other accounts — Ensure Security Hub is enabled in all accounts and that Admin account is set correctly. Use --query filters in CLI to check across accounts.
• False positives — Some checks are generic (e.g., S3 bucket public even if it's intentionally public for static hosting). Investigate the resource's actual policy and data before suppressing.
• Findings not appearing — Security Hub can take up to 2 hours to aggregate. If a finding seems missing, check services are enabled (GuardDuty, Inspector) and that the finding was generated after enabling them.
• IAM permission errors — You need securityhub:GetFindings and securityhub:BatchUpdateFindings on the resource or via a policy. Example policy:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "securityhub:GetFindings",
        "securityhub:BatchUpdateFindings"
      ],
      "Resource": "*"
    }
  ]
}

Edge case: A finding may have WorkflowStatus: RESOLVED but still appear in queries. Filter by NEW or NOTIFIED to track open work.

What you learned & what's next

You now know how to evaluate findings with Security Hub — from filtering to priority to action. You can explain the core concept behind it, and you've completed a hands-on exercise using the CLI to list, inspect, and update findings.

Next in the Cloud security essentials path, you'll learn how to automate threat responses with Systems Manager, turning the evaluation process you just practiced into an automated remediation loop. This is where cloud security becomes truly proactive — reducing alert fatigue and response time.

Keep this triage mindset: context beats severity, and every finding deserves a clear workflow state. Your cloud's security posture depends on the decisions you make from here.