AWS Security Hub Automation Rules (CSPM)

As organizations scale their AWS footprint, the flood of security findings from Security Hub (and its integrated services) becomes challenging to triage manually. To manage this, Automation Rules in Security Hub CSPM allow you to define criteria-driven, near-real-time updates to findings (e.g. suppressing noise, reclassifying severity, tagging, or setting workflow state). This helps your security team focus on higher-value alerts rather than chasing every low-priority finding.

In effect, Automation Rules bring some level of automated decision logic within Security Hub before triggering further orchestration or external remediation.

In the sections below, we explore:

• What are Automation Rules
• When they are evaluated / triggered
• Where in the Security Hub / AWS pipeline they operate
• How to design, implement, and operate them

What: Definition, Capabilities & Use Cases

DefinitionAn Automation Rule is a rule you configure in AWS Security Hub CSPM (Cloud Security Posture Management) that inspects incoming findings (in AWS Security Finding Format) and automatically updates fields of those findings, or suppresses them, based on matching criteria you define. (

These rules act inside the Security Hub environment (i.e. before or concurrent with further EventBridge-driven actions) to reduce manual handling of low-value findings. (

Supported actions / updatesUsing an Automation Rule, you can automatically:

• Change the severity (e.g. elevate or de-escalate)
• Change the workflow status (e.g. NEW, IN_PROGRESS, SUPPRESSED)
• Add Notes or annotations
• Add User-defined fields or tags
• Suppress the finding entirely (i.e. mark it so it doesn't surface)
• Possibly mark a rule as terminal so no subsequent rules are applied (
  AWS Documentation
  )

Use Cases / ExamplesHere are common automation rule patterns:

• Suppress informational findings (e.g. benign or low-risk noise) so that they don't clutter the console. (
  AWS Documentation
  )
• Elevate severity of findings in production accounts or specific resource types (e.g. S3 buckets in production). (
  AWS Documentation
  )
• Auto-assign workflow status (e.g. set to IN_PROGRESS) to trigger downstream orchestration. (
  awsforengineers.com
  )
• Tagging or annotating findings with environment, team, or resource metadata.
• Terminal rules: you can mark a rule as "terminal" so that once matched and applied, no later rules will be considered. (
  AWS Documentation
  )

Also, AWS provides rule templates in the console to help you get started. (

Limitations / Notes

• Automation rules act only within the Security Hub CSPM layer (they do not directly call Lambdas, SNS, etc). For external actions, you still rely on EventBridge rules. (
  AWS Documentation
  )
• Order matters: if multiple rules match a given finding, the RuleOrder parameter defines which rule applies when, and you can mark one as terminal to block further modifications. (
  AWS Documentation
  )
• The filters you define (in the rule criteria) must follow the constraints for PREFIX, NOT_EQUALS, CONTAINS etc. (
  AWS Documentation
  )
• Once you edit a rule, it only affects new or updated findings after the change. (
  AWS Documentation
  )

When: Timing & Trigger Conditions

When evaluation happensAutomation Rules are evaluated as findings arrive or are updated — essentially in near real time as Security Hub processes findings. (

Importantly, the update from an Automation Rule happens before EventBridge rules are triggered. Then, the updated finding flows into EventBridge/other orchestration if configured. (

So the sequence is:

1. A new finding is ingested (or an existing finding is updated)
2. Automation Rules are applied (in RuleOrder sequence)
3. After modifications, EventBridge rules see the (possibly modified) finding, triggering downstream workflows

When rule order / terminal status mattersIf multiple rules apply to the same finding, the RuleOrder integer value (1–1000) determines the application order (lowest first). (

When they should be enabled / disabled

• You might disable (or not create) rules for accounts or Regions where you don't want this behavior. (
  AWS Documentation
  )
• You can disable or reorder rules dynamically as threat patterns evolve. (
  AWS Documentation
  )

Where: Placement in the AWS / Security Hub Pipeline

Here's how Automation Rules fit in the AWS / Security Hub architecture:

1. Finding sources — e.g., AWS Config, GuardDuty, Firewall Manager, third-party tools feed in findings to Security Hub.
2. Security Hub ingestion & CSPM processing — Security Hub collects, deduplicates, normalizes to ASFF.
3. Automation Rules layer (CSPM) — After ingestion but before further external actions, Security Hub evaluates your Automation Rules.
4. EventBridge / orchestration — After Automation Rules have made updates, EventBridge rules (configured separately) may trigger Lambdas, SNS, Step Functions, or integrate with other systems for deeper remediation.
5. Remediation / actions external — The downstream workflows handle things like remediation, alerting, tickets, etc.

Thus, Automation Rules act as a pre-filter & field-modifier before more active orchestration.

Flow Diagram (textual with AWS icons in mind)

Below is a simplified flow using AWS icon notation (you can convert into a visual):

[ Finding Sources (GuardDuty, Config, etc.) ] → [ AWS Security Hub Ingestion / Normalization ] → [ Automation Rules Engine ]  
     → (if matches) → update severity / workflow / suppress → [ EventBridge / Orchestration Layer ] → [ Remediation Lamba / Step Function / SNS / Tickets / External Systems ]

If you drew this visually, you'd use AWS icons for Security Hub, EventBridge, Lambda / Step Functions, etc.

How: Design, Implementation & Best Practices

Designing Automation Rules

1. Define filtering criteria
2. • Use field filters on ASFF fields (e.g. ResourceType, ControlId, SeverityLabel, AccountId, etc.)
   • Use PREFIX, EQUALS, NOT_EQUALS, CONTAINS filters — these are processed in a defined order (PREFIX first) (
     AWS Documentation
     )
   • Avoid conflicting filters (e.g. combining EQUALS and NOT_EQUALS on same field). (
     AWS Documentation
     )
3. Choose action(s)
4. • Do you want to suppress?
   • Or alter severity, workflow status, notes, tags?
   • Optionally mark as terminal so no further rules apply. (
     AWS Documentation
     )
5. Decide rule order
6. • Assign a RuleOrder (1–1000). Lower numbers are applied first. (
     AWS Documentation
     )
   • If multiple rules may target overlapping criteria, ensure order is logical.
   • Use terminal where appropriate.
7. Test / preview
8. • In the console, when creating a rule, AWS shows a beta set of findings that match. (
     AWS Documentation
     )
   • Validate filter logic across Regions / accounts.
9. Enable and monitor
10. • Deploy in target accounts & Regions. (
      AWS Documentation
      )
    • Monitor how your rules are modifying findings, check for unintended suppression.

Implementation Steps (Console / API / CloudFormation)

• Console: In the Security Hub console, go to Automations → Create rule. You can start from templates or custom. (
  AWS Documentation
  )
• API / CLI: Use CreateAutomationRule API or CLI. Provide RuleName, RuleOrder, RuleStatus, Criteria, Actions, IsTerminal. (
  AWS Documentation
  )
• Infrastructure as Code (IaC): Use AWS::SecurityHub::AutomationRule resource in CloudFormation or equivalent in Terraform. (
  AWS Documentation
  )
• Update / Edit: Use console or BatchUpdateAutomationRules. Note: edits only affect new/updated findings after the change. (
  AWS Documentation
  )

Operating / Maintaining

• Versioning / change control: Keep track of rule definitions, order, and logic in source control.
• Logging / audit: Use finding history (Security Hub shows how findings were updated) to trace roles. (
  AWS Documentation
  )
• Adjusting filters & rules: As new services / findings emerge, adjust rules or add new ones.
• Avoid over-suppression: Be cautious not to suppress too aggressively, in case you hide real risks.
• Test in staging / sandbox: Before applying a rule broadly, test in non-production accounts.
• Combine with external orchestration: Use Automation Rules for internal filtering, then EventBridge / Lambdas for deeper responses.

Example (pseudocode / configuration)

Suppose you want a rule that:

• Matches: Findings where ResourceType starts with AwsS3Bucket and SeverityLabel = LOW
• Action: SUPPRESS the finding
• Terminal: yes

In JSON-like pseudo:

{
  "RuleName": "SuppressLowS3Buckets",
  "RuleOrder": 10,
  "RuleStatus": "ENABLED",
  "IsTerminal": true,
  "Criteria": {
    "ResourceType": { "Prefix": ["AwsS3Bucket"] },
    "SeverityLabel": { "Equals": ["LOW"] }
  },
  "Actions": {
    "Suppress": {}
  }
}

Once deployed, any new LOW severity S3 bucket finding would be suppressed (and not clutter Security Hub UI).

You might have another rule (Order 20) that catches ResourceType AwsEC2 + SeverityLabel = MEDIUM and sets workflow to IN_PROGRESS.

Caveats & Best Practices

• Prefer filtering by ControlId rather than titles, because control titles may change, but IDs remain consistent. (
  AWS Documentation
  )
• Rule changes apply only to new or updated findings, not historical ones. (
  AWS Documentation
  )
• Don't assume Automation Rules replace full remediation — they only update fields; actual remediation needs orchestration.
• Use terminal rules cautiously — overuse may block other useful rules.
• Avoid overly broad filters (e.g. "all findings in account") unless you truly want that.
• Monitor for drift — as new AWS services or integrations come in, review rule applicability.

Summary & Takeaways

• What: Automation Rules are in-SecurityHub logic that updates or suppresses findings based on criteria, without leaving the CSPM layer.
• When: They run in near real time as new or updated findings come in, before EventBridge rules.
• Where: They intervene between ingestion and external orchestration, acting as a mid-layer filter/modifier.
• How: You define filters + actions + order (and optionally terminal status), deploy via console / API / IaC, and maintain over time with care.

By leveraging Automation Rules wisely, you can cut down noise, better highlight critical issues, and streamline your security operations.