AWS Security Hub Compliance Standards — CIS, PCI DSS, FSBP, NIST for MCP Servers

Available standards and Standard ARNs

Security Hub offers six standards. The ARN format includes the region — each standard must be enabled per-region.

# List all available standards in current region
aws securityhub describe-standards \
  --query 'Standards[*].{Name:Name,Arn:StandardsArn,Status:EnabledByDefault}'

# Standard ARNs (us-east-1 — replace region for other regions):
# AWS Foundational Security Best Practices v1.0.0 (FSBP):
#   arn:aws:securityhub:us-east-1::standards/aws-foundational-security-best-practices/v/1.0.0
#
# CIS AWS Foundations Benchmark v1.2.0 (legacy — prefer 1.4 or 3.0):
#   arn:aws:securityhub:us-east-1::standards/cis-aws-foundations-benchmark/v/1.2.0
#
# CIS AWS Foundations Benchmark v1.4.0:
#   arn:aws:securityhub:us-east-1::standards/cis-aws-foundations-benchmark/v/1.4.0
#
# CIS AWS Foundations Benchmark v3.0.0:
#   arn:aws:securityhub:us-east-1::standards/cis-aws-foundations-benchmark/v/3.0.0
#
# PCI DSS v3.2.1:
#   arn:aws:securityhub:us-east-1::standards/pci-dss/v/3.2.1
#
# NIST SP 800-53 Rev 5:
#   arn:aws:securityhub:us-east-1::standards/nist-800-53/v/5.0.0

# Enable FSBP and CIS v1.4 (no default standards — selective choice):
aws securityhub batch-enable-standards \
  --standards-subscription-requests '[
    {"StandardsArn": "arn:aws:securityhub:us-east-1::standards/aws-foundational-security-best-practices/v/1.0.0"},
    {"StandardsArn": "arn:aws:securityhub:us-east-1::standards/cis-aws-foundations-benchmark/v/1.4.0"}
  ]'

# Check enabled standards and their status
aws securityhub get-enabled-standards
# Status: READY = controls running; INCOMPLETE = some controls failed to initialize
# StandardsSubscriptionArn returned — needed for control management

Disabling irrelevant controls

After enabling a standard, disable controls that don't apply to your MCP server infrastructure. A FAILED finding on a disabled control does not affect your compliance score and does not generate chargeable Config evaluations.

# List all controls for a standard with their current status
aws securityhub describe-standards-controls \
  --standards-subscription-arn "arn:aws:securityhub:us-east-1:123456789012:subscription/aws-foundational-security-best-practices/v/1.0.0" \
  --query 'Controls[*].{Id:ControlId,Title:Title,Status:ControlStatus,Severity:SeverityRating}'

# Disable a specific control (legacy STANDARD_CONTROL mode)
aws securityhub update-standards-control \
  --standards-control-arn "arn:aws:securityhub:us-east-1:123456789012:control/aws-foundational-security-best-practices/v/1.0.0/IAM.6" \
  --control-status DISABLED \
  --disabled-reason "MFA hardware tokens not applicable to service accounts used by MCP automation"

# In SECURITY_CONTROL mode (recommended), disable across all standards at once:
aws securityhub batch-update-standards-control-associations \
  --standards-control-association-updates '[
    {
      "SecurityControlId": "IAM.6",
      "StandardsArn": "arn:aws:securityhub:us-east-1::standards/aws-foundational-security-best-practices/v/1.0.0",
      "AssociationStatus": "DISABLED",
      "UpdatedReason": "Hardware MFA not applicable to machine accounts"
    },
    {
      "SecurityControlId": "IAM.9",
      "StandardsArn": "arn:aws:securityhub:us-east-1::standards/aws-foundational-security-best-practices/v/1.0.0",
      "AssociationStatus": "DISABLED",
      "UpdatedReason": "Virtual MFA on root account managed by Organizations SCP"
    }
  ]'

# Get compliance score for a specific standard
aws securityhub get-enabled-standards \
  --query 'StandardsSubscriptions[?StandardsArn==`arn:aws:securityhub:us-east-1::standards/aws-foundational-security-best-practices/v/1.0.0`].StandardsStatus'

Controls to commonly disable for MCP server accounts that use AWS Organizations service control policies (SCPs) to govern root account access:

Key FSBP controls for MCP server deployments

FSBP covers the AWS services MCP servers most commonly use. These are the highest-signal controls for a typical MCP deployment on ECS, Lambda, or EC2.

# Query findings for specific control IDs to assess current compliance
aws securityhub get-findings \
  --filters '{
    "ComplianceSecurityControlId": [
      {"Value": "EC2.2", "Comparison": "EQUALS"},
      {"Value": "EC2.19", "Comparison": "EQUALS"},
      {"Value": "Lambda.1", "Comparison": "EQUALS"},
      {"Value": "ECS.2", "Comparison": "EQUALS"}
    ],
    "ComplianceStatus": [{"Value": "FAILED", "Comparison": "EQUALS"}],
    "RecordState": [{"Value": "ACTIVE", "Comparison": "EQUALS"}]
  }' \
  --query 'Findings[*].{Control:Compliance.SecurityControlId,Resource:Resources[0].Id,Status:Compliance.Status}'

Control evaluation types and timing

Security Hub controls run as Config rules with two evaluation modes: periodic (runs on a schedule) and change-triggered (runs when the relevant resource is created or modified). Understanding the mode matters for how quickly a finding appears after you fix a misconfiguration.

# Find out if a control is periodic or change-triggered
aws configservice describe-config-rules \
  --config-rule-names "SecurityHub-EC2.2-a1b2c3d4e5" \
  --query 'ConfigRules[0].{Source:Source.SourceDetails[0].MessageType,Frequency:MaximumExecutionFrequency}'

# Periodic controls run on these frequencies:
# One_Hour | Three_Hours | Six_Hours | Twelve_Hours | TwentyFour_Hours
# Most CIS and FSBP controls run every 12 or 24 hours for periodic checks

# Force a re-evaluation on a specific rule (for change-triggered rules):
aws configservice start-config-rules-evaluation \
  --config-rule-names "SecurityHub-IAM.1-f6g7h8i9j0"

# After fixing a control violation, findings update on next evaluation cycle
# For periodic controls: may take up to 24 hours to show PASSED
# For change-triggered controls: typically updates within 5-15 minutes of resource change

# Check what Config rules Security Hub has created in your account
aws configservice describe-config-rules \
  --query 'ConfigRules[?contains(ConfigRuleName, `SecurityHub`)].{Name:ConfigRuleName,State:ConfigRuleState}' \
  | head -30

After remediating a failing control (e.g., enabling VPC flow logs for EC2.6), the finding does not immediately update to PASSED. Change-triggered controls re-evaluate within minutes of the resource change. Periodic controls (common for account-level checks like root MFA, GuardDuty enablement) re-evaluate on their fixed schedule — up to 24 hours. Use start-config-rules-evaluation to trigger an immediate re-evaluation without waiting for the next scheduled cycle.

Failure modes reference