Security Hub and Config rules

Findings in one place, drift as a signal.

In short. GuardDuty finds threats; Config records configuration; Security Hub aggregates findings from both plus partner tools into a single prioritization surface.

GuardDuty finds threats; Config records configuration; Security Hub aggregates findings from both plus partner tools into a single prioritization surface. Turning them on without owners creates alert fatigue. Turning them on with routing to a ticket queue and auto-remediation for known-safe fixes creates a posture program.

Enable AWS Config recorders with a locked-down S3/SNS destination, subscribe Security Hub standards (AWS FSBP, CIS) appropriate to your estate, and suppress findings with justification — not silence.

Wire the baseline

aws securityhub enable-security-hub
aws securityhub batch-enable-standards \
  --standards-subscription-requests StandardsArn=arn:aws:securityhub:…:standards/aws-foundational-security-best-practices/v/1.0.0
aws configservice describe-configuration-recorders

… StandardsStatus: READY …
{ "ConfigurationRecorders": [{ "name": "default", "recordingGroup": … }] }

Noise control

Insight filters and automation rules keep humans on high-severity, high-confidence items. Track mean time to acknowledge. Pair with SCPs that prevent disabling Hub/Config/Trail without break-glass.

Going deeper

Cross-Region and member account aggregation needs a home region strategy. Document it. Findings without account ID context in tickets waste IR time — enrich EventBridge payloads with tags and owner maps.

Auto-remediation is great for closing public S3 ACLs and terrible for nuanced IAM. Start with remediations that are reversible and low blast radius; require human approval for identity changes.

Align Hub severity with your paging policy. If everything is CRITICAL, nothing is. Tune and suppress with expiry, same as policy exceptions.

Map each enabled standard control to an owner team. Unowned controls rot. A simple spreadsheet or Service Catalog product tagging security:owner is enough to start.

Integrate partner findings sparingly at first — volume explodes. Add one source, tune, then expand. Hub is only as good as the routing and ownership model behind it.

Review suppressed findings monthly. Suppressions without expiry are exceptions by another name.

Create automatic Jira/ServiceNow tickets only for HIGH/CRITICAL with product-account tags resolved. Low findings go to a weekly digest so humans stay responsive.

Protect Security Hub and Config with SCPs that deny DisableSecurityHub and StopConfigurationRecorder except from a break-glass role.

Train on-call on Hub finding anatomy once — severity, compliance status, related resources — so tickets include enough context for the owning team to act without a security engineer translating every alert.

Try this

Enable Security Hub in a lab, note an FSBP failure (often S3 or IAM), fix it, and confirm the finding resolves or goes inactive.

aws securityhub get-findings --max-results 3 --query 'Findings[].{Title:Title,Severity:Severity.Label}'

… S3 buckets should … HIGH …

Takeaway

Security Hub + Config turn raw posture into a managed queue. Enable standards, route findings, suppress with reasons, and protect the telemetry with SCPs.

Next: instance roles and SSM — kill standing SSH on bastions.

Related