Docs

Appearance

AWS Security Hub Finding Triage ​

Purpose: Triage workflow for AWS Security Hub findings across all 7 Cirius AWS accounts.

Audience: Rory Console: AWS Management account (206820231356) → Security Hub

Overview ​

Security Hub aggregates findings from multiple sources across all 7 AWS accounts into the Management account. Cirius uses NIST 800-53 R5 as the primary posture standard, enabled org-wide.

Important: AWS Security Hub has no native HIPAA standard. For HIPAA-specific assessments use AWS Audit Manager with the HIPAA-Omnibus-Jan-2013 framework (also in Management account). Security Hub NIST 800-53 R5 covers the same security controls with broader coverage.

Accounts:

AccountIDPrimary use
Management206820231356Org root — Security Hub aggregator
Backup863609217450Veeam backup targets
Dev040067931468Development
Identity414134953818IAM Identity Center
Logging038901680748CloudTrail, S3 archive, syslog VM
Networking238342914131Palo Alto firewall infrastructure
Prod807267566999DR workloads, Cloud PC

Accessing Security Hub ​

  1. Sign into AWS Console as Rory's IAM Identity Center user: https://d-xxxxxxxxxx.awsapps.com/start
  2. Switch to the Management account (206820231356) with SecurityAudit or similar role
  3. Navigate to Security Hub → ensure region is us-east-1 (aggregation region)
  4. Findings → filter Record state = ACTIVE

Findings from all 7 member accounts roll up here via the org integration.

Finding Lifecycle ​

NEW (automated detection)
  │
  ├─ Remediated → RESOLVED (update manually or via Config re-evaluation)
  │
  └─ Accepted risk → SUPPRESSED (document in risk-acceptance-register.md)

Do not leave findings in NEW/ACTIVE indefinitely — active findings in Security Hub are direct audit evidence of unresolved controls.

Triage Workflow ​

Step 1 — Filter to actionable findings:

  • Status: ACTIVE
  • Severity: CRITICAL, HIGH (review MEDIUM monthly, LOW quarterly)

Step 2 — For each finding:

  1. Read the finding title and description — understand which control failed
  2. Click the finding → Resources tab — identify the specific resource (ARN)
  3. Determine which AWS account owns the resource — note the account ID
  4. Cross-reference with Terraform state:
    bash
    cd ~/src/aws-infra
terraform state list | grep <resource-name>
    If the resource is in Terraform state, the fix goes in Terraform. If not managed, import first.
  5. Check compliance/risk-acceptance-register.md — is this already a documented accepted risk?
  6. Remediate or suppress (below)

Step 3 — After remediation:

Wait up to 24 hours for Security Hub to re-evaluate. For faster re-evaluation:

  • AWS Config → Rules → find the relevant rule → Actions → Re-evaluate

Severity Response SLAs ​

SeverityRemediate By
CRITICAL7 days or add to risk-acceptance-register.md with justification
HIGH30 days
MEDIUM90 days (reviewed monthly)
LOWQuarterly review

Suppressing a Finding (Accepted Risk) ​

When a finding cannot be remediated (architectural limitation, compensating control in place):

  1. In Security Hub: finding → Actions → Suppress → add a note explaining why
  2. Document in compliance/risk-acceptance-register.md:
    • Finding title
    • Control ID (e.g., NIST 800-53 R5 / SC-28)
    • Reason for acceptance
    • Compensating controls in place
    • Rory's written acceptance
    • Review date

Never suppress a CRITICAL without a written entry in the risk acceptance register.

Common CRITICAL Findings and Resolutions ​

FindingTypical CauseResolution
S3 bucket server access logging should be enabledNew bucket created without logging configAdd logging block in Terraform S3 resource
CloudTrail should be enabled in all regionsNew region used without CloudTrailEnable via Terraform in CloudTrail stack in Logging account
Root account MFA should be enabledMFA not configuredEnable MFA in root account (all 7) — break-glass accounts must have TOTP in Keeper
Root account should not have access keysRoot access keys existDelete root access keys immediately via IAM Console → root account
Security Hub should be enabledMember account not onboardedEnable via Terraform in aws-infra Security Hub module
VPC flow logs should be enabledNew VPC without flow log configAdd aws_flow_log resource in Terraform
IAM password policy should meet minimum requirementsOrg-level password policy not setConfigure in IAM Identity Center settings
EBS volumes should be encryptedNew EC2 instance without encrypted EBSUpdate Terraform to set encrypted = true and kms_key_id on all EBS volumes

Integration With SecOps ​

The aws_security_hub_agent.py in ops-automation queries Security Hub every 4 hours and posts HIGH/CRITICAL findings to SecOps. The primary triage workflow is in SecOps — findings appear there with context from other agents.

Go directly to Security Hub console for:

  • Mass remediation across many findings
  • Investigation of a specific finding in detail
  • Suppression with notes
  • Verifying re-evaluation after a fix

AWS Audit Manager (HIPAA) ​

For HIPAA audit preparation:

  1. AWS Console → Management account → Audit Manager
  2. Assessments → find the HIPAA-Omnibus-Jan-2013 assessment
  3. Review controls with FAILED status
  4. Evidence is collected automatically from AWS Config rules — download evidence for the relevant controls for the audit PBC package

Audit Manager evidence maps directly to HIPAA control requirements. Use it alongside compliance/soc2-pbc-guide.md for audit prep.

  • compliance/risk-acceptance-register.md — accepted risk documentation
  • aws/aws-network-topology.md — AWS account and network overview
  • runbooks/aws-account-access.md — how to switch between AWS accounts
  • runbooks/aws-iam-identity-center.md — IAM Identity Center operations
  • cicd/oidc-authentication.md — how GitHub Actions authenticate to AWS

Internal use only — Cirius Group