AWS Security Hub Automation Rules — Auto-Triage, Suppression, Severity Overrides for MCP Servers

Create an automation rule

Each rule has a name, description, evaluation order, conditions (what to match), and actions (what to update). Conditions are AND'd together; multiple values within a single condition field are OR'd.

# Rule 1: Auto-suppress LOW severity findings from dev/test accounts
# Matches any LOW finding from accounts tagged as non-production
aws securityhub create-automation-rule \
  --rule-name "suppress-low-sev-dev-accounts" \
  --description "Auto-suppress LOW severity findings in dev and test environments — accepted risk" \
  --rule-order 100 \
  --is-terminal true \
  --rule-status ENABLED \
  --criteria '{
    "SeverityLabel": [{"Value": "LOW", "Comparison": "EQUALS"}],
    "AwsAccountId": [
      {"Value": "111111111111", "Comparison": "EQUALS"},
      {"Value": "222222222222", "Comparison": "EQUALS"}
    ]
  }' \
  --actions '[{
    "Type": "FINDING_FIELDS_UPDATE",
    "FindingFieldsUpdate": {
      "Workflow": {"Status": "SUPPRESSED"},
      "Note": {
        "Text": "Auto-suppressed: LOW severity finding in dev/test account — accepted risk per security policy 2026-09",
        "UpdatedBy": "security-hub-automation"
      }
    }
  }]'

# Rule 2: Escalate HIGH findings on production MCP endpoints to CRITICAL
# Matches HIGH severity findings on resources tagged Environment=production
aws securityhub create-automation-rule \
  --rule-name "escalate-prod-mcp-to-critical" \
  --description "Escalate HIGH findings on production MCP resources to CRITICAL for immediate paging" \
  --rule-order 50 \
  --is-terminal false \
  --rule-status ENABLED \
  --criteria '{
    "SeverityLabel": [{"Value": "HIGH", "Comparison": "EQUALS"}],
    "ResourceTags": [
      {
        "Key": "Environment",
        "Value": "production",
        "Comparison": "EQUALS"
      },
      {
        "Key": "Service",
        "Value": "mcp-server",
        "Comparison": "EQUALS"
      }
    ]
  }' \
  --actions '[{
    "Type": "FINDING_FIELDS_UPDATE",
    "FindingFieldsUpdate": {
      "Severity": {"Label": "CRITICAL"},
      "Note": {
        "Text": "Severity escalated to CRITICAL: production MCP server resource — immediate response required",
        "UpdatedBy": "security-hub-automation"
      }
    }
  }]'

Rule evaluation order and terminal rules

When a finding arrives or is updated, Security Hub evaluates all enabled automation rules in ascending order by RuleOrder (1 evaluates before 1000). If a rule matches and has IsTerminal: true, evaluation stops — no subsequent rules are applied to that finding. If a rule matches but IsTerminal: false, evaluation continues to the next rule.

# List all automation rules with their order and status
aws securityhub list-automation-rules \
  --query 'AutomationRulesMetadata[*].{Name:RuleName,Order:RuleOrder,Status:RuleStatus,Terminal:IsTerminal}'

# Recommended rule ordering for MCP server environments:
# Order 10-49:  Critical escalations (NEVER terminal — let other rules also run)
# Order 50-99:  Enrichment rules (add context, tags, notes — never terminal)
# Order 100-499: Standard suppression rules (terminal=true — stop after suppression)
# Order 500-999: Catch-all fallbacks

# Example: both rules below apply to a single HIGH prod finding
# Rule order 50 (is_terminal=false): escalates HIGH → CRITICAL for prod resources
# Rule order 200 (is_terminal=true): suppresses CRITICAL findings from approved scanner
#
# If finding comes from prod resource AND approved scanner:
# 1. Order 50 runs: severity escalated to CRITICAL, continues evaluation
# 2. Order 200 runs: CRITICAL + approved-scanner matches → workflow = SUPPRESSED, stops
# Result: finding escalated AND suppressed (scanner output accepted as known risk)

# Update rule order (re-priority without recreating)
aws securityhub update-automation-rules \
  --update-automation-rules-request-items '[{
    "RuleArn": "arn:aws:securityhub:us-east-1:123456789012:automation-rule/suppress-low-sev-dev-accounts",
    "RuleOrder": 150
  }]'

Condition types and comparators

Automation rule conditions use the same filter structure as GetFindings. Different ASFF fields support different comparator types.

# String comparators: EQUALS | PREFIX | NOT_EQUALS | PREFIX_NOT_EQUALS | CONTAINS | NOT_CONTAINS
# Number comparators: EQUALS | NOT_EQUALS | GT | GTE | LT | LTE
# Date comparators: Start, End (ISO 8601 date range)

# Match findings by generator type prefix (all GuardDuty findings)
aws securityhub create-automation-rule \
  --rule-name "tag-guardduty-findings" \
  --rule-order 10 \
  --is-terminal false \
  --rule-status ENABLED \
  --criteria '{
    "GeneratorId": [{"Value": "arn:aws:guardduty:", "Comparison": "PREFIX"}]
  }' \
  --actions '[{
    "Type": "FINDING_FIELDS_UPDATE",
    "FindingFieldsUpdate": {
      "UserDefinedFields": {
        "finding_source": "guardduty",
        "requires_incident_response": "true"
      }
    }
  }]'

# Match by finding type prefix
# criteria: {"Type": [{"Value": "TTPs/", "Comparison": "PREFIX"}]}

# Match by normalized severity number range (equivalent to CRITICAL: 76-100)
# criteria: {"SeverityNormalized": [{"Gte": 76, "Lte": 100}]}

# Match by resource type
# criteria: {"ResourceType": [{"Value": "AwsLambdaFunction", "Comparison": "EQUALS"}]}

# Match by specific finding title containing keyword
# criteria: {"Title": [{"Value": "credential", "Comparison": "CONTAINS"}]}

# Match by date — findings created in the last 24 hours
# criteria: {"CreatedAt": [{"Start": "2026-10-07T00:00:00Z", "End": "2026-10-08T23:59:59Z"}]}

Automation rules vs EventBridge — choosing the right tool

Both automation rules and EventBridge react to Security Hub findings, but they have different capabilities and purposes. Most MCP server security pipelines use both together.

# Example combined pipeline: automation rule + EventBridge

# Step 1: Automation rule adds UserDefinedField to mark high-priority findings
# (done above — tags CRITICAL findings with requires_incident_response=true)

# Step 2: EventBridge rule fires on Security Hub findings where that field is set
# EventBridge pattern:
{
  "source": ["aws.securityhub"],
  "detail-type": ["Security Hub Findings - Imported"],
  "detail": {
    "findings": {
      "Severity": {"Label": ["CRITICAL"]},
      "UserDefinedFields": {
        "requires_incident_response": ["true"]
      }
    }
  }
}

# EventBridge target: Lambda that creates PagerDuty incident + JIRA ticket + Slack alert
# The automation rule ran first (normalized severity, added context)
# EventBridge sees the final normalized finding with full context

Managing automation rules

# List all rules (metadata only — no conditions/actions)
aws securityhub list-automation-rules

# Get full rule details including conditions and actions
aws securityhub batch-get-automation-rules \
  --automation-rules-arns '[
    "arn:aws:securityhub:us-east-1:123456789012:automation-rule/suppress-low-sev-dev-accounts"
  ]'

# Disable a rule (preserves configuration, stops evaluation)
aws securityhub update-automation-rules \
  --update-automation-rules-request-items '[{
    "RuleArn": "arn:aws:securityhub:us-east-1:123456789012:automation-rule/suppress-low-sev-dev-accounts",
    "RuleStatus": "DISABLED"
  }]'

# Delete rules (permanently removes)
aws securityhub batch-delete-automation-rules \
  --automation-rules-arns '[
    "arn:aws:securityhub:us-east-1:123456789012:automation-rule/old-rule-name"
  ]'

# Automation rules do NOT retroactively apply to existing findings
# They only run when a finding is created or updated
# To retroactively suppress existing findings: use batch-update-findings with a GetFindings filter

Failure modes reference