# Control reference for Security Hub CSPM
<a name="securityhub-controls-reference"></a>

This control reference provides a table of available AWS Security Hub CSPM controls with links to more information about each control. In the table, controls are listed in alphabetical order by control ID. Only controls in active use by Security Hub CSPM are included here. Retired controls are excluded from the table.

The table provides the following information for each control:
+ **Security control ID** – This ID applies across standards and indicates the AWS service and resource that the control relates to. The Security Hub CSPM console displays security control IDs, regardless of whether [consolidated control findings](controls-findings-create-update.md#consolidated-control-findings) is turned on or off in your account. However, Security Hub CSPM findings reference security control IDs only if consolidated control findings is turned on in your account. If consolidated control findings is turned off in your account, some control IDs vary by standard in your control findings. For a mapping of standard-specific control IDs to security control IDs, see [How consolidation impacts control IDs and titles](asff-changes-consolidation.md#securityhub-findings-format-changes-ids-titles).

  If you want to set up [automations](automations.md) for security controls, we recommend filtering based on control ID rather than title or description. Whereas Security Hub CSPM may occasionally update control titles or descriptions, control IDs stay the same.

  Control IDs may skip numbers. These are placeholders for future controls.
+ **Security control title** – This title applies across standards. The Security Hub CSPM console displays security control titles, regardless of whether consolidated control findings is turned on or off in your account. However, Security Hub CSPM findings reference security control titles only if consolidated control findings is turned on in your account. If consolidated control findings is turned off in your account, some control titles vary by standard in your control findings. For a mapping of standard-specific control IDs to security control IDs, see [How consolidation impacts control IDs and titles](asff-changes-consolidation.md#securityhub-findings-format-changes-ids-titles).
+ **Applicable standards** – Indicates which standards a control applies to. Choose a control to review specific requirements from third-party compliance frameworks.
+ **Severity** – The severity of a control identifies its importance from a security standpoint. For information about how Security Hub CSPM determines control severity, see [Severity levels for control findings](controls-findings-create-update.md#control-findings-severity).
+ **Supports custom parameters** – Indicates whether the control supports custom values for one or more parameters. Choose a control to review the parameter details. For more information, see [Understanding control parameters in Security Hub CSPM](custom-control-parameters.md).
+ **Schedule type** – Indicates when the control is evaluated. For more information, see [Schedule for running security checks](securityhub-standards-schedule.md).

Choose a control to review additional details. Controls are listed in alphabetical order by security control ID.


| Security control ID | Security control title | Applicable standards | Severity | Supports custom parameters | Schedule type | 
| --- | --- | --- | --- | --- | --- | 
| [Account.1](account-controls.md#account-1)  | Security contact information should be provided for an AWS account  | CIS AWS Foundations Benchmark v5.0.0, CIS AWS Foundations Benchmark v3.0.0, AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5  | MEDIUM  | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  | Periodic  | 
|  [Account.2](account-controls.md#account-2)  |  AWS account should be part of an AWS Organizations organization  |  NIST SP 800-53 Rev. 5  |  HIGH  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Periodic  | 
|  [ACM.1](acm-controls.md#acm-1)  |  Imported and ACM-issued certificates should be renewed after a specified time period  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5, NIST SP 800-171 Rev. 2, PCI DSS v4.0.1 |  MEDIUM  |  ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes  |  Change triggered and periodic  | 
|  [ACM.2](acm-controls.md#acm-2)  |  RSA certificates managed by ACM should use a key length of at least 2,048 bits  | AWS Foundational Security Best Practices v1.0.0, PCI DSS v4.0.1 |  HIGH  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [ACM.3](acm-controls.md#acm-3)  | ACM certificates should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [Amplify.1](amplify-controls.md#amplify-1)  | Amplify apps should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [Amplify.2](amplify-controls.md#amplify-2)  | Amplify branches should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [APIGateway.1](apigateway-controls.md#apigateway-1)  |  API Gateway REST and WebSocket API execution logging should be enabled  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5  |  MEDIUM  |  ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes  |  Change triggered  | 
|  [APIGateway.2](apigateway-controls.md#apigateway-2)  |  API Gateway REST API stages should be configured to use SSL certificates for backend authentication  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5, NIST SP 800-171 Rev. 2  |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [APIGateway.3](apigateway-controls.md#apigateway-3)  |  API Gateway REST API stages should have AWS X-Ray tracing enabled  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5  |  LOW  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [APIGateway.4](apigateway-controls.md#apigateway-4)  |  API Gateway should be associated with a WAF Web ACL  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5  |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [APIGateway.5](apigateway-controls.md#apigateway-5)  |  API Gateway REST API cache data should be encrypted at rest  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5  |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [APIGateway.8](apigateway-controls.md#apigateway-8)  |  API Gateway routes should specify an authorization type  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5  |  MEDIUM  |  ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes  |  Periodic  | 
|  [APIGateway.9](apigateway-controls.md#apigateway-9)  |  Access logging should be configured for API Gateway V2 Stages  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5, PCI DSS v4.0.1 |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [APIGateway.10](apigateway-controls.md#apigateway-10)  |  API Gateway V2 integrations should use HTTPS for private connections  |  AWS Foundational Security Best Practices v1.0.0  |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [APIGateway.11](apigateway-controls.md#apigateway-11)  |  API Gateway domain names should use recommended security policies  |  AWS Foundational Security Best Practices  |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [AppConfig.1](appconfig-controls.md#appconfig-1)  | AWS AppConfig applications should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [AppConfig.2](appconfig-controls.md#appconfig-2)  | AWS AppConfig configuration profiles should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [AppConfig.3](appconfig-controls.md#appconfig-3)  | AWS AppConfig environments should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [AppConfig.4](appconfig-controls.md#appconfig-4)  | AWS AppConfig extension associations should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [AppFlow.1](appflow-controls.md#appflow-1)  | Amazon AppFlow flows should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [AppRunner.1](apprunner-controls.md#apprunner-1)  | App Runner services should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [AppRunner.2](apprunner-controls.md#apprunner-2)  | App Runner VPC connectors should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [AppSync.2](appsync-controls.md#appsync-2)  |  AWS AppSync should have field-level logging enabled  |  AWS Foundational Security Best Practices v1.0.0, PCI DSS v4.0.1 |  MEDIUM  |  ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes  |  Change triggered  | 
|  [AppSync.4](appsync-controls.md#appsync-4)  | AWS AppSync GraphQL APIs should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [AppSync.5](appsync-controls.md#appsync-5)  |  AWS AppSync GraphQL APIs should not be authenticated with API keys  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5  |  HIGH  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [Athena.2](athena-controls.md#athena-2)  | Athena data catalogs should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [Athena.3](athena-controls.md#athena-3)  | Athena workgroups should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [Athena.4](athena-controls.md#athena-4)  | Athena workgroups should have logging enabled | AWS Foundational Security Best Practices | MEDIUM | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Change triggered | 
|  [AutoScaling.1](autoscaling-controls.md#autoscaling-1)  | Auto Scaling groups associated with a load balancer should use ELB health checks | AWS Foundational Security Best Practices, PCI DSS v3.2.1, NIST SP 800-53 Rev. 5 | LOW | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Change triggered | 
|  [AutoScaling.2](autoscaling-controls.md#autoscaling-2)  |  Amazon EC2 Auto Scaling group should cover multiple Availability Zones  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5  |  MEDIUM  |  ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes  |  Change triggered  | 
|  [AutoScaling.3](autoscaling-controls.md#autoscaling-3)  |  Auto Scaling group launch configurations should configure EC2 instances to require Instance Metadata Service Version 2 (IMDSv2)  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5, PCI DSS v4.0.1 |  HIGH  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [Autoscaling.5](autoscaling-controls.md#autoscaling-5)  |  Amazon EC2 instances launched using Auto Scaling group launch configurations should not have Public IP addresses  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5, PCI DSS v4.0.1 |  HIGH  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [AutoScaling.6](autoscaling-controls.md#autoscaling-6)  |  Auto Scaling groups should use multiple instance types in multiple Availability Zones  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5  |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [AutoScaling.9](autoscaling-controls.md#autoscaling-9)  |  EC2 Auto Scaling groups should use EC2 launch templates  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5  |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [AutoScaling.10](autoscaling-controls.md#autoscaling-10)  | EC2 Auto Scaling groups should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [Backup.1](backup-controls.md#backup-1)  |  AWS Backup recovery points should be encrypted at rest  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5  |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [Backup.2](backup-controls.md#backup-2)  | AWS Backup recovery points should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [Backup.3](backup-controls.md#backup-3)  | AWS Backup vaults should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [Backup.4](backup-controls.md#backup-4)  | AWS Backup report plans should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [Backup.5](backup-controls.md#backup-5)  | AWS Backup backup plans should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [Batch.1](batch-controls.md#batch-1)  | Batch job queues should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [Batch.2](batch-controls.md#batch-2)  | Batch scheduling policies should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [Batch.3](batch-controls.md#batch-3)  | Batch compute environments should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [Batch.4](batch-controls.md#batch-4)  | Compute resources properties in managed Batch compute environments should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [CloudFormation.2](cloudformation-controls.md#cloudformation-2)  | CloudFormation stacks should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [CloudFormation.3](cloudformation-controls.md#cloudformation-3)  | CloudFormation stacks should have termination protection enabled | AWS Foundational Security Best Practices | MEDIUM | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Change triggered | 
|  [CloudFormation.4](cloudformation-controls.md#cloudformation-4)  | CloudFormation stacks should have associated service roles | AWS Foundational Security Best Practices | MEDIUM | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Change triggered | 
|  [CloudFront.1](cloudfront-controls.md#cloudfront-1)  | CloudFront distributions should have a default root object configured | AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5, PCI DSS v4.0.1 | HIGH | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Change triggered | 
|  [CloudFront.3](cloudfront-controls.md#cloudfront-3)  |  CloudFront distributions should require encryption in transit  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5, PCI DSS v4.0.1 |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [CloudFront.4](cloudfront-controls.md#cloudfront-4)  |  CloudFront distributions should have origin failover configured  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5  |  LOW  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [CloudFront.5](cloudfront-controls.md#cloudfront-5)  |  CloudFront distributions should have logging enabled  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5, PCI DSS v4.0.1 |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [CloudFront.6](cloudfront-controls.md#cloudfront-6)  |  CloudFront distributions should have WAF enabled  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5, PCI DSS v4.0.1 |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [CloudFront.7](cloudfront-controls.md#cloudfront-7)  |  CloudFront distributions should use custom SSL/TLS certificates  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5, NIST SP 800-171 Rev. 2  | LOW |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [CloudFront.8](cloudfront-controls.md#cloudfront-8)  |  CloudFront distributions should use SNI to serve HTTPS requests  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5  |  LOW  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [CloudFront.9](cloudfront-controls.md#cloudfront-9)  |  CloudFront distributions should encrypt traffic to custom origins  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5, PCI DSS v4.0.1 |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [CloudFront.10](cloudfront-controls.md#cloudfront-10)  |  CloudFront distributions should not use deprecated SSL protocols between edge locations and custom origins  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5, NIST SP 800-171 Rev. 2, PCI DSS v4.0.1 |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [CloudFront.12](cloudfront-controls.md#cloudfront-12)  |  CloudFront distributions should not point to non-existent S3 origins  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5, PCI DSS v4.0.1 |  HIGH  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Periodic  | 
|  [CloudFront.13](cloudfront-controls.md#cloudfront-13)  |  CloudFront distributions should use origin access control  |  AWS Foundational Security Best Practices v1.0.0  |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [CloudFront.14](cloudfront-controls.md#cloudfront-14)  | CloudFront distributions should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [CloudFront.15](cloudfront-controls.md#cloudfront-15)  | CloudFront distributions should use the recommended TLS security policy | AWS Foundational Security Best Practices v1.0.0 | MEDIUM | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Change triggered | 
|  [CloudFront.16](cloudfront-controls.md#cloudfront-16)  | CloudFront distributions should use origin access control for Lambda function URL origins | AWS Foundational Security Best Practices v1.0.0 | MEDIUM | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Change triggered | 
|  [CloudFront.17](cloudfront-controls.md#cloudfront-17)  | CloudFront distributions should use trusted key groups for signed URLs and cookies | AWS Foundational Security Best Practices v1.0.0 | MEDIUM | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Change triggered | 
|  [CloudTrail.1](cloudtrail-controls.md#cloudtrail-1)  | CloudTrail should be enabled and configured with at least one multi-Region trail that includes read and write management events | CIS AWS Foundations Benchmark v5.0.0, CIS AWS Foundations Benchmark v3.0.0, CIS AWS Foundations Benchmark v1.4.0, CIS AWS Foundations Benchmark v1.2.0, AWS Foundational Security Best Practices, NIST SP 800-53 Rev. 5 | HIGH | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Periodic | 
|  [CloudTrail.2](cloudtrail-controls.md#cloudtrail-2)  |  CloudTrail should have encryption at-rest enabled  | CIS AWS Foundations Benchmark v5.0.0, CIS AWS Foundations Benchmark v3.0.0, CIS AWS Foundations Benchmark v1.2.0, CIS AWS Foundations Benchmark v1.4.0 AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5, NIST SP 800-171 Rev. 2, PCI DSS v3.2.1, PCI DSS v4.0.1 |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Periodic  | 
|  [CloudTrail.3](cloudtrail-controls.md#cloudtrail-3)  | At least one CloudTrail trail should be enabled | NIST SP 800-171 Rev. 2, PCI DSS v4.0.1, PCI DSS v3.2.1 | HIGH | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Periodic | 
|  [CloudTrail.4](cloudtrail-controls.md#cloudtrail-4)  |  CloudTrail log file validation should be enabled  | CIS AWS Foundations Benchmark v5.0.0, CIS AWS Foundations Benchmark v3.0.0, CIS AWS Foundations Benchmark v1.4.0, CIS AWS Foundations Benchmark v1.2.0, AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5, NIST SP 800-171 Rev. 2, PCI DSS v4.0.1, PCI DSS v3.2.1 |  LOW  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Periodic  | 
|  [CloudTrail.5](cloudtrail-controls.md#cloudtrail-5)  |  CloudTrail trails should be integrated with Amazon CloudWatch Logs  | CIS AWS Foundations Benchmark v1.2.0, CIS AWS Foundations Benchmark v1.4.0, AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5, PCI DSS v3.2.1, PCI DSS v4.0.1 | MEDIUM |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Periodic  | 
|  [CloudTrail.6](cloudtrail-controls.md#cloudtrail-6)  |  Ensure the S3 bucket used to store CloudTrail logs is not publicly accessible  |  CIS AWS Foundations Benchmark v1.2.0, CIS AWS Foundations Benchmark v1.4.0, PCI DSS v4.0.1 |  CRITICAL  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered and periodic  | 
|  [CloudTrail.7](cloudtrail-controls.md#cloudtrail-7)  |  Ensure S3 bucket access logging is enabled on the CloudTrail S3 bucket  | CIS AWS Foundations Benchmark v5.0.0, CIS AWS Foundations Benchmark v3.0.0, CIS AWS Foundations Benchmark v1.2.0, CIS AWS Foundations Benchmark v1.4.0, CIS AWS Foundations Benchmark v3.0.0, PCI DSS v4.0.1 |  LOW  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Periodic  | 
|  [CloudTrail.9](cloudtrail-controls.md#cloudtrail-9)  | CloudTrail trails should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [CloudTrail.10](cloudtrail-controls.md#cloudtrail-10)  | CloudTrail Lake event data stores should be encrypted with customer managed AWS KMS keys | NIST SP 800-53 Rev. 5 | MEDIUM | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Periodic | 
|  [CloudWatch.1](cloudwatch-controls.md#cloudwatch-1)  |  A log metric filter and alarm should exist for usage of the "root" user  | CIS AWS Foundations Benchmark v1.4.0, CIS AWS Foundations Benchmark v1.2.0, NIST SP 800-171 Rev. 2, PCI DSS v3.2.1 |  LOW  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Periodic  | 
|  [CloudWatch.2](cloudwatch-controls.md#cloudwatch-2)  |  Ensure a log metric filter and alarm exist for unauthorized API calls  | CIS AWS Foundations Benchmark v1.2.0, NIST SP 800-171 Rev. 2 |  LOW  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Periodic  | 
|  [CloudWatch.3](cloudwatch-controls.md#cloudwatch-3)  |  Ensure a log metric filter and alarm exist for Management Console sign-in without MFA  | CIS AWS Foundations Benchmark v1.2.0  |  LOW  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Periodic  | 
|  [CloudWatch.4](cloudwatch-controls.md#cloudwatch-4)  |  Ensure a log metric filter and alarm exist for IAM policy changes  | CIS AWS Foundations Benchmark v1.4.0, CIS AWS Foundations Benchmark v1.2.0, NIST SP 800-171 Rev. 2 |  LOW  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Periodic  | 
|  [CloudWatch.5](cloudwatch-controls.md#cloudwatch-5)  |  Ensure a log metric filter and alarm exist for CloudTrail configuration changes  | CIS AWS Foundations Benchmark v1.4.0, CIS AWS Foundations Benchmark v1.2.0, NIST SP 800-171 Rev. 2 |  LOW  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Periodic  | 
|  [CloudWatch.6](cloudwatch-controls.md#cloudwatch-6)  |  Ensure a log metric filter and alarm exist for AWS Management Console authentication failures  | CIS AWS Foundations Benchmark v1.4.0, CIS AWS Foundations Benchmark v1.2.0, NIST SP 800-171 Rev. 2 |  LOW  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Periodic  | 
|  [CloudWatch.7](cloudwatch-controls.md#cloudwatch-7)  |  Ensure a log metric filter and alarm exist for disabling or scheduled deletion of customer created CMKs  | CIS AWS Foundations Benchmark v1.4.0, CIS AWS Foundations Benchmark v1.2.0, NIST SP 800-171 Rev. 2  |  LOW  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Periodic  | 
|  [CloudWatch.8](cloudwatch-controls.md#cloudwatch-8)  |  Ensure a log metric filter and alarm exist for S3 bucket policy changes  | CIS AWS Foundations Benchmark v1.4.0, CIS AWS Foundations Benchmark v1.2.0, NIST SP 800-171 Rev. 2 |  LOW  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Periodic  | 
|  [CloudWatch.9](cloudwatch-controls.md#cloudwatch-9)  |  Ensure a log metric filter and alarm exist for AWS Config configuration changes  | CIS AWS Foundations Benchmark v1.4.0, CIS AWS Foundations Benchmark v1.2.0, NIST SP 800-171 Rev. 2  |  LOW  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Periodic  | 
|  [CloudWatch.10](cloudwatch-controls.md#cloudwatch-10)  |  Ensure a log metric filter and alarm exist for security group changes  | CIS AWS Foundations Benchmark v1.4.0, CIS AWS Foundations Benchmark v1.2.0, NIST SP 800-171 Rev. 2 |  LOW  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Periodic  | 
|  [CloudWatch.11](cloudwatch-controls.md#cloudwatch-11)  |  Ensure a log metric filter and alarm exist for changes to Network Access Control Lists (NACL)  | CIS AWS Foundations Benchmark v1.4.0, CIS AWS Foundations Benchmark v1.2.0, NIST SP 800-171 Rev. 2  |  LOW  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Periodic  | 
|  [CloudWatch.12](cloudwatch-controls.md#cloudwatch-12)  |  Ensure a log metric filter and alarm exist for changes to network gateways  | CIS AWS Foundations Benchmark v1.4.0, CIS AWS Foundations Benchmark v1.2.0, NIST SP 800-171 Rev. 2 |  LOW  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Periodic  | 
|  [CloudWatch.13](cloudwatch-controls.md#cloudwatch-13)  |  Ensure a log metric filter and alarm exist for route table changes  | CIS AWS Foundations Benchmark v1.4.0, CIS AWS Foundations Benchmark v1.2.0, NIST SP 800-171 Rev. 2  |  LOW  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Periodic  | 
|  [CloudWatch.14](cloudwatch-controls.md#cloudwatch-14)  |  Ensure a log metric filter and alarm exist for VPC changes  | CIS AWS Foundations Benchmark v1.4.0, CIS AWS Foundations Benchmark v1.2.0, NIST SP 800-171 Rev. 2 |  LOW  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Periodic  | 
|  [CloudWatch.15](cloudwatch-controls.md#cloudwatch-15)  |  CloudWatch alarms should have specified actions configured  | NIST SP 800-53 Rev. 5, NIST SP 800-171 Rev. 2 |  HIGH  |  ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes  |  Change triggered  | 
|  [CloudWatch.16](cloudwatch-controls.md#cloudwatch-16)  |  CloudWatch log groups should be retained for a specified time period  |  NIST SP 800-53 Rev. 5  |  MEDIUM  |  ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes  |  Periodic  | 
|  [CloudWatch.17](cloudwatch-controls.md#cloudwatch-17)  |  CloudWatch alarm actions should be enabled  |  NIST SP 800-53 Rev. 5  |  HIGH  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [CodeArtifact.1](codeartifact-controls.md#codeartifact-1)  | CodeArtifact repositories should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [CodeBuild.1](codebuild-controls.md#codebuild-1)  | CodeBuild Bitbucket source repository URLs should not contain sensitive credentials | AWS Foundational Security Best Practices, NIST SP 800-53 Rev. 5, PCI DSS v3.2.1, PCI DSS v4.0.1 | CRITICAL | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Change triggered | 
|  [CodeBuild.2](codebuild-controls.md#codebuild-2)  |  CodeBuild project environment variables should not contain clear text credentials  | AWS Foundational Security Best Practices, NIST SP 800-53 Rev. 5, PCI DSS v3.2.1, PCI DSS v4.0.1 |  CRITICAL  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [CodeBuild.3](codebuild-controls.md#codebuild-3)  |  CodeBuild S3 logs should be encrypted  | AWS Foundational Security Best Practices, NIST SP 800-53 Rev. 5, PCI DSS v4.0.1, |  LOW  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [CodeBuild.4](codebuild-controls.md#codebuild-4)  |  CodeBuild project environments should have a logging configuration  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5  |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [CodeBuild.7](codebuild-controls.md#codebuild-7)  | CodeBuild report group exports should be encrypted at rest | AWS Foundational Security Best Practices | MEDIUM | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Change triggered | 
|  [CodeGuruProfiler.1](codeguruprofiler-controls.md#codeguruprofiler-1)  | CodeGuru Profiler profiling groups should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [CodeGuruReviewer.1](codegurureviewer-controls.md#codegurureviewer-1)  | CodeGuru Reviewer repository associations should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [Cognito.1](cognito-controls.md#cognito-1)  | Cognito user pools should have threat protection activated with full function enforcement mode for standard authentication | AWS Foundational Security Best Practices | MEDIUM | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [Cognito.2](cognito-controls.md#cognito-2)  | Cognito identity pools should not allow unauthenticated identities | AWS Foundational Security Best Practices | MEDIUM | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Change triggered | 
|  [Cognito.3](cognito-controls.md#cognito-3)  | Password policies for Cognito user pools should have strong configurations | AWS Foundational Security Best Practices | MEDIUM | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [Cognito.4](cognito-controls.md#cognito-4)  | Cognito user pools should have threat protection activated with full function enforcement mode for custom authentication | AWS Foundational Security Best Practices | MEDIUM | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Change triggered | 
|  [Cognito.5](cognito-controls.md#cognito-5)  | MFA should be enabled for Cognito user pools | AWS Foundational Security Best Practices | MEDIUM | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Change triggered | 
|  [Cognito.6](cognito-controls.md#cognito-6)  | Cognito user pools should have deletion protection enabled | AWS Foundational Security Best Practices | MEDIUM | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Change triggered | 
|  [Config.1](config-controls.md#config-1)  | AWS Config should be enabled and use the service-linked role for resource recording | CIS AWS Foundations Benchmark v5.0.0, CIS AWS Foundations Benchmark v3.0.0, CIS AWS Foundations Benchmark v1.4.0, CIS AWS Foundations Benchmark v1.2.0, AWS Foundational Security Best Practices, NIST SP 800-53 Rev. 5, PCI DSS v3.2.1 | CRITICAL | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Periodic | 
|  [Connect.1](connect-controls.md#connect-1)  | Amazon Connect Customer Profiles object types should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [Connect.2](connect-controls.md#connect-2)  | Amazon Connect instances should have CloudWatch logging enabled | AWS Foundational Security Best Practices | MEDIUM | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Change triggered | 
|  [DataFirehose.1](datafirehose-controls.md#datafirehose-1)  | Firehose delivery streams should be encrypted at rest | AWS Foundational Security Best Practices, NIST SP 800-53 Rev. 5 | MEDIUM | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Periodic | 
|  [DataSync.1](datasync-controls.md#datasync-1)  | DataSync tasks should have logging enabled | AWS Foundational Security Best Practices | MEDIUM | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Change triggered | 
|  [DataSync.2](datasync-controls.md#datasync-2)  | DataSync tasks should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [Detective.1](detective-controls.md#detective-1)  | Detective behavior graphs should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [DMS.1](dms-controls.md#dms-1)  |  Database Migration Service replication instances should not be public  | AWS Foundational Security Best Practices, NIST SP 800-53 Rev. 5, PCI DSS v3.2.1, PCI DSS v4.0.1 |  CRITICAL  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Periodic  | 
|  [DMS.2](dms-controls.md#dms-2)  | DMS certificates should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [DMS.3](dms-controls.md#dms-3)  | DMS event subscriptions should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [DMS.4](dms-controls.md#dms-4)  | DMS replication instances should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [DMS.5](dms-controls.md#dms-5)  | DMS replication subnet groups should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [DMS.6](dms-controls.md#dms-6)  |  DMS replication instances should have automatic minor version upgrade enabled  | AWS Foundational Security Best Practices, NIST SP 800-53 Rev. 5, PCI DSS v4.0.1 |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [DMS.7](dms-controls.md#dms-7)  |  DMS replication tasks for the target database should have logging enabled  | AWS Foundational Security Best Practices, NIST SP 800-53 Rev. 5, PCI DSS v4.0.1 |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [DMS.8](dms-controls.md#dms-8)  |  DMS replication tasks for the source database should have logging enabled  | AWS Foundational Security Best Practices, NIST SP 800-53 Rev. 5, PCI DSS v4.0.1 |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [DMS.9](dms-controls.md#dms-9)  |  DMS endpoints should use SSL  | AWS Foundational Security Best Practices, NIST SP 800-53 Rev. 5, PCI DSS v4.0.1 |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [DMS.10](dms-controls.md#dms-10)  | DMS endpoints for Neptune databases should have IAM authorization enabled | AWS Foundational Security Best Practices, NIST SP 800-53 Rev. 5, PCI DSS v4.0.1 | MEDIUM | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Change triggered | 
|  [DMS.11](dms-controls.md#dms-11)  | DMS endpoints for MongoDB should have an authentication mechanism enabled | AWS Foundational Security Best Practices, NIST SP 800-53 Rev. 5, PCI DSS v4.0.1 | MEDIUM | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Change triggered | 
|  [DMS.12](dms-controls.md#dms-12)  | DMS endpoints for Redis OSS should have TLS enabled | AWS Foundational Security Best Practices, NIST SP 800-53 Rev. 5, PCI DSS v4.0.1 | MEDIUM | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Change triggered | 
|  [DMS.13](dms-controls.md#dms-13)  | DMS replication instances should be configured to use multiple Availability Zones | AWS Foundational Security Best Practices | MEDIUM | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Change triggered | 
|  [DocumentDB.1](documentdb-controls.md#documentdb-1)  |  Amazon DocumentDB clusters should be encrypted at rest  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5  |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [DocumentDB.2](documentdb-controls.md#documentdb-2)  |  Amazon DocumentDB clusters should have an adequate backup retention period  | AWS Foundational Security Best Practices, NIST SP 800-53 Rev. 5, PCI DSS v4.0.1  |  MEDIUM  |  ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes  |  Change triggered  | 
|  [DocumentDB.3](documentdb-controls.md#documentdb-3)  |  Amazon DocumentDB manual cluster snapshots should not be public  | AWS Foundational Security Best Practices, NIST SP 800-53 Rev. 5, PCI DSS v4.0.1 |  CRITICAL  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [DocumentDB.4](documentdb-controls.md#documentdb-4)  |  Amazon DocumentDB clusters should publish audit logs to CloudWatch Logs  | AWS Foundational Security Best Practices, NIST SP 800-53 Rev. 5, PCI DSS v4.0.1 |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [DocumentDB.5](documentdb-controls.md#documentdb-5)  |  Amazon DocumentDB clusters should have deletion protection enabled  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5  |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [DocumentDB.6](documentdb-controls.md#documentdb-6)  | Amazon DocumentDB clusters should be encrypted in transit | AWS Foundational Security Best Practices | MEDIUM | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Periodic | 
|  [DynamoDB.1](dynamodb-controls.md#dynamodb-1)  |  DynamoDB tables should automatically scale capacity with demand  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5  |  MEDIUM  |  ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes  |  Periodic  | 
|  [DynamoDB.2](dynamodb-controls.md#dynamodb-2)  |  DynamoDB tables should have point-in-time recovery enabled  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5  |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [DynamoDB.3](dynamodb-controls.md#dynamodb-3)  |  DynamoDB Accelerator (DAX) clusters should be encrypted at rest  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5  |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Periodic  | 
|  [DynamoDB.4](dynamodb-controls.md#dynamodb-4)  |  DynamoDB tables should be present in a backup plan  |  NIST SP 800-53 Rev. 5  |  MEDIUM  |  ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes  |  Periodic  | 
|  [DynamoDB.5](dynamodb-controls.md#dynamodb-5)  | DynamoDB tables should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [DynamoDB.6](dynamodb-controls.md#dynamodb-6)  |  DynamoDB tables should have deletion protection enabled  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5  |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [DynamoDB.7](dynamodb-controls.md#dynamodb-7)  | DynamoDB Accelerator clusters should be encrypted in transit | AWS Foundational Security Best Practices, NIST SP 800-53 Rev. 5, PCI DSS v4.0.1 | MEDIUM | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Periodic | 
|  [EC2.1](ec2-controls.md#ec2-1)  |  EBS snapshots should not be publicly restorable  |  AWS Foundational Security Best Practices v1.0.0, PCI DSS v3.2.1, NIST SP 800-53 Rev. 5  |  CRITICAL  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Periodic  | 
|  [EC2.2](ec2-controls.md#ec2-2)  |  VPC default security groups should not allow inbound or outbound traffic  | CIS AWS Foundations Benchmark v5.0.0, CIS AWS Foundations Benchmark v3.0.0, CIS AWS Foundations Benchmark v1.2.0, AWS Foundational Security Best Practices v1.0.0, PCI DSS v3.2.1, CIS AWS Foundations Benchmark v1.4.0, NIST SP 800-53 Rev. 5  |  HIGH  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [EC2.3](ec2-controls.md#ec2-3)  |  Attached EBS volumes should be encrypted at-rest  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5  |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [EC2.4](ec2-controls.md#ec2-4)  |  Stopped EC2 instances should be removed after a specified time period  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5  |  MEDIUM  |  ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes  |  Periodic  | 
|  [EC2.6](ec2-controls.md#ec2-6)  |  VPC flow logging should be enabled in all VPCs  | CIS AWS Foundations Benchmark v5.0.0, CIS AWS Foundations Benchmark v3.0.0, CIS AWS Foundations Benchmark v1.2.0, AWS Foundational Security Best Practices v1.0.0, PCI DSS v3.2.1, CIS AWS Foundations Benchmark v1.4.0, NIST SP 800-53 Rev. 5, NIST SP 800-171 Rev. 2  |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Periodic  | 
|  [EC2.7](ec2-controls.md#ec2-7)  |  EBS default encryption should be enabled  | CIS AWS Foundations Benchmark v5.0.0, CIS AWS Foundations Benchmark v3.0.0, AWS Foundational Security Best Practices v1.0.0, CIS AWS Foundations Benchmark v1.4.0, NIST SP 800-53 Rev. 5  |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Periodic  | 
|  [EC2.8](ec2-controls.md#ec2-8)  |  EC2 instances should use Instance Metadata Service Version 2 (IMDSv2)  | CIS AWS Foundations Benchmark v5.0.0, CIS AWS Foundations Benchmark v3.0.0, AWS Foundational Security Best Practices, NIST SP 800-53 Rev. 5, PCI DSS v4.0.1 |  HIGH  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [EC2.9](ec2-controls.md#ec2-9)  |  EC2 instances should not have a public IPv4 address  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5  |  HIGH  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [EC2.10](ec2-controls.md#ec2-10)  |  Amazon EC2 should be configured to use VPC endpoints that are created for the Amazon EC2 service  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5, NIST SP 800-171 Rev. 2  |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Periodic  | 
|  [EC2.12](ec2-controls.md#ec2-12)  |  Unused EC2 EIPs should be removed  |  PCI DSS v3.2.1, NIST SP 800-53 Rev. 5  |  LOW  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [EC2.13](ec2-controls.md#ec2-13)  | Security groups should not allow ingress from 0.0.0.0/0 or ::/0 to port 22 | CIS AWS Foundations Benchmark v1.2.0, PCI DSS v3.2.1, PCI DSS v4.0.1, NIST SP 800-53 Rev. 5, NIST SP 800-171 Rev. 2 | HIGH | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Change triggered and periodic | 
|  [EC2.14](ec2-controls.md#ec2-14)  | Security groups should not allow ingress from 0.0.0.0/0 or ::/0 to port 3389 | CIS AWS Foundations Benchmark v1.2.0, PCI DSS v4.0.1 | HIGH | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Change triggered and periodic | 
|  [EC2.15](ec2-controls.md#ec2-15)  |  EC2 subnets should not automatically assign public IP addresses  | AWS Foundational Security Best Practices, NIST SP 800-53 Rev. 5, PCI DSS v4.0.1, |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [EC2.16](ec2-controls.md#ec2-16)  |  Unused Network Access Control Lists should be removed  | AWS Foundational Security Best Practices, NIST SP 800-53 Rev. 5, NIST SP 800-171 Rev. 2, PCI DSS v4.0.1, |  LOW  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [EC2.17](ec2-controls.md#ec2-17)  |  EC2 instances should not use multiple ENIs  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5  |  LOW  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [EC2.18](ec2-controls.md#ec2-18)  |  Security groups should only allow unrestricted incoming traffic for authorized ports  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5, NIST SP 800-171 Rev. 2  |  HIGH  |  ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes  |  Change triggered  | 
|  [EC2.19](ec2-controls.md#ec2-19)  | Security groups should not allow unrestricted access to ports with high risk | AWS Foundational Security Best Practices, NIST SP 800-53 Rev. 5, NIST SP 800-171 Rev. 2 | CRITICAL | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Change triggered and periodic | 
|  [EC2.20](ec2-controls.md#ec2-20)  |  Both VPN tunnels for an AWS Site-to-Site VPN connection should be up  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5, NIST SP 800-171 Rev. 2  |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [EC2.21](ec2-controls.md#ec2-21)  |  Network ACLs should not allow ingress from 0.0.0.0/0 to port 22 or port 3389  | CIS AWS Foundations Benchmark v5.0.0, CIS AWS Foundations Benchmark v3.0.0, CIS AWS Foundations Benchmark v1.4.0, AWS Foundational Security Best Practices, NIST SP 800-53 Rev. 5, NIST SP 800-171 Rev. 2, PCI DSS v4.0.1 |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [EC2.22](ec2-controls.md#ec2-22)  | Unused EC2 security groups should be removed |   | MEDIUM | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Periodic | 
|  [EC2.23](ec2-controls.md#ec2-23)  |  EC2 Transit Gateways should not automatically accept VPC attachment requests  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5  |  HIGH  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [EC2.24](ec2-controls.md#ec2-24)  |  EC2 paravirtual instance types should not be used  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5  |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [EC2.25](ec2-controls.md#ec2-25)  |  EC2 launch templates should not assign public IPs to network interfaces  | AWS Foundational Security Best Practices, NIST SP 800-53 Rev. 5, PCI DSS v4.0.1 |  HIGH  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [EC2.28](ec2-controls.md#ec2-28)  |  EBS volumes should be in a backup plan  |  NIST SP 800-53 Rev. 5  |  LOW  |  ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes  |  Periodic  | 
|  [EC2.33](ec2-controls.md#ec2-33)  | EC2 transit gateway attachments should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [EC2.34](ec2-controls.md#ec2-34)  | EC2 transit gateway route tables should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [EC2.35](ec2-controls.md#ec2-35)  | EC2 network interfaces should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [EC2.36](ec2-controls.md#ec2-36)  | EC2 customer gateways should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [EC2.37](ec2-controls.md#ec2-37)  | EC2 Elastic IP addresses should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [EC2.38](ec2-controls.md#ec2-38)  | EC2 instances should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [EC2.39](ec2-controls.md#ec2-39)  | EC2 internet gateways should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [EC2.40](ec2-controls.md#ec2-40)  | EC2 NAT gateways should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [EC2.41](ec2-controls.md#ec2-41)  | EC2 network ACLs should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [EC2.42](ec2-controls.md#ec2-42)  | EC2 route tables should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [EC2.43](ec2-controls.md#ec2-43)  | EC2 security groups should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [EC2.44](ec2-controls.md#ec2-44)  | EC2 subnets should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [EC2.45](ec2-controls.md#ec2-45)  | EC2 volumes should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [EC2.46](ec2-controls.md#ec2-46)  | Amazon VPCs should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [EC2.47](ec2-controls.md#ec2-47)  | Amazon VPC endpoint services should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [EC2.48](ec2-controls.md#ec2-48)  | Amazon VPC flow logs should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [EC2.49](ec2-controls.md#ec2-49)  | Amazon VPC peering connections should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [EC2.50](ec2-controls.md#ec2-50)  | EC2 VPN gateways should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [EC2.51](ec2-controls.md#ec2-51)  |  EC2 Client VPN endpoints should have client connection logging enabled  | AWS Foundational Security Best Practices, NIST SP 800-53 Rev. 5, NIST SP 800-171 Rev. 2, PCI DSS v4.0.1 |  LOW  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [EC2.52](ec2-controls.md#ec2-52)  | EC2 transit gateways should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [EC2.53](ec2-controls.md#ec2-53)  | EC2 security groups should not allow ingress from 0.0.0.0/0 to remote server administration ports | CIS AWS Foundations Benchmark v5.0.0, CIS AWS Foundations Benchmark v3.0.0, PCI DSS v4.0.1 | HIGH | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Periodic | 
|  [EC2.54](ec2-controls.md#ec2-54)  | EC2 security groups should not allow ingress from ::/0 to remote server administration ports | CIS AWS Foundations Benchmark v5.0.0, CIS AWS Foundations Benchmark v3.0.0, PCI DSS v4.0.1 | HIGH | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Periodic | 
|  [EC2.55](ec2-controls.md#ec2-55)  | VPCs should be configured with an interface endpoint for ECR API | AWS Foundational Security Best Practices, NIST SP 800-53 Rev. 5 | MEDIUM | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Periodic | 
|  [EC2.56](ec2-controls.md#ec2-56)  | VPCs should be configured with an interface endpoint for Docker Registry | AWS Foundational Security Best Practices, NIST SP 800-53 Rev. 5 | MEDIUM | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Periodic | 
|  [EC2.57](ec2-controls.md#ec2-57)  | VPCs should be configured with an interface endpoint for Systems Manager | AWS Foundational Security Best Practices, NIST SP 800-53 Rev. 5 | MEDIUM | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Periodic | 
|  [EC2.58](ec2-controls.md#ec2-58)  | VPCs should be configured with an interface endpoint for Systems Manager Incident Manager Contacts | AWS Foundational Security Best Practices, NIST SP 800-53 Rev. 5 | MEDIUM | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Periodic | 
|  [EC2.60](ec2-controls.md#ec2-60)  | VPCs should be configured with an interface endpoint for Systems Manager Incident Manager | AWS Foundational Security Best Practices, NIST SP 800-53 Rev. 5 | MEDIUM | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Periodic | 
|  [EC2.170](ec2-controls.md#ec2-170)  | EC2 launch templates should use Instance Metadata Service Version 2 (IMDSv2) | AWS Foundational Security Best Practices, PCI DSS v4.0.1 | LOW | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Change triggered | 
|  [EC2.171](ec2-controls.md#ec2-171)  | EC2 VPN connections should have logging enabled | AWS Foundational Security Best Practices, PCI DSS v4.0.1 | MEDIUM | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Change triggered | 
|  [EC2.172](ec2-controls.md#ec2-172)  | EC2 VPC Block Public Access settings should block internet gateway traffic | AWS Foundational Security Best Practices | MEDIUM | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [EC2.173](ec2-controls.md#ec2-173)  | EC2 Spot Fleet requests with launch parameters should enable encryption for attached EBS volumes | AWS Foundational Security Best Practices | MEDIUM | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Change triggered | 
|  [EC2.174](ec2-controls.md#ec2-174)  | EC2 DHCP option sets should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [EC2.175](ec2-controls.md#ec2-175)  | EC2 launch templates should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [EC2.176](ec2-controls.md#ec2-176)  | EC2 prefix lists should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [EC2.177](ec2-controls.md#ec2-177)  | EC2 traffic mirror sessions should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [EC2.178](ec2-controls.md#ec2-178)  | EC2 traffic mirror filters should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [EC2.179](ec2-controls.md#ec2-179)  | EC2 traffic mirror targets should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [EC2.180](ec2-controls.md#ec2-180)  | EC2 network interfaces should have source/destination checking enabled | AWS Foundational Security Best Practices v1.0.0 | MEDIUM | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Change triggered | 
|  [EC2.181](ec2-controls.md#ec2-181)  | EC2 launch templates should enable encryption for attached EBS volumes | AWS Foundational Security Best Practices v1.0.0 | MEDIUM | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Change triggered | 
|  [EC2.182](ec2-controls.md#ec2-182)  | EBS Snapshots should not be publicly accessible | AWS Foundational Security Best Practices | HIGH | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Change triggered | 
|  [EC2.183](ec2-controls.md#ec2-183)  | EC2 VPN connections should use IKEv2 protocol | AWS Foundational Security Best Practices | MEDIUM | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Change triggered | 
|  [ECR.1](ecr-controls.md#ecr-1)  |  ECR private repositories should have image scanning configured  | AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5, PCI DSS v4.0.1 |  HIGH  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Periodic  | 
|  [ECR.2](ecr-controls.md#ecr-2)  |  ECR private repositories should have tag immutability configured  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5  |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [ECR.3](ecr-controls.md#ecr-3)  |  ECR repositories should have at least one lifecycle policy configured  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5  |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [ECR.4](ecr-controls.md#ecr-4)  | ECR public repositories should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [ECR.5](ecr-controls.md#ecr-5)  | ECR repositories should be encrypted with customer managed AWS KMS keys | NIST SP 800-53 Rev. 5 | MEDIUM | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [ECS.2](ecs-controls.md#ecs-2)  |  ECS services should not have public IP addresses assigned to them automatically  | AWS Foundational Security Best Practices, NIST SP 800-53 Rev. 5, PCI DSS v4.0.1 |  HIGH  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [ECS.3](ecs-controls.md#ecs-3)  |  ECS task definitions should not share the host's process namespace  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5  |  HIGH  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [ECS.4](ecs-controls.md#ecs-4)  |  ECS containers should run as non-privileged  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5  |  HIGH  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [ECS.5](ecs-controls.md#ecs-5)  |  ECS containers should be limited to read-only access to root filesystems  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5  |  HIGH  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [ECS.8](ecs-controls.md#ecs-8)  |  Secrets should not be passed as container environment variables  | AWS Foundational Security Best Practices, NIST SP 800-53 Rev. 5, PCI DSS v4.0.1 |  HIGH  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [ECS.9](ecs-controls.md#ecs-9)  |  ECS task definitions should have a logging configuration  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5  |  HIGH  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [ECS.10](ecs-controls.md#ecs-10)  |  ECS Fargate services should run on the latest Fargate platform version  | AWS Foundational Security Best Practices, NIST SP 800-53 Rev. 5, PCI DSS v4.0.1 |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [ECS.12](ecs-controls.md#ecs-12)  |  ECS clusters should use Container Insights  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5  |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [ECS.13](ecs-controls.md#ecs-13)  | ECS services should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [ECS.14](ecs-controls.md#ecs-14)  | ECS clusters should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [ECS.15](ecs-controls.md#ecs-15)  | ECS task definitions should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [ECS.16](ecs-controls.md#ecs-16)  | ECS task sets should not automatically assign public IP addresses | AWS Foundational Security Best Practices, PCI DSS v4.0.1 | HIGH | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Change triggered | 
|  [ECS.17](ecs-controls.md#ecs-17)  | ECS task definitions should not use host network mode | NIST SP 800-53 Rev. 5 | MEDIUM | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Change triggered | 
|  [ECS.18](ecs-controls.md#ecs-18)  | ECS Task Definitions should use in-transit encryption for EFS volumes | AWS Foundational Security Best Practices | MEDIUM | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Change triggered | 
|  [ECS.19](ecs-controls.md#ecs-19)  | ECS capacity providers should have managed termination protection enabled | AWS Foundational Security Best Practices | MEDIUM | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Change triggered | 
|  [ECS.20](ecs-controls.md#ecs-20)  | ECS Task Definitions should configure non-root users in Linux container definitions | AWS Foundational Security Best Practices | MEDIUM | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Change triggered | 
|  [ECS.21](ecs-controls.md#ecs-21)  | ECS Task Definitions should configure non-administrator users in Windows container definitions | AWS Foundational Security Best Practices | MEDIUM | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Change triggered | 
|  [EFS.1](efs-controls.md#efs-1)  |  Elastic File System should be configured to encrypt file data at-rest using AWS KMS  | CIS AWS Foundations Benchmark v5.0.0, CIS AWS Foundations Benchmark v3.0.0, AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5  |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Periodic  | 
|  [EFS.2](efs-controls.md#efs-2)  |  Amazon EFS volumes should be in backup plans  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5  |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Periodic  | 
|  [EFS.3](efs-controls.md#efs-3)  |  EFS access points should enforce a root directory  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5  |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [EFS.4](efs-controls.md#efs-4)  |  EFS access points should enforce a user identity  | AWS Foundational Security Best Practices, NIST SP 800-53 Rev. 5, PCI DSS v4.0.1 |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [EFS.5](efs-controls.md#efs-5)  | EFS access points should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [EFS.6](efs-controls.md#efs-6)  | EFS mount targets should not be associated with subnets that assign public IP addresses on launch | AWS Foundational Security Best Practices | MEDIUM | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Periodic | 
|  [EFS.7](efs-controls.md#efs-7)  | EFS file systems should have automatic backups enabled | AWS Foundational Security Best Practices | MEDIUM | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Change triggered | 
|  [EFS.8](efs-controls.md#efs-8)  | EFS file systems should be encrypted at rest | CIS AWS Foundations Benchmark v5.0.0, AWS Foundational Security Best Practices | MEDIUM | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [EKS.1](eks-controls.md#eks-1)  |  EKS cluster endpoints should not be publicly accessible  | AWS Foundational Security Best Practices, NIST SP 800-53 Rev. 5, PCI DSS v4.0.1 |  HIGH  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Periodic  | 
|  [EKS.2](eks-controls.md#eks-2)  |  EKS clusters should run on a supported Kubernetes version  | AWS Foundational Security Best Practices, NIST SP 800-53 Rev. 5, PCI DSS v4.0.1 |  HIGH  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [EKS.3](eks-controls.md#eks-3)  | EKS clusters should use encrypted Kubernetes secrets | AWS Foundational Security Best Practices, NIST SP 800-53 Rev. 5, PCI DSS v4.0.1 | MEDIUM | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Periodic | 
|  [EKS.6](eks-controls.md#eks-6)  | EKS clusters should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [EKS.7](eks-controls.md#eks-7)  | EKS identity provider configurations should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [EKS.8](eks-controls.md#eks-8)  |  EKS clusters should have audit logging enabled  | AWS Foundational Security Best Practices, NIST SP 800-53 Rev. 5, PCI DSS v4.0.1 |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [EKS.9](eks-controls.md#eks-9)  | EKS node groups should run on a supported Kubernetes version | AWS Foundational Security Best Practices | HIGH | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Change triggered | 
|  [ElastiCache.1](elasticache-controls.md#elasticache-1)  | ElastiCache (Redis OSS) clusters should have automatic backups enabled | AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5 | HIGH | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Periodic | 
|  [ElastiCache.2](elasticache-controls.md#elasticache-2)  |  ElastiCache clusters should have automatic minor version upgrades enabled | AWS Foundational Security Best Practices, NIST SP 800-53 Rev. 5, PCI DSS v4.0.1 |  HIGH  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Periodic  | 
|  [ElastiCache.3](elasticache-controls.md#elasticache-3)  | ElastiCache replication groups should have automatic failover enabled  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5  |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Periodic  | 
|  [ElastiCache.4](elasticache-controls.md#elasticache-4)  | ElastiCache replication groups should be encrypted-at-rest |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5  |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Periodic  | 
|  [ElastiCache.5](elasticache-controls.md#elasticache-5)  | ElastiCache replication groups should be encrypted-in-transit | AWS Foundational Security Best Practices, NIST SP 800-53 Rev. 5, PCI DSS v4.0.1 |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Periodic  | 
|  [ElastiCache.6](elasticache-controls.md#elasticache-6)  |  ElastiCache (Redis OSS) replication groups of earlier versions should have Redis OSS AUTH enabled  | AWS Foundational Security Best Practices, NIST SP 800-53 Rev. 5, PCI DSS v4.0.1 |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Periodic  | 
|  [ElastiCache.7](elasticache-controls.md#elasticache-7)  | ElastiCache clusters should not use the default subnet group |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5  |  HIGH  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Periodic  | 
|  [ElasticBeanstalk.1](elasticbeanstalk-controls.md#elasticbeanstalk-1)  |  Elastic Beanstalk environments should have enhanced health reporting enabled  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5  |  LOW  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [ElasticBeanstalk.2](elasticbeanstalk-controls.md#elasticbeanstalk-2)  |  Elastic Beanstalk managed platform updates should be enabled  | AWS Foundational Security Best Practices, NIST SP 800-53 Rev. 5, PCI DSS v4.0.1 |  HIGH  |  ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes  |  Change triggered  | 
|  [ElasticBeanstalk.3](elasticbeanstalk-controls.md#elasticbeanstalk-3)  |  Elastic Beanstalk should stream logs to CloudWatch  | AWS Foundational Security Best Practices, PCI DSS v4.0.1 |  HIGH  |  ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes  |  Change triggered  | 
|  [ELB.1](elb-controls.md#elb-1)  |  Application Load Balancer should be configured to redirect all HTTP requests to HTTPS  |  AWS Foundational Security Best Practices v1.0.0, PCI DSS v3.2.1, NIST SP 800-53 Rev. 5  |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Periodic  | 
|  [ELB.2](elb-controls.md#elb-2)  |  Classic Load Balancers with SSL/HTTPS listeners should use a certificate provided by AWS Certificate Manager  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5, NIST SP 800-171 Rev. 2  |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [ELB.3](elb-controls.md#elb-3)  |  Classic Load Balancer listeners should be configured with HTTPS or TLS termination  | AWS Foundational Security Best Practices, NIST SP 800-53 Rev. 5, NIST SP 800-171 Rev. 2, PCI DSS v4.0.1 |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [ELB.4](elb-controls.md#elb-4)  |  Application Load Balancer should be configured to drop http headers  | AWS Foundational Security Best Practices, NIST SP 800-53 Rev. 5, PCI DSS v4.0.1 |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [ELB.5](elb-controls.md#elb-5)  |  Application and Classic Load Balancers logging should be enabled  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5  |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [ELB.6](elb-controls.md#elb-6)  | Application, Gateway, and Network Load Balancers should have deletion protection enabled | AWS Foundational Security Best Practices, NIST SP 800-53 Rev. 5 | MEDIUM | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Change triggered | 
|  [ELB.7](elb-controls.md#elb-7)  |  Classic Load Balancers should have connection draining enabled  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5  | LOW |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [ELB.8](elb-controls.md#elb-8)  |  Classic Load Balancers with SSL listeners should use a predefined security policy that has strong configuration  | AWS Foundational Security Best Practices, NIST SP 800-53 Rev. 5, NIST SP 800-171 Rev. 2, PCI DSS v4.0.1 |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [ELB.9](elb-controls.md#elb-9)  |  Classic Load Balancers should have cross-zone load balancing enabled  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5  |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [ELB.10](elb-controls.md#elb-10)  |  Classic Load Balancer should span multiple Availability Zones  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5  |  MEDIUM  |  ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes  |  Change triggered  | 
|  [ELB.12](elb-controls.md#elb-12)  |  Application Load Balancer should be configured with defensive or strictest desync mitigation mode  | AWS Foundational Security Best Practices, NIST SP 800-53 Rev. 5, PCI DSS v4.0.1 |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [ELB.13](elb-controls.md#elb-13)  |  Application, Network and Gateway Load Balancers should span multiple Availability Zones  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5  |  MEDIUM  |  ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes  |  Change triggered  | 
|  [ELB.14](elb-controls.md#elb-14)  |  Classic Load Balancer should be configured with defensive or strictest desync mitigation mode  | AWS Foundational Security Best Practices, NIST SP 800-53 Rev. 5, PCI DSS v4.0.1 |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [ELB.16](elb-controls.md#elb-16)  |  Application Load Balancers should be associated with an AWS WAF web ACL  |  NIST SP 800-53 Rev. 5  |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [ELB.17](elb-controls.md#elb-17)  | Application and Network Load Balancers with listeners should use recommended security policies  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5  |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [ELB.18](elb-controls.md#elb-18)  | Application and Network Load Balancer listeners should use secure protocols to encrypt data in transit | AWS Foundational Security Best Practices v1.0.0 | MEDIUM | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Change triggered | 
|  [ELB.21](elb-controls.md#elb-21)  |  Application and Network Load Balancer target groups should use encrypted health check protocols  |  AWS Foundational Security Best Practices v1.0.0  |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [ELB.22](elb-controls.md#elb-22)  |  ELB target groups should use encrypted transport protocols  |  AWS Foundational Security Best Practices v1.0.0  |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [EMR.1](emr-controls.md#emr-1)  | Amazon EMR cluster primary nodes should not have public IP addresses | AWS Foundational Security Best Practices, NIST SP 800-53 Rev. 5, PCI DSS v4.0.1 | HIGH | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Periodic | 
|  [EMR.2](emr-controls.md#emr-2)  | Amazon EMR block public access setting should be enabled | AWS Foundational Security Best Practices, NIST SP 800-53 Rev. 5, PCI DSS v4.0.1 | CRITICAL | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Periodic | 
|  [EMR.3](emr-controls.md#emr-3)  | Amazon EMR security configurations should be encrypted at rest | AWS Foundational Security Best Practices, NIST SP 800-53 Rev. 5 | MEDIUM | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Change triggered | 
|  [EMR.4](emr-controls.md#emr-4)  | Amazon EMR security configurations should be encrypted in transit | AWS Foundational Security Best Practices, NIST SP 800-53 Rev. 5 | MEDIUM | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Change triggered | 
|  [ES.1](es-controls.md#es-1)  |  Elasticsearch domains should have encryption at-rest enabled  |  AWS Foundational Security Best Practices v1.0.0, PCI DSS v3.2.1, NIST SP 800-53 Rev. 5  |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Periodic  | 
|  [ES.2](es-controls.md#es-2)  |  Elasticsearch domains should not be publicly accessible  | AWS Foundational Security Best Practices, PCI DSS v3.2.1, PCI DSS v4.0.1, NIST SP 800-53 Rev. 5  |  CRITICAL  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Periodic  | 
|  [ES.3](es-controls.md#es-3)  |  Elasticsearch domains should encrypt data sent between nodes  | AWS Foundational Security Best Practices, NIST SP 800-53 Rev. 5, PCI DSS v4.0.1, |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [ES.4](es-controls.md#es-4)  |  Elasticsearch domain error logging to CloudWatch Logs should be enabled  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5  |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [ES.5](es-controls.md#es-5)  |  Elasticsearch domains should have audit logging enabled  | AWS Foundational Security Best Practices, NIST SP 800-53 Rev. 5 |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [ES.6](es-controls.md#es-6)  |  Elasticsearch domains should have at least three data nodes  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5  |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [ES.7](es-controls.md#es-7)  |  Elasticsearch domains should be configured with at least three dedicated master nodes  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5  |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [ES.8](es-controls.md#es-8)  | Connections to Elasticsearch domains should be encrypted using the latest TLS security policy | AWS Foundational Security Best Practices, NIST SP 800-53 Rev. 5, PCI DSS v4.0.1 | MEDIUM | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Change triggered | 
|  [ES.9](es-controls.md#es-9)  | Elasticsearch domains should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [EventBridge.2](eventbridge-controls.md#eventbridge-2)  | EventBridge event buses should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [EventBridge.3](eventbridge-controls.md#eventbridge-3)  |  EventBridge custom event buses should have a resource-based policy attached  | AWS Foundational Security Best Practices, NIST SP 800-53 Rev. 5, PCI DSS v4.0.1 |  LOW  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [EventBridge.4](eventbridge-controls.md#eventbridge-4)  |  EventBridge global endpoints should have event replication enabled  |  NIST SP 800-53 Rev. 5  |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [FraudDetector.1](frauddetector-controls.md#frauddetector-1)  | Amazon Fraud Detector entity types should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [FraudDetector.2](frauddetector-controls.md#frauddetector-2)  | Amazon Fraud Detector labels should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [FraudDetector.3](frauddetector-controls.md#frauddetector-3)  | Amazon Fraud Detector outcomes should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [FraudDetector.4](frauddetector-controls.md#frauddetector-4)  | Amazon Fraud Detector variables should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [FSx.1](fsx-controls.md#fsx-1)  |  FSx for OpenZFS file systems should be configured to copy tags to backups and volumes  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5  |  LOW  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  | Periodic | 
|  [FSx.2](fsx-controls.md#fsx-2)  | FSx for Lustre file systems should be configured to copy tags to backups | AWS Foundational Security Best Practices, NIST SP 800-53 Rev. 5 | LOW | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Periodic | 
|  [FSx.3](fsx-controls.md#fsx-3)  | FSx for OpenZFS file systems should be configured for Multi-AZ deployment | AWS Foundational Security Best Practices | MEDIUM | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Periodic | 
|  [FSx.4](fsx-controls.md#fsx-4)  | FSx for NetApp ONTAP file systems should be configured for Multi-AZ deployment | AWS Foundational Security Best Practices | MEDIUM | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Periodic | 
|  [FSx.5](fsx-controls.md#fsx-5)  | FSx for Windows File Server file systems should be configured for Multi-AZ deployment | AWS Foundational Security Best Practices | MEDIUM | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Periodic | 
|  [Glue.1](glue-controls.md#glue-1)  | AWS Glue jobs should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [Glue.3](glue-controls.md#glue-3)  | AWS Glue machine learning transforms should be encrypted at rest | AWS Foundational Security Best Practices | MEDIUM | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Change triggered | 
|  [Glue.4](glue-controls.md#glue-4)  | AWS Glue Spark jobs should run on supported versions of AWS Glue | AWS Foundational Security Best Practices, NIST SP 800-53 Rev. 5 | MEDIUM | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Change triggered | 
|  [GlobalAccelerator.1](globalaccelerator-controls.md#globalaccelerator-1)  | Global Accelerator accelerators should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [GuardDuty.1](guardduty-controls.md#guardduty-1)  |  GuardDuty should be enabled  | AWS Foundational Security Best Practices, NIST SP 800-53 Rev. 5, NIST SP 800-171 Rev. 2, PCI DSS v3.2.1, PCI DSS v4.0.1 |  HIGH  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Periodic  | 
|  [GuardDuty.2](guardduty-controls.md#guardduty-2)  | GuardDuty filters should be tagged  | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [GuardDuty.3](guardduty-controls.md#guardduty-3)  | GuardDuty IPSets should be tagged  | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [GuardDuty.4](guardduty-controls.md#guardduty-4)  | GuardDuty detectors should be tagged  | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [GuardDuty.5](guardduty-controls.md#guardduty-5)  | GuardDuty EKS Audit Log Monitoring should be enabled | AWS Foundational Security Best Practices | HIGH | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Periodic | 
|  [GuardDuty.6](guardduty-controls.md#guardduty-6)  | GuardDuty Lambda Protection should be enabled | AWS Foundational Security Best Practices, PCI DSS v4.0.1 | HIGH | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Periodic | 
|  [GuardDuty.7](guardduty-controls.md#guardduty-7)  | GuardDuty EKS Runtime Monitoring should be enabled | AWS Foundational Security Best Practices, PCI DSS v4.0.1 | HIGH | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Periodic | 
|  [GuardDuty.8](guardduty-controls.md#guardduty-8)  | GuardDuty Malware Protection for EC2 should be enabled | AWS Foundational Security Best Practices | HIGH | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Periodic | 
|  [GuardDuty.9](guardduty-controls.md#guardduty-9)  | GuardDuty RDS Protection should be enabled | AWS Foundational Security Best Practices, PCI DSS v4.0.1 | HIGH | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Periodic | 
|  [GuardDuty.10](guardduty-controls.md#guardduty-10)  | GuardDuty S3 Protection should be enabled | AWS Foundational Security Best Practices, PCI DSS v4.0.1 | HIGH | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Periodic | 
|  [GuardDuty.11](guardduty-controls.md#guardduty-11)  | GuardDuty Runtime Monitoring should be enabled | AWS Foundational Security Best Practices | HIGH | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Periodic | 
|  [GuardDuty.12](guardduty-controls.md#guardduty-12)  | GuardDuty ECS Runtime Monitoring should be enabled | AWS Foundational Security Best Practices | MEDIUM | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Periodic | 
|  [GuardDuty.13](guardduty-controls.md#guardduty-13)  | GuardDuty EC2 Runtime Monitoring should be enabled | AWS Foundational Security Best Practices | MEDIUM | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Periodic | 
|  [IAM.1](iam-controls.md#iam-1)  |  IAM policies should not allow full "\$1" administrative privileges  | CIS AWS Foundations Benchmark v1.2.0, AWS Foundational Security Best Practices v1.0.0, PCI DSS v3.2.1, CIS AWS Foundations Benchmark v1.4.0, NIST SP 800-53 Rev. 5, NIST SP 800-171 Rev. 2  |  HIGH  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [IAM.2](iam-controls.md#iam-2)  |  IAM users should not have IAM policies attached  | CIS AWS Foundations Benchmark v5.0.0, CIS AWS Foundations Benchmark v3.0.0, CIS AWS Foundations Benchmark v1.2.0, AWS Foundational Security Best Practices v1.0.0, PCI DSS v3.2.1, NIST SP 800-53 Rev. 5, NIST SP 800-171 Rev. 2  |  LOW  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [IAM.3](iam-controls.md#iam-3)  |  IAM users' access keys should be rotated every 90 days or less  | CIS AWS Foundations Benchmark v5.0.0, CIS AWS Foundations Benchmark v3.0.0, CIS AWS Foundations Benchmark v1.4.0, CIS AWS Foundations Benchmark v1.2.0, AWS Foundational Security Best Practices, NIST SP 800-53 Rev. 5, PCI DSS v4.0.1 |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Periodic  | 
|  [IAM.4](iam-controls.md#iam-4)  |  IAM root user access key should not exist  | CIS AWS Foundations Benchmark v5.0.0, CIS AWS Foundations Benchmark v3.0.0, CIS AWS Foundations Benchmark v1.4.0, CIS AWS Foundations Benchmark v1.2.0, AWS Foundational Security Best Practices v1.0.0, PCI DSS v3.2.1, NIST SP 800-53 Rev. 5  |  CRITICAL  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Periodic  | 
|  [IAM.5](iam-controls.md#iam-5)  |  MFA should be enabled for all IAM users that have a console password  | CIS AWS Foundations Benchmark v5.0.0, CIS AWS Foundations Benchmark v3.0.0, CIS AWS Foundations Benchmark v1.4.0, CIS AWS Foundations Benchmark v1.2.0, AWS Foundational Security Best Practices, NIST SP 800-53 Rev. 5, PCI DSS v4.0.1 |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Periodic  | 
|  [IAM.6](iam-controls.md#iam-6)  |  Hardware MFA should be enabled for the root user  | CIS AWS Foundations Benchmark v5.0.0, CIS AWS Foundations Benchmark v3.0.0, CIS AWS Foundations Benchmark v1.4.0, CIS AWS Foundations Benchmark v1.2.0, AWS Foundational Security Best Practices, NIST SP 800-53 Rev. 5, PCI DSS v3.2.1, PCI DSS v4.0.1 |  CRITICAL  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Periodic  | 
|  [IAM.7](iam-controls.md#iam-7)  |  Password policies for IAM users should have strong configurations  | AWS Foundational Security Best Practices, NIST SP 800-53 Rev. 5, NIST SP 800-171 Rev. 2, PCI DSS v4.0.1 |  MEDIUM  |  ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes  |  Periodic  | 
|  [IAM.8](iam-controls.md#iam-8)  |  Unused IAM user credentials should be removed  | CIS AWS Foundations Benchmark v1.2.0, AWS Foundational Security Best Practices, NIST SP 800-53 Rev. 5, NIST SP 800-171 Rev. 2, PCI DSS v3.2.1, PCI DSS v4.0.1 |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Periodic  | 
|  [IAM.9](iam-controls.md#iam-9)  |  MFA should be enabled for the root user  | CIS AWS Foundations Benchmark v5.0.0, CIS AWS Foundations Benchmark v3.0.0, CIS AWS Foundations Benchmark v1.4.0, CIS AWS Foundations Benchmark v1.2.0, NIST SP 800-53 Rev. 5, PCI DSS v3.2.1, PCI DSS v4.0.1 |  CRITICAL  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Periodic  | 
|  [IAM.10](iam-controls.md#iam-10)  |  Password policies for IAM users should have strong configurations  | NIST SP 800-171 Rev. 2, PCI DSS v3.2.1 |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Periodic  | 
|  [IAM.11](iam-controls.md#iam-11)  |  Ensure IAM password policy requires at least one uppercase letter  | CIS AWS Foundations Benchmark v1.2.0, NIST SP 800-171 Rev. 2, PCI DSS v4.0.1 |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Periodic  | 
|  [IAM.12](iam-controls.md#iam-12)  |  Ensure IAM password policy requires at least one lowercase letter  | CIS AWS Foundations Benchmark v1.2.0, NIST SP 800-171 Rev. 2, PCI DSS v4.0.1 |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Periodic  | 
|  [IAM.13](iam-controls.md#iam-13)  |  Ensure IAM password policy requires at least one symbol  | CIS AWS Foundations Benchmark v1.2.0, NIST SP 800-171 Rev. 2 |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Periodic  | 
|  [IAM.14](iam-controls.md#iam-14)  |  Ensure IAM password policy requires at least one number  | CIS AWS Foundations Benchmark v1.2.0, NIST SP 800-171 Rev. 2, PCI DSS v4.0.1 |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Periodic  | 
|  [IAM.15](iam-controls.md#iam-15)  |  Ensure IAM password policy requires minimum password length of 14 or greater  | CIS AWS Foundations Benchmark v5.0.0, CIS AWS Foundations Benchmark v3.0.0, CIS AWS Foundations Benchmark v1.4.0, CIS AWS Foundations Benchmark v1.2.0, NIST SP 800-171 Rev. 2 |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Periodic  | 
|  [IAM.16](iam-controls.md#iam-16)  |  Ensure IAM password policy prevents password reuse  | CIS AWS Foundations Benchmark v5.0.0, CIS AWS Foundations Benchmark v3.0.0, CIS AWS Foundations Benchmark v1.4.0, CIS AWS Foundations Benchmark v1.2.0, NIST SP 800-171 Rev. 2, PCI DSS v4.0.1 |  LOW  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Periodic  | 
|  [IAM.17](iam-controls.md#iam-17)  |  Ensure IAM password policy expires passwords within 90 days or less  | CIS AWS Foundations Benchmark v1.2.0, PCI DSS v4.0.1 |  LOW  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Periodic  | 
|  [IAM.18](iam-controls.md#iam-18)  |  Ensure a support role has been created to manage incidents with AWS Support  | CIS AWS Foundations Benchmark v5.0.0, CIS AWS Foundations Benchmark v3.0.0, CIS AWS Foundations Benchmark v1.4.0, CIS AWS Foundations Benchmark v1.2.0, NIST SP 800-171 Rev. 2, PCI DSS v4.0.1 |  LOW  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Periodic  | 
|  [IAM.19](iam-controls.md#iam-19)  |  MFA should be enabled for all IAM users  | NIST SP 800-53 Rev. 5, NIST SP 800-171 Rev. 2, PCI DSS v3.2.1, PCI DSS v4.0.1 |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Periodic  | 
|  [IAM.21](iam-controls.md#iam-21)  |  IAM customer managed policies that you create should not allow wildcard actions for services  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5, NIST SP 800-171 Rev. 2  |  LOW  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [IAM.22](iam-controls.md#iam-22)  |  IAM user credentials unused for 45 days should be removed  | CIS AWS Foundations Benchmark v5.0.0, CIS AWS Foundations Benchmark v3.0.0, CIS AWS Foundations Benchmark v1.4.0, NIST SP 800-171 Rev. 2 |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Periodic  | 
|  [IAM.23](iam-controls.md#iam-23)  | IAM Access Analyzer analyzers should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [IAM.24](iam-controls.md#iam-24)  | IAM roles should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [IAM.25](iam-controls.md#iam-25)  | IAM users should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [IAM.26](iam-controls.md#iam-26) | Expired SSL/TLS certificates managed in IAM should be removed | CIS AWS Foundations Benchmark v5.0.0, CIS AWS Foundations Benchmark v3.0.0 | MEDIUM | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Periodic | 
|  [IAM.27](iam-controls.md#iam-27)  | IAM identities should not have the AWSCloudShellFullAccess policy attached | CIS AWS Foundations Benchmark v5.0.0, CIS AWS Foundations Benchmark v3.0.0 | MEDIUM | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Change triggered | 
|  [IAM.28](iam-controls.md#iam-28)  | IAM Access Analyzer external access analyzer should be enabled | CIS AWS Foundations Benchmark v5.0.0, CIS AWS Foundations Benchmark v3.0.0 | HIGH | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Periodic | 
|  [Inspector.1](inspector-controls.md#inspector-1)  | Amazon Inspector EC2 scanning should be enabled | AWS Foundational Security Best Practices, PCI DSS v4.0.1 | HIGH | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Periodic | 
|  [Inspector.2](inspector-controls.md#inspector-2)  | Amazon Inspector ECR scanning should be enabled | AWS Foundational Security Best Practices, PCI DSS v4.0.1 | HIGH | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Periodic | 
|  [Inspector.3](inspector-controls.md#inspector-3)  | Amazon Inspector Lambda code scanning should be enabled | AWS Foundational Security Best Practices, PCI DSS v4.0.1 | HIGH | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Periodic | 
|  [Inspector.4](inspector-controls.md#inspector-4)  | Amazon Inspector Lambda standard scanning should be enabled | AWS Foundational Security Best Practices, PCI DSS v4.0.1 | HIGH | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Periodic | 
|  [IoT.1](iot-controls.md#iot-1)  | AWS IoT Device Defender security profiles should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [IoT.2](iot-controls.md#iot-2)  | AWS IoT Core mitigation actions should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [IoT.3](iot-controls.md#iot-3)  | AWS IoT Core dimensions should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [IoT.4](iot-controls.md#iot-4)  | AWS IoT Core authorizers should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [IoT.5](iot-controls.md#iot-5)  | AWS IoT Core role aliases should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [IoT.6](iot-controls.md#iot-6)  | AWS IoT Core policies should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [IoTEvents.1](iotevents-controls.md#iotevents-1)  | AWS IoT Events inputs should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [IoTEvents.2](iotevents-controls.md#iotevents-2)  | AWS IoT Events detector models should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [IoTEvents.3](iotevents-controls.md#iotevents-3)  | AWS IoT Events alarm models should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [IoTSiteWise.1](iotsitewise-controls.md#iotsitewise-1)  | AWS IoT SiteWise asset models should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [IoTSiteWise.2](iotsitewise-controls.md#iotsitewise-2)  | AWS IoT SiteWise dashboards should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [IoTSiteWise.3](iotsitewise-controls.md#iotsitewise-3)  | AWS IoT SiteWise gateways should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [IoTSiteWise.4](iotsitewise-controls.md#iotsitewise-4)  | AWS IoT SiteWise portals should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [IoTSiteWise.5](iotsitewise-controls.md#iotsitewise-5)  | AWS IoT SiteWise projects should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [IoTTwinMaker.1](iottwinmaker-controls.md#iottwinmaker-1)  | AWS IoT TwinMaker sync jobs should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [IoTTwinMaker.2](iottwinmaker-controls.md#iottwinmaker-2)  | AWS IoT TwinMaker workspaces should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [IoTTwinMaker.3](iottwinmaker-controls.md#iottwinmaker-3)  | AWS IoT TwinMaker scenes should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [IoTTwinMaker.4](iottwinmaker-controls.md#iottwinmaker-4)  | AWS IoT TwinMaker entities should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [IoTWireless.1](iotwireless-controls.md#iotwireless-1)  | AWS IoT Wireless multicast groups should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [IoTWireless.2](iotwireless-controls.md#iotwireless-2)  | AWS IoT Wireless service profiles should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [IoTWireless.3](iotwireless-controls.md#iotwireless-3)  | AWS IoT Wireless FUOTA tasks should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [IVS.1](ivs-controls.md#ivs-1)  | IVS playback key pairs should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [IVS.2](ivs-controls.md#ivs-2)  | IVS recording configurations should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [IVS.3](ivs-controls.md#ivs-3)  | IVS channels should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [Keyspaces.1](keyspaces-controls.md#keyspaces-1)  | Amazon Keyspaces keyspaces should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [Kinesis.1](kinesis-controls.md#kinesis-1)  |  Kinesis streams should be encrypted at rest  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5  |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [Kinesis.2](kinesis-controls.md#kinesis-2)  | Kinesis streams should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [Kinesis.3](kinesis-controls.md#kinesis-3)  | Kinesis streams should have an adequate data retention period | AWS Foundational Security Best Practices | MEDIUM | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [KMS.1](kms-controls.md#kms-1)  |  IAM customer managed policies should not allow decryption actions on all KMS keys  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5  |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [KMS.2](kms-controls.md#kms-2)  |  IAM principals should not have IAM inline policies that allow decryption actions on all KMS keys  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5  |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [KMS.3](kms-controls.md#kms-3)  |  AWS KMS keys should not be deleted unintentionally  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5  |  CRITICAL  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [KMS.4](kms-controls.md#kms-4)  |  AWS KMS key rotation should be enabled  | CIS AWS Foundations Benchmark v5.0.0, CIS AWS Foundations Benchmark v3.0.0, CIS AWS Foundations Benchmark v1.4.0, CIS AWS Foundations Benchmark v1.2.0, NIST SP 800-53 Rev. 5, PCI DSS v3.2.1, PCI DSS v4.0.1 |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Periodic  | 
|  [KMS.5](kms-controls.md#kms-5)  | KMS keys should not be publicly accessible | AWS Foundational Security Best Practices | CRITICAL | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Change triggered | 
|  [Lambda.1](lambda-controls.md#lambda-1)  |  Lambda function policies should prohibit public access  | AWS Foundational Security Best Practices, NIST SP 800-53 Rev. 5, PCI DSS v3.2.1, PCI DSS v4.0.1 |  CRITICAL  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [Lambda.2](lambda-controls.md#lambda-2)  |  Lambda functions should use supported runtimes  | AWS Foundational Security Best Practices, NIST SP 800-53 Rev. 5, PCI DSS v4.0.1 |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [Lambda.3](lambda-controls.md#lambda-3)  |  Lambda functions should be in a VPC  |  PCI DSS v3.2.1, NIST SP 800-53 Rev. 5  |  LOW  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [Lambda.5](lambda-controls.md#lambda-5)  |  VPC Lambda functions should operate in multiple Availability Zones  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5  |  MEDIUM  |  ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes  |  Change triggered  | 
|  [Lambda.6](lambda-controls.md#lambda-6)  | Lambda functions should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [Lambda.7](lambda-controls.md#lambda-7)  | Lambda functions should have AWS X-Ray active tracing enabled | NIST SP 800-53 Rev. 5 | LOW | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Change triggered | 
|  [Macie.1](macie-controls.md#macie-1)  |  Amazon Macie should be enabled  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5  |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Periodic  | 
|  [Macie.2](macie-controls.md#macie-2)  | Macie automated sensitive data discovery should be enabled | AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5 | HIGH | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Periodic | 
|  [MSK.1](msk-controls.md#msk-1)  |  MSK clusters should be encrypted in transit among broker nodes  | AWS Foundational Security Best Practices, NIST SP 800-53 Rev. 5, PCI DSS v4.0.1 |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [MSK.2](msk-controls.md#msk-2)  |  MSK clusters should have enhanced monitoring configured  |  NIST SP 800-53 Rev. 5  |  LOW  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [MSK.3](msk-controls.md#msk-3)  | MSK Connect connectors should be encrypted in transit | AWS Foundational Security Best Practices, PCI DSS v4.0.1 | MEDIUM | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  | Change triggered | 
|  [MSK.4](msk-controls.md#msk-4)  | MSK clusters should have public access disabled | AWS Foundational Security Best Practices | CRITICAL | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Change triggered | 
|  [MSK.5](msk-controls.md#msk-5)  | MSK connectors should have logging enabled | AWS Foundational Security Best Practices | MEDIUM | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Change triggered | 
|  [MSK.6](msk-controls.md#msk-6)  | MSK clusters should disable unauthenticated access | AWS Foundational Security Best Practices | MEDIUM | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Change triggered | 
|  [MQ.2](mq-controls.md#mq-2)  | ActiveMQ brokers should stream audit logs to CloudWatch | AWS Foundational Security Best Practices, NIST SP 800-53 Rev. 5, PCI DSS v4.0.1 | MEDIUM | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Change triggered | 
|  [MQ.4](mq-controls.md#mq-4)  | Amazon MQ brokers should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [MQ.5](mq-controls.md#mq-5)  |  ActiveMQ brokers should use active/standby deployment mode  | NIST SP 800-53 Rev. 5 |  LOW  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [MQ.6](mq-controls.md#mq-6)  |  RabbitMQ brokers should use cluster deployment mode  | NIST SP 800-53 Rev. 5 |  LOW  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [Neptune.1](neptune-controls.md#neptune-1)  |  Neptune DB clusters should be encrypted at rest  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5  |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  | Change triggered | 
|  [Neptune.2](neptune-controls.md#neptune-2)  |  Neptune DB clusters should publish audit logs to CloudWatch Logs  | AWS Foundational Security Best Practices, NIST SP 800-53 Rev. 5, PCI DSS v4.0.1  |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  | Change triggered | 
|  [Neptune.3](neptune-controls.md#neptune-3)  |  Neptune DB cluster snapshots should not be public  | AWS Foundational Security Best Practices, NIST SP 800-53 Rev. 5, PCI DSS v4.0.1 |  CRITICAL  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [Neptune.4](neptune-controls.md#neptune-4)  |  Neptune DB clusters should have deletion protection enabled  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5  |  LOW  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [Neptune.5](neptune-controls.md#neptune-5)  |  Neptune DB clusters should have automated backups enabled  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5  |  MEDIUM  |  ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes  |  Change triggered  | 
|  [Neptune.6](neptune-controls.md#neptune-6)  |  Neptune DB cluster snapshots should be encrypted at rest  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5  |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [Neptune.7](neptune-controls.md#neptune-7)  |  Neptune DB clusters should have IAM database authentication enabled  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5  |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [Neptune.8](neptune-controls.md#neptune-8)  |  Neptune DB clusters should be configured to copy tags to snapshots  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5  |  LOW  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [Neptune.9](neptune-controls.md#neptune-9)  |  Neptune DB clusters should be deployed across multiple Availability Zones  |  NIST SP 800-53 Rev. 5  |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [NetworkFirewall.1](networkfirewall-controls.md#networkfirewall-1)  |  Network Firewall firewalls should be deployed across multiple Availability Zones  |  NIST SP 800-53 Rev. 5  |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [NetworkFirewall.2](networkfirewall-controls.md#networkfirewall-2)  |  Network Firewall logging should be enabled  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5, NIST SP 800-171 Rev. 2  |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Periodic  | 
|  [NetworkFirewall.3](networkfirewall-controls.md#networkfirewall-3)  |  Network Firewall policies should have at least one rule group associated  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5, NIST SP 800-171 Rev. 2  |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [NetworkFirewall.4](networkfirewall-controls.md#networkfirewall-4)  |  The default stateless action for Network Firewall policies should be drop or forward for full packets  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5  |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [NetworkFirewall.5](networkfirewall-controls.md#networkfirewall-5)  |  The default stateless action for Network Firewall policies should be drop or forward for fragmented packets  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5, NIST SP 800-171 Rev. 2  |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [NetworkFirewall.6](networkfirewall-controls.md#networkfirewall-6)  |  Stateless network firewall rule group should not be empty  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5, NIST SP 800-171 Rev. 2  |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [NetworkFirewall.7](networkfirewall-controls.md#networkfirewall-7)  | Network Firewall firewalls should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [NetworkFirewall.8](networkfirewall-controls.md#networkfirewall-8)  | Network Firewall firewall policies should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [NetworkFirewall.9](networkfirewall-controls.md#networkfirewall-9)  |  Network Firewall firewalls should have deletion protection enabled  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5  |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [NetworkFirewall.10](networkfirewall-controls.md#networkfirewall-10)  | Network Firewall firewalls should have subnet change protection enabled | AWS Foundational Security Best Practices, NIST SP 800-53 Rev. 5 | MEDIUM | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Change triggered | 
|  [Opensearch.1](opensearch-controls.md#opensearch-1)  |  OpenSearch domains should have encryption at rest enabled  |  AWS Foundational Security Best Practices v1.0.0, PCI DSS v3.2.1, NIST SP 800-53 Rev. 5  |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [Opensearch.2](opensearch-controls.md#opensearch-2)  |  OpenSearch domains should not be publicly accessible  |  AWS Foundational Security Best Practices v1.0.0, PCI DSS v3.2.1, NIST SP 800-53 Rev. 5  |  CRITICAL  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [Opensearch.3](opensearch-controls.md#opensearch-3)  |  OpenSearch domains should encrypt data sent between nodes  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5  |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [Opensearch.4](opensearch-controls.md#opensearch-4)  |  OpenSearch domain error logging to CloudWatch Logs should be enabled  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5  |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [Opensearch.5](opensearch-controls.md#opensearch-5)  |  OpenSearch domains should have audit logging enabled  | AWS Foundational Security Best Practices, NIST SP 800-53 Rev. 5, PCI DSS v4.0.1 |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [Opensearch.6](opensearch-controls.md#opensearch-6)  |  OpenSearch domains should have at least three data nodes  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5  |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [Opensearch.7](opensearch-controls.md#opensearch-7)  |  OpenSearch domains should have fine-grained access control enabled  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5  |  HIGH  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [Opensearch.8](opensearch-controls.md#opensearch-8)  | Connections to OpenSearch domains should be encrypted using the latest TLS security policy |  AWS Foundational Security Best Practices, NIST SP 800-53 Rev. 5 | MEDIUM | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Change triggered | 
|  [Opensearch.9](opensearch-controls.md#opensearch-9)  | OpenSearch domains should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [Opensearch.10](opensearch-controls.md#opensearch-10)  |  OpenSearch domains should have the latest software update installed  | AWS Foundational Security Best Practices, NIST SP 800-53 Rev. 5, PCI DSS v4.0.1 | MEDIUM |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [Opensearch.11](opensearch-controls.md#opensearch-11)  | OpenSearch domains should have at least three dedicated primary nodes | NIST SP 800-53 Rev. 5 | LOW | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Periodic | 
|  [PCA.1](pca-controls.md#pca-1)  |  AWS Private CA root certificate authority should be disabled  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5  |  LOW  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  | Periodic | 
|  [PCA.2](pca-controls.md#pca-2)  | AWS Private CA certificate authorities should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [RDS.1](rds-controls.md#rds-1)  |  RDS snapshot should be private  |  AWS Foundational Security Best Practices v1.0.0, PCI DSS v3.2.1, NIST SP 800-53 Rev. 5  |  CRITICAL  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [RDS.2](rds-controls.md#rds-2)  |  RDS DB Instances should prohibit public access, as determined by the PubliclyAccessible configuration  | CIS AWS Foundations Benchmark v5.0.0, CIS AWS Foundations Benchmark v3.0.0, AWS Foundational Security Best Practices, NIST SP 800-53 Rev. 5, PCI DSS v3.2.1, PCI DSS v4.0.1 |  CRITICAL  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [RDS.3](rds-controls.md#rds-3)  |  RDS DB instances should have encryption at-rest enabled  | CIS AWS Foundations Benchmark v5.0.0, CIS AWS Foundations Benchmark v3.0.0, CIS AWS Foundations Benchmark v1.4.0, AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5  |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [RDS.4](rds-controls.md#rds-4)  |  RDS cluster snapshots and database snapshots should be encrypted at rest  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5  |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [RDS.5](rds-controls.md#rds-5)  |  RDS DB instances should be configured with multiple Availability Zones  | CIS AWS Foundations Benchmark v5.0.0, AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5  |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [RDS.6](rds-controls.md#rds-6)  |  Enhanced monitoring should be configured for RDS DB instances  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5  |  LOW  |  ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes  |  Change triggered  | 
|  [RDS.7](rds-controls.md#rds-7)  |  RDS clusters should have deletion protection enabled  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5  | MEDIUM |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [RDS.8](rds-controls.md#rds-8)  |  RDS DB instances should have deletion protection enabled  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5  |  LOW  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [RDS.9](rds-controls.md#rds-9)  | RDS DB instances should publish logs to CloudWatch Logs | AWS Foundational Security Best Practices, NIST SP 800-53 Rev. 5, PCI DSS v4.0.1 |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [RDS.10](rds-controls.md#rds-10)  |  IAM authentication should be configured for RDS instances  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5  |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [RDS.11](rds-controls.md#rds-11)  |  RDS instances should have automatic backups enabled  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5  |  MEDIUM  |  ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes  |  Change triggered  | 
|  [RDS.12](rds-controls.md#rds-12)  |  IAM authentication should be configured for RDS clusters  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5  |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [RDS.13](rds-controls.md#rds-13)  |  RDS automatic minor version upgrades should be enabled  | CIS AWS Foundations Benchmark v5.0.0, CIS AWS Foundations Benchmark v3.0.0, AWS Foundational Security Best Practices, NIST SP 800-53 Rev. 5, PCI DSS v4.0.1 |  HIGH  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [RDS.14](rds-controls.md#rds-14)  |  Amazon Aurora clusters should have backtracking enabled  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5  |  MEDIUM  |  ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes  |  Change triggered  | 
|  [RDS.15](rds-controls.md#rds-15)  |  RDS DB clusters should be configured for multiple Availability Zones  | CIS AWS Foundations Benchmark v5.0.0, AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5  |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [RDS.16](rds-controls.md#rds-16)  | Aurora DB clusters should be configured to copy tags to DB snapshots | AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5 | LOW  | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Change triggered | 
|  [RDS.17](rds-controls.md#rds-17)  |  RDS DB instances should be configured to copy tags to snapshots  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5  |  LOW  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [RDS.18](rds-controls.md#rds-18)  |  RDS instances should be deployed in a VPC  |   |  HIGH  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [RDS.19](rds-controls.md#rds-19)  |  Existing RDS event notification subscriptions should be configured for critical cluster events  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5  |  LOW  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [RDS.20](rds-controls.md#rds-20)  |  Existing RDS event notification subscriptions should be configured for critical database instance events  | AWS Foundational Security Best Practices, NIST SP 800-53 Rev. 5, PCI DSS v4.0.1 |  LOW  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [RDS.21](rds-controls.md#rds-21)  |  An RDS event notifications subscription should be configured for critical database parameter group events  | AWS Foundational Security Best Practices, NIST SP 800-53 Rev. 5, PCI DSS v4.0.1 |  LOW  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [RDS.22](rds-controls.md#rds-22)  |  An RDS event notifications subscription should be configured for critical database security group events  | AWS Foundational Security Best Practices, NIST SP 800-53 Rev. 5, PCI DSS v4.0.1 |  LOW  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [RDS.23](rds-controls.md#rds-23)  |  RDS instances should not use a database engine default port  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5  |  LOW  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [RDS.24](rds-controls.md#rds-24)  |  RDS Database Clusters should use a custom administrator username  | AWS Foundational Security Best Practices, NIST SP 800-53 Rev. 5, PCI DSS v4.0.1 |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [RDS.25](rds-controls.md#rds-25)  |  RDS database instances should use a custom administrator username  | AWS Foundational Security Best Practices, NIST SP 800-53 Rev. 5, PCI DSS v4.0.1 |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [RDS.26](rds-controls.md#rds-26)  |  RDS DB instances should be protected by a backup plan  |  NIST SP 800-53 Rev. 5  |  MEDIUM  |  ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes  |  Periodic  | 
|  [RDS.27](rds-controls.md#rds-27)  |  RDS DB clusters should be encrypted at rest  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5  |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [RDS.28](rds-controls.md#rds-28)  | RDS DB clusters should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [RDS.29](rds-controls.md#rds-29)  | RDS DB cluster snapshots should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [RDS.30](rds-controls.md#rds-30)  | RDS DB instances should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [RDS.31](rds-controls.md#rds-31)  | RDS DB security groups should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [RDS.32](rds-controls.md#rds-32)  | RDS DB snapshots should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [RDS.33](rds-controls.md#rds-33)  | RDS DB subnet groups should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [RDS.34](rds-controls.md#rds-34)  |  Aurora MySQL DB clusters should publish audit logs to CloudWatch Logs  | AWS Foundational Security Best Practices, NIST SP 800-53 Rev. 5, PCI DSS v4.0.1 |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [RDS.35](rds-controls.md#rds-35)  |  RDS DB clusters should have automatic minor version upgrade enabled  | AWS Foundational Security Best Practices, NIST SP 800-53 Rev. 5, PCI DSS v4.0.1 |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [RDS.36](rds-controls.md#rds-36)  | RDS for PostgreSQL DB instances should publish logs to CloudWatch Logs | AWS Foundational Security Best Practices, PCI DSS v4.0.1 | MEDIUM | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [RDS.37](rds-controls.md#rds-37)  | Aurora PostgreSQL DB clusters should publish logs to CloudWatch Logs | AWS Foundational Security Best Practices, PCI DSS v4.0.1 | MEDIUM | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Change triggered | 
|  [RDS.38](rds-controls.md#rds-38)  | RDS for PostgreSQL DB instances should be encrypted in transit | AWS Foundational Security Best Practices | MEDIUM | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Periodic | 
|  [RDS.39](rds-controls.md#rds-39)  | RDS for MySQL DB instances should be encrypted in transit | AWS Foundational Security Best Practices | MEDIUM | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Periodic | 
|  [RDS.40](rds-controls.md#rds-40)  | RDS for SQL Server DB instances should publish logs to CloudWatch Logs | AWS Foundational Security Best Practices, NIST SP 800-53 Rev. 5 | MEDIUM | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [RDS.41](rds-controls.md#rds-41)  | RDS for SQL Server DB instances should be encrypted in transit | AWS Foundational Security Best Practices | MEDIUM | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Periodic | 
|  [RDS.42](rds-controls.md#rds-42)  | RDS for MariaDB DB instances should publish logs to CloudWatch Logs | AWS Foundational Security Best Practices, NIST SP 800-53 Rev. 5 | MEDIUM | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Periodic | 
|  [RDS.43](rds-controls.md#rds-43)  | RDS DB proxies should require TLS encryption for connections | AWS Foundational Security Best Practices | MEDIUM | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Periodic | 
|  [RDS.44](rds-controls.md#rds-44)  | RDS for MariaDB DB instances should be encrypted in transit | AWS Foundational Security Best Practices | MEDIUM | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Periodic | 
|  [RDS.45](rds-controls.md#rds-45)  | Aurora MySQL DB clusters should have audit logging enabled | AWS Foundational Security Best Practices, NIST SP 800-53 Rev. 5 | MEDIUM | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Periodic | 
|  [RDS.46](rds-controls.md#rds-46)  | RDS DB instances should not be deployed in public subnets with routes to internet gateways | AWS Foundational Security Best Practices | HIGH | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Periodic | 
|  [RDS.47](rds-controls.md#rds-47)  | RDS for PostgreSQL DB clusters should be configured to copy tags to DB snapshots | AWS Foundational Security Best Practices | LOW | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Change triggered | 
|  [RDS.48](rds-controls.md#rds-48)  | RDS for MySQL DB clusters should be configured to copy tags to DB snapshots | AWS Foundational Security Best Practices | LOW | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Change triggered | 
|  [RDS.50](rds-controls.md#rds-50)  |  RDS DB clusters should have enough backup retention period set  |  AWS Foundational Security Best Practices v1.0.0  |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) Yes  |  Change triggered  | 
|  [Redshift.1](redshift-controls.md#redshift-1)  |  Amazon Redshift clusters should prohibit public access  | AWS Foundational Security Best Practices, NIST SP 800-53 Rev. 5, PCI DSS v3.2.1, PCI DSS v4.0.1 |  CRITICAL  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [Redshift.2](redshift-controls.md#redshift-2)  |  Connections to Amazon Redshift clusters should be encrypted in transit  | AWS Foundational Security Best Practices, NIST SP 800-53 Rev. 5, PCI DSS v4.0.1 |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [Redshift.3](redshift-controls.md#redshift-3)  |  Amazon Redshift clusters should have automatic snapshots enabled  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5  |  MEDIUM  |  ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes  |  Change triggered  | 
|  [Redshift.4](redshift-controls.md#redshift-4)  |  Amazon Redshift clusters should have audit logging enabled  | AWS Foundational Security Best Practices, NIST SP 800-53 Rev. 5, PCI DSS v4.0.1 |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [Redshift.6](redshift-controls.md#redshift-6)  |  Amazon Redshift should have automatic upgrades to major versions enabled  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5  |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [Redshift.7](redshift-controls.md#redshift-7)  |  Redshift clusters should use enhanced VPC routing  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5  |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [Redshift.8](redshift-controls.md#redshift-8)  |  Amazon Redshift clusters should not use the default Admin username  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5  |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [Redshift.10](redshift-controls.md#redshift-10)  |  Redshift clusters should be encrypted at rest  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5  |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [Redshift.11](redshift-controls.md#redshift-11)  | Redshift clusters should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [Redshift.12](redshift-controls.md#redshift-12)  | Redshift event subscription notifications should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [Redshift.13](redshift-controls.md#redshift-13)  | Redshift cluster snapshots should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [Redshift.14](redshift-controls.md#redshift-14)  | Redshift cluster subnet groups should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [Redshift.15](redshift-controls.md#redshift-15)  | Redshift security groups should allow ingress on the cluster port only from restricted origins | AWS Foundational Security Best Practices, PCI DSS v4.0.1 | HIGH | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Periodic | 
|  [Redshift.16](redshift-controls.md#redshift-16)  | Redshift cluster subnet groups should have subnets from multiple Availability Zones | NIST SP 800-53 Rev. 5 | MEDIUM | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Change triggered | 
|  [Redshift.17](redshift-controls.md#redshift-17)  | Redshift cluster parameter groups should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [Redshift.18](redshift-controls.md#redshift-18)  | Redshift clusters should have Multi-AZ deployments enabled | AWS Foundational Security Best Practices | MEDIUM | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Change triggered | 
|  [RedshiftServerless.1](redshiftserverless-controls.md#redshiftserverless-1)  | Amazon Redshift Serverless workgroups should use enhanced VPC routing | AWS Foundational Security Best Practices | HIGH | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Periodic | 
|  [RedshiftServerless.2](redshiftserverless-controls.md#redshiftserverless-2)  | Connections to Redshift Serverless workgroups should be required to use SSL | AWS Foundational Security Best Practices | MEDIUM | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Periodic | 
|  [RedshiftServerless.3](redshiftserverless-controls.md#redshiftserverless-3)  | Redshift Serverless workgroups should prohibit public access | AWS Foundational Security Best Practices | HIGH | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Periodic | 
|  [RedshiftServerless.4](redshiftserverless-controls.md#redshiftserverless-4)  | Redshift Serverless namespaces should be encrypted with customer managed AWS KMS keys | NIST SP 800-53 Rev. 5 | MEDIUM | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Periodic | 
|  [RedshiftServerless.5](redshiftserverless-controls.md#redshiftserverless-5)  | Redshift Serverless namespaces should not use the default admin username | AWS Foundational Security Best Practices | MEDIUM | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Periodic | 
|  [RedshiftServerless.6](redshiftserverless-controls.md#redshiftserverless-6)  | Redshift Serverless namespaces should export logs to CloudWatch Logs | AWS Foundational Security Best Practices | MEDIUM | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Periodic | 
|  [Route53.1](route53-controls.md#route53-1)  | Route 53 health checks should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [Route53.2](route53-controls.md#route53-2)  |  Route 53 public hosted zones should log DNS queries  | AWS Foundational Security Best Practices, NIST SP 800-53 Rev. 5, PCI DSS v4.0.1 |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [S3.1](s3-controls.md#s3-1)  | S3 general purpose buckets should have block public access settings enabled | CIS AWS Foundations Benchmark v5.0.0, CIS AWS Foundations Benchmark v3.0.0, CIS AWS Foundations Benchmark v1.4.0, AWS Foundational Security Best Practices, NIST SP 800-53 Rev. 5, PCI DSS v3.2.1, PCI DSS v4.0.1 | MEDIUM | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Periodic | 
|  [S3.2](s3-controls.md#s3-2)  | S3 general purpose buckets should block public read access | AWS Foundational Security Best Practices, PCI DSS v3.2.1, NIST SP 800-53 Rev. 5 | CRITICAL | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Change triggered and periodic | 
|  [S3.3](s3-controls.md#s3-3)  | S3 general purpose buckets should block public write access | AWS Foundational Security Best Practices, PCI DSS v3.2.1, NIST SP 800-53 Rev. 5 | CRITICAL | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Change triggered and periodic | 
|  [S3.5](s3-controls.md#s3-5)  | S3 general purpose buckets should require requests to use SSL | CIS AWS Foundations Benchmark v5.0.0, CIS AWS Foundations Benchmark v3.0.0, CIS AWS Foundations Benchmark v1.4.0, AWS Foundational Security Best Practices, NIST SP 800-53 Rev. 5, NIST SP 800-171 Rev. 2, PCI DSS v3.2.1, PCI DSS v4.0.1 | MEDIUM | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Change triggered | 
|  [S3.6](s3-controls.md#s3-6)  | S3 general purpose bucket policies should restrict access to other AWS accounts | AWS Foundational Security Best Practices, NIST SP 800-53 Rev. 5, NIST SP 800-171 Rev. 2 | HIGH | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Change triggered | 
|  [S3.7](s3-controls.md#s3-7)  | S3 general purpose buckets should use cross-Region replication | PCI DSS v3.2.1, NIST SP 800-53 Rev. 5 | LOW | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Change triggered | 
|  [S3.8](s3-controls.md#s3-8)  | S3 general purpose buckets should block public access | CIS AWS Foundations Benchmark v5.0.0, CIS AWS Foundations Benchmark v3.0.0, CIS AWS Foundations Benchmark v1.4.0, AWS Foundational Security Best Practices, NIST SP 800-53 Rev. 5, PCI DSS v4.0.1 | HIGH | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Change triggered | 
|  [S3.9](s3-controls.md#s3-9)  | S3 general purpose buckets should have server access logging enabled | AWS Foundational Security Best Practices, NIST SP 800-53 Rev. 5, NIST SP 800-171 Rev. 2, PCI DSS v4.0.1 | MEDIUM | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Change triggered | 
|  [S3.10](s3-controls.md#s3-10)  | S3 general purpose buckets with versioning enabled should have Lifecycle configurations | NIST SP 800-53 Rev. 5 | MEDIUM | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Change triggered | 
|  [S3.11](s3-controls.md#s3-11)  | S3 general purpose buckets should have event notifications enabled | NIST SP 800-53 Rev. 5, NIST SP 800-171 Rev. 2 | MEDIUM | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [S3.12](s3-controls.md#s3-12)  | ACLs should not be used to manage user access to S3 general purpose buckets | AWS Foundational Security Best Practices, NIST SP 800-53 Rev. 5 | MEDIUM | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Change triggered | 
|  [S3.13](s3-controls.md#s3-13)  | S3 general purpose buckets should have Lifecycle configurations | AWS Foundational Security Best Practices, NIST SP 800-53 Rev. 5 | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [S3.14](s3-controls.md#s3-14)  | S3 general purpose buckets should have versioning enabled | NIST SP 800-53 Rev. 5, NIST SP 800-171 Rev. 2 | LOW | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Change triggered | 
|  [S3.15](s3-controls.md#s3-15)  | S3 general purpose buckets should have Object Lock enabled | NIST SP 800-53 Rev. 5, PCI DSS v4.0.1 | MEDIUM | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [S3.17](s3-controls.md#s3-17)  | S3 general purpose buckets should be encrypted at rest with AWS KMS keys | NIST SP 800-53 Rev. 5, NIST SP 800-171 Rev. 2, PCI DSS v4.0.1 | MEDIUM | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Change triggered | 
|  [S3.19](s3-controls.md#s3-19)  | S3 access points should have block public access settings enabled | AWS Foundational Security Best Practices, NIST SP 800-53 Rev. 5, PCI DSS v4.0.1 | CRITICAL | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Change triggered | 
|  [S3.20](s3-controls.md#s3-20)  | S3 general purpose buckets should have MFA delete enabled | CIS AWS Foundations Benchmark v5.0.0, CIS AWS Foundations Benchmark v3.0.0, CIS AWS Foundations Benchmark v1.4.0, NIST SP 800-53 Rev. 5 | LOW | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Change triggered | 
|  [S3.22](s3-controls.md#s3-22)  | S3 general purpose buckets should log object-level write events | CIS AWS Foundations Benchmark v5.0.0, CIS AWS Foundations Benchmark v3.0.0, PCI DSS v4.0.1 | MEDIUM | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Periodic | 
|  [S3.23](s3-controls.md#s3-23)  | S3 general purpose buckets should log object-level read events | CIS AWS Foundations Benchmark v5.0.0, CIS AWS Foundations Benchmark v3.0.0, PCI DSS v4.0.1 | MEDIUM | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Periodic | 
|  [S3.24](s3-controls.md#s3-24)  | S3 Multi-Region Access Points should have block public access settings enabled | AWS Foundational Security Best Practices, PCI DSS v4.0.1 | HIGH | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Change triggered | 
|  [S3.25](s3-controls.md#s3-25)  | S3 directory buckets should have lifecycle configurations | AWS Foundational Security Best Practices | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [SageMaker.1](sagemaker-controls.md#sagemaker-1)  |  Amazon SageMaker notebook instances should not have direct internet access  | AWS Foundational Security Best Practices, NIST SP 800-53 Rev. 5, PCI DSS v3.2.1, PCI DSS v4.0.1 |  HIGH  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Periodic  | 
|  [SageMaker.2](sagemaker-controls.md#sagemaker-2)  |  SageMaker notebook instances should be launched in a custom VPC  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5  |  HIGH  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [SageMaker.3](sagemaker-controls.md#sagemaker-3)  |  Users should not have root access to SageMaker notebook instances  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5  |  HIGH  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [SageMaker.4](sagemaker-controls.md#sagemaker-4)  | SageMaker endpoint production variants should have an initial instance count greater than 1 | AWS Foundational Security Best Practices, NIST SP 800-53 Rev. 5 | MEDIUM | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Periodic | 
|  [SageMaker.5](sagemaker-controls.md#sagemaker-5)  | SageMaker models should have network isolation enabled | AWS Foundational Security Best Practices | MEDIUM | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Change triggered | 
|  [SageMaker.6](sagemaker-controls.md#sagemaker-6)  | SageMaker app image configurations should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [SageMaker.7](sagemaker-controls.md#sagemaker-7)  | SageMaker images should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [SageMaker.8](sagemaker-controls.md#sagemaker-8)  | SageMaker notebook instances should run on supported platforms | AWS Foundational Security Best Practices | MEDIUM | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Periodic | 
|  [SageMaker.9](sagemaker-controls.md#sagemaker-9)  |  SageMaker data quality job definitions should have inter-container traffic encryption enabled  |  AWS Foundational Security Best Practices v1.0.0  |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [SageMaker.10](sagemaker-controls.md#sagemaker-10)  |  SageMaker model explainability job definitions should have inter-container traffic encryption enabled  |  AWS Foundational Security Best Practices v1.0.0  |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [SageMaker.11](sagemaker-controls.md#sagemaker-11)  |  SageMaker data quality job definitions should have network isolation enabled  |  AWS Foundational Security Best Practices v1.0.0  |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [SageMaker.12](sagemaker-controls.md#sagemaker-12)  |  SageMaker model bias job definitions should have network isolation enabled  |  AWS Foundational Security Best Practices v1.0.0  |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [SageMaker.13](sagemaker-controls.md#sagemaker-13)  |  SageMaker model quality job definitions should have inter-container traffic encryption enabled  |  AWS Foundational Security Best Practices v1.0.0  |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [SageMaker.14](sagemaker-controls.md#sagemaker-14)  |  SageMaker monitoring schedules should have network isolation enabled  |  AWS Foundational Security Best Practices v1.0.0  |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [SageMaker.15](sagemaker-controls.md#sagemaker-15)  |  SageMaker model bias job definitions should have inter-container traffic encryption enabled  |  AWS Foundational Security Best Practices v1.0.0  |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [SageMaker.16](sagemaker-controls.md#sagemaker-16)  | SageMaker models should use private registry in VPC for primary containers | AWS Foundational Security Best Practices | MEDIUM | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Change triggered | 
|  [SageMaker.17](sagemaker-controls.md#sagemaker-17)  | SageMaker feature group offline stores should be encrypted with AWS KMS keys | AWS Foundational Security Best Practices | MEDIUM | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Change triggered | 
|  [SecretsManager.1](secretsmanager-controls.md#secretsmanager-1)  |  Secrets Manager secrets should have automatic rotation enabled  | AWS Foundational Security Best Practices, NIST SP 800-53 Rev. 5, PCI DSS v4.0.1 |  MEDIUM  |  ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes  |  Change triggered  | 
|  [SecretsManager.2](secretsmanager-controls.md#secretsmanager-2)  |  Secrets Manager secrets configured with automatic rotation should rotate successfully  | AWS Foundational Security Best Practices, NIST SP 800-53 Rev. 5, PCI DSS v4.0.1 |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [SecretsManager.3](secretsmanager-controls.md#secretsmanager-3)  |  Remove unused Secrets Manager secrets  | AWS Foundational Security Best Practices, NIST SP 800-53 Rev. 5 |  MEDIUM  |  ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes  |  Periodic  | 
|  [SecretsManager.4](secretsmanager-controls.md#secretsmanager-4)  |  Secrets Manager secrets should be rotated within a specified number of days  | AWS Foundational Security Best Practices, NIST SP 800-53 Rev. 5, PCI DSS v4.0.1 |  MEDIUM  |  ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes  |  Periodic  | 
|  [SecretsManager.5](secretsmanager-controls.md#secretsmanager-5)  | Secrets Manager secrets should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [ServiceCatalog.1](servicecatalog-controls.md#servicecatalog-1)  | Service Catalog portfolios should be shared within an AWS organization only | AWS Foundational Security Best Practices, NIST SP 800-53 Rev. 5 | MEDIUM | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Periodic | 
|  [SES.1](ses-controls.md#ses-1)  | SES contact lists should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [SES.2](ses-controls.md#ses-2)  | SES configuration sets should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [SES.3](ses-controls.md#ses-3)  | SES configuration sets should have TLS enabled for sending emails | AWS Foundational Security Best Practices | MEDIUM | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Change triggered | 
|  [SNS.1](sns-controls.md#sns-1)  | SNS topics should be encrypted at-rest using AWS KMS | NIST SP 800-53 Rev. 5, NIST SP 800-171 Rev. 2 | MEDIUM | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Change triggered | 
|  [SNS.3](sns-controls.md#sns-3)  | SNS topics should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [SNS.4](sns-controls.md#sns-4)  | SNS topic access policies should not allow public access | AWS Foundational Security Best Practices | CRITICAL | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Change triggered | 
|  [SQS.1](sqs-controls.md#sqs-1)  |  Amazon SQS queues should be encrypted at rest  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5  |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [SQS.2](sqs-controls.md#sqs-2)  | SQS queues should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [SQS.3](sqs-controls.md#sqs-3)  | SQS queue access policies should not allow public access | AWS Foundational Security Best Practices | CRITICAL | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Change triggered | 
|  [SSM.1](ssm-controls.md#ssm-1)  |  EC2 instances should be managed by AWS Systems Manager  |  AWS Foundational Security Best Practices v1.0.0, PCI DSS v3.2.1, NIST SP 800-53 Rev. 5  |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [SSM.2](ssm-controls.md#ssm-2)  |  EC2 instances managed by Systems Manager should have a patch compliance status of COMPLIANT after a patch installation  | AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5, NIST SP 800-171 Rev. 2, PCI DSS v3.2.1, PCI DSS v4.0.1 |  HIGH  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [SSM.3](ssm-controls.md#ssm-3)  |  EC2 instances managed by Systems Manager should have an association compliance status of COMPLIANT  | AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5, PCI DSS v3.2.1, PCI DSS v4.0.1 |  LOW  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [SSM.4](ssm-controls.md#ssm-4)  |  SSM documents should not be public  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5  |  CRITICAL  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Periodic  | 
|  [SSM.5](ssm-controls.md#ssm-5)  | SSM documents should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [SSM.6](ssm-controls.md#ssm-6)  | SSM Automation should have CloudWatch logging enabled | AWS Foundational Security Best Practices v1.0.0 | MEDIUM | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Periodic | 
|  [SSM.7](ssm-controls.md#ssm-7)  | SSM documents should have the block public sharing setting enabled | AWS Foundational Security Best Practices v1.0.0 | CRITICAL | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Periodic | 
|  [StepFunctions.1](stepfunctions-controls.md#stepfunctions-1)  |  Step Functions state machines should have logging turned on  | AWS Foundational Security Best Practices v1.0.0, PCI DSS v4.0.1 |  MEDIUM  |  ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes  |  Change triggered  | 
|  [StepFunctions.2](stepfunctions-controls.md#stepfunctions-2)  | Step Functions activities should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [Transfer.1](transfer-controls.md#transfer-1)  | Transfer Family workflows should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [Transfer.2](transfer-controls.md#transfer-2)  | Transfer Family servers should not use FTP protocol for endpoint connection | AWS Foundational Security Best Practices, NIST SP 800-53 Rev. 5, PCI DSS v4.0.1 | MEDIUM | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Periodic | 
|  [Transfer.3](transfer-controls.md#transfer-3)  | Transfer Family connectors should have logging enabled | AWS Foundational Security Best Practices, NIST SP 800-53 Rev. 5 | MEDIUM | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Change triggered | 
|  [Transfer.4](transfer-controls.md#transfer-4)  | Transfer Family agreements should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [Transfer.5](transfer-controls.md#transfer-5)  | Transfer Family certificates should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [Transfer.6](transfer-controls.md#transfer-6)  | Transfer Family connectors should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [Transfer.7](transfer-controls.md#transfer-7)  | Transfer Family profiles should be tagged | AWS Resource Tagging Standard | LOW | ![\[Yes\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-yes.png) Yes | Change triggered | 
|  [WAF.1](waf-controls.md#waf-1)  |  AWS WAF Classic Global Web ACL logging should be enabled  | AWS Foundational Security Best Practices, NIST SP 800-53 Rev. 5, PCI DSS v4.0.1 |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Periodic  | 
|  [WAF.2](waf-controls.md#waf-2)  |  AWS WAF Classic Regional rules should have at least one condition  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5  |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [WAF.3](waf-controls.md#waf-3)  |  AWS WAF Classic Regional rule groups should have at least one rule  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5  |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [WAF.4](waf-controls.md#waf-4)  |  AWS WAF Classic Regional web ACLs should have at least one rule or rule group  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5  |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [WAF.6](waf-controls.md#waf-6)  |  AWS WAF Classic global rules should have at least one condition  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5  |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [WAF.7](waf-controls.md#waf-7)  |  AWS WAF Classic global rule groups should have at least one rule  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5  |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [WAF.8](waf-controls.md#waf-8)  |  AWS WAF Classic global web ACLs should have at least one rule or rule group  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5  |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [WAF.10](waf-controls.md#waf-10)  |  AWS WAF web ACLs should have at least one rule or rule group  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5  |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [WAF.11](waf-controls.md#waf-11)  |  AWS WAF web ACL logging should be enabled  | NIST SP 800-53 Rev. 5, PCI DSS v4.0.1 |  LOW  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Periodic  | 
|  [WAF.12](waf-controls.md#waf-12)  |  AWS WAF rules should have CloudWatch metrics enabled  |  AWS Foundational Security Best Practices v1.0.0, NIST SP 800-53 Rev. 5, NIST SP 800-171 Rev. 2  |  MEDIUM  |  ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No  |  Change triggered  | 
|  [WorkSpaces.1](workspaces-controls.md#workspaces-1)  | WorkSpaces user volumes should be encrypted at rest | AWS Foundational Security Best Practices | MEDIUM | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Change triggered | 
|  [WorkSpaces.2](workspaces-controls.md#workspaces-2)  | WorkSpaces root volumes should be encrypted at rest | AWS Foundational Security Best Practices | MEDIUM | ![\[No\]](http://docs.aws.amazon.com/securityhub/latest/userguide/images/icon-no.png) No | Change triggered | 

# Change log for Security Hub CSPM controls
<a name="controls-change-log"></a>

The following change log tracks material changes to existing AWS Security Hub CSPM controls, which can result in changes to the overall status of a control and the compliance status of its findings. For information about how Security Hub CSPM evaluates control status, see [Evaluating compliance status and control status](controls-overall-status.md). Changes can take a few days after their entry in this log to affect all AWS Regions in which the control is available.

This log tracks changes occurring since April 2023. Choose a control to review additional details about it. Title changes are noted in a control's detailed description for 90 days.


| Date of change | Control ID and title | Description of change | 
| --- | --- | --- | 
| April 7, 2026 | [[EC2.1] Amazon EBS snapshots should not be configured to be publicly restorable](ec2-controls.md#ec2-1) | Security Hub CSPM changed the title and description of this control. The new title and description more accurately reflect that the control checks whether Amazon EBS snapshots are configured to be publicly restorable. Previously, the title of this control was: *Amazon EBS snapshots should not be publicly restorable*. | 
| April 7, 2026 | [[EC2.182] Block public access settings should be enabled for Amazon EBS snapshots](ec2-controls.md#ec2-182) | Security Hub CSPM changed the title and description of this control. The new title and description more accurately reflect that the control checks whether account level block public access is enabled for Amazon EBS snapshots. Previously, the title of this control was: *Amazon EBS Snapshots should not be publicly accessible*. | 
| April 6, 2026 | [[ELB.17] Application and Network Load Balancers with listeners should use recommended security policies](elb-controls.md#elb-17) | Security Hub CSPM updated the parameter value for this control to reflect recommended security policies. | 
| April 3, 2026 | [[Cognito.3] Password policies for Cognito user pools should have strong configurations](cognito-controls.md#cognito-3) | Security Hub CSPM expanded the range of supported values for the `temporaryPasswordValidity` parameter of this control. You can now specify a value ranging from 1-365 days. Previously, the range was 7-365 days. | 
| April 3, 2026 | [[EKS.2] EKS clusters should run on a supported Kubernetes version](eks-controls.md#eks-2) | This control checks whether an Amazon EKS cluster runs on a supported Kubernetes version. Security Hub CSPM changed the parameter value for this control from `1.32` to `1.33`. Standard support for Kubernetes version 1.32 in Amazon EKS ended on March 23, 2026.  | 
| April 3, 2026 | [[Lambda.2] Lambda functions should use supported runtimes](lambda-controls.md#lambda-2)  | Lambda.2 parameter for supported runtimes no longer includes ruby3.2 as Lambda has deprecated this runtime. | 
| March 24, 2026 | [[RDS.50] RDS DB clusters should have enough backup retention period set](rds-controls.md#rds-50) | Security Hub CSPM updated the control title to reflect that the control checks all RDS DB clusters. | 
| March 24, 2026 | [[ECS.5] ECS task definitions should configure containers to be limited to read-only access to root filesystems](ecs-controls.md#ecs-5) | Security Hub CSPM updated the control title and description to reflect that the control checks ECS task definitions. Security Hub CSPM also updated the control to not generate findings for task definitions with `runtimePlatform` configured to specify a `WINDOWS_SERVER` OS family. | 
| March 9, 2026 | [AppSync.1] AWS AppSync API caches should be encrypted at rest | Security Hub CSPM retired this control and removed it from the [AWS Foundational Security Best Practices (FSBP) standard](https://docs.aws.amazon.com/securityhub/latest/userguide/fsbp-standard.html). AWS AppSync now provides default encryption on all current and future API caches. | 
| March 9, 2026 | [AppSync.6] AWS AppSync API caches should be encrypted in transit | Security Hub CSPM retired this control and removed it from the [AWS Foundational Security Best Practices (FSBP) standard](https://docs.aws.amazon.com/securityhub/latest/userguide/fsbp-standard.html). AWS AppSync now provides default encryption on all current and future API caches. | 
| March 4, 2026 | [ECS.1] Amazon ECS task definitions should have secure networking modes and user definitions | Security Hub CSPM retired this control and removed it from the [AWS Foundational Security Best Practices (FSBP) standard](https://docs.aws.amazon.com/securityhub/latest/userguide/fsbp-standard.html) and the [NIST SP 800-53 Rev. 5 standard](https://docs.aws.amazon.com/securityhub/latest/userguide/nist-standard.html).  | 
| February 5, 2026 | [[AppSync.1] AWS AppSync API caches should be encrypted at rest](appsync-controls.md#appsync-1) | Security Hub CSPM will retire this control and remove from all applicable Security Hub CSPM standards on March 9, 2026. AWS AppSync is providing default encryption on all current and future API caches. | 
| February 5, 2026 | [[AppSync.6] AWS AppSync API caches should be encrypted in transit](appsync-controls.md#appsync-6) | Security Hub CSPM will retire this control and remove from all applicable Security Hub CSPM standards on March 9, 2026. AWS AppSync is providing default encryption on all current and future API caches. | 
| January 16, 2026 | [[ECS.1] Amazon ECS task definitions should have secure networking modes and user definitions](ecs-controls.md#ecs-1) | Security Hub CSPM provided notice that this control will be retired and removed from all applicable Security Hub CSPM standards after February 16, 2026. | 
| January 12, 2026 | [[Redshift.4] Amazon Redshift clusters should have audit logging enabled](redshift-controls.md#redshift-4) | Security Hub CSPM updated this control to remove the `loggingEnabled` parameter. | 
| January 12, 2026 | [MQ.3] Amazon MQ brokers should have automatic minor version upgrade enabled | Security Hub CSPM retired the control and removed the control from all applicable standards. Security Hub CSPM retired the control due to Amazon MQ requirements for automatic minor version upgrades. Previously, the control applied to the [AWS Foundational Security Best Practices (FSBP) standard](https://docs.aws.amazon.com/securityhub/latest/userguide/fsbp-standard.html), the [NIST SP 800-53 Rev. 5 standard](https://docs.aws.amazon.com/securityhub/latest/userguide/nist-standard.html) and the [PCI DSS v4.0.1 standard](https://docs.aws.amazon.com/securityhub/latest/userguide/pci-standard.html).  | 
| January 12, 2026 | [[Lambda.2] Lambda functions should use supported runtimes](lambda-controls.md#lambda-2) | This control checks whether the runtime settings for an AWS Lambda function match expected values for supported runtimes in each language. Security Hub CSPM now supports `dotnet10` as a parameter value for this control. AWS Lambda added support for this runtime. | 
| December 15, 2025 | [[Lambda.2] Lambda functions should use supported runtimes](lambda-controls.md#lambda-2) | This control checks whether the runtime settings for an AWS Lambda function match expected values for supported runtimes in each language. Security Hub CSPM no longer supports `python3.9` as a parameter value for this control. AWS Lambda no longer supports this runtime. | 
| December 12, 2025 | [[EKS.2] EKS clusters should run on a supported Kubernetes version](eks-controls.md#eks-2) | This control checks whether an Amazon EKS cluster runs on a supported Kubernetes version. Security Hub CSPM changed the parameter value for this control from `1.31` to `1.32`. Standard support for Kubernetes version 1.31 in Amazon EKS ended on November 26, 2025.  | 
| November 21, 2025 | [[Lambda.2] Lambda functions should use supported runtimes](lambda-controls.md#lambda-2) | This control checks whether the runtime settings for an AWS Lambda function match expected values for supported runtimes in each language. Security Hub CSPM now supports `nodejs24.x` and `python3.14` as parameter values for this control. AWS Lambda added support for these runtimes. | 
| November 14, 2025 | [[EC2.15] Amazon EC2 subnets should not automatically assign public IP addresses](ec2-controls.md#ec2-15) | Security Hub CSPM updated the description and rationale for this control. Previously, the control only checked for IPv4 public IP auto-assignment in Amazon VPC subnets using the `MapPublicIpOnLaunch` flag. This control now checks for both IPv4 and IPv6 public IP auto-assignment. The control's description and rationale have been updated to reflect these changes. | 
| November 14, 2025 | [[Lambda.2] Lambda functions should use supported runtimes](lambda-controls.md#lambda-2) | This control checks whether the runtime settings for an AWS Lambda function match expected values for supported runtimes in each language. Security Hub CSPM now supports `java25` as a parameter value for this control. AWS Lambda added support for this runtime. | 
| November 13, 2025 | [[SNS.4] SNS topic access policies should not allow public access](sns-controls.md#sns-4) | Security Hub CSPM changed the severity of this control from `HIGH` to `CRITICAL`. Allowing public access to Amazon SNS topics poses a significant security risk. | 
| November 13, 2025 | [[SQS.3] SQS queue access policies should not allow public access](sqs-controls.md#sqs-3) | Security Hub CSPM changed the severity of this control from `HIGH` to `CRITICAL`. Allowing public access to Amazon SQS queues poses a significant security risk. | 
| November 13, 2025 | [[GuardDuty.7] GuardDuty EKS Runtime Monitoring should be enabled](guardduty-controls.md#guardduty-7) | Security Hub CSPM changed the severity of this control from `MEDIUM` to `HIGH`. This type of runtime monitoring provides enhanced threat detection for Amazon EKS resources. | 
| November 13, 2025 | [[MQ.3] Amazon MQ brokers should have automatic minor version upgrade enabled](mq-controls.md#mq-3) | Security Hub CSPM changed the severity of this control from `LOW` to `MEDIUM`. Minor version upgrades include security patches that are necessary for maintaining Amazon MQ broker security. | 
| November 13, 2025 | [[Opensearch.10] OpenSearch domains should have the latest software update installed](opensearch-controls.md#opensearch-10) | Security Hub CSPM changed the severity of this control from `LOW` to `MEDIUM`. Software updates include security patches that are necessary for maintaining OpenSearch domain security. | 
| November 13, 2025 | [[RDS.7] RDS clusters should have deletion protection enabled](rds-controls.md#rds-7) | Security Hub CSPM changed the severity of this control from `LOW` to `MEDIUM`. Deletion protection helps prevent accidental deletion of Amazon RDS databases and deletion of RDS databases by unauthorized entities. | 
| November 13, 2025 | [[CloudTrail.5] CloudTrail trails should be integrated with Amazon CloudWatch Logs](cloudtrail-controls.md#cloudtrail-5) | Security Hub CSPM changed the severity of this control from `LOW` to `MEDIUM`. AWS CloudTrail logging data in Amazon CloudWatch Logs can be used for audit activities, alarms, and other important security operations. | 
| November 13, 2025 | [[ServiceCatalog.1] Service Catalog portfolios should be shared within an AWS organization only](servicecatalog-controls.md#servicecatalog-1) | Security Hub CSPM changed the severity of this control from `HIGH` to `MEDIUM`. Sharing AWS Service Catalog portfolios with specific accounts could be intentional and doesn’t necessarily indicate that a portfolio is publicly accessible. | 
| November 13, 2025 | [[CloudFront.7] CloudFront distributions should use custom SSL/TLS certificates](cloudfront-controls.md#cloudfront-7) | Security Hub CSPM changed the severity of this control from `MEDIUM` to `LOW`. Default `cloudfront.net` domain names for Amazon CloudFront distributions are generated randomly, which reduces security risk. | 
| November 13, 2025 | [[ELB.7] Classic Load Balancers should have connection draining enabled](elb-controls.md#elb-7) | Security Hub CSPM changed the severity of this control from `MEDIUM` to `LOW`. In multi-instance deployments, other healthy instances can handle user sessions when an instance is terminated without connection draining, which reduces operational impact and availability risks. | 
| November 13, 2025 | [[RedshiftServerless.5] Redshift Serverless namespaces should not use the default admin username](redshiftserverless-controls.md#redshiftserverless-5) | Security Hub CSPM updated this control to remove the optional `validAdminUserNames` parameter. | 
| October 23, 2025 | [[ElastiCache.1] ElastiCache (Redis OSS) clusters should have automatic backups enabled](elasticache-controls.md#elasticache-1) | Security Hub CSPM reverted the changes that were made to the title, description, and rule for this control on October 14, 2025. | 
| October 22, 2025 | [[CloudFront.1] CloudFront distributions should have a default root object configured](cloudfront-controls.md#cloudfront-1) | Security Hub CSPM updated this control to not generate findings for Amazon CloudFront distributions that use custom origins.  | 
| October 16, 2025 | [[CloudFront.15] CloudFront distributions should use the recommended TLS security policy](cloudfront-controls.md#cloudfront-15) | This control checks whether an Amazon CloudFront distribution is configured to use a recommended TLS security policy. Security Hub CSPM now supports `TLSv1.2_2025` and `TLSv1.3_2025` as parameter values for this control. | 
| October 14, 2025 | [[ElastiCache.1] ElastiCache (Redis OSS) clusters should have automatic backups enabled](elasticache-controls.md#elasticache-1) | Security Hub CSPM changed the title, description, and rule for this control. Previously, the control checked Redis OSS clusters and all replication groups, using the [elasticache-redis-cluster-automatic-backup-check](https://docs.aws.amazon.com/config/latest/developerguide/elasticache-redis-cluster-automatic-backup-check.html) rule. The title of the control was: *ElastiCache (Redis OSS) clusters should have automatic backups enabled*. This control now checks Valkey clusters in addition to Redis OSS clusters and all replication groups, using the [elasticache-automatic-backup-check-enabled](https://docs.aws.amazon.com/config/latest/developerguide/elasticache-automatic-backup-check-enabled.html) rule. The new title and description reflect that the control checks both types of clusters.  | 
| October 5, 2025 | [[Opensearch.10] OpenSearch domains should have the latest software update installed](opensearch-controls.md#opensearch-10) | The rule for this control was updated to also generate a `PASSED` finding if an Amazon OpenSearch Service domain has no software updates available and the update status is ineligible. Previously, this control generated a `PASSED` finding only if an OpenSearch domain had no software updates available and the update status was complete.  | 
| September 24, 2025 | [Redshift.9] Redshift clusters should not use the default database name [RedshiftServerless.7] Redshift Serverless namespaces should not use the default database name | Security Hub CSPM retired these controls and removed them from all applicable standards. Security Hub CSPM retired these controls due to inherent Amazon Redshift limitations that prevented effective remediation of `FAILED` findings for the controls. Previously, the controls applied to the [AWS Foundational Security Best Practices (FSBP) standard](https://docs.aws.amazon.com/securityhub/latest/userguide/fsbp-standard.html) and the [NIST SP 800-53 Rev. 5 standard](https://docs.aws.amazon.com/securityhub/latest/userguide/nist-standard.html). The Redshift.9 control also applied to the [AWS Control Tower service-managed standard](https://docs.aws.amazon.com/securityhub/latest/userguide/service-managed-standard-aws-control-tower.html).  | 
| September 9, 2025 | [[Lambda.2] Lambda functions should use supported runtimes](lambda-controls.md#lambda-2) | This control checks whether the runtime settings for an AWS Lambda function match expected values for supported runtimes in each language. Security Hub CSPM no longer supports `nodejs18.x` as a parameter value for this control. AWS Lambda no longer supports Node.js 18 runtimes. | 
| August 13, 2025 | [[SageMaker.5] SageMaker models should have network isolation enabled](sagemaker-controls.md#sagemaker-5) | Security Hub CSPM changed the title and description of this control. The new title and description more accurately reflect that the control checks the setting for the `EnableNetworkIsolation` parameter of Amazon SageMaker AI hosted models. Previously, the title of this control was: *SageMaker models should block inbound traffic*.  | 
| August 13, 2025 | [[EFS.6] EFS mount targets should not be associated with subnets that assign public IP addresses on launch](efs-controls.md#efs-6) | Security Hub CSPM changed the title and description of this control. The new title and description more precisely reflect the scope and nature of the check that the control performs. Previously, the title of this control was: *EFS mount targets should not be associated with a public subnet*.  | 
| July 24, 2025 | [[EKS.2] EKS clusters should run on a supported Kubernetes version](eks-controls.md#eks-2) | This control checks whether an Amazon EKS cluster runs on a supported Kubernetes version. Security Hub CSPM changed the parameter value for this control from `1.30` to `1.31`. Standard support for Kubernetes version 1.30 in Amazon EKS ended on July 23, 2025.  | 
| July 23, 2025 | [[EC2.173] EC2 Spot Fleet requests with launch parameters should enable encryption for attached EBS volumes](ec2-controls.md#ec2-173) | Security Hub CSPM changed the title of this control. The new title more accurately reflects that the control only checks Amazon EC2 Spot Fleet requests that specify launch parameters. Previously, the title of this control was: *EC2 Spot Fleet requests should enable encryption for attached EBS volumes*.  | 
| June 30, 2025 | [[IAM.13] Ensure IAM password policy requires at least one symbol](iam-controls.md#iam-13) | Security Hub CSPM removed this control from the [PCI DSS v4.0.1 standard](pci-standard.md). PCI DSS v4.0.1 doesn't explicitly require the use of symbols in passwords.  | 
| June 30, 2025 | [[IAM.17] Ensure IAM password policy expires passwords within 90 days or less](iam-controls.md#iam-17) | Security Hub CSPM removed this control from the [NIST SP 800-171 Revision 2 standard](standards-reference-nist-800-171.md). NIST SP 800-171 Revision 2 doesn't explicitly require password expiration periods of 90 days or less.  | 
| June 30, 2025 | [[RDS.16] Aurora DB clusters should be configured to copy tags to DB snapshots](rds-controls.md#rds-16) | Security Hub CSPM changed the title of this control. The new title more accurately reflects that the control only checks Amazon Aurora DB clusters. Previously, the title of this control was: *RDS DB clusters should be configured to copy tags to snapshots*. | 
| June 30, 2025 | [[SageMaker.8] SageMaker notebook instances should run on supported platforms](sagemaker-controls.md#sagemaker-8) | This control checks whether an Amazon SageMaker AI notebook instance is configured to run on a supported platform, based on the platform identifier specified for the notebook instance. Security Hub CSPM no longer supports `notebook-al2-v1` and `notebook-al2-v2` as parameter values for this control. Notebook instances that run on these platforms reached end of support on June 30, 2025. | 
| May 30, 2025 | [[IAM.10] Password policies for IAM users should have strong configurations](iam-controls.md#iam-10) | Security Hub CSPM removed this control from the [PCI DSS v4.0.1 standard](pci-standard.md). This control checks whether account password policies for IAM users meet minimum requirements, including a minimum password length of 7 characters. PCI DSS v4.0.1 now requires passwords to have a minimum of 8 characters. The control continues to apply to the PCI DSS v3.2.1 standard, which has different password requirements. To evaluate account password policies against PCI DSS v4.0.1 requirements, you can use the [IAM.7 control](iam-controls.md#iam-7). This control requires passwords to have a minimum of 8 characters. It also supports custom values for password length and other parameters. The IAM.7 control is part of the PCI DSS v4.0.1 standard in Security Hub CSPM.  | 
| May 8, 2025 | [RDS.46] RDS DB instances should not be deployed in public subnets with routes to internet gateways | Security Hub CSPM rolled back the release of the RDS.46 control in all AWS Regions. Previously, this control supported the AWS Foundational Security Best Practices (FSBP) standard. | 
| April 7, 2025 | [[ELB.17] Application and Network Load Balancers with listeners should use recommended security policies](elb-controls.md#elb-17) | This control checks whether the HTTPS listener for an Application Load Balancer or the TLS listener for a Network Load Balancer is configured to encrypt data in transit by using a recommended security policy. Security Hub CSPM now supports two additional parameter values for this control: `ELBSecurityPolicy-TLS13-1-2-Res-2021-06` and `ELBSecurityPolicy-TLS13-1-2-Res-FIPS-2023-04`. | 
| March 27, 2025 | [[Lambda.2] Lambda functions should use supported runtimes](lambda-controls.md#lambda-2) | This control checks whether the runtime settings for an AWS Lambda function match expected values for supported runtimes in each language. Security Hub CSPM now supports `ruby3.4` as a parameter value for this control. AWS Lambda added support for this runtime. | 
| March 26, 2025 | [[EKS.2] EKS clusters should run on a supported Kubernetes version](eks-controls.md#eks-2) | This control checks whether an Amazon Elastic Kubernetes Service (Amazon EKS) cluster runs on a supported Kubernetes version. For the `oldestVersionSupported` parameter, Security Hub CSPM changed the value from `1.29` to `1.30`. The oldest supported Kubernetes version is now `1.30`. | 
| March 10, 2025 | [[Lambda.2] Lambda functions should use supported runtimes](lambda-controls.md#lambda-2) | This control checks whether the runtime settings for an AWS Lambda function match expected values for supported runtimes in each language. Security Hub CSPM no longer supports `dotnet6` and `python3.8` as parameter values for this control. AWS Lambda no longer supports these runtimes. | 
| March 7, 2025 | [[RDS.18] RDS instances should be deployed in a VPC](rds-controls.md#rds-18) | Security Hub CSPM removed this control from the AWS Foundational Security Best Practices standard and automated checks for NIST SP 800-53 Rev. 5 requirements. Since Amazon EC2-Classic networking was retired, Amazon Relational Database Service (Amazon RDS) instances can no longer be deployed outside a VPC. The control continues to be part of the [AWS Control Tower service-managed standard](service-managed-standard-aws-control-tower.md). | 
| January 10, 2025 | [Glue.2] AWS Glue jobs should have logging enabled | Security Hub CSPM retired this control and removed it from all standards. | 
| December 20, 2024 | EC2.61 through EC2.169  | Security Hub CSPM rolled back the release of the EC2.61 through EC2.169 controls. | 
| December 12, 2024 | [[RDS.23] RDS instances should not use a database engine default port](rds-controls.md#rds-23)  | RDS.23 checks whether an Amazon Relational Database Service (Amazon RDS) cluster or instance uses a port other than the default port of the database engine. We updated the control so that the underlying AWS Config rule returns a result of NOT\$1APPLICABLE for RDS instances that are part of a cluster. | 
| December 2, 2024 | [[Lambda.2] Lambda functions should use supported runtimes](lambda-controls.md#lambda-2)  | Lambda.2 checks whether the AWS Lambda function settings for runtimes match the expected values set for the supported runtimes in each language. Security Hub CSPM now supports nodejs22.x as a parameter. | 
| November 26, 2024 | [[EKS.2] EKS clusters should run on a supported Kubernetes version](eks-controls.md#eks-2)  | This control checks whether an Amazon Elastic Kubernetes Service (Amazon EKS) cluster runs on a supported Kubernetes version. The oldest supported version is now 1.29. | 
| November 20, 2024 | [[Config.1] AWS Config should be enabled and use the service-linked role for resource recording](config-controls.md#config-1)  | Config.1 checks whether AWS Config is enabled, uses the service-linked role, and records resources for enabled controls. Security Hub CSPM increased the severity of this control from `MEDIUM` to `CRITICAL`. Security Hub CSPM also added [new status codes and status reasons](controls-findings-create-update.md#control-findings-asff-compliance) for failed Config.1 findings. These changes reflect the importance of Config.1 to the operation of Security Hub CSPM controls. If you have AWS Config or resource recording disabled, you can receive inaccurate control findings. To receive a `PASSED` finding for Config.1, turn on resource recording for resources that correspond to enabled Security Hub CSPM controls, and disable controls that aren't required in your organization. For instructions on configuring AWS Config for Security Hub CSPM, see [Enabling and configuring AWS Config for Security Hub CSPM](securityhub-setup-prereqs.md). For a list of Security Hub CSPM controls and their corresponding resources, see [Required AWS Config resources for control findings](controls-config-resources.md). | 
| November 12, 2024 | [[Lambda.2] Lambda functions should use supported runtimes](lambda-controls.md#lambda-2)  | Lambda.2 checks whether the AWS Lambda function settings for runtimes match the expected values set for the supported runtimes in each language. Security Hub CSPM now supports python3.13 as a parameter. | 
| October 11, 2024 | ElastiCache controls  | Changed control titles for ElastiCache.3, ElastiCache.4, ElastiCache.5, and ElastiCache.7. Titles no longer mention Redis OSS because the controls also apply to ElastiCache for Valkey. | 
| September 27, 2024 | [[ELB.4] Application Load Balancer should be configured to drop invalid http headers](elb-controls.md#elb-4)  | Changed control title from  Application Load Balancer should be configured to drop http headers to Application Load Balancer should be configured to drop invalid http headers. | 
| August 19, 2024 | Title changes to DMS.12 and ElastiCache controls  | Changed control titles for DMS.12 and ElastiCache.1 through ElastiCache.7. We changed these titles to reflect a name change in the Amazon ElastiCache (Redis OSS) service. | 
| August 15, 2024 | [[Config.1] AWS Config should be enabled and use the service-linked role for resource recording](config-controls.md#config-1)  | Config.1 checks whether AWS Config is enabled, uses the service-linked role, and records resources for enabled controls. Security Hub CSPM added a custom control parameter named includeConfigServiceLinkedRoleCheck. By setting this parameter to false, you can opt out of checking whether AWS Config uses the service-linked role. | 
| July 31, 2024 | [[IoT.1] AWS IoT Device Defender security profiles should be tagged](iot-controls.md#iot-1)  | Changed control title from AWS IoT Core security profiles should be tagged to AWS IoT Device Defender security profiles should be tagged. | 
| July 29, 2024 | [[Lambda.2] Lambda functions should use supported runtimes](lambda-controls.md#lambda-2)  | Lambda.2 checks whether the AWS Lambda function settings for runtimes match the expected values set for the supported runtimes in each language. Security Hub CSPM no longer supports nodejs16.x as a parameter. | 
| July 29, 2024 | [[EKS.2] EKS clusters should run on a supported Kubernetes version](eks-controls.md#eks-2)  | This control checks whether an Amazon Elastic Kubernetes Service (Amazon EKS) cluster runs on a supported Kubernetes version. The oldest supported version is 1.28. | 
| June 25, 2024 | [[Config.1] AWS Config should be enabled and use the service-linked role for resource recording](config-controls.md#config-1)  | This control checks whether AWS Config is enabled, uses the service-linked role, and records resources for enabled controls. Security Hub CSPM updated the control title to reflect what the control evaluates. | 
| June 14, 2024 | [[RDS.34] Aurora MySQL DB clusters should publish audit logs to CloudWatch Logs](rds-controls.md#rds-34)  | This control checks whether an Amazon Aurora MySQL DB cluster is configured to publish audit logs to Amazon CloudWatch Logs. Security Hub CSPM updated the control so that it doesn't generate findings for Aurora Serverless v1 DB clusters. | 
| June 11, 2024 | [[EKS.2] EKS clusters should run on a supported Kubernetes version](eks-controls.md#eks-2)  | This control checks whether an Amazon Elastic Kubernetes Service (Amazon EKS) cluster runs on a supported Kubernetes version. The oldest supported version is 1.27. | 
| June 10, 2024 | [[Config.1] AWS Config should be enabled and use the service-linked role for resource recording](config-controls.md#config-1)  | This control checks whether AWS Config is enabled and AWS Config resource recording is turned on. Previously, the control produced a PASSED finding only if you configured recording for all resources. Security Hub CSPM updated the control to produce a PASSED finding when recording is turned on for resources that are required for enabled controls. The control has also been updated to check whether the AWS Config service-linked role is used, which provides permissions to record necessary resources. | 
| May 8, 2024 | [[S3.20] S3 general purpose buckets should have MFA delete enabled](s3-controls.md#s3-20)  | This control checks whether an Amazon S3 general purpose versioned bucket has multi-factor authentication (MFA) delete enabled. Previously, the control produced a FAILED finding for buckets that have a Lifecycle configuration. However, MFA delete with versioning can't be enabled on a bucket that has a Lifecycle configuration. Security Hub CSPM updated the control to produce no findings for buckets that have a Lifecycle configuration. The control description has been updated to reflect the current behavior.  | 
| May 2, 2024 | [[EKS.2] EKS clusters should run on a supported Kubernetes version](eks-controls.md#eks-2)  | Security Hub CSPM updated the oldest supported version of Kubernetes that the Amazon EKS cluster can run on to produce a passed finding. The current oldest supported version is Kubernetes 1.26. | 
| April 30, 2024 | [[CloudTrail.3] At least one CloudTrail trail should be enabled](cloudtrail-controls.md#cloudtrail-3)  | Changed control title from CloudTrail should be enabled to At least one CloudTrail trail should be enabled. This control currently produces a PASSED finding if an AWS account has at least one CloudTrail trail enabled. The title and description have been changed to accurately reflect the current behavior. | 
| April 29, 2024 | [[AutoScaling.1] Auto Scaling groups associated with a load balancer should use ELB health checks](autoscaling-controls.md#autoscaling-1)  | Changed control title from Auto Scaling groups associated with a Classic Load Balancer should use load balancer health checks to Auto Scaling groups associated with a load balancer should use ELB health checks. This control currently evaluates Application, Gateway, Network, and Classic Load Balancers. The title and description have been changed to accurately reflect the current behavior. | 
| April 19, 2024 | [[CloudTrail.1] CloudTrail should be enabled and configured with at least one multi-Region trail that includes read and write management events](cloudtrail-controls.md#cloudtrail-1)  | The control checks whether AWS CloudTrail is enabled and configured with at least one multi-Region trail that includes read and write management events. Previously, the control incorrectly generated PASSED findings when an account had CloudTrail enabled and configured with at least one multi-Region trail, even if no trail captured read and write management events. The control now generates a PASSED finding only when CloudTrail is enabled and configured with at least one multi-Region trail that captures read and write management events. | 
| April 10, 2024 | [Athena.1] Athena workgroups should be encrypted at rest  | Security Hub CSPM retired this control and removed it from all standards. Athena workgroups send logs to Amazon Simple Storage Service (Amazon S3) buckets. Amazon S3 now provides default encryption with S3 managed keys (SS3-S3) on new and existing S3 buckets. | 
| April 10, 2024 | [AutoScaling.4] Auto Scaling group launch configuration should not have a metadata response hop limit greater than 1  | Security Hub CSPM retired this control and removed it from all standards. Metadata response hop limits for Amazon Elastic Compute Cloud (Amazon EC2) instances are workload dependent. | 
| April 10, 2024 | [CloudFormation.1] CloudFormation stacks should be integrated with Simple Notification Service (SNS)  | Security Hub CSPM retired this control and removed it from all standards. Integrating AWS CloudFormation stacks with Amazon SNS topics is no longer a security best practice. Though integrating important CloudFormation stacks with SNS topics can be useful, it is not required for all stacks. | 
| April 10, 2024 | [CodeBuild.5] CodeBuild project environments should not have privileged mode enabled  | Security Hub CSPM retired this control and removed it from all standards. Enabling privileged mode in a CodeBuild project does not impose an additional risk to the customer environment. | 
| April 10, 2024 | [IAM.20] Avoid the use of the root user  | Security Hub CSPM retired this control and removed it from all standards. The purpose of this control is covered by another control, [[CloudWatch.1] A log metric filter and alarm should exist for usage of the "root" user](cloudwatch-controls.md#cloudwatch-1). | 
| April 10, 2024 | [SNS.2] Logging of delivery status should be enabled for notification messages sent to a topic  | Security Hub CSPM retired this control and removed it from all standards. Logging delivery status for SNS topics is no longer a security best practice. Though logging delivery status for important SNS topics can be useful, it is not required for all topics. | 
| April 10, 2024 | [[S3.10] S3 general purpose buckets with versioning enabled should have Lifecycle configurations](s3-controls.md#s3-10)  | Security Hub CSPM removed this control from AWS Foundational Security Best Practices and Service-Managed Standard: AWS Control Tower. The purpose of this control is covered by two other controls: [[S3.13] S3 general purpose buckets should have Lifecycle configurations](s3-controls.md#s3-13) and [[S3.14] S3 general purpose buckets should have versioning enabled](s3-controls.md#s3-14). This control is still part of NIST SP 800-53 Rev. 5. | 
| April 10, 2024 | [[S3.11] S3 general purpose buckets should have event notifications enabled](s3-controls.md#s3-11)  | Security Hub CSPM removed this control from AWS Foundational Security Best Practices and Service-Managed Standard: AWS Control Tower. Though there are some cases where event notifications for S3 buckets are useful, this not a universal security best practice. This control is still part of NIST SP 800-53 Rev. 5. | 
| April 10, 2024 | [[SNS.1] SNS topics should be encrypted at-rest using AWS KMS](sns-controls.md#sns-1)  | Security Hub CSPM removed this control from AWS Foundational Security Best Practices and Service-Managed Standard: AWS Control Tower. By default, SNS encrypts topics at rest with disk encryption. For more information, see [Data encryption](https://docs.aws.amazon.com/sns/latest/dg/sns-data-encryption.html). Using AWS KMS to encrypt topics is no longer recommended as a security best practice. This control is still part of NIST SP 800-53 Rev. 5. | 
| April 8, 2024 | [[ELB.6] Application, Gateway, and Network Load Balancers should have deletion protection enabled](elb-controls.md#elb-6)  | Changed control title from Application Load Balancer deletion protection should be enabled to Application, Gateway, and Network Load Balancers should have deletion protection enabled. This control currently evaluates Application, Gateway, and Network Load Balancers. The title and description have been changed to accurately reflect the current behavior. | 
| March 22, 2024 | [[Opensearch.8] Connections to OpenSearch domains should be encrypted using the latest TLS security policy](opensearch-controls.md#opensearch-8)  | Changed control title from Connections to OpenSearch domains should be encrypted using TLS 1.2 to Connections to OpenSearch domains should be encrypted using the latest TLS security policy. Previously, the control only checked whether connections to OpenSearch domains used TLS 1.2. The control now produces a PASSED finding if OpenSearch domains are encrypted using the latest TLS security policy. The control title and description have been updated to reflect the current behavior.  | 
| March 22, 2024 | [[ES.8] Connections to Elasticsearch domains should be encrypted using the latest TLS security policy](es-controls.md#es-8)  | Changed control title from Connections to Elasticsearch domains should be encrypted using TLS 1.2 to Connections to Elasticsearch domains should be encrypted using the latest TLS security policy. Previously, the control only checked whether connections to Elasticsearch domains used TLS 1.2. The control now produces a PASSED finding if Elasticsearch domains are encrypted using the latest TLS security policy. The control title and description have been updated to reflect the current behavior.  | 
| March 12, 2024 | [[S3.1] S3 general purpose buckets should have block public access settings enabled](s3-controls.md#s3-1)  | Changed title from S3 Block Public Access setting should be enabled to S3 general purpose buckets should have block public access settings enabled. Security Hub CSPM changed the title to account for a new S3 bucket type. | 
| March 12, 2024 | [[S3.2] S3 general purpose buckets should block public read access](s3-controls.md#s3-2)  | Changed title from S3 buckets should prohibit public read access to S3 general purpose buckets should block public read access. Security Hub CSPM changed the title to account for a new S3 bucket type. | 
| March 12, 2024 | [[S3.3] S3 general purpose buckets should block public write access](s3-controls.md#s3-3)  | Changed title from S3 buckets should prohibit public write access to S3 general purpose buckets should block public write access. Security Hub CSPM changed the title to account for a new S3 bucket type. | 
| March 12, 2024 | [[S3.5] S3 general purpose buckets should require requests to use SSL](s3-controls.md#s3-5)  | Changed title from S3 buckets should require requests to use Secure Socket Layer to S3 general purpose buckets should require requests to use SSL. Security Hub CSPM changed the title to account for a new S3 bucket type. | 
| March 12, 2024 | [[S3.6] S3 general purpose bucket policies should restrict access to other AWS accounts](s3-controls.md#s3-6)  | Changed title from S3 permissions granted to other AWS accounts in bucket policies should be restricted to S3 general purpose bucket policies should restrict access to other AWS accounts. Security Hub CSPM changed the title to account for a new S3 bucket type. | 
| March 12, 2024 | [[S3.7] S3 general purpose buckets should use cross-Region replication](s3-controls.md#s3-7)  | Changed title from S3 buckets should have cross-Region replication enabled to S3 general purpose buckets should use cross-Region replication. Security Hub CSPM changed the title to account for a new S3 bucket type. | 
| March 12, 2024 | [[S3.7] S3 general purpose buckets should use cross-Region replication](s3-controls.md#s3-7)  | Changed title from S3 buckets should have cross-Region replication enabled to S3 general purpose buckets should use cross-Region replication. Security Hub CSPM changed the title to account for a new S3 bucket type. | 
| March 12, 2024 | [[S3.8] S3 general purpose buckets should block public access](s3-controls.md#s3-8)  | Changed title from S3 Block Public Access setting should be enabled at the bucket-level to S3 general purpose buckets should block public access. Security Hub CSPM changed the title to account for a new S3 bucket type. | 
| March 12, 2024 | [[S3.9] S3 general purpose buckets should have server access logging enabled](s3-controls.md#s3-9)  | Changed title from S3 bucket server access logging should be enabled to Server access logging should be enabled for S3 general purpose buckets. Security Hub CSPM changed the title to account for a new S3 bucket type. | 
| March 12, 2024 | [[S3.10] S3 general purpose buckets with versioning enabled should have Lifecycle configurations](s3-controls.md#s3-10)  | Changed title from S3 buckets with versioning enabled should have lifecycle policies configured to S3 general purpose buckets with versioning enabled should have Lifecycle configurations. Security Hub CSPM changed the title to account for a new S3 bucket type. | 
| March 12, 2024 | [[S3.11] S3 general purpose buckets should have event notifications enabled](s3-controls.md#s3-11)  | Changed title from S3 buckets should have event notifications enabled to S3 general purpose buckets should have event notifications enabled. Security Hub CSPM changed the title to account for a new S3 bucket type. | 
| March 12, 2024 | [[S3.12] ACLs should not be used to manage user access to S3 general purpose buckets](s3-controls.md#s3-12)  | Changed title from S3 access control lists (ACLs) should not be used to manage user access to buckets to ACLs should not be used to manage user access to S3 general purpose buckets. Security Hub CSPM changed the title to account for a new S3 bucket type. | 
| March 12, 2024 | [[S3.13] S3 general purpose buckets should have Lifecycle configurations](s3-controls.md#s3-13)  | Changed title from S3 buckets should have lifecycle policies configured to S3 general purpose buckets should have Lifecycle configurations. Security Hub CSPM changed the title to account for a new S3 bucket type. | 
| March 12, 2024 | [[S3.14] S3 general purpose buckets should have versioning enabled](s3-controls.md#s3-14)  | Changed title from S3 buckets should use versioning to S3 general purpose buckets should have versioning enabled. Security Hub CSPM changed the title to account for a new S3 bucket type. | 
| March 12, 2024 | [[S3.15] S3 general purpose buckets should have Object Lock enabled](s3-controls.md#s3-15)  | Changed title from S3 buckets should be configured to use Object Lock to S3 general purpose buckets should have Object Lock enabled. Security Hub CSPM changed the title to account for a new S3 bucket type. | 
| March 12, 2024 | [[S3.17] S3 general purpose buckets should be encrypted at rest with AWS KMS keys](s3-controls.md#s3-17)  | Changed title from S3 buckets should be encrypted at rest with AWS KMS keys to S3 general purpose buckets should be encrypted at rest with AWS KMS keys. Security Hub CSPM changed the title to account for a new S3 bucket type. | 
| March 7, 2024 | [[Lambda.2] Lambda functions should use supported runtimes](lambda-controls.md#lambda-2)  | Lambda.2 checks whether the AWS Lambda function settings for runtimes match the expected values set for the supported runtimes in each language. Security Hub CSPM now supports nodejs20.x and ruby3.3 as parameters. | 
| February 22, 2024 | [[Lambda.2] Lambda functions should use supported runtimes](lambda-controls.md#lambda-2)  | Lambda.2 checks whether the AWS Lambda function settings for runtimes match the expected values set for the supported runtimes in each language. Security Hub CSPM now supports dotnet8 as a parameter. | 
| February 5, 2024 | [[EKS.2] EKS clusters should run on a supported Kubernetes version](eks-controls.md#eks-2)  | Security Hub CSPM updated the oldest supported version of Kubernetes that the Amazon EKS cluster can run on to produce a passed finding. The current oldest supported version is Kubernetes 1.25.  | 
| January 10, 2024 | [[CodeBuild.1] CodeBuild Bitbucket source repository URLs should not contain sensitive credentials](codebuild-controls.md#codebuild-1)  | Changed title from CodeBuild GitHub or Bitbucket source repository URLs should use OAuth to CodeBuild Bitbucket source repository URLs should not contain sensitive credentials. Security Hub CSPM removed mention of OAuth because other connection methods can also be secure. Security Hub CSPM removed mention of GitHub because it's no longer possible to have a personal access token or username and password in GitHub source repository URLs. | 
| January 8, 2024 | [[Lambda.2] Lambda functions should use supported runtimes](lambda-controls.md#lambda-2)  | Lambda.2 checks whether the AWS Lambda function settings for runtimes match the expected values set for the supported runtimes in each language. Security Hub CSPM no longer supports go1.x and java8 as parameters because these are retired runtimes. | 
| December 29, 2023 | [[RDS.8] RDS DB instances should have deletion protection enabled](rds-controls.md#rds-8)  | RDS.8 checks whether an Amazon RDS DB instance that uses one of the supported database engines has deletion protection enabled. Security Hub CSPM now supports custom-oracle-ee, oracle-ee-cdb, and oracle-se2-cdb as database engines. | 
| December 22, 2023 | [[Lambda.2] Lambda functions should use supported runtimes](lambda-controls.md#lambda-2)  | Lambda.2 checks whether the AWS Lambda function settings for runtimes match the expected values set for the supported runtimes in each language. Security Hub CSPM now supports java21 and python3.12 as parameters. Security Hub CSPM no longer supports ruby2.7 as a parameter. | 
| December 15, 2023 | [[CloudFront.1] CloudFront distributions should have a default root object configured](cloudfront-controls.md#cloudfront-1)  | CloudFront.1 checks whether an Amazon CloudFront distribution has a default root object configured. Security Hub CSPM lowered the severity of this control from CRITICAL to HIGH because adding the default root object is a recommendation that depends on a user's application and specific requirements. | 
| December 5, 2023  | [[EC2.13] Security groups should not allow ingress from 0.0.0.0/0 or ::/0 to port 22](ec2-controls.md#ec2-13)  | Changed control title from Security groups should not allow ingress from 0.0.0.0/0 to port 22 to  Security groups should not allow ingress from 0.0.0.0/0 or ::/0 to port 22.  | 
| December 5, 2023  | [[EC2.14] Security groups should not allow ingress from 0.0.0.0/0 or ::/0 to port 3389](ec2-controls.md#ec2-14)  | Changed control title from Ensure no security groups allow ingress from 0.0.0.0/0 to port 3389 to  Security groups should not allow ingress from 0.0.0.0/0 or ::/0 to port 3389.  | 
| December 5, 2023  | [[RDS.9] RDS DB instances should publish logs to CloudWatch Logs](rds-controls.md#rds-9)  | Changed control title from Database logging should be enabled to  RDS DB instances should publish logs to CloudWatch Logs. Security Hub CSPM identified that this control only checks whether logs are published to Amazon CloudWatch Logs and doesn't check whether RDS logs are enabled. The control produces a PASSED finding if RDS DB instances are configured to publish logs to CloudWatch Logs. The control title has been updated to reflect the current behavior.  | 
| December 5, 2023 | [[EKS.8] EKS clusters should have audit logging enabled](eks-controls.md#eks-8)  | This control checks whether Amazon EKS clusters have audit logging enabled. The AWS Config rule that Security Hub CSPM uses to evaluate this control changed from eks-cluster-logging-enabled to eks-cluster-log-enabled. | 
| November 17, 2023  | [[EC2.19] Security groups should not allow unrestricted access to ports with high risk](ec2-controls.md#ec2-19)  | EC2.19 checks whether unrestricted incoming traffic for a security group is accessible to the specified ports that are considered to be high risk. Security Hub CSPM updated this control to account for managed prefix lists when they are supplied as the source for a security group rule. The control produces a FAILED finding if the prefix lists contain the strings '0.0.0.0/0' or '::/0'.  | 
| November 16, 2023  | [[CloudWatch.15] CloudWatch alarms should have specified actions configured](cloudwatch-controls.md#cloudwatch-15)  | Changed control title from CloudWatch alarms should have an action configured for the ALARM state to  CloudWatch alarms should have specified actions configured.  | 
| November 16, 2023  | [[CloudWatch.16] CloudWatch log groups should be retained for a specified time period](cloudwatch-controls.md#cloudwatch-16)  | Changed control title from CloudWatch log groups should be retained for at least 1 year to  CloudWatch log groups should be retained for a specified time period.  | 
| November 16, 2023  | [[Lambda.5] VPC Lambda functions should operate in multiple Availability Zones](lambda-controls.md#lambda-5)  | Changed control title from VPC Lambda functions should operate in more than one Availability Zone to  VPC Lambda functions should operate in multiple Availability Zones.  | 
| November 16, 2023  | [[AppSync.2] AWS AppSync should have field-level logging enabled](appsync-controls.md#appsync-2)  | Changed control title from AWS AppSync should have request-level and field-level logging turned on to AWS AppSync should have field-level logging enabled.  | 
| November 16, 2023  | [[EMR.1] Amazon EMR cluster primary nodes should not have public IP addresses](emr-controls.md#emr-1)  | Changed control title from Amazon Elastic MapReduce cluster master nodes should not have public IP addresses to Amazon EMR cluster primary nodes should not have public IP addresses.  | 
| November 16, 2023  | [[Opensearch.2] OpenSearch domains should not be publicly accessible](opensearch-controls.md#opensearch-2)  | Changed control title from OpenSearch domains should be in a VPC to OpenSearch domains should not be publicly accessible.  | 
| November 16, 2023  | [[ES.2] Elasticsearch domains should not be publicly accessible](es-controls.md#es-2)  | Changed control title from Elasticsearch domains should be in a VPC to Elasticsearch domains should not be publicly accessible.  | 
| October 31, 2023  | [[ES.4] Elasticsearch domain error logging to CloudWatch Logs should be enabled](es-controls.md#es-4)  | ES.4 checks whether Elasticsearch domains are configured to send error logs to Amazon CloudWatch Logs. The control previously produced a PASSED finding for an Elasticsearch domain that has any logs configured to send to CloudWatch Logs. Security Hub CSPM updated the control to produce a PASSED finding only for an Elasticsearch domain that is configured to send error logs to CloudWatch Logs. The control was also updated to exclude Elasticsearch versions that don’t support error logs from evaluation.  | 
| October 16, 2023  | [[EC2.13] Security groups should not allow ingress from 0.0.0.0/0 or ::/0 to port 22](ec2-controls.md#ec2-13)  | EC2.13 checks whether security groups allow unrestricted ingress access to port 22. Security Hub CSPM updated this control to account for managed prefix lists when they are supplied as the source for a security group rule. The control produces a FAILED finding if the prefix lists contain the strings '0.0.0.0/0' or '::/0'.  | 
| October 16, 2023  | [[EC2.14] Security groups should not allow ingress from 0.0.0.0/0 or ::/0 to port 3389](ec2-controls.md#ec2-14)  | EC2.14 checks whether security groups allow unrestricted ingress access to port 3389. Security Hub CSPM updated this control to account for managed prefix lists when they are supplied as the source for a security group rule. The control produces a FAILED finding if the prefix lists contain the strings '0.0.0.0/0' or '::/0'.  | 
| October 16, 2023  | [[EC2.18] Security groups should only allow unrestricted incoming traffic for authorized ports](ec2-controls.md#ec2-18)  | EC2.18 checks whether the security groups that are in use allow unrestricted incoming traffic. Security Hub CSPM updated this control to account for managed prefix lists when they are supplied as the source for a security group rule. The control produces a FAILED finding if the prefix lists contain the strings '0.0.0.0/0' or '::/0'.  | 
| October 16, 2023  | [[Lambda.2] Lambda functions should use supported runtimes](lambda-controls.md#lambda-2)  | Lambda.2 checks whether the AWS Lambda function settings for runtimes match the expected values set for the supported runtimes in each language. Security Hub CSPM now supports python3.11 as a parameter.  | 
| October 4, 2023  | [[S3.7] S3 general purpose buckets should use cross-Region replication](s3-controls.md#s3-7)  | Security Hub CSPM added the parameter ReplicationType with a value of CROSS-REGION to ensure that S3 buckets have cross-Region replication enabled rather than same-Region replication.  | 
| September 27, 2023  | [[EKS.2] EKS clusters should run on a supported Kubernetes version](eks-controls.md#eks-2)  | Security Hub CSPM updated the oldest supported version of Kubernetes that the Amazon EKS cluster can run on to produce a passed finding. The current oldest supported version is Kubernetes 1.24.  | 
| September 20, 2023  | [CloudFront.2] CloudFront distributions should have origin access identity enabled  | Security Hub CSPM retired this control and removed it from all standards. Instead, see [[CloudFront.13] CloudFront distributions should use origin access control](cloudfront-controls.md#cloudfront-13). Origin access control is the current security best practice. This control will be removed from documentation in 90 days. | 
| September 20, 2023  | [[EC2.22] Unused Amazon EC2 security groups should be removed](ec2-controls.md#ec2-22)  | Security Hub CSPM removed this control from AWS Foundational Security Best Practices (FSBP) and National Institute of Standards and Technology (NIST) SP 800-53 Rev. 5. It is still part of Service-Managed Standard: AWS Control Tower. This control produces a passed finding if security groups are attached to EC2 instances or to an elastic network interface. However, for certain use cases, unattached security groups don't pose a security risk. You can use other EC2 controls—such as EC2.2, EC2.13, EC2.14, EC2.18, and EC2.19—to monitor your security groups.  | 
| September 20, 2023  | [EC2.29] EC2 instances should be launched in a VPC  | Security Hub CSPM retired this control and removed it from all standards. Amazon EC2 has migrated EC2-Classic instances to a VPC. This control will be removed from documentation in 90 days. | 
| September 20, 2023  | [S3.4] S3 buckets should have server-side encryption enabled  | Security Hub CSPM retired this control and removed it from all standards. Amazon S3 now provides default encryption with S3 managed keys (SS3-S3) on new and existing S3 buckets. The encryption settings are unchanged for existing buckets that are encrypted with SS3-S3 or SS3-KMS server-side encryption. This control will be removed from documentation in 90 days.  | 
| September 14, 2023  | [[EC2.2] VPC default security groups should not allow inbound or outbound traffic](ec2-controls.md#ec2-2)  | Changed control title from The VPC default security group should not allow inbound and outbound traffic to VPC default security groups should not allow inbound or outbound traffic.  | 
| September 14, 2023  | [[IAM.9] MFA should be enabled for the root user](iam-controls.md#iam-9)  | Changed control title from Virtual MFA should be enabled for the root user to MFA should be enabled for the root user.  | 
|  September 14, 2023  | [[RDS.19] Existing RDS event notification subscriptions should be configured for critical cluster events](rds-controls.md#rds-19)  | Changed control title from An RDS event notifications subscription should be configured for critical cluster events to Existing RDS event notification subscriptions should be configured for critical cluster events.  | 
| September 14, 2023  | [[RDS.20] Existing RDS event notification subscriptions should be configured for critical database instance events](rds-controls.md#rds-20)  | Changed control title from An RDS event notifications subscription should be configured for critical database instance events to Existing RDS event notification subscriptions should be configured for critical database instance events.  | 
| September 14, 2023  | [[WAF.2] AWS WAF Classic Regional rules should have at least one condition](waf-controls.md#waf-2)  | Changed control title from A WAF Regional rule should have at least one condition to AWS WAF Classic Regional rules should have at least one condition.  | 
| September 14, 2023  | [[WAF.3] AWS WAF Classic Regional rule groups should have at least one rule](waf-controls.md#waf-3)  | Changed control title from A WAF Regional rule group should have at least one rule to AWS WAF Classic Regional rule groups should have at least one rule.  | 
| September 14, 2023  | [[WAF.4] AWS WAF Classic Regional web ACLs should have at least one rule or rule group](waf-controls.md#waf-4)  | Changed control title from A WAF Regional web ACL should have at least one rule or rule group to AWS WAF Classic Regional web ACLs should have at least one rule or rule group.  | 
| September 14, 2023  | [[WAF.6] AWS WAF Classic global rules should have at least one condition](waf-controls.md#waf-6)  | Changed control title from A WAF global rule should have at least one condition to AWS WAF Classic global rules should have at least one condition.  | 
| September 14, 2023  | [[WAF.7] AWS WAF Classic global rule groups should have at least one rule](waf-controls.md#waf-7)  | Changed control title from A WAF global rule group should have at least one rule to AWS WAF Classic global rule groups should have at least one rule.  | 
| September 14, 2023  | [[WAF.8] AWS WAF Classic global web ACLs should have at least one rule or rule group](waf-controls.md#waf-8)  | Changed control title from A WAF global web ACL should have at least one rule or rule group to AWS WAF Classic global web ACLs should have at least one rule or rule group.  | 
| September 14, 2023  | [[WAF.10] AWS WAF web ACLs should have at least one rule or rule group](waf-controls.md#waf-10)  | Changed control title from A WAFv2 web ACL should have at least one rule or rule group to AWS WAF web ACLs should have at least one rule or rule group.  | 
| September 14, 2023  | [[WAF.11] AWS WAF web ACL logging should be enabled](waf-controls.md#waf-11)  | Changed control title from AWS WAFv2 web ACL logging should be activated to AWS WAF web ACL logging should be enabled.  | 
|  July 20, 2023  | [S3.4] S3 buckets should have server-side encryption enabled  | S3.4 checks whether an Amazon S3 bucket either has server-side encryption enabled or that the S3 bucket policy explicitly denies PutObject requests without server-side encryption. Security Hub CSPM updated this control to include dual-layer server side encryption with KMS keys (DSSE-KMS). The control produces a passed finding when an S3 bucket is encrypted with SSE-S3, SSE-KMS, or DSSE-KMS.  | 
| July 17, 2023  | [[S3.17] S3 general purpose buckets should be encrypted at rest with AWS KMS keys](s3-controls.md#s3-17)  | S3.17 checks whether an Amazon S3 bucket is encrypted with an AWS KMS key. Security Hub CSPM updated this control to include dual-layer server side encryption with KMS keys (DSSE-KMS). The control produces a passed finding when an S3 bucket is encrypted with SSE-KMS or DSSE-KMS.  | 
| June 9, 2023  | [[EKS.2] EKS clusters should run on a supported Kubernetes version](eks-controls.md#eks-2)  | EKS.2 checks whether an Amazon EKS cluster is running on a supported Kubernetes version.The oldest supported version is now 1.23.  | 
| June 9, 2023  | [[Lambda.2] Lambda functions should use supported runtimes](lambda-controls.md#lambda-2)  | Lambda.2 checks whether the AWS Lambda function settings for runtimes match the expected values set for the supported runtimes in each language. Security Hub CSPM now supports ruby3.2 as a parameter.  | 
| June 5, 2023  | [[APIGateway.5] API Gateway REST API cache data should be encrypted at rest](apigateway-controls.md#apigateway-5)  | APIGateway.5.checks whether all methods in Amazon API Gateway REST API stages are encrypted at rest. Security Hub CSPM updated the control to evaluate the encryption of a particular method only when caching is enabled for that method.  | 
| May 18, 2023  | [[Lambda.2] Lambda functions should use supported runtimes](lambda-controls.md#lambda-2)  | Lambda.2 checks whether the AWS Lambda function settings for runtimes match the expected values set for the supported runtimes in each language. Security Hub CSPM now supports java17 as a parameter.  | 
| May 18, 2023  | [[Lambda.2] Lambda functions should use supported runtimes](lambda-controls.md#lambda-2)  | Lambda.2 checks whether the AWS Lambda function settings for runtimes match the expected values set for the supported runtimes in each language. Security Hub CSPM no longer supports nodejs12.x as a parameter.  | 
| April 23, 2023  | [[ECS.10] ECS Fargate services should run on the latest Fargate platform version](ecs-controls.md#ecs-10)  | ECS.10 checks whether Amazon ECS Fargate services are running the latest Fargate platform version. Customers can deploy Amazon ECS through ECS directly, or by using CodeDeploy. Security Hub CSPM updated this control to produce Passed findings when you use CodeDeploy to deploy ECS Fargate services.  | 
| April 20, 2023  | [[S3.6] S3 general purpose bucket policies should restrict access to other AWS accounts](s3-controls.md#s3-6)  | S3.6 checks whether an Amazon Simple Storage Service (Amazon S3) bucket policy prevents principals from other AWS accounts from performing denied actions on resources in the S3 bucket. Security Hub CSPM updated the control to account for conditionals in a bucket policy.  | 
| April 18, 2023  | [[Lambda.2] Lambda functions should use supported runtimes](lambda-controls.md#lambda-2)  | Lambda.2 checks whether the AWS Lambda function settings for runtimes match the expected values set for the supported runtimes in each language. Security Hub CSPM now supports python3.10 as a parameter. | 
| April 18, 2023  | [[Lambda.2] Lambda functions should use supported runtimes](lambda-controls.md#lambda-2)  | Lambda.2 checks whether the AWS Lambda function settings for runtimes match the expected values set for the supported runtimes in each language. Security Hub CSPM no longer supports dotnetcore3.1 as a parameter. | 
| April 17, 2023  | [[RDS.11] RDS instances should have automatic backups enabled](rds-controls.md#rds-11)  | RDS.11 checks whether Amazon RDS instances have automated backups enabled, with a backup retention period that's greater than or equal to seven days. Security Hub CSPM updated this control to exclude read replicas from evaluation, as not all engines support automated backups on read replicas. Additionally, RDS doesn’t provide the option to specify a backup retention period when creating read replicas. Read replicas are created with a backup retention period of 0 by default.  | 

# Security Hub CSPM controls for AWS accounts
<a name="account-controls"></a>

These Security Hub CSPM controls evaluate AWS accounts.

These controls may not be available in all AWS Regions. For more information, see [Availability of controls by Region](securityhub-regions.md#securityhub-regions-control-support).

## [Account.1] Security contact information should be provided for an AWS account
<a name="account-1"></a>

**Related requirements:** CIS AWS Foundations Benchmark v5.0.0/1.2, NIST.800-53.r5 CM-2, NIST.800-53.r5 CM-2(2)

**Category:** Identify > Resource Configuration

**Severity:** Medium

**Resource type:** `AWS::::Account`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/security-account-information-provided.html](https://docs.aws.amazon.com/config/latest/developerguide/security-account-information-provided.html)

**Schedule type:** Periodic

**Parameters:** None

This control checks if an Amazon Web Services (AWS) account has security contact information. The control fails if security contact information is not provided for the account.

Alternate security contacts allow AWS to contact another person about issues with your account in case you're unavailable. Notifications can be from Support, or other AWS service teams about security-related topics associated with your AWS account usage.

### Remediation
<a name="account-1-remediation"></a>

To add an alternate contact as a security contact to your AWS account, see [Update the alternate contacts for your AWS account](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-update-contact-alternate.html) in the *AWS Account Management Reference Guide*.

## [Account.2] AWS accounts should be part of an AWS Organizations organization
<a name="account-2"></a>

**Category:** Protect > Secure access management > Access control

**Related requirements:** NIST.800-53.r5 CA-9(1), NIST.800-53.r5 CM-2

**Severity:** High

**Resource type:** `AWS::::Account`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/account-part-of-organizations.html](https://docs.aws.amazon.com/config/latest/developerguide/account-part-of-organizations.html)

**Schedule type:** Periodic

**Parameters:** None

This control checks if an AWS account is part of an organization managed through AWS Organizations. The control fails if the account is not part of an organization.

Organizations helps you centrally manage your environment as you scale your workloads on AWS. You can use multiple AWS accounts to isolate workloads that have specific security requirements, or to comply with frameworks such as HIPAA or PCI. By creating an organization, you can administer multiple accounts as a single unit and centrally manage their access to AWS services, resources, and Regions.

### Remediation
<a name="account-2-remediation"></a>

To create a new organization and automatically add AWS accounts to it, see [Creating an organization](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_org_create.html) in the *AWS Organizations User Guide*. To add accounts to an existing organization, see [Inviting an AWS account to join your organization](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts_invites.html) in the *AWS Organizations User Guide*.

# Security Hub CSPM controls for AWS Amplify
<a name="amplify-controls"></a>

These Security Hub CSPM controls evaluate the AWS Amplify service and resources. The controls might not be available in all AWS Regions. For more information, see [Availability of controls by Region](securityhub-regions.md#securityhub-regions-control-support).

## [Amplify.1] Amplify apps should be tagged
<a name="amplify-1"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::Amplify::App`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/amplify-app-tagged.html](https://docs.aws.amazon.com/config/latest/developerguide/amplify-app-tagged.html)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
| requiredKeyTags | A list of non-system tag keys that must be assigned to an evaluated resource. Tag keys are case sensitive. | StringList (maximum of 6 items) | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions). | No default value | 

This control checks whether an AWS Amplify app has the tag keys specified by the `requiredKeyTags` parameter. The control fails if the app doesn't have any tag keys, or it doesn't have all the keys specified by the `requiredKeyTags` parameter. If you don't specify any values for the `requiredKeyTags` parameter, the control checks only for the existence of a tag key and fails if the app doesn't have any tag keys. The control ignores system tags, which are applied automatically and have the `aws:` prefix.

A tag is a label that you create and assign to an AWS resource. Each tag consists of a required tag key and an optional tag value. You can use tags to categorize resources by purpose, owner, environment, or other criteria. They can help you identify, organize, search for, and filter resources. They can also help you track resource owners for actions and notifications. You can also use tags to implement attribute-based access control (ABAC) as an authorization strategy. For more information about ABAC strategies, see [Define permissions based on attributes with ABAC authorization](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*. For more information about tags, see the [Tagging AWS Resources and Tag Editor User Guide](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html).

**Note**  
Do not store personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible from many AWS services. They aren't intended to be used for private or sensitive data.

### Remediation
<a name="amplify-1-remediation"></a>

For information about adding tags to an AWS Amplify app, see [Resource tagging support](https://docs.aws.amazon.com/amplify/latest/userguide/resource-tagging-support-chapter.html) in the *AWS Amplify Hosting User Guide*.

## [Amplify.2] Amplify branches should be tagged
<a name="amplify-2"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::Amplify::Branch`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/amplify-branch-tagged.html](https://docs.aws.amazon.com/config/latest/developerguide/amplify-branch-tagged.html)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
| requiredKeyTags | A list of non-system tag keys that must be assigned to an evaluated resource. Tag keys are case sensitive. | StringList (maximum of 6 items) | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions). | No default value | 

This control checks whether an AWS Amplify branch has the tag keys specified by the `requiredKeyTags` parameter. The control fails if the branch doesn't have any tag keys, or it doesn't have all the keys specified by the `requiredKeyTags` parameter. If you don't specify any values for the `requiredKeyTags` parameter, the control checks only for the existence of a tag key and fails if the branch doesn't have any tag keys. The control ignores system tags, which are applied automatically and have the `aws:` prefix.

A tag is a label that you create and assign to an AWS resource. Each tag consists of a required tag key and an optional tag value. You can use tags to categorize resources by purpose, owner, environment, or other criteria. They can help you identify, organize, search for, and filter resources. They can also help you track resource owners for actions and notifications. You can also use tags to implement attribute-based access control (ABAC) as an authorization strategy. For more information about ABAC strategies, see [Define permissions based on attributes with ABAC authorization](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*. For more information about tags, see the [Tagging AWS Resources and Tag Editor User Guide](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html).

**Note**  
Do not store personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible from many AWS services. They aren't intended to be used for private or sensitive data.

### Remediation
<a name="amplify-2-remediation"></a>

For information about adding tags to an AWS Amplify branch, see [Resource tagging support](https://docs.aws.amazon.com/amplify/latest/userguide/resource-tagging-support-chapter.html) in the *AWS Amplify Hosting User Guide*.

# Security Hub CSPM controls for Amazon API Gateway
<a name="apigateway-controls"></a>

These AWS Security Hub CSPM controls evaluate the Amazon API Gateway service and resources. The controls might not be available in all AWS Regions. For more information, see [Availability of controls by Region](securityhub-regions.md#securityhub-regions-control-support).

## [APIGateway.1] API Gateway REST and WebSocket API execution logging should be enabled
<a name="apigateway-1"></a>

**Related requirements:** NIST.800-53.r5 AC-4(26), NIST.800-53.r5 AU-10, NIST.800-53.r5 AU-12, NIST.800-53.r5 AU-2, NIST.800-53.r5 AU-3, NIST.800-53.r5 AU-6(3), NIST.800-53.r5 AU-6(4), NIST.800-53.r5 CA-7, NIST.800-53.r5 SC-7(9), NIST.800-53.r5 SI-7(8)

**Category:** Identify > Logging

**Severity:** Medium

**Resource type:** `AWS::ApiGateway::Stage`, `AWS::ApiGatewayV2::Stage`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/api-gw-execution-logging-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/api-gw-execution-logging-enabled.html)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  `loggingLevel`  |  Logging level  |  Enum  |  `ERROR`, `INFO`  |  `No default value`  | 

This control checks whether all stages of an Amazon API Gateway REST or WebSocket API have logging enabled. The control fails if the `loggingLevel` isn't `ERROR` or `INFO` for all stages of the API. Unless you provide custom parameter values to indicate that a specific log type should be enabled, Security Hub CSPM produces a passed finding if the logging level is either `ERROR` or `INFO`.

API Gateway REST or WebSocket API stages should have relevant logs enabled. API Gateway REST and WebSocket API execution logging provides detailed records of requests made to API Gateway REST and WebSocket API stages. The stages include API integration backend responses, Lambda authorizer responses, and the `requestId` for AWS integration endpoints.

### Remediation
<a name="apigateway-1-remediation"></a>

To enable logging for REST and WebSocket API operations, see [Set up CloudWatch API logging using the API Gateway console](https://docs.aws.amazon.com/apigateway/latest/developerguide/set-up-logging.html#set-up-access-logging-using-console) in the *API Gateway Developer Guide*.

## [APIGateway.2] API Gateway REST API stages should be configured to use SSL certificates for backend authentication
<a name="apigateway-2"></a>

**Related requirements:** NIST.800-53.r5 AC-17(2), NIST.800-53.r5 AC-4, NIST.800-53.r5 IA-5(1), NIST.800-53.r5 SC-12(3), NIST.800-53.r5 SC-13, NIST.800-53.r5 SC-23, NIST.800-53.r5 SC-23(3), NIST.800-53.r5 SC-7(4), NIST.800-53.r5 SC-8, NIST.800-53.r5 SC-8(1), NIST.800-53.r5 SC-8(2), NIST.800-53.r5 SI-7(6), NIST.800-171.r2 3.13.15

**Category:** Protect > Data Protection > Encryption of data-in-transit

**Severity:** Medium

**Resource type:** `AWS::ApiGateway::Stage`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/api-gw-ssl-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/api-gw-ssl-enabled.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether Amazon API Gateway REST API stages have SSL certificates configured. Backend systems use these certificates to authenticate that incoming requests are from API Gateway.

API Gateway REST API stages should be configured with SSL certificates to allow backend systems to authenticate that requests originate from API Gateway.

### Remediation
<a name="apigateway-2-remediation"></a>

For detailed instructions on how to generate and configure API Gateway REST API SSL certificates, see [Generate and configure an SSL certificate for backend authentication](https://docs.aws.amazon.com/apigateway/latest/developerguide/getting-started-client-side-ssl-authentication.html) in the *API Gateway Developer Guide*.

## [APIGateway.3] API Gateway REST API stages should have AWS X-Ray tracing enabled
<a name="apigateway-3"></a>

**Related requirements:** NIST.800-53.r5 CA-7

**Category:** Detect > Detection services

**Severity:** Low

**Resource type:** `AWS::ApiGateway::Stage`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/api-gw-xray-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/api-gw-xray-enabled.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether AWS X-Ray active tracing is enabled for your Amazon API Gateway REST API stages.

X-Ray active tracing enables a more rapid response to performance changes in the underlying infrastructure. Changes in performance could result in a lack of availability of the API. X-Ray active tracing provides real-time metrics of user requests that flow through your API Gateway REST API operations and connected services.

### Remediation
<a name="apigateway-3-remediation"></a>

For detailed instructions on how to enable X-Ray active tracing for API Gateway REST API operations, see [Amazon API Gateway active tracing support for AWS X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/xray-services-apigateway.html) in the *AWS X-Ray Developer Guide*. 

## [APIGateway.4] API Gateway should be associated with a WAF Web ACL
<a name="apigateway-4"></a>

**Related requirements:** NIST.800-53.r5 AC-4(21)

**Category:** Protect > Protective services

**Severity:** Medium

**Resource type:** `AWS::ApiGateway::Stage`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/api-gw-associated-with-waf.html](https://docs.aws.amazon.com/config/latest/developerguide/api-gw-associated-with-waf.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether an API Gateway stage uses an AWS WAF web access control list (ACL). This control fails if an AWS WAF web ACL is not attached to a REST API Gateway stage.

AWS WAF is a web application firewall that helps protect web applications and APIs from attacks. It enables you to configure an ACL, which is a set of rules that allow, block, or count web requests based on customizable web security rules and conditions that you define. Ensure that your API Gateway stage is associated with an AWS WAF web ACL to help protect it from malicious attacks.

### Remediation
<a name="apigateway-4-remediation"></a>

For information on how to use the API Gateway console to associate an AWS WAF Regional web ACL with an existing API Gateway API stage, see [Using AWS WAF to protect your APIs](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-control-access-aws-waf.html) in the *API Gateway Developer Guide*.

## [APIGateway.5] API Gateway REST API cache data should be encrypted at rest
<a name="apigateway-5"></a>

**Related requirements:** NIST.800-53.r5 CA-9(1), NIST.800-53.r5 CM-3(6), NIST.800-53.r5 SC-13, NIST.800-53.r5 SC-28, NIST.800-53.r5 SC-28(1), NIST.800-53.r5 SC-7(10), NIST.800-53.r5 SI-7(6)

**Category:** Protect > Data protection > Encryption of data at rest

**Severity:** Medium

**Resource type:** `AWS::ApiGateway::Stage`

**AWS Config rule:** `api-gw-cache-encrypted` (custom Security Hub CSPM rule)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether all methods in API Gateway REST API stages that have cache enabled are encrypted. The control fails if any method in an API Gateway REST API stage is configured to cache and the cache is not encrypted. Security Hub CSPM evaluates the encryption of a particular method only when caching is enabled for that method.

Encrypting data at rest reduces the risk of data stored on disk being accessed by a user not authenticated to AWS. It adds another set of access controls to limit unauthorized users ability access the data. For example, API permissions are required to decrypt the data before it can be read.

API Gateway REST API caches should be encrypted at rest for an added layer of security.

### Remediation
<a name="apigateway-5-remediation"></a>

To configure API caching for a stage, see [Enable Amazon API Gateway caching](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-caching.html#enable-api-gateway-caching) in the *API Gateway Developer Guide*. In **Cache Settings**, choose **Encrypt cache data**.

## [APIGateway.8] API Gateway routes should specify an authorization type
<a name="apigateway-8"></a>

**Related requirements:** NIST.800-53.r5 AC-3, NIST.800-53.r5 CM-2, NIST.800-53.r5 CM-2(2)

**Category:** Protect > Secure Access Management

**Severity:** Medium

**Resource type:** `AWS::ApiGatewayV2::Route`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/api-gwv2-authorization-type-configured.html](https://docs.aws.amazon.com/config/latest/developerguide/api-gwv2-authorization-type-configured.html)

**Schedule type:** Periodic

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  `authorizationType`  |  Authorization type of the API routes  |  Enum  |  `AWS_IAM`, `CUSTOM`, `JWT`  |  No default value  | 

This control checks if Amazon API Gateway routes have an authorization type. The control fails if the API Gateway route doesn't have any authorization type. Optionally, you can provide a custom parameter value if you want the control to pass only if the route uses the authorization type specified in the `authorizationType` parameter.

API Gateway supports multiple mechanisms for controlling and managing access to your API. By specifying an authorization type, you can restrict access to your API to only authorized users or processes.

### Remediation
<a name="apigateway-8-remediation"></a>

To set an authorization type for HTTP APIs, see [Controlling and managing access to an HTTP API in API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-access-control.html) in the *API Gateway Developer Guide*. To set an authorization type for WebSocket APIs, see [Controlling and managing access to a WebSocket API in API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-websocket-api-control-access.html) in the *API Gateway Developer Guide*.

## [APIGateway.9] Access logging should be configured for API Gateway V2 Stages
<a name="apigateway-9"></a>

**Related requirements:** NIST.800-53.r5 AC-4(26), NIST.800-53.r5 AU-10, NIST.800-53.r5 AU-12, NIST.800-53.r5 AU-2, NIST.800-53.r5 AU-3, NIST.800-53.r5 AU-6(3), NIST.800-53.r5 AU-6(4), NIST.800-53.r5 CA-7, NIST.800-53.r5 SC-7(9), NIST.800-53.r5 SI-7(8), PCI DSS v4.0.1/10.4.2

**Category:** Identify > Logging

**Severity:** Medium

**Resource type:** `AWS::ApiGatewayV2::Stage`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/api-gwv2-access-logs-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/api-gwv2-access-logs-enabled.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks if Amazon API Gateway V2 stages have access logging configured. This control fails if access log settings aren't defined.

API Gateway access logs provide detailed information about who has accessed your API and how the caller accessed the API. These logs are useful for applications such as security and access audits and forensics investigation. Enable these access logs to analyze traffic patterns and to troubleshoot issues.

For additional best practices, see [Monitoring REST APIs](https://docs.aws.amazon.com/apigateway/latest/developerguide/rest-api-monitor.html) in the *API Gateway Developer Guide*.

### Remediation
<a name="apigateway-9-remediation"></a>

To set up access logging, see [Set up CloudWatch API logging using the API Gateway console](https://docs.aws.amazon.com/apigateway/latest/developerguide/set-up-logging.html#set-up-access-logging-using-console) in the *API Gateway Developer Guide*. 

## [APIGateway.10] API Gateway V2 integrations should use HTTPS for private connections
<a name="apigateway-10"></a>

**Category:** Protect > Data Protection > Encryption of data-in-transit

**Severity:** Medium

**Resource type:** `AWS::ApiGatewayV2::Integration`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/apigatewayv2-integration-private-https-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/apigatewayv2-integration-private-https-enabled.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether an API Gateway V2 integration has HTTPS enabled for private connections. The control fails if a private connection doesn't have TLS configured.

VPC Links connect API Gateway to private resources. While VPC Links create private connectivity, they don't inherently encrypt data. Configuring TLS ensures use of HTTPS for end-to-end encryption from client through API Gateway to backend. Without TLS, sensitive API traffic flows unencrypted across private connections. HTTPS encryption protects the traffic through private connections from data interception, man-in-the-middle attacks and credential exposure. 

### Remediation
<a name="apigateway-10-remediation"></a>

To enable encryption in transit for private connections in an API Gateway v2 Integration, see [Update a private integration](https://docs.aws.amazon.com/apigateway/latest/developerguide/set-up-private-integration.html#set-up-private-integration-update) in the *Amazon API Gateway Developer Guide*. Configure [TLS configuration](https://docs.aws.amazon.com/apigatewayv2/latest/api-reference/apis-apiid-integrations-integrationid.html#apis-apiid-integrations-integrationid-model-tlsconfig) so that the private integration uses HTTPS protocol.

## [APIGateway.11] API Gateway domain names should use recommended security policies
<a name="apigateway-11"></a>

**Category:** Protect > Encryption of data-in-transit

**Severity:** Medium

**Resource type:** `AWS::ApiGateway::DomainName`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/apigateway-domain-name-tls-check.html](https://docs.aws.amazon.com/config/latest/developerguide/apigateway-domain-name-tls-check.html)

**Schedule type:** Change triggered

**Parameters:**
+ `allowedSecurityPolicies`: `SecurityPolicy_TLS13_1_3_2025_09, SecurityPolicy_TLS13_1_3_FIPS_2025_09, SecurityPolicy_TLS13_1_2_PFS_PQ_2025_09, SecurityPolicy_TLS13_2025_EDGE, SecurityPolicy_TLS12_PFS_2025_EDGE` (not customizable)

This control checks whether an API Gateway domain name is configured to encrypt data in transit by using a recommended security policy. The control fails if the API Gateway domain name isn't configured to use a recommended security policy.

A security policy is a predefined combination of minimum TLS version and cipher suites offered by API Gateway. When your clients establish a TLS handshake to your API or custom domain name, the security policy enforces the TLS version and cipher suite accepted by API Gateway. Security policies protect your APIs and custom domain names from network security problems such as tampering and eavesdropping between a client and server. Using a recommended security policy helps ensure that API Gateway domain names use modern, secure TLS configurations that protect data in transit between clients and your API.

### Remediation
<a name="apigateway-11-remediation"></a>

To update the TLS security policy for an API Gateway domain name, see [How to change a security policy](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-security-policies-update.html) in the *Amazon API Gateway Developer Guide*.

# Security Hub CSPM controls for AWS AppConfig
<a name="appconfig-controls"></a>

These Security Hub CSPM controls evaluate the AWS AppConfig service and resources.

These controls may not be available in all AWS Regions. For more information, see [Availability of controls by Region](securityhub-regions.md#securityhub-regions-control-support).

## [AppConfig.1] AWS AppConfig applications should be tagged
<a name="appconfig-1"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::AppConfig::Application`

**AWS Config rule:** `appconfig-application-tagged`

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredKeyTags  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  | No default value  | 

This control checks whether an AWS AppConfig application has tags with the specific keys defined in the parameter `requiredKeyTags`. The control fails if the application doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredKeyTags`. If the parameter `requiredKeyTags` isn't provided, the control only checks for the existence of a tag key and fails if the application isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [Define permissions based on attributes with ABAC authorization](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Best practices and strategies](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *Tagging AWS Resources and Tag Editor User Guide*.

### Remediation
<a name="appconfig-1-remediation"></a>

To add tags to an AWS AppConfig application, see [https://docs.aws.amazon.com/appconfig/2019-10-09/APIReference/API_TagResource.html](https://docs.aws.amazon.com/appconfig/2019-10-09/APIReference/API_TagResource.html) in the *AWS AppConfig API Reference*.

## [AppConfig.2] AWS AppConfig configuration profiles should be tagged
<a name="appconfig-2"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::AppConfig::ConfigurationProfile`

**AWS Config rule:** `appconfig-configuration-profile-tagged`

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredKeyTags  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  | No default value  | 

This control checks whether an AWS AppConfig configuration profile has tags with the specific keys defined in the parameter `requiredKeyTags`. The control fails if the configuration profile doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredKeyTags`. If the parameter `requiredKeyTags` isn't provided, the control only checks for the existence of a tag key and fails if the configuration profile isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [Define permissions based on attributes with ABAC authorization](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Best practices and strategies](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *Tagging AWS Resources and Tag Editor User Guide*.

### Remediation
<a name="appconfig-2-remediation"></a>

To add tags to an AWS AppConfig configuration profile, see [https://docs.aws.amazon.com/appconfig/2019-10-09/APIReference/API_TagResource.html](https://docs.aws.amazon.com/appconfig/2019-10-09/APIReference/API_TagResource.html) in the *AWS AppConfig API Reference*.

## [AppConfig.3] AWS AppConfig environments should be tagged
<a name="appconfig-3"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::AppConfig::Environment`

**AWS Config rule:** `appconfig-environment-tagged`

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredKeyTags  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  | No default value  | 

This control checks whether an AWS AppConfig environment has tags with the specific keys defined in the parameter `requiredKeyTags`. The control fails if the environment doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredKeyTags`. If the parameter `requiredKeyTags` isn't provided, the control only checks for the existence of a tag key and fails if the environment isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [Define permissions based on attributes with ABAC authorization](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Best practices and strategies](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *Tagging AWS Resources and Tag Editor User Guide*.

### Remediation
<a name="appconfig-3-remediation"></a>

To add tags to an AWS AppConfig environment, see [https://docs.aws.amazon.com/appconfig/2019-10-09/APIReference/API_TagResource.html](https://docs.aws.amazon.com/appconfig/2019-10-09/APIReference/API_TagResource.html) in the *AWS AppConfig API Reference*.

## [AppConfig.4] AWS AppConfig extension associations should be tagged
<a name="appconfig-4"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::AppConfig::ExtensionAssociation`

**AWS Config rule:** `appconfig-extension-association-tagged`

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredKeyTags  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  | No default value  | 

This control checks whether an AWS AppConfig extension association has tags with the specific keys defined in the parameter `requiredKeyTags`. The control fails if the extension association doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredKeyTags`. If the parameter `requiredKeyTags` isn't provided, the control only checks for the existence of a tag key and fails if the extension association isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [Define permissions based on attributes with ABAC authorization](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Best practices and strategies](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *Tagging AWS Resources and Tag Editor User Guide*.

### Remediation
<a name="appconfig-4-remediation"></a>

To add tags to an AWS AppConfig extension association, see [https://docs.aws.amazon.com/appconfig/2019-10-09/APIReference/API_TagResource.html](https://docs.aws.amazon.com/appconfig/2019-10-09/APIReference/API_TagResource.html) in the *AWS AppConfig API Reference*.

# Security Hub CSPM controls for Amazon AppFlow
<a name="appflow-controls"></a>

These Security Hub CSPM controls evaluate the Amazon AppFlow service and resources.

These controls may not be available in all AWS Regions. For more information, see [Availability of controls by Region](securityhub-regions.md#securityhub-regions-control-support).

## [AppFlow.1] Amazon AppFlow flows should be tagged
<a name="appflow-1"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::AppFlow::Flow`

**AWS Config rule:** `appflow-flow-tagged`

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredKeyTags  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  | No default value  | 

This control checks whether an Amazon AppFlow flow has tags with the specific keys defined in the parameter `requiredKeyTags`. The control fails if the flow doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredKeyTags`. If the parameter `requiredKeyTags` isn't provided, the control only checks for the existence of a tag key and fails if the flow isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [Define permissions based on attributes with ABAC authorization](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Best practices and strategies](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *Tagging AWS Resources and Tag Editor User Guide*.

### Remediation
<a name="appflow-1-remediation"></a>

To add tags to an Amazon AppFlow flow, see [Creating flows in Amazon AppFlow](https://docs.aws.amazon.com/appflow/latest/userguide/flows-manage.html) in the *Amazon AppFlow User Guide*.

# Security Hub CSPM controls for AWS App Runner
<a name="apprunner-controls"></a>

These AWS Security Hub CSPM controls evaluate the AWS App Runner service and resources. The controls might not be available in all AWS Regions. For more information, see [Availability of controls by Region](securityhub-regions.md#securityhub-regions-control-support).

## [AppRunner.1] App Runner services should be tagged
<a name="apprunner-1"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::AppRunner::Service`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/apprunner-service-tagged.html](https://docs.aws.amazon.com/config/latest/developerguide/apprunner-service-tagged.html)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredKeyTags  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  | No default value  | 

This control checks whether an AWS App Runner service has tags with the specific keys defined in the parameter `requiredKeyTags`. The control fails if the App Runner service doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredKeyTags`. If the parameter `requiredKeyTags` isn't provided, the control only checks for the existence of a tag key and fails if the App Runner service isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [Define permissions based on attributes with ABAC authorization](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Best practices and strategies](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *Tagging AWS Resources and Tag Editor User Guide*.

### Remediation
<a name="apprunner-1-remediation"></a>

For information about adding tags to an AWS App Runner service, see [https://docs.aws.amazon.com/apprunner/latest/api/API_TagResource.html](https://docs.aws.amazon.com/apprunner/latest/api/API_TagResource.html) in the *AWS App Runner API Reference*.

## [AppRunner.2] App Runner VPC connectors should be tagged
<a name="apprunner-2"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::AppRunner::VpcConnector`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/apprunner-vpc-connector-tagged.html](https://docs.aws.amazon.com/config/latest/developerguide/apprunner-vpc-connector-tagged.html)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredKeyTags  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  | No default value  | 

This control checks whether an AWS App Runner VPC connector has tags with the specific keys defined in the parameter `requiredKeyTags`. The control fails if the VPC connector doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredKeyTags`. If the parameter `requiredKeyTags` isn't provided, the control only checks for the existence of a tag key and fails if the VPC connector isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [Define permissions based on attributes with ABAC authorization](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Best practices and strategies](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *Tagging AWS Resources and Tag Editor User Guide*.

### Remediation
<a name="apprunner-2-remediation"></a>

For information about adding tags to an AWS App Runner VPC connector, see [https://docs.aws.amazon.com/apprunner/latest/api/API_TagResource.html](https://docs.aws.amazon.com/apprunner/latest/api/API_TagResource.html) in the *AWS App Runner API Reference*.

# Security Hub CSPM controls for AWS AppSync
<a name="appsync-controls"></a>

These Security Hub CSPM controls evaluate the AWS AppSync service and resources.

These controls may not be available in all AWS Regions. For more information, see [Availability of controls by Region](securityhub-regions.md#securityhub-regions-control-support).

## [AppSync.1] AWS AppSync API caches should be encrypted at rest
<a name="appsync-1"></a>

**Important**  
Security Hub CSPM retired this control on March 9, 2026. For more information, see [Change log for Security Hub CSPM controls](controls-change-log.md). AWS AppSync now provides default encryption on all current and future API caches.

**Category:** Protect > Data Protection > Encryption of data-at-rest

**Severity:** Medium

**Resource type:** `AWS::AppSync::GraphQLApi`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/appsync-cache-ct-encryption-at-rest.html](https://docs.aws.amazon.com/config/latest/developerguide/appsync-cache-ct-encryption-at-rest.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether an AWS AppSync API cache is encrypted at rest. The control fails if the API cache isn't encrypted at rest.

Data at rest refers to data that's stored in persistent, non-volatile storage for any duration. Encrypting data at rest helps you protect its confidentiality, which reduces the risk that an unauthorized user can access it.

### Remediation
<a name="appsync-1-remediation"></a>

You can't change the encryption settings after enabling caching for your AWS AppSync API. Instead, you must delete the cache and and recreate it with encryption enabled. For more information, see [Cache encryption](https://docs.aws.amazon.com/appsync/latest/devguide/enabling-caching.html#caching-encryption) in the *AWS AppSync Developer Guide*.

## [AppSync.2] AWS AppSync should have field-level logging enabled
<a name="appsync-2"></a>

**Related requirements:** PCI DSS v4.0.1/10.4.2

**Category:** Identify > Logging

**Severity:** Medium

**Resource type:** `AWS::AppSync::GraphQLApi`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/appsync-logging-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/appsync-logging-enabled.html)

**Schedule type:** Change triggered

**Parameters:** 


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  `fieldLoggingLevel`  |  Field logging level  |  Enum  |  `ERROR`, `ALL`, `INFO`, `DEBUG`  |  `No default value`  | 

This control checks whether an AWS AppSync API has field-level logging turned on. The control fails if the field resolver log level is set to **None**. Unless you provide custom parameter values to indicate that a specific log type should be enabled, Security Hub CSPM produces a passed finding if the field resolver log level is either `ERROR` or `ALL`.

You can use logging and metrics to identify, troubleshoot, and optimize your GraphQL queries. Turning on logging for AWS AppSync GraphQL helps you get detailed information about API requests and responses, identify and respond to issues, and comply with regulatory requirements.

### Remediation
<a name="appsync-2-remediation"></a>

To turn on logging for AWS AppSync, see [Setup and configuration](https://docs.aws.amazon.com/appsync/latest/devguide/monitoring.html#setup-and-configuration) in the *AWS AppSync Developer Guide*.

## [AppSync.4] AWS AppSync GraphQL APIs should be tagged
<a name="appsync-4"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::AppSync::GraphQLApi`

**AWS Config rule:** `tagged-appsync-graphqlapi` (custom Security Hub CSPM rule)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  | No default value  | 

This control checks whether an AWS AppSync GraphQL API has tags with the specific keys defined in the parameter `requiredTagKeys`. The control fails if the GraphQL API doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredTagKeys`. If the parameter `requiredTagKeys` isn't provided, the control only checks for the existence of a tag key and fails if the GraphQL API isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [What is ABAC for AWS?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Tagging your AWS resources](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *AWS General Reference*.

### Remediation
<a name="appsync-4-remediation"></a>

To add tags to an AWS AppSync GraphQL API, see [https://docs.aws.amazon.com/appsync/latest/APIReference/API_TagResource.html](https://docs.aws.amazon.com/appsync/latest/APIReference/API_TagResource.html) in the *AWS AppSync API Reference*.

## [AppSync.5] AWS AppSync GraphQL APIs should not be authenticated with API keys
<a name="appsync-5"></a>

**Related requirements:** NIST.800-53.r5 AC-2(1), NIST.800-53.r5 AC-3, NIST.800-53.r5 AC-3(15), NIST.800-53.r5 AC-3(7), NIST.800-53.r5 AC-6

**Category:** Protect > Secure access management > Passwordless authentication

**Severity:** High

**Resource type:** `AWS::AppSync::GraphQLApi`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/appsync-authorization-check.html](https://docs.aws.amazon.com/config/latest/developerguide/appsync-authorization-check.html)

**Schedule type:** Change triggered

**Parameters:**
+ `AllowedAuthorizationTypes`: ` AWS_LAMBDA, AWS_IAM, OPENID_CONNECT, AMAZON_COGNITO_USER_POOLS` (not customizable)

This control checks whether your application uses an API key to interact with an AWS AppSync GraphQL API. The control fails if an AWS AppSync GraphQL API is authenticated with an API key.

An API key is a hard-coded value in your application that is generated by the AWS AppSync service when you create an unauthenticated GraphQL endpoint. If this API key is compromised, your endpoint is vulnerable to unintended access. Unless you are supporting a publicly accessible application or website, we don't recommend using an API key for authentication.

### Remediation
<a name="appsync-5-remediation"></a>

To set an authorization option for your AWS AppSync GraphQL API, see [Authorization and authentication ](https://docs.aws.amazon.com/appsync/latest/devguide/security-authz.html) in the *AWS AppSync Developer Guide*.

## [AppSync.6] AWS AppSync API caches should be encrypted in transit
<a name="appsync-6"></a>

**Important**  
Security Hub CSPM retired this control on March 9, 2026. For more information, see [Change log for Security Hub CSPM controls](controls-change-log.md). AWS AppSync now provides default encryption on all current and future API caches.

**Category:** Protect > Data Protection > Encryption of data-in-transit

**Severity:** Medium

**Resource type:** `AWS::AppSync::ApiCache`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/appsync-cache-ct-encryption-in-transit.html](https://docs.aws.amazon.com/config/latest/developerguide/appsync-cache-ct-encryption-in-transit.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether an AWS AppSync API cache is encrypted in transit. The control fails if the API cache isn't encrypted in transit.

Data in transit refers to data that moves from one location to another, such as between nodes in your cluster or between your cluster and your application. Data may move across the internet or within a private network. Encrypting data in transit reduces the risk that an unauthorized user can eavesdrop on network traffic.

### Remediation
<a name="appsync-6-remediation"></a>

You can't change the encryption settings after enabling caching for your AWS AppSync API. Instead, you must delete the cache and and recreate it with encryption enabled. For more information, see [Cache encryption](https://docs.aws.amazon.com/appsync/latest/devguide/enabling-caching.html#caching-encryption) in the *AWS AppSync Developer Guide*.

# Security Hub CSPM controls for Amazon Athena
<a name="athena-controls"></a>

These AWS Security Hub CSPM controls evaluate the Amazon Athena service and resources. The controls might not be available in all AWS Regions. For more information, see [Availability of controls by Region](securityhub-regions.md#securityhub-regions-control-support).

## [Athena.1] Athena workgroups should be encrypted at rest
<a name="athena-1"></a>

**Important**  
Security Hub CSPM retired this control in April 2024. For more information, see [Change log for Security Hub CSPM controls](controls-change-log.md).

**Category:** Protect > Data protection > Encryption of data at rest

**Related requirements:** NIST.800-53.r5 CA-9(1), NIST.800-53.r5 CM-3(6), NIST.800-53.r5 SC-13, NIST.800-53.r5 SC-28, NIST.800-53.r5 SC-28(1), NIST.800-53.r5 SC-7(10), NIST.800-53.r5 SI-7(6)

**Severity:** Medium

**Resource type:** `AWS::Athena::WorkGroup`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/athena-workgroup-encrypted-at-rest.html](https://docs.aws.amazon.com/config/latest/developerguide/athena-workgroup-encrypted-at-rest.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks if an Athena workgroup is encrypted at rest. The control fails if an Athena workgroup isn’t encrypted at rest.

In Athena, you can create workgroups for running queries for teams, applications, or different workloads. Each workgroup has a setting to enable encryption on all queries. You have the option to use server-side encryption with Amazon Simple Storage Service (Amazon S3) managed keys, server-side encryption with AWS Key Management Service (AWS KMS) keys, or client-side encryption with customer managed KMS keys. Data at rest refers to any data that's stored in persistent, non-volatile storage for any duration. Encryption helps you protect the confidentiality of such data, reducing the risk that an unauthorized user can access it.

### Remediation
<a name="athena-1-remediation"></a>

To enable encryption at rest for Athena workgroups, see [Edit a workgroup](https://docs.aws.amazon.com/athena/latest/ug/workgroups-create-update-delete.html#editing-workgroups) in the *Amazon Athena User Guide*. In the **Query Result Configuration** section, select **Encrypt query results**.

## [Athena.2] Athena data catalogs should be tagged
<a name="athena-2"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::Athena::DataCatalog`

**AWS Config rule:** `tagged-athena-datacatalog` (custom Security Hub CSPM rule)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  |  No default value  | 

This control checks whether an Amazon Athena data catalog has tags with the specific keys defined in the parameter `requiredTagKeys`. The control fails if the data catalog doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredTagKeys`. If the parameter `requiredTagKeys` isn't provided, the control only checks for the existence of a tag key and fails if the data catalog isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [What is ABAC for AWS?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Tagging your AWS resources](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *AWS General Reference*.

### Remediation
<a name="athena-2-remediation"></a>

To add tags to an Athena data catalog, see [Tagging Athena resources](https://docs.aws.amazon.com/athena/latest/ug/tags.html) in the *Amazon Athena User Guide*.

## [Athena.3] Athena workgroups should be tagged
<a name="athena-3"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::Athena::WorkGroup`

**AWS Config rule:** `tagged-athena-workgroup` (custom Security Hub CSPM rule)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  |  No default value  | 

This control checks whether an Amazon Athena workgroup has tags with the specific keys defined in the parameter `requiredTagKeys`. The control fails if the workgroup doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredTagKeys`. If the parameter `requiredTagKeys` isn't provided, the control only checks for the existence of a tag key and fails if the workgroup isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [What is ABAC for AWS?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Tagging your AWS resources](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *AWS General Reference*.

### Remediation
<a name="athena-3-remediation"></a>

To add tags to an Athena workgroup, see [Adding and deleting tags on an individual workgroup](https://docs.aws.amazon.com/athena/latest/ug/tags-console.html#tags-add-delete) in the *Amazon Athena User Guide*.

## [Athena.4] Athena workgroups should have logging enabled
<a name="athena-4"></a>

**Category:** Identify > Logging

**Severity:** Medium

**Resource type:** `AWS::Athena::WorkGroup`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/athena-workgroup-logging-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/athena-workgroup-logging-enabled.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether an Amazon Athena workgroup has logging enabled. The control fails if the workgroup doesn't have logging enabled.

Audit logs track and monitor system activities. They provide a record of events that can help you detect security breaches, investigate incidents, and comply with regulations. Audit logs also enhance the overall accountability and transparency of your organization.

### Remediation
<a name="athena-4-remediation"></a>

For information about enabling logging for an Athena workgroup, see [Enable CloudWatch query metrics in Athena](https://docs.aws.amazon.com/athena/latest/ug/athena-cloudwatch-metrics-enable.html) in the *Amazon Athena User Guide*.

# Security Hub CSPM controls for AWS Backup
<a name="backup-controls"></a>

These Security Hub CSPM controls evaluate the AWS Backup service and resources.

These controls may not be available in all AWS Regions. For more information, see [Availability of controls by Region](securityhub-regions.md#securityhub-regions-control-support).

## [Backup.1] AWS Backup recovery points should be encrypted at rest
<a name="backup-1"></a>

**Related requirements:** NIST.800-53.r5 CP-9(8), NIST.800-53.r5 SI-12

**Category:** Protect > Data Protection > Encryption of data-at-rest

**Severity:** Medium

**Resource type:** `AWS::Backup::RecoveryPoint`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/backup-recovery-point-encrypted.html](https://docs.aws.amazon.com/config/latest/developerguide/backup-recovery-point-encrypted.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks if an AWS Backup recovery point is encrypted at rest. The control fails if the recovery point isn't encrypted at rest.

An AWS Backup recovery point refers to a specific copy or snapshot of data that is created as part of a backup process. It represents a particular moment in time when the data was backed up and serves as a restore point in case the original data becomes lost, corrupted, or inaccessible. Encrypting the backup recovery points adds an extra layer of protection against unauthorized access. Encryption is a best practice to protect the confidentiality, integrity, and security of backup data.

### Remediation
<a name="backup-1-remediation"></a>

To encrypt an AWS Backup recovery point, see [Encryption for backups in AWS Backup](https://docs.aws.amazon.com/aws-backup/latest/devguide/encryption.html) in the *AWS Backup Developer Guide*.

## [Backup.2] AWS Backup recovery points should be tagged
<a name="backup-2"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::Backup::RecoveryPoint`

**AWS Configrule:** `tagged-backup-recoverypoint` (custom Security Hub CSPM rule)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  | No default value  | 

This control checks whether an AWS Backup recovery point has tags with the specific keys defined in the parameter `requiredTagKeys`. The control fails if the recovery point doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredTagKeys`. If the parameter `requiredTagKeys` isn't provided, the control only checks for the existence of a tag key and fails if the recovery point isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [What is ABAC for AWS?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Tagging your AWS resources](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *AWS General Reference*.

### Remediation
<a name="backup-2-remediation"></a>

**To add tags to an AWS Backup recovery point**

1. Open the AWS Backup console at [https://console.aws.amazon.com/backup](https://console.aws.amazon.com/backup).

1. In the navigation pane, choose **Backup plans**.

1. Select a backup plan from the list.

1. In the **Backup plan tags** section, choose **Manage tags**.

1. Enter the key and value for the tag. Choose **Add new tag** for additional key-value pairs.

1. When you are finished adding tags, choose **Save**.

## [Backup.3] AWS Backup vaults should be tagged
<a name="backup-3"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::Backup::BackupVault`

**AWS Configrule:** `tagged-backup-backupvault` (custom Security Hub CSPM rule)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  | No default value  | 

This control checks whether an AWS Backup vault has tags with the specific keys defined in the parameter `requiredTagKeys`. The control fails if the recovery point doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredTagKeys`. If the parameter `requiredTagKeys` isn't provided, the control only checks for the existence of a tag key and fails if the recovery point isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [What is ABAC for AWS?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Tagging your AWS resources](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *AWS General Reference*.

### Remediation
<a name="backup-3-remediation"></a>

**To add tags to an AWS Backup vault**

1. Open the AWS Backup console at [https://console.aws.amazon.com/backup](https://console.aws.amazon.com/backup).

1. In the navigation pane, choose **Backup vaults**.

1. Select a backup vault from the list.

1. In the **Backup vault tags** section, choose **Manage tags**.

1. Enter the key and value for the tag. Choose **Add new tag** for additional key-value pairs.

1. When you are finished adding tags, choose **Save**.

## [Backup.4] AWS Backup report plans should be tagged
<a name="backup-4"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::Backup::ReportPlan`

**AWS Configrule:** `tagged-backup-reportplan` (custom Security Hub CSPM rule)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  | No default value  | 

This control checks whether an AWS Backup report plan has tags with the specific keys defined in the parameter `requiredTagKeys`. The control fails if the report plan doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredTagKeys`. If the parameter `requiredTagKeys` isn't provided, the control only checks for the existence of a tag key and fails if the report plan isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [What is ABAC for AWS?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Tagging your AWS resources](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *AWS General Reference*.

### Remediation
<a name="backup-4-remediation"></a>

**To add tags to an AWS Backup report plan**

1. Open the AWS Backup console at [https://console.aws.amazon.com/backup](https://console.aws.amazon.com/backup).

1. In the navigation pane, choose **Backup vaults**.

1. Select a backup vault from the list.

1. In the **Backup vault tags** section, choose **Manage tags**.

1. Choose **Add new tag**. Enter the key and value for the tag. Repeat for additional key-value pairs.

1. When you are finished adding tags, choose **Save**.

## [Backup.5] AWS Backup backup plans should be tagged
<a name="backup-5"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::Backup::BackupPlan`

**AWS Configrule:** `tagged-backup-backupplan` (custom Security Hub CSPM rule)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  | No default value  | 

This control checks whether an AWS Backup backup plan has tags with the specific keys defined in the parameter `requiredTagKeys`. The control fails if the backup plan doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredTagKeys`. If the parameter `requiredTagKeys` isn't provided, the control only checks for the existence of a tag key and fails if the backup plan isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [What is ABAC for AWS?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Tagging your AWS resources](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *AWS General Reference*.

### Remediation
<a name="backup-5-remediation"></a>

**To add tags to an AWS Backup backup plan**

1. Open the AWS Backup console at [https://console.aws.amazon.com/backup](https://console.aws.amazon.com/backup).

1. In the navigation pane, choose **Backup vaults**.

1. Select a backup vault from the list.

1. In the **Backup vault tags** section, choose **Manage tags**.

1. Choose **Add new tag**. Enter the key and value for the tag. Repeat for additional key-value pairs.

1. When you are finished adding tags, choose **Save**.

# Security Hub CSPM controls for AWS Batch
<a name="batch-controls"></a>

These Security Hub CSPM controls evaluate the AWS Batch service and resources. The controls might not be available in all AWS Regions. For more information, see [Availability of controls by Region](securityhub-regions.md#securityhub-regions-control-support).

## [Batch.1] Batch job queues should be tagged
<a name="batch-1"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::Batch::JobQueue`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/batch-job-queue-tagged.html](https://docs.aws.amazon.com/config/latest/developerguide/batch-job-queue-tagged.html)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredKeyTags  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  | No default value  | 

This control checks whether an AWS Batch job queue has tags with the specific keys defined in the parameter `requiredKeyTags`. The control fails if the job queue doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredKeyTags`. If the parameter `requiredKeyTags` isn't provided, the control only checks for the existence of a tag key and fails if the job queue isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [Define permissions based on attributes with ABAC authorization](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Best practices and strategies](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *Tagging AWS Resources and Tag Editor User Guide*.

### Remediation
<a name="batch-1-remediation"></a>

To add tags to a Batch job queue, see [Tag your resources](https://docs.aws.amazon.com/batch/latest/userguide/tag-resources.html) in the *AWS Batch User Guide*.

## [Batch.2] Batch scheduling policies should be tagged
<a name="batch-2"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::Batch::SchedulingPolicy`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/batch-scheduling-policy-tagged.html](https://docs.aws.amazon.com/config/latest/developerguide/batch-scheduling-policy-tagged.html)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredKeyTags  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  | No default value  | 

This control checks whether an AWS Batch scheduling policy has tags with the specific keys defined in the parameter `requiredKeyTags`. The control fails if the scheduling policy doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredKeyTags`. If the parameter `requiredKeyTags` isn't provided, the control only checks for the existence of a tag key and fails if the scheduling policy isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [Define permissions based on attributes with ABAC authorization](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Best practices and strategies](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *Tagging AWS Resources and Tag Editor User Guide*.

### Remediation
<a name="batch-2-remediation"></a>

To add tags to a Batch scheduling policy, see [Tag your resources](https://docs.aws.amazon.com/batch/latest/userguide/tag-resources.html) in the *AWS Batch User Guide*.

## [Batch.3] Batch compute environments should be tagged
<a name="batch-3"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::Batch::ComputeEnvironment`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/batch-compute-environment-tagged.html](https://docs.aws.amazon.com/config/latest/developerguide/batch-compute-environment-tagged.html)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredKeyTags  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  | No default value  | 

This control checks whether an AWS Batch compute environment has tags with the specific keys defined in the parameter `requiredKeyTags`. The control fails if the compute environment doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredKeyTags`. If the parameter `requiredKeyTags` isn't provided, the control only checks for the existence of a tag key and fails if the compute environment isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [Define permissions based on attributes with ABAC authorization](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Best practices and strategies](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *Tagging AWS Resources and Tag Editor User Guide*.

### Remediation
<a name="batch-3-remediation"></a>

To add tags to a Batch compute environment, see [Tag your resources](https://docs.aws.amazon.com/batch/latest/userguide/tag-resources.html) in the *AWS Batch User Guide*.

## [Batch.4] Compute resources properties in managed Batch compute environments should be tagged
<a name="batch-4"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::Batch::ComputeEnvironment`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/batch-managed-compute-env-compute-resources-tagged.html](https://docs.aws.amazon.com/config/latest/developerguide/batch-managed-compute-env-compute-resources-tagged.html)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
| requiredKeyTags | A list of non-system tag keys that must be assigned to an evaluated resource. Tag keys are case sensitive. | StringList (maximum of 6 items) | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions). | No default value | 

This control checks whether the compute resources property in a managed AWS Batch compute environment has the tag keys specified by the `requiredKeyTags` parameter. The control fails if the compute resources property doesn't have any tag keys, or it doesn't have all the keys specified by the `requiredKeyTags` parameter. If you don't specify any values for the `requiredKeyTags` parameter, the control checks only for the existence of a tag key and fails if a compute resources property doesn't have any tag keys. The control ignores system tags, which are applied automatically and have the `aws:` prefix. This control doesn’t evaluate unmanaged compute environments, or managed environments that use AWS Fargate resources.

A tag is a label that you create and assign to an AWS resource. Each tag consists of a required tag key and an optional tag value. You can use tags to categorize resources by purpose, owner, environment, or other criteria. They can help you identify, organize, search for, and filter resources. They can also help you track resource owners for actions and notifications. You can also use tags to implement attribute-based access control (ABAC) as an authorization strategy. For more information about ABAC strategies, see [Define permissions based on attributes with ABAC authorization](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*. For more information about tags, see the [Tagging AWS Resources and Tag Editor User Guide](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html).

**Note**  
Do not store personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible from many AWS services. They aren't intended to be used for private or sensitive data.

### Remediation
<a name="batch-4-remediation"></a>

For information about adding tags to compute resources in a managed AWS Batch compute environment, see [Tag your resources](https://docs.aws.amazon.com/batch/latest/userguide/tag-resources.html) in the *AWS Batch User Guide*.

# Security Hub CSPM controls for AWS Certificate Manager
<a name="acm-controls"></a>

These AWS Security Hub CSPM controls evaluate the AWS Certificate Manager (ACM) service and resources. The controls might not be available in all AWS Regions. For more information, see [Availability of controls by Region](securityhub-regions.md#securityhub-regions-control-support).

## [ACM.1] Imported and ACM-issued certificates should be renewed after a specified time period
<a name="acm-1"></a>

**Related requirements:** NIST.800-53.r5 SC-28(3), NIST.800-53.r5 SC-7(16), NIST.800-171.r2 3.13.15, PCI DSS v4.0.1/4.2.1

**Category:** Protect > Data Protection > Encryption of data-in-transit

**Severity:** Medium

**Resource type:** `AWS::ACM::Certificate`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/acm-certificate-expiration-check.html](https://docs.aws.amazon.com/config/latest/developerguide/acm-certificate-expiration-check.html)

**Schedule type:** Change triggered and periodic

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  `daysToExpiration`  |  Number of days within which the ACM certificate must be renewed  |  Integer  |  `14` to `365`  |  `30`  | 

This control checks whether an AWS Certificate Manager (ACM) certificate is renewed within the specified time period. It checks both imported certificates and certificates provided by ACM. The control fails if the certificate isn't renewed within the specified time period. Unless you provide a custom parameter value for the renewal period, Security Hub CSPM uses a default value of 30 days.

ACM can automatically renew certificates that use DNS validation. For certificates that use email validation, you must respond to a domain validation email. ACM doesn't automatically renew certificates that you import. You must renew imported certificates manually.

### Remediation
<a name="acm-1-remediation"></a>

ACM provides managed renewal for your SSL/TLS certificates issued by Amazon. This means that ACM either renews your certificates automatically (if you use DNS validation), or it sends you email notices when the certificate expiration approaches. These services are provided for both public and private ACM certificates.

**For domains validated by email**  
When a certificate is 45 days from expiration, ACM sends to the domain owner an email for each domain name. To validate the domains and complete the renewal, you must respond to the email notifications.  
For more information, see [Renewal for domains validated by email](https://docs.aws.amazon.com/acm/latest/userguide/email-renewal-validation.html) in the *AWS Certificate Manager User Guide*.

**For domains validated by DNS**  
ACM automatically renews certificates that use DNS validation. 60 days before the expiration, ACM verifies that the certificate can be renewed.  
If it cannot validate a domain name, then ACM sends a notification that manual validation is required. It sends these notifications 45 days, 30 days, 7 days, and 1 day before the expiration.  
For more information, see [Renewal for domains validated by DNS](https://docs.aws.amazon.com/acm/latest/userguide/dns-renewal-validation.html) in the *AWS Certificate Manager User Guide*.

## [ACM.2] RSA certificates managed by ACM should use a key length of at least 2,048 bits
<a name="acm-2"></a>

**Related requirements:** PCI DSS v4.0.1/4.2.1

**Category:** Identify > Inventory > Inventory services

**Severity:** High

**Resource type:** `AWS::ACM::Certificate`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/acm-certificate-rsa-check.html](https://docs.aws.amazon.com/config/latest/developerguide/acm-certificate-rsa-check.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether RSA certificates managed by AWS Certificate Manager use a key length of at least 2,048 bits. The control fails if the key length is smaller than 2,048 bits.

The strength of encryption directly correlates with key size. We recommend key lengths of at least 2,048 bits to protect your AWS resources as computing power becomes less expensive and servers become more advanced.

### Remediation
<a name="acm-2-remediation"></a>

The minimum key length for RSA certificates issued by ACM is already 2,048 bits. For instructions on issuing new RSA certificates with ACM, see [Issuing and managing certificates](https://docs.aws.amazon.com/acm/latest/userguide/gs.html) in the *AWS Certificate Manager User Guide*.

While ACM allows you to import certificates with shorter key lengths, you must use keys of at least 2,048 bits to pass this control. You can't change the key length after importing a certificate. Instead, you must delete certificates with a key length smaller than 2,048 bits. For more information about importing certificates into ACM, see [Prerequisites for importing certificates](https://docs.aws.amazon.com/acm/latest/userguide/import-certificate-prerequisites.html) in the *AWS Certificate Manager User Guide*.

## [ACM.3] ACM certificates should be tagged
<a name="acm-3"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::ACM::Certificate`

**AWS Config rule:** `tagged-acm-certificate` (custom Security Hub CSPM rule)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  | No default value  | 

This control checks whether an AWS Certificate Manager (ACM) certificate has tags with the specific keys defined in the parameter `requiredTagKeys`. The control fails if the certificate doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredTagKeys`. If the parameter `requiredTagKeys` isn't provided, the control only checks for the existence of a tag key and fails if the certificate isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [What is ABAC for AWS?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Tagging your AWS resources](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *AWS General Reference*.

### Remediation
<a name="acm-3-remediation"></a>

To add tags to an ACM certificate, see [Tagging AWS Certificate Manager certificates](https://docs.aws.amazon.com/acm/latest/userguide/tags.html) in the *AWS Certificate Manager User Guide*.

# Security Hub CSPM controls for CloudFormation
<a name="cloudformation-controls"></a>

These Security Hub CSPM controls evaluate the AWS CloudFormation service and resources.

These controls may not be available in all AWS Regions. For more information, see [Availability of controls by Region](securityhub-regions.md#securityhub-regions-control-support).

## [CloudFormation.1] CloudFormation stacks should be integrated with Simple Notification Service (SNS)
<a name="cloudformation-1"></a>

**Important**  
Security Hub CSPM retired this control in April 2024. For more information, see [Change log for Security Hub CSPM controls](controls-change-log.md).

**Related requirements:** NIST.800-53.r5 SI-4(12), NIST.800-53.r5 SI-4(5)

**Category:** Detect > Detection services > Application monitoring

**Severity:** Low

**Resource type:** `AWS::CloudFormation::Stack`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/cloudformation-stack-notification-check.html](https://docs.aws.amazon.com/config/latest/developerguide/cloudformation-stack-notification-check.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether an Amazon Simple Notification Service notification is integrated with an CloudFormation stack. The control fails for a CloudFormation stack if no SNS notification is associated with it.

Configuring an SNS notification with your CloudFormation stack helps immediately notify stakeholders of any events or changes occurring with the stack.

### Remediation
<a name="cloudformation-1-remediation"></a>

To integrate a CloudFormation stack and an SNS topic, see [Updating stacks directly](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-updating-stacks-direct.html) in the *AWS CloudFormation User Guide*.

## [CloudFormation.2] CloudFormation stacks should be tagged
<a name="cloudformation-2"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::CloudFormation::Stack`

**AWS Config rule:** `tagged-cloudformation-stack` (custom Security Hub CSPM rule)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  | No default value  | 

This control checks whether an AWS CloudFormation stack has tags with the specific keys defined in the parameter `requiredTagKeys`. The control fails if the stack doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredTagKeys`. If the parameter `requiredTagKeys` isn't provided, the control only checks for the existence of a tag key and fails if the stack isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [What is ABAC for AWS?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Tagging your AWS resources](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *AWS General Reference*.

### Remediation
<a name="cloudformation-2-remediation"></a>

To add tags to a CloudFormation stack, see [CreateStack](https://docs.aws.amazon.com/AWSCloudFormation/latest/APIReference/API_CreateStack.html) in the *AWS CloudFormation API Reference*.

## [CloudFormation.3] CloudFormation stacks should have termination protection enabled
<a name="cloudformation-3"></a>

**Category:** Protect > Data Protection > Data deletion protection

**Severity:** Medium

**Resource type:** `AWS::CloudFormation::Stack`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/cloudformation-termination-protection-check.html](https://docs.aws.amazon.com/config/latest/developerguide/cloudformation-termination-protection-check.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether an AWS CloudFormation stack has termination protection enabled. The control fails if termination protection is not enabled on a CloudFormation stack.

CloudFormation helps to manage related resources as a single unit called a Stack. You can prevent a stack from being accidentally deleted by enabling termination protection on the stack. If a user attempts to delete a stack with termination protection enabled, the deletion fails and the stack, including its status, remains unchanged. You can set termination protection on a stack with any status except `DELETE_IN_PROGRESS` or `DELETE_COMPLETE`. 

**Note**  
Enabling or disabling termination protection on a stack passes the same choice on to any nested stacks belonging to that stack as well. You can't enable or disable termination protection directly on a nested stack. You can't directly delete a nested stack belonging with a stack that has termination protection enabled. If NESTED is displayed next to the stack name, the stack is a nested stack. You can only change termination protection on the root stack to which the nested stack belongs. 

### Remediation
<a name="cloudformation-3-remediation"></a>

To enable termination protection on a CloudFormation stack, see [Protect CloudFormation stacks from being deleted](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-protect-stacks.html) in the *AWS CloudFormation User Guide*.

## [CloudFormation.4] CloudFormation stacks should have associated service roles
<a name="cloudformation-4"></a>

**Category:** Detect > Secure access management

**Severity:** Medium

**Resource type:** `AWS::CloudFormation::Stack`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/cloudformation-stack-service-role-check.html](https://docs.aws.amazon.com/config/latest/developerguide/cloudformation-stack-service-role-check.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether an AWS CloudFormation stack has a service role associated with it. The control fails for a CloudFormation stack if no service role is associated with it.

Service-managed StackSets use execution roles through AWS Organizations trusted access integration. The control also generates a FAILED finding for an AWS CloudFormation stack created by service-managed StackSets because there is no service role associated with it. Due to how service-managed StackSets authenticate, the `roleARN` field cannot be populated for these stacks.

Using service roles with CloudFormation stacks helps implement least privilege access by separating permissions between the user who creates/updates stacks and the permissions needed by CloudFormation to create/update resources. This reduces the risk of privilege escalation and helps maintain security boundaries between different operational roles.

**Note**  
It is not possible to remove a service role attached to a stack after the stack is created. Other users that have permissions to perform operations on this stack are able to use this role, regardless of whether those users have the `iam:PassRole` permission or not. If the role includes permissions that the user shouldn't have, you can unintentionally escalate a user's permissions. Ensure that the role grants least privilege.

### Remediation
<a name="cloudformation-4-remediation"></a>

To associate a service role with a CloudFormation stack, see [CloudFormation service role](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-iam-servicerole.html) in the *AWS CloudFormation User Guide*.

# Security Hub CSPM controls for Amazon CloudFront
<a name="cloudfront-controls"></a>

These AWS Security Hub CSPM controls evaluate the Amazon CloudFront service and resources. The controls might not be available in all AWS Regions. For more information, see [Availability of controls by Region](securityhub-regions.md#securityhub-regions-control-support).

## [CloudFront.1] CloudFront distributions should have a default root object configured
<a name="cloudfront-1"></a>

**Related requirements:** NIST.800-53.r5 SC-7(11), NIST.800-53.r5 SC-7(16), PCI DSS v4.0.1/2.2.6

**Category:** Protect > Secure access management > Resources not publicly accessible

**Severity:** High

**Resource type:** `AWS::CloudFront::Distribution`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/cloudfront-default-root-object-configured.html](https://docs.aws.amazon.com/config/latest/developerguide/cloudfront-default-root-object-configured.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether an Amazon CloudFront distribution with S3 origins is configured to return a specific object that is the default root object. The control fails if the CloudFront distribution uses S3 origins and doesn't have a default root object configured. This control doesn't apply to CloudFront distributions that use custom origins.

A user might sometimes request the distribution's root URL instead of an object in the distribution. When this happens, specifying a default root object can help you to avoid exposing the contents of your web distribution.

### Remediation
<a name="cloudfront-1-remediation"></a>

To configure a default root object for a CloudFront distribution, see [How to specify a default root object](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/DefaultRootObject.html#DefaultRootObjectHowToDefine) in the *Amazon CloudFront Developer Guide*.

## [CloudFront.3] CloudFront distributions should require encryption in transit
<a name="cloudfront-3"></a>

**Related requirements:** NIST.800-53.r5 AC-17(2), NIST.800-53.r5 AC-4, NIST.800-53.r5 IA-5(1), NIST.800-53.r5 SC-12(3), NIST.800-53.r5 SC-13, NIST.800-53.r5 SC-23, NIST.800-53.r5 SC-23(3), NIST.800-53.r5 SC-7(4), NIST.800-53.r5 SC-8, NIST.800-53.r5 SC-8(1), NIST.800-53.r5 SC-8(2), NIST.800-53.r5 SI-7(6), PCI DSS v4.0.1/4.2.1

**Category:** Protect > Data Protection > Encryption of data-in-transit

**Severity:** Medium

**Resource type:** `AWS::CloudFront::Distribution`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/cloudfront-viewer-policy-https.html](https://docs.aws.amazon.com/config/latest/developerguide/cloudfront-viewer-policy-https.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether an Amazon CloudFront distribution requires viewers to use HTTPS directly or whether it uses redirection. The control fails if `ViewerProtocolPolicy` is set to `allow-all` for `defaultCacheBehavior` or for `cacheBehaviors`.

HTTPS (TLS) can be used to help prevent potential attackers from using person-in-the-middle or similar attacks to eavesdrop on or manipulate network traffic. Only encrypted connections over HTTPS (TLS) should be allowed. Encrypting data in transit can affect performance. You should test your application with this feature to understand the performance profile and the impact of TLS.

### Remediation
<a name="cloudfront-3-remediation"></a>

To encrypt a CloudFront distribution in transit, see [Requiring HTTPS for communication between viewers and CloudFront](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/using-https-viewers-to-cloudfront.html) in the *Amazon CloudFront Developer Guide*.

## [CloudFront.4] CloudFront distributions should have origin failover configured
<a name="cloudfront-4"></a>

**Related requirements:** NIST.800-53.r5 CP-10, NIST.800-53.r5 SC-36, NIST.800-53.r5 SC-5(2), NIST.800-53.r5 SI-13(5)

**Category:** Recover > Resilience > High availability

**Severity:** Low

**Resource type:** `AWS::CloudFront::Distribution`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/cloudfront-origin-failover-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/cloudfront-origin-failover-enabled.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether an Amazon CloudFront distribution is configured with an origin group that has two or more origins.

CloudFront origin failover can increase availability. Origin failover automatically redirects traffic to a secondary origin if the primary origin is unavailable or if it returns specific HTTP response status codes.

### Remediation
<a name="cloudfront-4-remediation"></a>

To configure origin failover for a CloudFront distribution, see [Creating an origin group](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/high_availability_origin_failover.html#concept_origin_groups.creating) in the *Amazon CloudFront Developer Guide*.

## [CloudFront.5] CloudFront distributions should have logging enabled
<a name="cloudfront-5"></a>

**Related requirements:** NIST.800-53.r5 AC-2(4), NIST.800-53.r5 AC-4(26), NIST.800-53.r5 AC-6(9), NIST.800-53.r5 AU-10, NIST.800-53.r5 AU-12, NIST.800-53.r5 AU-2, NIST.800-53.r5 AU-3, NIST.800-53.r5 AU-6(3), NIST.800-53.r5 AU-6(4), NIST.800-53.r5 CA-7, NIST.800-53.r5 SC-7(9), NIST.800-53.r5 SI-3(8), NIST.800-53.r5 SI-4(20), NIST.800-53.r5 SI-7(8), PCI DSS v4.0.1/10.4.2

**Category:** Identify > Logging

**Severity:** Medium

**Resource type:** `AWS::CloudFront::Distribution`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/cloudfront-accesslogs-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/cloudfront-accesslogs-enabled.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether server access logging is enabled on CloudFront distributions. The control fails if access logging is not enabled for a distribution. This control only evaluates whether standard logging (legacy) is enabled for a distribution.

CloudFront access logs provide detailed information about every user request that CloudFront receives. Each log contains information such as the date and time the request was received, the IP address of the viewer that made the request, the source of the request, and the port number of the request from the viewer. These logs are useful for applications such as security and access audits and forensics investigation. For more information about analyzing access logs, see [Query Amazon CloudFront logs](https://docs.aws.amazon.com/athena/latest/ug/cloudfront-logs.html) in the *Amazon Athena User Guide*.

### Remediation
<a name="cloudfront-5-remediation"></a>

To configure standard logging (legacy) for a CloudFront distribution, see [Configure standard logging (legacy)](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/standard-logging-legacy-s3.html) in the *Amazon CloudFront Developer Guide*.

## [CloudFront.6] CloudFront distributions should have WAF enabled
<a name="cloudfront-6"></a>

**Related requirements:** NIST.800-53.r5 AC-4(21), PCI DSS v4.0.1/6.4.2

**Category:** Protect > Protective services

**Severity:** Medium

**Resource type:** `AWS::CloudFront::Distribution`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/cloudfront-associated-with-waf.html](https://docs.aws.amazon.com/config/latest/developerguide/cloudfront-associated-with-waf.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether CloudFront distributions are associated with either AWS WAF Classic or AWS WAF web ACLs. The control fails if the distribution is not associated with a web ACL.

AWS WAF is a web application firewall that helps protect web applications and APIs from attacks. It allows you to configure a set of rules, called a web access control list (web ACL), that allow, block, or count web requests based on customizable web security rules and conditions that you define. Ensure your CloudFront distribution is associated with an AWS WAF web ACL to help protect it from malicious attacks.

### Remediation
<a name="cloudfront-6-remediation"></a>

To associate an AWS WAF web ACL with a CloudFront distribution, see [Using AWS WAF to control access to your content](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-web-awswaf.html) in the *Amazon CloudFront Developer Guide*.

## [CloudFront.7] CloudFront distributions should use custom SSL/TLS certificates
<a name="cloudfront-7"></a>

**Related requirements:** NIST.800-53.r5 AC-17(2), NIST.800-53.r5 AC-4, NIST.800-53.r5 IA-5(1), NIST.800-53.r5 SC-12(3), NIST.800-53.r5 SC-13, NIST.800-53.r5 SC-23, NIST.800-53.r5 SC-23(3), NIST.800-53.r5 SC-7(4), NIST.800-53.r5 SC-8, NIST.800-53.r5 SC-8(1), NIST.800-53.r5 SC-8(2), NIST.800-53.r5 SI-7(6), NIST.800-171.r2 3.13.15

**Category:** Protect > Data Protection > Encryption of data-in-transit

**Severity:** Low

**Resource type:** `AWS::CloudFront::Distribution`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/cloudfront-custom-ssl-certificate.html](https://docs.aws.amazon.com/config/latest/developerguide/cloudfront-custom-ssl-certificate.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether CloudFront distributions are using the default SSL/TLS certificate CloudFront provides. This control passes if the CloudFront distribution uses a custom SSL/TLS certificate. This control fails if the CloudFront distribution uses the default SSL/TLS certificate.

 Custom SSL/TLS allow your users to access content by using alternate domain names. You can store custom certificates in AWS Certificate Manager (recommended), or in IAM. 

### Remediation
<a name="cloudfront-7-remediation"></a>

To add an alternate domain name for a CloudFront distribution using a custom SSL/TLS certificate, see [Adding an alternate domain name](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/CNAMEs.html#CreatingCNAME) in the *Amazon CloudFront Developer Guide*.

## [CloudFront.8] CloudFront distributions should use SNI to serve HTTPS requests
<a name="cloudfront-8"></a>

**Related requirements:** NIST.800-53.r5 CA-9(1), NIST.800-53.r5 CM-2

**Category:** Protect > Secure network configuration

**Severity:** Low

**Resource type:** `AWS::CloudFront::Distribution`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/cloudfront-sni-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/cloudfront-sni-enabled.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks if Amazon CloudFront distributions are using a custom SSL/TLS certificate and are configured to use SNI to serve HTTPS requests. This control fails if a custom SSL/TLS certificate is associated but the SSL/TLS support method is a dedicated IP address.

Server Name Indication (SNI) is an extension to the TLS protocol that is supported by browsers and clients released after 2010. If you configure CloudFront to serve HTTPS requests using SNI, CloudFront associates your alternate domain name with an IP address for each edge location. When a viewer submits an HTTPS request for your content, DNS routes the request to the IP address for the correct edge location. The IP address to your domain name is determined during the SSL/TLS handshake negotiation; the IP address isn't dedicated to your distribution. 

### Remediation
<a name="cloudfront-8-remediation"></a>

To configure a CloudFront distribution to use SNI to serve HTTPS requests, see [Using SNI to Serve HTTPS Requests (works for Most Clients)](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/cnames-https-dedicated-ip-or-sni.html#cnames-https-sni) in the CloudFront Developer Guide. For information about custom SSL certificates, see [Requirements for using SSL/TLS certificates with CloudFront](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/cnames-and-https-requirements.html).

## [CloudFront.9] CloudFront distributions should encrypt traffic to custom origins
<a name="cloudfront-9"></a>

**Related requirements:** NIST.800-53.r5 AC-17(2), NIST.800-53.r5 AC-4, NIST.800-53.r5 IA-5(1), NIST.800-53.r5 SC-12(3), NIST.800-53.r5 SC-13, NIST.800-53.r5 SC-23, NIST.800-53.r5 SC-23(3), NIST.800-53.r5 SC-7(4), NIST.800-53.r5 SC-8, NIST.800-53.r5 SC-8(1), NIST.800-53.r5 SC-8(2), NIST.800-53.r5 SI-7(6), PCI DSS v4.0.1/4.2.1

**Category:** Protect > Data Protection > Encryption of data-in-transit

**Severity:** Medium

**Resource type:** `AWS::CloudFront::Distribution`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/cloudfront-traffic-to-origin-encrypted.html](https://docs.aws.amazon.com/config/latest/developerguide/cloudfront-traffic-to-origin-encrypted.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks if Amazon CloudFront distributions are encrypting traffic to custom origins. This control fails for a CloudFront distribution whose origin protocol policy allows 'http-only'. This control also fails if the distribution's origin protocol policy is 'match-viewer' while the viewer protocol policy is 'allow-all'.

HTTPS (TLS) can be used to help prevent eavesdropping or manipulation of network traffic. Only encrypted connections over HTTPS (TLS) should be allowed. 

### Remediation
<a name="cloudfront-9-remediation"></a>

To update the Origin Protocol Policy to require encryption for a CloudFront connection, see [Requiring HTTPS for communication between CloudFront and your custom origin](https://docs.aws.amazon.com//AmazonCloudFront/latest/DeveloperGuide/using-https-cloudfront-to-custom-origin.html) in the *Amazon CloudFront Developer Guide*.

## [CloudFront.10] CloudFront distributions should not use deprecated SSL protocols between edge locations and custom origins
<a name="cloudfront-10"></a>

**Related requirements:** NIST.800-53.r5 AC-17(2), NIST.800-53.r5 AC-4, NIST.800-53.r5 IA-5(1), NIST.800-53.r5 SC-12(3), NIST.800-53.r5 SC-13, NIST.800-53.r5 SC-23, NIST.800-53.r5 SC-7(4), NIST.800-53.r5 SC-8, NIST.800-53.r5 SC-8(1), NIST.800-53.r5 SC-8(2), NIST.800-53.r5 SI-7(6), NIST.800-171.r2 3.13.15, PCI DSS v4.0.1/4.2.1

**Category:** Protect > Data Protection > Encryption of data-in-transit

**Severity:** Medium

**Resource type:** `AWS::CloudFront::Distribution`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/cloudfront-no-deprecated-ssl-protocols.html](https://docs.aws.amazon.com/config/latest/developerguide/cloudfront-no-deprecated-ssl-protocols.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks if Amazon CloudFront distributions are using deprecated SSL protocols for HTTPS communication between CloudFront edge locations and your custom origins. This control fails if a CloudFront distribution has a `CustomOriginConfig` where `OriginSslProtocols` includes `SSLv3`.

In 2015, the Internet Engineering Task Force (IETF) officially announced that SSL 3.0 should be deprecated due to the protocol being insufficiently secure. It is recommended that you use TLSv1.2 or later for HTTPS communication to your custom origins. 

### Remediation
<a name="cloudfront-10-remediation"></a>

To update the Origin SSL Protocols for a CloudFront distribution, see [Requiring HTTPS for communication between CloudFront and your custom origin](https://docs.aws.amazon.com//AmazonCloudFront/latest/DeveloperGuide/using-https-cloudfront-to-custom-origin.html) in the *Amazon CloudFront Developer Guide*.

## [CloudFront.12] CloudFront distributions should not point to non-existent S3 origins
<a name="cloudfront-12"></a>

**Related requirements:** NIST.800-53.r5 CM-2, NIST.800-53.r5 CM-2(2), PCI DSS v4.0.1/2.2.6

**Category:** Identify > Resource configuration

**Severity:** High

**Resource type:** `AWS::CloudFront::Distribution`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/cloudfront-s3-origin-non-existent-bucket.html](https://docs.aws.amazon.com/config/latest/developerguide/cloudfront-s3-origin-non-existent-bucket.html)

**Schedule type:** Periodic

**Parameters:** None

This control checks whether Amazon CloudFront distributions are pointing to non-existent Amazon S3 origins. The control fails for a CloudFront distribution if the origin is configured to point to a non-existent bucket. This control only applies to CloudFront distributions where an S3 bucket without static website hosting is the S3 origin.

When a CloudFront distribution in your account is configured to point to a non-existent bucket, a malicious third party can create the referenced bucket and serve their own content through your distribution. We recommend checking all origins regardless of routing behavior to ensure that your distributions are pointing to appropriate origins. 

### Remediation
<a name="cloudfront-12-remediation"></a>

To modify a CloudFront distribution to point to a new origin, see [Updating a distribution](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/HowToUpdateDistribution.html) in the *Amazon CloudFront Developer Guide*.

## [CloudFront.13] CloudFront distributions should use origin access control
<a name="cloudfront-13"></a>

**Category:** Protect > Secure access management > Resource not publicly accessible

**Severity:** Medium

**Resource type:** `AWS::CloudFront::Distribution`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/cloudfront-s3-origin-access-control-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/cloudfront-s3-origin-access-control-enabled.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether an Amazon CloudFront distribution with an Amazon S3 origin has origin access control (OAC) configured. The control fails if OAC isn't configured for the CloudFront distribution.

When using an S3 bucket as an origin for your CloudFront distribution, you can enable OAC. This permits access to the content in the bucket only through the specified CloudFront distribution, and prohibits access directly from the bucket or another distribution. Although CloudFront supports Origin Access Identity (OAI), OAC offers additional functionality, and distributions using OAI can migrate to OAC. While OAI provides a secure way to access S3 origins, it has limitations, such as lack of support for granular policy configurations and for HTTP/HTTPS requests that use the POST method in AWS Regions that require AWS Signature Version 4 (SigV4). OAI also doesn't support encryption with AWS Key Management Service. OAC is based on an AWS best practice of using IAM service principals to authenticate with S3 origins. 

### Remediation
<a name="cloudfront-13-remediation"></a>

To configure OAC for a CloudFront distribution with S3 origins, see [ Restricting access to an Amazon S3 origin](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-restricting-access-to-s3.html) in the *Amazon CloudFront Developer Guide*.

## [CloudFront.14] CloudFront distributions should be tagged
<a name="cloudfront-14"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::CloudFront::Distribution`

**AWS Config rule:**`tagged-cloudfront-distribution` (custom Security Hub CSPM rule)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  | No default value  | 

This control checks whether an Amazon CloudFront distribution has tags with the specific keys defined in the parameter `requiredTagKeys`. The control fails if the distribution doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredTagKeys`. If the parameter `requiredTagKeys` isn't provided, the control only checks for the existence of a tag key and fails if the distribution isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [What is ABAC for AWS?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Tagging your AWS resources](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *AWS General Reference*.

### Remediation
<a name="cloudfront-14-remediation"></a>

To add tags to a CloudFront distribution, see [Tagging Amazon CloudFront distributions](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/tagging.html) in the *Amazon CloudFront Developer Guide*.

## [CloudFront.15] CloudFront distributions should use the recommended TLS security policy
<a name="cloudfront-15"></a>

**Category:** Protect > Data Protection > Encryption of data-in-transit

**Severity:** Medium

**Resource type:** `AWS::CloudFront::Distribution`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/cloudfront-ssl-policy-check.html](https://docs.aws.amazon.com/config/latest/developerguide/cloudfront-ssl-policy-check.html)

**Schedule type:** Change triggered

**Parameters:** `securityPolicies`: `TLSv1.2_2021,TLSv1.2_2025,TLSv1.3_2025` (not customizable)

This control checks whether an Amazon CloudFront distribution is configured to use a recommended TLS security policy. The control fails if the CloudFront distribution is not configured to use a recommended TLS security policy.

If you configure an Amazon CloudFront distribution to require viewers to use HTTPS to access content, you have to choose a security policy and specify the minimum SSL/TLS protocol version to use. This determines which protocol version CloudFront uses to communicate with viewers, and the ciphers that CloudFront uses to encrypt the communications. We recommend using the latest security policy that CloudFront provides. This ensures that CloudFront uses the latest cipher suites to encrypt data in transit between a viewer and a CloudFront distribution.

**Note**  
This control generates findings only for CloudFront distributions that are configured to use custom SSL certificates and are not configured to support legacy clients.

### Remediation
<a name="cloudfront-15-remediation"></a>

For information about configuring the security policy for a CloudFront distribution, see [Update a distribution](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/HowToUpdateDistribution.html) in the *Amazon CloudFront Developer Guide*. When you configure the security policy for a distribution, choose the latest security policy.

## [CloudFront.16] CloudFront distributions should use origin access control for Lambda function URL origins
<a name="cloudfront-16"></a>

**Category:** Protect > Secure access management > Access control

**Severity:** Medium

**Resource type:** `AWS::CloudFront::Distribution`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/cloudfront-origin-lambda-url-oac-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/cloudfront-origin-lambda-url-oac-enabled.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether an Amazon CloudFront distribution with an AWS Lambda function URL as an origin has origin access control (OAC) enabled. The control fails if the CloudFront distribution has a Lambda function URL as an origin and OAC isn't enabled.

An AWS Lambda function URL is a dedicated HTTPS endpoint for a Lambda function. If a Lambda function URL is the origin for a CloudFront distribution, the function URL must be publicly accessible. Therefore, as a security best practice, you should create an OAC and add it to the Lambda function URL in a distribution. OAC uses IAM service principals to authenticate requests between CloudFront and the function URL. It also supports the use of resource-based policies to allow invocation of a function only if a request is on behalf of a CloudFront distribution specified in the policy.

### Remediation
<a name="cloudfront-16-remediation"></a>

For information about configuring OAC for an Amazon CloudFront distribution that uses a Lambda function URL as an origin, see [Restrict access to an AWS Lambda function URL origin](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-restricting-access-to-lambda.html) in the *Amazon CloudFront Developer Guide*.

## [CloudFront.17] CloudFront distributions should use trusted key groups for signed URLs and cookies
<a name="cloudfront-17"></a>

**Category:** Protect > Secure access management > Access control

**Severity:** Medium

**Resource type:** `AWS::CloudFront::Distribution`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/cloudfront-distribution-key-group-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/cloudfront-distribution-key-group-enabled.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether an Amazon CloudFront distribution is configured to use trusted key groups for signed URL or signed cookie authentication. The control fails if the CloudFront distribution uses trusted signers, or if the distribution has no authentication configured.

To use signed URLs or signed cookies, you need a signer. A signer is either a trusted key group that you create in CloudFront, or an AWS account that contains a CloudFront key pair. We recommend that you use trusted key groups because with CloudFront key groups, you don't need to use the AWS account root user to manage the public keys for CloudFront signed URLs and signed cookies.

**Note**  
This control does not evaluate multi-tenant CloudFront distributions `(connectionMode=tenant-only)`.

### Remediation
<a name="cloudfront-17-remediation"></a>

For information about using trusted key groups with signed URLs and cookies, see [Using trusted key groups](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/PrivateContent.html) in the *Amazon CloudFront Developer Guide*.

# Security Hub CSPM controls for AWS CloudTrail
<a name="cloudtrail-controls"></a>

These AWS Security Hub CSPM controls evaluate the AWS CloudTrail service and resources. The controls might not be available in all AWS Regions. For more information, see [Availability of controls by Region](securityhub-regions.md#securityhub-regions-control-support).

## [CloudTrail.1] CloudTrail should be enabled and configured with at least one multi-Region trail that includes read and write management events
<a name="cloudtrail-1"></a>

**Related requirements:** CIS AWS Foundations Benchmark v5.0.0/3.1, CIS AWS Foundations Benchmark v1.2.0/2.1, CIS AWS Foundations Benchmark v1.4.0/3.1, CIS AWS Foundations Benchmark v3.0.0/3.1, NIST.800-53.r5 AC-2(4), NIST.800-53.r5 AC-4(26), NIST.800-53.r5 AC-6(9), NIST.800-53.r5 AU-10, NIST.800-53.r5 AU-12, NIST.800-53.r5 AU-2, NIST.800-53.r5 AU-3, NIST.800-53.r5 AU-6(3), NIST.800-53.r5 AU-6(4), NIST.800-53.r5 AU-14(1), NIST.800-53.r5 CA-7, NIST.800-53.r5 SC-7(9), NIST.800-53.r5 SI-3(8), NIST.800-53.r5 SI-4(20), NIST.800-53.r5 SI-7(8), NIST.800-53.r5 SA-8(22)

**Category:** Identify > Logging

**Severity:** High

**Resource type:** `AWS::::Account`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/multi-region-cloudtrail-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/multi-region-cloudtrail-enabled.html)

**Schedule type:** Periodic

**Parameters:**
+ `readWriteType`: `ALL` (not customizable)

  `includeManagementEvents`: `true` (not customizable)

This control checks whether there is at least one multi-Region AWS CloudTrail trail that captures read and write management events. The control fails if CloudTrail is disabled or if there isn't at least one CloudTrail trail that captures read and write management events.

AWS CloudTrail records AWS API calls for your account and delivers log files to you. The recorded information includes the following information:
+ Identity of the API caller
+ Time of the API call
+ Source IP address of the API caller
+ Request parameters
+ Response elements returned by the AWS service

CloudTrail provides a history of AWS API calls for an account, including API calls made from the AWS Management Console, AWS SDKs, command line tools. The history also includes API calls from higher-level AWS services such as AWS CloudFormation.

The AWS API call history produced by CloudTrail enables security analysis, resource change tracking, and compliance auditing. Multi-Region trails also provide the following benefits.
+ A multi-Region trail helps to detect unexpected activity occurring in otherwise unused Regions.
+ A multi-Region trail ensures that global service event logging is enabled for a trail by default. Global service event logging records events generated by AWS global services.
+ For a multi-Region trail, management events for all read and write operations ensure that CloudTrail records management operations on all resources in an AWS account.

By default, CloudTrail trails that are created using the AWS Management Console are multi-Region trails.

### Remediation
<a name="cloudtrail-1-remediation"></a>

To create a new multi-Region trail in CloudTrail, see [Creating a trail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-a-trail-using-the-console-first-time.html) in the *AWS CloudTrail User Guide*. Use the following values:


| Field | Value | 
| --- | --- | 
|  Additional settings, Log file validation  |  Enabled  | 
|  Choose log events, Management events, API activity  |  **Read** and **Write**. Clear check boxes for exclusions.  | 

To update an existing trail, see [Updating a trail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-update-a-trail-console.html) in the *AWS CloudTrail User Guide*. In **Management events**, for **API activity**, choose **Read** and **Write**.

## [CloudTrail.2] CloudTrail should have encryption at-rest enabled
<a name="cloudtrail-2"></a>

**Related requirements:** CIS AWS Foundations Benchmark v5.0.0/3.5, CIS AWS Foundations Benchmark v1.2.0/2.7, CIS AWS Foundations Benchmark v1.4.0/3.7, CIS AWS Foundations Benchmark v3.0.0/3.5, NIST.800-53.r5 AU-9, NIST.800-53.r5 CA-9(1), NIST.800-53.r5 CM-3(6), NIST.800-53.r5 SC-13, NIST.800-53.r5 SC-28, NIST.800-53.r5 SC-28(1), NIST.800-53.r5 SC-7(10), NIST.800-53.r5 SI-7(6), NIST.800-171.r2 3.3.8, PCI DSS v3.2.1/3.4, PCI DSS v4.0.1/10.3.2

**Category:** Protect > Data Protection > Encryption of data-at-rest

**Severity:** Medium

**Resource type:** `AWS::CloudTrail::Trail`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/cloud-trail-encryption-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/cloud-trail-encryption-enabled.html)

**Schedule type:** Periodic

**Parameters:** None

This control checks whether CloudTrail is configured to use the server-side encryption (SSE) AWS KMS key encryption. The control fails if the `KmsKeyId` isn't defined.

For an added layer of security for your sensitive CloudTrail log files, you should use [server-side encryption with AWS KMS keys (SSE-KMS)](https://docs.aws.amazon.com/AmazonS3/latest/dev/UsingKMSEncryption.html) for your CloudTrail log files for encryption at rest. Note that by default, the log files delivered by CloudTrail to your buckets are encrypted by [Amazon server-side encryption with Amazon S3-managed encryption keys (SSE-S3)](https://docs.aws.amazon.com/AmazonS3/latest/dev/UsingServerSideEncryption.html). 

### Remediation
<a name="cloudtrail-2-remediation"></a>

To enable SSE-KMS encryption for CloudTrail log files, see [Update a trail to use a KMS key](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/create-kms-key-policy-for-cloudtrail-update-trail.html#kms-key-policy-update-trail) in the *AWS CloudTrail User Guide*.

## [CloudTrail.3] At least one CloudTrail trail should be enabled
<a name="cloudtrail-3"></a>

**Related requirements:** NIST.800-171.r2 3.3.1, NIST.800-171.r2 3.14.6, NIST.800-171.r2 3.14.7, PCI DSS v3.2.1/10.1, PCI DSS v3.2.1/10.2.1, PCI DSS v3.2.1/10.2.2, PCI DSS v3.2.1/10.2.3, PCI DSS v3.2.1/10.2.4, PCI DSS v3.2.1/10.2.5, PCI DSS v3.2.1/10.2.6, PCI DSS v3.2.1/10.2.7, PCI DSS v3.2.1/10.3.1, PCI DSS v3.2.1/10.3.2, PCI DSS v3.2.1/10.3.3, PCI DSS v3.2.1/10.3.4, PCI DSS v3.2.1/10.3.5, PCI DSS v3.2.1/10.3.6, PCI DSS v4.0.1/10.2.1

**Category:** Identify > Logging

**Severity:** High

**Resource type:** `AWS::::Account`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/cloudtrail-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/cloudtrail-enabled.html)

**Schedule type:** Periodic

**Parameters:** None

This control checks whether an AWS CloudTrail trail is enabled in your AWS account. The control fails if your account doesn't have at least one CloudTrail trail enabled.

However, some AWS services do not enable logging of all APIs and events. You should implement any additional audit trails other than CloudTrail and review the documentation for each service in [CloudTrail Supported Services and Integrations](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-aws-service-specific-topics.html).

### Remediation
<a name="cloudtrail-3-remediation"></a>

To get started with CloudTrail and create a trail, see the [Getting started with AWS CloudTrail tutorial](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-tutorial.html) in the *AWS CloudTrail User Guide*.

## [CloudTrail.4] CloudTrail log file validation should be enabled
<a name="cloudtrail-4"></a>

**Related requirements:** CIS AWS Foundations Benchmark v5.0.0/3.2, CIS AWS Foundations Benchmark v1.2.0/2.2, CIS AWS Foundations Benchmark v1.4.0/3.2, CIS AWS Foundations Benchmark v3.0.0/3.2, NIST.800-53.r5 AU-9, NIST.800-53.r5 SI-4, NIST.800-53.r5 SI-7(1), NIST.800-53.r5 SI-7(3), NIST.800-53.r5 SI-7(7), NIST.800-171.r2 3.3.8, PCI DSS v3.2.1/10.5.2, PCI DSS v3.2.1/10.5.5, PCI DSS v4.0.1/10.3.2

**Category:** Data protection > Data integrity

**Severity:** Low

**Resource type:** `AWS::CloudTrail::Trail`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/cloud-trail-log-file-validation-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/cloud-trail-log-file-validation-enabled.html)

**Schedule type:** Periodic

**Parameters:** None

This control checks whether log file integrity validation is enabled on a CloudTrail trail.

CloudTrail log file validation creates a digitally signed digest file that contains a hash of each log that CloudTrail writes to Amazon S3. You can use these digest files to determine whether a log file was changed, deleted, or unchanged after CloudTrail delivered the log.

Security Hub CSPM recommends that you enable file validation on all trails. Log file validation provides additional integrity checks of CloudTrail logs.

### Remediation
<a name="cloudtrail-4-remediation"></a>

To enable CloudTrail log file validation, see [Enabling log file integrity validation for CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-log-file-validation-enabling.html) in the *AWS CloudTrail User Guide*.

## [CloudTrail.5] CloudTrail trails should be integrated with Amazon CloudWatch Logs
<a name="cloudtrail-5"></a>

**Related requirements:** CIS AWS Foundations Benchmark v5.0.0/3.4, PCI DSS v3.2.1/10.5.3, CIS AWS Foundations Benchmark v1.2.0/2.4, CIS AWS Foundations Benchmark v1.4.0/3.4, NIST.800-53.r5 AC-2(4), NIST.800-53.r5 AC-4(26), NIST.800-53.r5 AC-6(9), NIST.800-53.r5 AU-10, NIST.800-53.r5 AU-12, NIST.800-53.r5 AU-2, NIST.800-53.r5 AU-3, NIST.800-53.r5 AU-6(1), NIST.800-53.r5 AU-6(3), NIST.800-53.r5 AU-6(4), NIST.800-53.r5 AU-6(5), NIST.800-53.r5 AU-7(1), NIST.800-53.r5 CA-7, NIST.800-53.r5 SC-7(9), NIST.800-53.r5 SI-20, NIST.800-53.r5 SI-3(8), NIST.800-53.r5 SI-4(20), NIST.800-53.r5 SI-4(5), NIST.800-53.r5 SI-7(8)

**Category:** Identify > Logging

**Severity:** Medium

**Resource type:** `AWS::CloudTrail::Trail`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/cloud-trail-cloud-watch-logs-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/cloud-trail-cloud-watch-logs-enabled.html)

**Schedule type:** Periodic

**Parameters:** None

This control checks whether CloudTrail trails are configured to send logs to CloudWatch Logs. The control fails if the `CloudWatchLogsLogGroupArn` property of the trail is empty.

CloudTrail records AWS API calls that are made in a given account. The recorded information includes the following:
+ The identity of the API caller
+ The time of the API call
+ The source IP address of the API caller
+ The request parameters
+ The response elements returned by the AWS service

CloudTrail uses Amazon S3 for log file storage and delivery. You can capture CloudTrail logs in a specified S3 bucket for long-term analysis. To perform real-time analysis, you can configure CloudTrail to send logs to CloudWatch Logs.

For a trail that is enabled in all Regions in an account, CloudTrail sends log files from all of those Regions to a CloudWatch Logs log group.

Security Hub CSPM recommends that you send CloudTrail logs to CloudWatch Logs. Note that this recommendation is intended to ensure that account activity is captured, monitored, and appropriately alarmed on. You can use CloudWatch Logs to set this up with your AWS services. This recommendation does not preclude the use of a different solution.

Sending CloudTrail logs to CloudWatch Logs facilitates real-time and historic activity logging based on user, API, resource, and IP address. You can use this approach to establish alarms and notifications for anomalous or sensitivity account activity.

### Remediation
<a name="cloudtrail-5-remediation"></a>

To integrate CloudTrail with CloudWatch Logs, see [Sending events to CloudWatch Logs](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/send-cloudtrail-events-to-cloudwatch-logs.html) in the *AWS CloudTrail User Guide*.

## [CloudTrail.6] Ensure the S3 bucket used to store CloudTrail logs is not publicly accessible
<a name="cloudtrail-6"></a>

**Related requirements:** CIS AWS Foundations Benchmark v1.2.0/2.3, CIS AWS Foundations Benchmark v1.4.0/3.3, PCI DSS v4.0.1/1.4.4

**Category:** Identify > Logging

**Severity:** Critical

**Resource type:** `AWS::S3::Bucket`

**AWS Config rule:** None (custom Security Hub CSPM rule)

**Schedule type:** Periodic and change triggered

**Parameters:** None

CloudTrail logs a record of every API call made in your account. These log files are stored in an S3 bucket. CIS recommends that the S3 bucket policy, or access control list (ACL), applied to the S3 bucket that CloudTrail logs to prevents public access to the CloudTrail logs. Allowing public access to CloudTrail log content might aid an adversary in identifying weaknesses in the affected account's use or configuration.

To run this check, Security Hub CSPM first uses custom logic to look for the S3 bucket where your CloudTrail logs are stored. It then uses the AWS Config managed rules to check that bucket is publicly accessible.

If you aggregate your logs into a single centralized S3 bucket, then Security Hub CSPM only runs the check against the account and Region where the centralized S3 bucket is located. For other accounts and Regions, the control status is **No data**.

If the bucket is publicly accessible, the check generates a failed finding.

### Remediation
<a name="cloudtrail-6-remediation"></a>

To block public access to your CloudTrail S3 bucket, see [Configuring block public access settings for your S3 buckets](https://docs.aws.amazon.com/AmazonS3/latest/userguide/configuring-block-public-access-bucket.html) in the *Amazon Simple Storage Service User Guide*. Select all four Amazon S3 Block Public Access Settings.

## [CloudTrail.7] Ensure S3 bucket access logging is enabled on the CloudTrail S3 bucket
<a name="cloudtrail-7"></a>

**Related requirements:** CIS AWS Foundations Benchmark v1.2.0/2.6, CIS AWS Foundations Benchmark v1.4.0/3.6, CIS AWS Foundations Benchmark v3.0.0/3.4, PCI DSS v4.0.1/10.2.1

**Category:** Identify > Logging

**Severity:** Low

**Resource type:** `AWS::S3::Bucket`

**AWS Config rule:** None (custom Security Hub CSPM rule)

**Schedule type:** Periodic

**Parameters:** None

S3 bucket access logging generates a log that contains access records for each request made to your S3 bucket. An access log record contains details about the request, such as the request type, the resources specified in the request worked, and the time and date the request was processed.

CIS recommends that you enable bucket access logging on the CloudTrail S3 bucket.

By enabling S3 bucket logging on target S3 buckets, you can capture all events that might affect objects in a target bucket. Configuring logs to be placed in a separate bucket enables access to log information, which can be useful in security and incident response workflows.

To run this check, Security Hub CSPM first uses custom logic to look for the bucket where your CloudTrail logs are stored and then uses the AWS Config managed rule to check if logging is enabled.

If CloudTrail delivers log files from multiple AWS accounts into a single destination Amazon S3 bucket, Security Hub CSPM evaluates this control only against the destination bucket in the Region where it's located. This streamlines your findings. However, you should turn on CloudTrail in all accounts that deliver logs to the destination bucket. For all accounts except the one that holds the destination bucket, the control status is **No data**.

### Remediation
<a name="cloudtrail-7-remediation"></a>

To enable server access logging for your CloudTrail S3 bucket, see [Enabling Amazon S3 server access logging](https://docs.aws.amazon.com/AmazonS3/latest/userguide/enable-server-access-logging.html#enable-server-logging) in the *Amazon Simple Storage Service User Guide*.

## [CloudTrail.9] CloudTrail trails should be tagged
<a name="cloudtrail-9"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::CloudTrail::Trail`

**AWS Config rule:** `tagged-cloudtrail-trail` (custom Security Hub CSPM rule)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  |  No default value  | 

This control checks whether an AWS CloudTrail trail has tags with the specific keys defined in the parameter `requiredTagKeys`. The control fails if the trail doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredTagKeys`. If the parameter `requiredTagKeys` isn't provided, the control only checks for the existence of a tag key and fails if the trail isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [What is ABAC for AWS?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Tagging your AWS resources](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *AWS General Reference*.

### Remediation
<a name="cloudtrail-9-remediation"></a>

To add tags to a CloudTrail trail, see [AddTags](https://docs.aws.amazon.com/awscloudtrail/latest/APIReference/API_AddTags.html) in the *AWS CloudTrail API Reference*.

## [CloudTrail.10] CloudTrail Lake event data stores should be encrypted with customer managed AWS KMS keys
<a name="cloudtrail-10"></a>

**Related requirements:** NIST.800-53.r5 AU-9, NIST.800-53.r5 CA-9(1), NIST.800-53.r5 CM-3(6), NIST.800-53.r5 SC-7(10), NIST.800-53.r5 SC-12(2), NIST.800-53.r5 SC-13, NIST.800-53.r5 SC-28, NIST.800-53.r5 SC-28(1), NIST.800-53.r5 SI-7(6)

**Category:** Protect > Data Protection > Encryption of data-at-rest

**Severity:** Medium

**Resource type:** `AWS::CloudTrail::EventDataStore`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/event-data-store-cmk-encryption-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/event-data-store-cmk-encryption-enabled.html)

**Schedule type:** Periodic

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  `kmsKeyArns`  |  A list of Amazon Resource Names (ARNs) of AWS KMS keys to include in the evaluation. The control generates a `FAILED` finding if an event data store isn't encrypted with a KMS key in the list.  |  StringList (maximum of 3 items)  |  1–3 ARNs of existing KMS keys. For example: `arn:aws:kms:us-west-2:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab`.  |  No default value  | 

This control checks whether an AWS CloudTrail Lake event data store is encrypted at rest with a customer managed AWS KMS key. The control fails if the event data store isn't encrypted with a customer managed KMS key. You can optionally specify a list of KMS keys for the control to include in the evaluation.

By default, AWS CloudTrail Lake encrypts event data stores with Amazon S3 managed keys (SSE-S3), using an AES-256 algorithm. For additional control, you can configure CloudTrail Lake to encrypt an event data store with a customer managed AWS KMS key (SSE-KMS) instead. A customer managed KMS key is an AWS KMS key that you create, own, and manage in your AWS account. You have full control over this type of KMS key. This includes defining and maintaining the key policy, managing grants, rotating cryptographic material, assigning tags, creating aliases, and enabling and disabling the key. You can use a customer managed KMS key in cryptographic operations for your CloudTrail data and audit usage with CloudTrail logs.

### Remediation
<a name="cloudtrail-10-remediation"></a>

For information about encrypting an AWS CloudTrail Lake event data store with an AWS KMS key that you specify, see [Update an event data store](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/query-event-data-store-update.html) in the *AWS CloudTrail User Guide*. After you associate an event data store with a KMS key, the KMS key can't be removed or changed.

# Security Hub CSPM controls for Amazon CloudWatch
<a name="cloudwatch-controls"></a>

These AWS Security Hub CSPM controls evaluate the Amazon CloudWatch service and resources. The controls might not be available in all AWS Regions. For more information, see [Availability of controls by Region](securityhub-regions.md#securityhub-regions-control-support).

## [CloudWatch.1] A log metric filter and alarm should exist for usage of the "root" user
<a name="cloudwatch-1"></a>

**Related requirements:** CIS AWS Foundations Benchmark v1.2.0/1.1,CIS AWS Foundations Benchmark v1.2.0/3.3, CIS AWS Foundations Benchmark v1.4.0/1.7,CIS AWS Foundations Benchmark v1.4.0/4.3, NIST.800-171.r2 3.14.6, NIST.800-171.r2 3.14.7, PCI DSS v3.2.1/7.2.1

**Category:** Detect > Detection services

**Severity:** Low

**Resource type:** `AWS::Logs::MetricFilter`, `AWS::CloudWatch::Alarm`, `AWS::CloudTrail::Trail`, `AWS::SNS::Topic`

**AWS Config rule:** None (custom Security Hub CSPM rule)

**Schedule type:** Periodic

**Parameters:** None

The root user has unrestricted access to all services and resources in an AWS account. We highly recommend that you avoid using the root user for daily tasks. Minimizing the use of the root user and adopting the principle of least privilege for access management reduces the risk of accidental changes and unintended disclosure of highly privileged credentials.

As a best practice, use your root user credentials only when required to [ perform account and service management tasks](https://docs.aws.amazon.com/general/latest/gr/aws_tasks-that-require-root.html). Apply AWS Identity and Access Management (IAM) policies directly to groups and roles but not users. For a tutorial on how to set up an administrator for daily use, see [ Creating your first IAM admin user and group](https://docs.aws.amazon.com/IAM/latest/UserGuide/getting-started_create-admin-group.html) in the *IAM User Guide*

To run this check, Security Hub CSPM uses custom logic to perform the exact audit steps prescribed for control 1.7 in the [CIS AWS Foundations Benchmark v1.4.0](https://acrobat.adobe.com/link/track?uri=urn:aaid:scds:US:2e5fec5c-5e99-4fb5-b08d-bb46b14754c1#pageNum=1). This control fails if the exact metric filters prescribed by CIS are not used. Additional fields or terms cannot be added to the metric filters.

**Note**  
When Security Hub CSPM performs the check for this control, it looks for CloudTrail trails that the current account uses. These trails might be organization trails that belong to another account. Multi-Region trails also might be based in a different Region.  
The check results in `FAILED` findings in the following cases:  
No trail is configured.
The available trails that are in the current Region and that are owned by current account do not meet the control requirements.
The check results in a control status of `NO_DATA` in the following cases:  
A multi-Region trail is based in a different Region. Security Hub CSPM can only generate findings in the Region where the trail is based.
A multi-Region trail belongs to a different account. Security Hub CSPM can only generate findings for the account that owns the trail.  
We recommend organization trails to log events from many accounts in an organization. Organization trails are multi-Region trails by default and can only be managed by the AWS Organizations management account or the CloudTrail delegated administrator account. Using an organization trail results in a control status of `NO_DATA` for controls evaluated in organization member accounts. In member accounts, Security Hub CSPM only generates findings for member-owned resources. Findings that pertain to organization trails are generated in the resource owner's account. You can see these findings in your Security Hub CSPM delegated administrator account by using cross-Region aggregation.
For the alarm, the current account must either own the referenced Amazon SNS topic, or must get access to the Amazon SNS topic by calling `ListSubscriptionsByTopic`. Otherwise Security Hub CSPM generates `WARNING` findings for the control.

### Remediation
<a name="cloudwatch-1-remediation"></a>

To pass this control, follow these steps to create an Amazon SNS topic, an AWS CloudTrail trail, a metric filter, and an alarm for the metric filter.

1. Create an Amazon SNS topic. For instructions, see [Getting started with Amazon SNS](https://docs.aws.amazon.com/sns/latest/dg/sns-getting-started.html#CreateTopic) in the *Amazon Simple Notification Service Developer Guide*. Create a topic that receives all CIS alarms, and create at least one subscription to the topic.

1. Create a CloudTrail trail that applies to all AWS Regions. For instructions, see [Creating a trail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-a-trail-using-the-console-first-time.html) in the *AWS CloudTrail User Guide*.

   Make note of the name of the CloudWatch Logs log group that you associate with the CloudTrail trail. You create the metric filter for that log group in the next step.

1. Create a metric filter. For instructions, see [Create a metric filter for a log group](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CreateMetricFilterProcedure.html) in the *Amazon CloudWatch User Guide*. Use the following values:    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/securityhub/latest/userguide/cloudwatch-controls.html)

1. Create an alarm based on the filter. For instructions, see [Create a CloudWatch alarm based on a log group-metric filter](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Alarm-On-Logs.html) in the *Amazon CloudWatch User Guide*. Use the following values:    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/securityhub/latest/userguide/cloudwatch-controls.html)

## [CloudWatch.2] Ensure a log metric filter and alarm exist for unauthorized API calls
<a name="cloudwatch-2"></a>

**Related requirements:** CIS AWS Foundations Benchmark v1.2.0/3.1, NIST.800-171.r2 3.13.1, NIST.800-171.r2 3.14.6, NIST.800-171.r2 3.14.7

**Category:** Detect > Detection services

**Severity:** Low

**Resource type:** `AWS::Logs::MetricFilter`, `AWS::CloudWatch::Alarm`, `AWS::CloudTrail::Trail`, `AWS::SNS::Topic`

**AWS Config rule:** None (custom Security Hub CSPM rule)

**Schedule type:** Periodic

**Parameters:** None

You can do real-time monitoring of API calls by directing CloudTrail logs to CloudWatch Logs and establishing corresponding metric filters and alarms.

CIS recommends that you create a metric filter and alarm for unauthorized API calls. Monitoring unauthorized API calls helps reveal application errors and might reduce time to detect malicious activity.

To run this check, Security Hub CSPM uses custom logic to perform the exact audit steps prescribed for control 3.1 in the [CIS AWS Foundations Benchmark v1.2](https://d1.awsstatic.com/whitepapers/compliance/AWS_CIS_Foundations_Benchmark.pdf). This control fails if the exact metric filters prescribed by CIS are not used. Additional fields or terms cannot be added to the metric filters.

**Note**  
When Security Hub CSPM performs the check for this control, it looks for CloudTrail trails that the current account uses. These trails might be organization trails that belong to another account. Multi-Region trails also might be based in a different Region.  
The check results in `FAILED` findings in the following cases:  
No trail is configured.
The available trails that are in the current Region and that are owned by current account do not meet the control requirements.
The check results in a control status of `NO_DATA` in the following cases:  
A multi-Region trail is based in a different Region. Security Hub CSPM can only generate findings in the Region where the trail is based.
A multi-Region trail belongs to a different account. Security Hub CSPM can only generate findings for the account that owns the trail.  
We recommend organization trails to log events from many accounts in an organization. Organization trails are multi-Region trails by default and can only be managed by the AWS Organizations management account or the CloudTrail delegated administrator account. Using an organization trail results in a control status of `NO_DATA` for controls evaluated in organization member accounts. In member accounts, Security Hub CSPM only generates findings for member-owned resources. Findings that pertain to organization trails are generated in the resource owner's account. You can see these findings in your Security Hub CSPM delegated administrator account by using cross-Region aggregation.
For the alarm, the current account must either own the referenced Amazon SNS topic, or must get access to the Amazon SNS topic by calling `ListSubscriptionsByTopic`. Otherwise Security Hub CSPM generates `WARNING` findings for the control.

### Remediation
<a name="cloudwatch-2-remediation"></a>

To pass this control, follow these steps to create an Amazon SNS topic, an AWS CloudTrail trail, a metric filter, and an alarm for the metric filter.

1. Create an Amazon SNS topic. For instructions, see [Getting started with Amazon SNS](https://docs.aws.amazon.com/sns/latest/dg/sns-getting-started.html#CreateTopic) in the *Amazon Simple Notification Service Developer Guide*. Create a topic that receives all CIS alarms, and create at least one subscription to the topic.

1. Create a CloudTrail trail that applies to all AWS Regions. For instructions, see [Creating a trail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-a-trail-using-the-console-first-time.html) in the *AWS CloudTrail User Guide*.

   Make note of the name of the CloudWatch Logs log group that you associate with the CloudTrail trail. You create the metric filter for that log group in the next step.

1. Create a metric filter. For instructions, see [Create a metric filter for a log group](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CreateMetricFilterProcedure.html) in the *Amazon CloudWatch User Guide*. Use the following values:    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/securityhub/latest/userguide/cloudwatch-controls.html)

1. Create an alarm based on the filter. For instructions, see [Create a CloudWatch alarm based on a log group-metric filter](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Alarm-On-Logs.html) in the *Amazon CloudWatch User Guide*. Use the following values:    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/securityhub/latest/userguide/cloudwatch-controls.html)

## [CloudWatch.3] Ensure a log metric filter and alarm exist for Management Console sign-in without MFA
<a name="cloudwatch-3"></a>

**Related requirements:** CIS AWS Foundations Benchmark v1.2.0/3.2

**Category:** Detect > Detection services

**Severity:** Low

**Resource type:** `AWS::Logs::MetricFilter`, `AWS::CloudWatch::Alarm`, `AWS::CloudTrail::Trail`, `AWS::SNS::Topic`

**AWS Config rule:** None (custom Security Hub CSPM rule)

**Schedule type:** Periodic

**Parameters:** None

You can do real-time monitoring of API calls by directing CloudTrail logs to CloudWatch Logs and establishing corresponding metric filters and alarms.

CIS recommends that you create a metric filter and alarm console logins that aren't protected by MFA. Monitoring for single-factor console logins increases visibility into accounts that aren't protected by MFA. 

To run this check, Security Hub CSPM uses custom logic to perform the exact audit steps prescribed for control 3.2 in the [CIS AWS Foundations Benchmark v1.2](https://d1.awsstatic.com/whitepapers/compliance/AWS_CIS_Foundations_Benchmark.pdf). This control fails if the exact metric filters prescribed by CIS are not used. Additional fields or terms cannot be added to the metric filters.

**Note**  
When Security Hub CSPM performs the check for this control, it looks for CloudTrail trails that the current account uses. These trails might be organization trails that belong to another account. Multi-Region trails also might be based in a different Region.  
The check results in `FAILED` findings in the following cases:  
No trail is configured.
The available trails that are in the current Region and that are owned by current account do not meet the control requirements.
The check results in a control status of `NO_DATA` in the following cases:  
A multi-Region trail is based in a different Region. Security Hub CSPM can only generate findings in the Region where the trail is based.
A multi-Region trail belongs to a different account. Security Hub CSPM can only generate findings for the account that owns the trail.  
We recommend organization trails to log events from many accounts in an organization. Organization trails are multi-Region trails by default and can only be managed by the AWS Organizations management account or the CloudTrail delegated administrator account. Using an organization trail results in a control status of `NO_DATA` for controls evaluated in organization member accounts. In member accounts, Security Hub CSPM only generates findings for member-owned resources. Findings that pertain to organization trails are generated in the resource owner's account. You can see these findings in your Security Hub CSPM delegated administrator account by using cross-Region aggregation.
For the alarm, the current account must either own the referenced Amazon SNS topic, or must get access to the Amazon SNS topic by calling `ListSubscriptionsByTopic`. Otherwise Security Hub CSPM generates `WARNING` findings for the control.

### Remediation
<a name="cloudwatch-3-remediation"></a>

To pass this control, follow these steps to create an Amazon SNS topic, an AWS CloudTrail trail, a metric filter, and an alarm for the metric filter.

1. Create an Amazon SNS topic. For instructions, see [Getting started with Amazon SNS](https://docs.aws.amazon.com/sns/latest/dg/sns-getting-started.html#CreateTopic) in the *Amazon Simple Notification Service Developer Guide*. Create a topic that receives all CIS alarms, and create at least one subscription to the topic.

1. Create a CloudTrail trail that applies to all AWS Regions. For instructions, see [Creating a trail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-a-trail-using-the-console-first-time.html) in the *AWS CloudTrail User Guide*.

   Make note of the name of the CloudWatch Logs log group that you associate with the CloudTrail trail. You create the metric filter for that log group in the next step.

1. Create a metric filter. For instructions, see [Create a metric filter for a log group](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CreateMetricFilterProcedure.html) in the *Amazon CloudWatch User Guide*. Use the following values:    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/securityhub/latest/userguide/cloudwatch-controls.html)

1. Create an alarm based on the filter. For instructions, see [Create a CloudWatch alarm based on a log group-metric filter](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Alarm-On-Logs.html) in the *Amazon CloudWatch User Guide*. Use the following values:    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/securityhub/latest/userguide/cloudwatch-controls.html)

## [CloudWatch.4] Ensure a log metric filter and alarm exist for IAM policy changes
<a name="cloudwatch-4"></a>

**Related requirements:** CIS AWS Foundations Benchmark v1.2.0/3.4, CIS AWS Foundations Benchmark v1.4.0/4.4, NIST.800-171.r2 3.14.6, NIST.800-171.r2 3.14.7

**Category:** Detect > Detection services

**Severity:** Low

**Resource type:** `AWS::Logs::MetricFilter`, `AWS::CloudWatch::Alarm`, `AWS::CloudTrail::Trail`, `AWS::SNS::Topic`

**AWS Config rule:** None (custom Security Hub CSPM rule)

**Schedule type:** Periodic

**Parameters:** None

This control checks whether you monitor API calls in real time by directing CloudTrail logs to CloudWatch Logs and establishing corresponding metric filters and alarms.

CIS recommends that you create a metric filter and alarm for changes made to IAM policies. Monitoring these changes helps ensure that authentication and authorization controls remain intact.

**Note**  
When Security Hub CSPM performs the check for this control, it looks for CloudTrail trails that the current account uses. These trails might be organization trails that belong to another account. Multi-Region trails also might be based in a different Region.  
The check results in `FAILED` findings in the following cases:  
No trail is configured.
The available trails that are in the current Region and that are owned by current account do not meet the control requirements.
The check results in a control status of `NO_DATA` in the following cases:  
A multi-Region trail is based in a different Region. Security Hub CSPM can only generate findings in the Region where the trail is based.
A multi-Region trail belongs to a different account. Security Hub CSPM can only generate findings for the account that owns the trail.  
We recommend organization trails to log events from many accounts in an organization. Organization trails are multi-Region trails by default and can only be managed by the AWS Organizations management account or the CloudTrail delegated administrator account. Using an organization trail results in a control status of `NO_DATA` for controls evaluated in organization member accounts. In member accounts, Security Hub CSPM only generates findings for member-owned resources. Findings that pertain to organization trails are generated in the resource owner's account. You can see these findings in your Security Hub CSPM delegated administrator account by using cross-Region aggregation.
For the alarm, the current account must either own the referenced Amazon SNS topic, or must get access to the Amazon SNS topic by calling `ListSubscriptionsByTopic`. Otherwise Security Hub CSPM generates `WARNING` findings for the control.

### Remediation
<a name="cloudwatch-4-remediation"></a>

**Note**  
Our recommended filter pattern in these remediation steps differs from the filter pattern in the CIS guidance. Our recommended filters target only events coming from IAM API calls.

To pass this control, follow these steps to create an Amazon SNS topic, an AWS CloudTrail trail, a metric filter, and an alarm for the metric filter.

1. Create an Amazon SNS topic. For instructions, see [Getting started with Amazon SNS](https://docs.aws.amazon.com/sns/latest/dg/sns-getting-started.html#CreateTopic) in the *Amazon Simple Notification Service Developer Guide*. Create a topic that receives all CIS alarms, and create at least one subscription to the topic.

1. Create a CloudTrail trail that applies to all AWS Regions. For instructions, see [Creating a trail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-a-trail-using-the-console-first-time.html) in the *AWS CloudTrail User Guide*.

   Make note of the name of the CloudWatch Logs log group that you associate with the CloudTrail trail. You create the metric filter for that log group in the next step.

1. Create a metric filter. For instructions, see [Create a metric filter for a log group](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CreateMetricFilterProcedure.html) in the *Amazon CloudWatch User Guide*. Use the following values:    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/securityhub/latest/userguide/cloudwatch-controls.html)

1. Create an alarm based on the filter. For instructions, see [Create a CloudWatch alarm based on a log group-metric filter](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Alarm-On-Logs.html) in the *Amazon CloudWatch User Guide*. Use the following values:    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/securityhub/latest/userguide/cloudwatch-controls.html)

## [CloudWatch.5] Ensure a log metric filter and alarm exist for CloudTrail configuration changes
<a name="cloudwatch-5"></a>

**Related requirements:** CIS AWS Foundations Benchmark v1.2.0/3.5, CIS AWS Foundations Benchmark v1.4.0/4.5, NIST.800-171.r2 3.3.8, NIST.800-171.r2 3.14.6, NIST.800-171.r2 3.14.7

**Category:** Detect > Detection services

**Severity:** Low

**Resource type:** `AWS::Logs::MetricFilter`, `AWS::CloudWatch::Alarm`, `AWS::CloudTrail::Trail`, `AWS::SNS::Topic`

**AWS Config rule:** None (custom Security Hub CSPM rule)

**Schedule type:** Periodic

**Parameters:** None

You can do real-time monitoring of API calls by directing CloudTrail logs to CloudWatch Logs and establishing corresponding metric filters and alarms.

CIS recommends that you create a metric filter and alarm for changes to CloudTrail configuration settings. Monitoring these changes helps ensure sustained visibility to activities in the account.

To run this check, Security Hub CSPM uses custom logic to perform the exact audit steps prescribed for control 4.5 in the [CIS AWS Foundations Benchmark v1.4.0](https://acrobat.adobe.com/link/track?uri=urn:aaid:scds:US:2e5fec5c-5e99-4fb5-b08d-bb46b14754c1#pageNum=1). This control fails if the exact metric filters prescribed by CIS are not used. Additional fields or terms cannot be added to the metric filters.

**Note**  
When Security Hub CSPM performs the check for this control, it looks for CloudTrail trails that the current account uses. These trails might be organization trails that belong to another account. Multi-Region trails also might be based in a different Region.  
The check results in `FAILED` findings in the following cases:  
No trail is configured.
The available trails that are in the current Region and that are owned by current account do not meet the control requirements.
The check results in a control status of `NO_DATA` in the following cases:  
A multi-Region trail is based in a different Region. Security Hub CSPM can only generate findings in the Region where the trail is based.
A multi-Region trail belongs to a different account. Security Hub CSPM can only generate findings for the account that owns the trail.  
We recommend organization trails to log events from many accounts in an organization. Organization trails are multi-Region trails by default and can only be managed by the AWS Organizations management account or the CloudTrail delegated administrator account. Using an organization trail results in a control status of `NO_DATA` for controls evaluated in organization member accounts. In member accounts, Security Hub CSPM only generates findings for member-owned resources. Findings that pertain to organization trails are generated in the resource owner's account. You can see these findings in your Security Hub CSPM delegated administrator account by using cross-Region aggregation.
For the alarm, the current account must either own the referenced Amazon SNS topic, or must get access to the Amazon SNS topic by calling `ListSubscriptionsByTopic`. Otherwise Security Hub CSPM generates `WARNING` findings for the control.

### Remediation
<a name="cloudwatch-5-remediation"></a>

To pass this control, follow these steps to create an Amazon SNS topic, an AWS CloudTrail trail, a metric filter, and an alarm for the metric filter.

1. Create an Amazon SNS topic. For instructions, see [Getting started with Amazon SNS](https://docs.aws.amazon.com/sns/latest/dg/sns-getting-started.html#CreateTopic) in the *Amazon Simple Notification Service Developer Guide*. Create a topic that receives all CIS alarms, and create at least one subscription to the topic.

1. Create a CloudTrail trail that applies to all AWS Regions. For instructions, see [Creating a trail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-a-trail-using-the-console-first-time.html) in the *AWS CloudTrail User Guide*.

   Make note of the name of the CloudWatch Logs log group that you associate with the CloudTrail trail. You create the metric filter for that log group in the next step.

1. Create a metric filter. For instructions, see [Create a metric filter for a log group](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CreateMetricFilterProcedure.html) in the *Amazon CloudWatch User Guide*. Use the following values:    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/securityhub/latest/userguide/cloudwatch-controls.html)

1. Create an alarm based on the filter. For instructions, see [Create a CloudWatch alarm based on a log group-metric filter](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Alarm-On-Logs.html) in the *Amazon CloudWatch User Guide*. Use the following values:    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/securityhub/latest/userguide/cloudwatch-controls.html)

## [CloudWatch.6] Ensure a log metric filter and alarm exist for AWS Management Console authentication failures
<a name="cloudwatch-6"></a>

**Related requirements:** CIS AWS Foundations Benchmark v1.2.0/3.6, CIS AWS Foundations Benchmark v1.4.0/4.6, NIST.800-171.r2 3.14.6, NIST.800-171.r2 3.14.7

**Category:** Detect > Detection services

**Severity:** Low

**Resource type:** `AWS::Logs::MetricFilter`, `AWS::CloudWatch::Alarm`, `AWS::CloudTrail::Trail`, `AWS::SNS::Topic`

**AWS Config rule:** None (custom Security Hub CSPM rule)

**Schedule type:** Periodic

**Parameters:** None

You can do real-time monitoring of API calls by directing CloudTrail logs to CloudWatch Logs and establishing corresponding metric filters and alarms.

CIS recommends that you create a metric filter and alarm for failed console authentication attempts. Monitoring failed console logins might decrease lead time to detect an attempt to brute-force a credential, which might provide an indicator, such as source IP, that you can use in other event correlations. 

To run this check, Security Hub CSPM uses custom logic to perform the exact audit steps prescribed for control 4.6 in the [CIS AWS Foundations Benchmark v1.4.0](https://acrobat.adobe.com/link/track?uri=urn:aaid:scds:US:2e5fec5c-5e99-4fb5-b08d-bb46b14754c1#pageNum=1). This control fails if the exact metric filters prescribed by CIS are not used. Additional fields or terms cannot be added to the metric filters.

**Note**  
When Security Hub CSPM performs the check for this control, it looks for CloudTrail trails that the current account uses. These trails might be organization trails that belong to another account. Multi-Region trails also might be based in a different Region.  
The check results in `FAILED` findings in the following cases:  
No trail is configured.
The available trails that are in the current Region and that are owned by current account do not meet the control requirements.
The check results in a control status of `NO_DATA` in the following cases:  
A multi-Region trail is based in a different Region. Security Hub CSPM can only generate findings in the Region where the trail is based.
A multi-Region trail belongs to a different account. Security Hub CSPM can only generate findings for the account that owns the trail.  
We recommend organization trails to log events from many accounts in an organization. Organization trails are multi-Region trails by default and can only be managed by the AWS Organizations management account or the CloudTrail delegated administrator account. Using an organization trail results in a control status of `NO_DATA` for controls evaluated in organization member accounts. In member accounts, Security Hub CSPM only generates findings for member-owned resources. Findings that pertain to organization trails are generated in the resource owner's account. You can see these findings in your Security Hub CSPM delegated administrator account by using cross-Region aggregation.
For the alarm, the current account must either own the referenced Amazon SNS topic, or must get access to the Amazon SNS topic by calling `ListSubscriptionsByTopic`. Otherwise Security Hub CSPM generates `WARNING` findings for the control.

### Remediation
<a name="cloudwatch-6-remediation"></a>

To pass this control, follow these steps to create an Amazon SNS topic, an AWS CloudTrail trail, a metric filter, and an alarm for the metric filter.

1. Create an Amazon SNS topic. For instructions, see [Getting started with Amazon SNS](https://docs.aws.amazon.com/sns/latest/dg/sns-getting-started.html#CreateTopic) in the *Amazon Simple Notification Service Developer Guide*. Create a topic that receives all CIS alarms, and create at least one subscription to the topic.

1. Create a CloudTrail trail that applies to all AWS Regions. For instructions, see [Creating a trail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-a-trail-using-the-console-first-time.html) in the *AWS CloudTrail User Guide*.

   Make note of the name of the CloudWatch Logs log group that you associate with the CloudTrail trail. You create the metric filter for that log group in the next step.

1. Create a metric filter. For instructions, see [Create a metric filter for a log group](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CreateMetricFilterProcedure.html) in the *Amazon CloudWatch User Guide*. Use the following values:    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/securityhub/latest/userguide/cloudwatch-controls.html)

1. Create an alarm based on the filter. For instructions, see [Create a CloudWatch alarm based on a log group-metric filter](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Alarm-On-Logs.html) in the *Amazon CloudWatch User Guide*. Use the following values:    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/securityhub/latest/userguide/cloudwatch-controls.html)

## [CloudWatch.7] Ensure a log metric filter and alarm exist for disabling or scheduled deletion of customer managed keys
<a name="cloudwatch-7"></a>

**Related requirements:** CIS AWS Foundations Benchmark v1.2.0/3.7, CIS AWS Foundations Benchmark v1.4.0/4.7, NIST.800-171.r2 3.13.10, NIST.800-171.r2 3.13.16, NIST.800-171.r2 3.14.6, NIST.800-171.r2 3.14.7

**Category:** Detect > Detection services

**Severity:** Low

**Resource type:** `AWS::Logs::MetricFilter`, `AWS::CloudWatch::Alarm`, `AWS::CloudTrail::Trail`, `AWS::SNS::Topic`

**AWS Config rule:** None (custom Security Hub CSPM rule)

**Schedule type:** Periodic

**Parameters:** None

You can do real-time monitoring of API calls by directing CloudTrail logs to CloudWatch Logs and establishing corresponding metric filters and alarms.

CIS recommends that you create a metric filter and alarm for customer managed keys that have changed state to disabled or scheduled deletion. Data encrypted with disabled or deleted keys is no longer accessible.

To run this check, Security Hub CSPM uses custom logic to perform the exact audit steps prescribed for control 4.7 in the [CIS AWS Foundations Benchmark v1.4.0](https://acrobat.adobe.com/link/track?uri=urn:aaid:scds:US:2e5fec5c-5e99-4fb5-b08d-bb46b14754c1#pageNum=1). This control fails if the exact metric filters prescribed by CIS are not used. Additional fields or terms cannot be added to the metric filters. The control also fails if `ExcludeManagementEventSources` contains `kms.amazonaws.com`.

**Note**  
When Security Hub CSPM performs the check for this control, it looks for CloudTrail trails that the current account uses. These trails might be organization trails that belong to another account. Multi-Region trails also might be based in a different Region.  
The check results in `FAILED` findings in the following cases:  
No trail is configured.
The available trails that are in the current Region and that are owned by current account do not meet the control requirements.
The check results in a control status of `NO_DATA` in the following cases:  
A multi-Region trail is based in a different Region. Security Hub CSPM can only generate findings in the Region where the trail is based.
A multi-Region trail belongs to a different account. Security Hub CSPM can only generate findings for the account that owns the trail.  
We recommend organization trails to log events from many accounts in an organization. Organization trails are multi-Region trails by default and can only be managed by the AWS Organizations management account or the CloudTrail delegated administrator account. Using an organization trail results in a control status of `NO_DATA` for controls evaluated in organization member accounts. In member accounts, Security Hub CSPM only generates findings for member-owned resources. Findings that pertain to organization trails are generated in the resource owner's account. You can see these findings in your Security Hub CSPM delegated administrator account by using cross-Region aggregation.
For the alarm, the current account must either own the referenced Amazon SNS topic, or must get access to the Amazon SNS topic by calling `ListSubscriptionsByTopic`. Otherwise Security Hub CSPM generates `WARNING` findings for the control.

### Remediation
<a name="cloudwatch-7-remediation"></a>

To pass this control, follow these steps to create an Amazon SNS topic, an AWS CloudTrail trail, a metric filter, and an alarm for the metric filter.

1. Create an Amazon SNS topic. For instructions, see [Getting started with Amazon SNS](https://docs.aws.amazon.com/sns/latest/dg/sns-getting-started.html#CreateTopic) in the *Amazon Simple Notification Service Developer Guide*. Create a topic that receives all CIS alarms, and create at least one subscription to the topic.

1. Create a CloudTrail trail that applies to all AWS Regions. For instructions, see [Creating a trail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-a-trail-using-the-console-first-time.html) in the *AWS CloudTrail User Guide*.

   Make note of the name of the CloudWatch Logs log group that you associate with the CloudTrail trail. You create the metric filter for that log group in the next step.

1. Create a metric filter. For instructions, see [Create a metric filter for a log group](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CreateMetricFilterProcedure.html) in the *Amazon CloudWatch User Guide*. Use the following values:    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/securityhub/latest/userguide/cloudwatch-controls.html)

1. Create an alarm based on the filter. For instructions, see [Create a CloudWatch alarm based on a log group-metric filter](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Alarm-On-Logs.html) in the *Amazon CloudWatch User Guide*. Use the following values:    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/securityhub/latest/userguide/cloudwatch-controls.html)

## [CloudWatch.8] Ensure a log metric filter and alarm exist for S3 bucket policy changes
<a name="cloudwatch-8"></a>

**Related requirements:** CIS AWS Foundations Benchmark v1.2.0/3.8, CIS AWS Foundations Benchmark v1.4.0/4.8, NIST.800-171.r2 3.14.6, NIST.800-171.r2 3.14.7

**Category:** Detect > Detection services

**Severity:** Low

**Resource type:** `AWS::Logs::MetricFilter`, `AWS::CloudWatch::Alarm`, `AWS::CloudTrail::Trail`, `AWS::SNS::Topic`

**AWS Config rule:** None (custom Security Hub CSPM rule)

**Schedule type:** Periodic

**Parameters:** None

You can do real-time monitoring of API calls by directing CloudTrail logs to CloudWatch Logs and establishing corresponding metric filters and alarms.

CIS recommends that you create a metric filter and alarm for changes to S3 bucket policies. Monitoring these changes might reduce time to detect and correct permissive policies on sensitive S3 buckets.

To run this check, Security Hub CSPM uses custom logic to perform the exact audit steps prescribed for control 4.8 in the [CIS AWS Foundations Benchmark v1.4.0](https://acrobat.adobe.com/link/track?uri=urn:aaid:scds:US:2e5fec5c-5e99-4fb5-b08d-bb46b14754c1#pageNum=1). This control fails if the exact metric filters prescribed by CIS are not used. Additional fields or terms cannot be added to the metric filters.

**Note**  
When Security Hub CSPM performs the check for this control, it looks for CloudTrail trails that the current account uses. These trails might be organization trails that belong to another account. Multi-Region trails also might be based in a different Region.  
The check results in `FAILED` findings in the following cases:  
No trail is configured.
The available trails that are in the current Region and that are owned by current account do not meet the control requirements.
The check results in a control status of `NO_DATA` in the following cases:  
A multi-Region trail is based in a different Region. Security Hub CSPM can only generate findings in the Region where the trail is based.
A multi-Region trail belongs to a different account. Security Hub CSPM can only generate findings for the account that owns the trail.  
We recommend organization trails to log events from many accounts in an organization. Organization trails are multi-Region trails by default and can only be managed by the AWS Organizations management account or the CloudTrail delegated administrator account. Using an organization trail results in a control status of `NO_DATA` for controls evaluated in organization member accounts. In member accounts, Security Hub CSPM only generates findings for member-owned resources. Findings that pertain to organization trails are generated in the resource owner's account. You can see these findings in your Security Hub CSPM delegated administrator account by using cross-Region aggregation.
For the alarm, the current account must either own the referenced Amazon SNS topic, or must get access to the Amazon SNS topic by calling `ListSubscriptionsByTopic`. Otherwise Security Hub CSPM generates `WARNING` findings for the control.

### Remediation
<a name="cloudwatch-8-remediation"></a>

To pass this control, follow these steps to create an Amazon SNS topic, an AWS CloudTrail trail, a metric filter, and an alarm for the metric filter.

1. Create an Amazon SNS topic. For instructions, see [Getting started with Amazon SNS](https://docs.aws.amazon.com/sns/latest/dg/sns-getting-started.html#CreateTopic) in the *Amazon Simple Notification Service Developer Guide*. Create a topic that receives all CIS alarms, and create at least one subscription to the topic.

1. Create a CloudTrail trail that applies to all AWS Regions. For instructions, see [Creating a trail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-a-trail-using-the-console-first-time.html) in the *AWS CloudTrail User Guide*.

   Make note of the name of the CloudWatch Logs log group that you associate with the CloudTrail trail. You create the metric filter for that log group in the next step.

1. Create a metric filter. For instructions, see [Create a metric filter for a log group](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CreateMetricFilterProcedure.html) in the *Amazon CloudWatch User Guide*. Use the following values:    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/securityhub/latest/userguide/cloudwatch-controls.html)

1. Create an alarm based on the filter. For instructions, see [Create a CloudWatch alarm based on a log group-metric filter](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Alarm-On-Logs.html) in the *Amazon CloudWatch User Guide*. Use the following values:    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/securityhub/latest/userguide/cloudwatch-controls.html)

## [CloudWatch.9] Ensure a log metric filter and alarm exist for AWS Config configuration changes
<a name="cloudwatch-9"></a>

**Related requirements:** CIS AWS Foundations Benchmark v1.2.0/3.9, CIS AWS Foundations Benchmark v1.4.0/4.9, NIST.800-171.r2 3.3.8, NIST.800-171.r2 3.14.6, NIST.800-171.r2 3.14.7

**Category:** Detect > Detection services

**Severity:** Low

**Resource type:** `AWS::Logs::MetricFilter`, `AWS::CloudWatch::Alarm`, `AWS::CloudTrail::Trail`, `AWS::SNS::Topic`

**AWS Config rule:** None (custom Security Hub CSPM rule)

**Schedule type:** Periodic

**Parameters:** None

You can do real-time monitoring of API calls by directing CloudTrail logs to CloudWatch Logs and establishing corresponding metric filters and alarms.

CIS recommends that you create a metric filter and alarm for changes to AWS Config configuration settings. Monitoring these changes helps ensure sustained visibility of configuration items in the account.

To run this check, Security Hub CSPM uses custom logic to perform the exact audit steps prescribed for control 4.9 in the [CIS AWS Foundations Benchmark v1.4.0](https://acrobat.adobe.com/link/track?uri=urn:aaid:scds:US:2e5fec5c-5e99-4fb5-b08d-bb46b14754c1#pageNum=1). This control fails if the exact metric filters prescribed by CIS are not used. Additional fields or terms cannot be added to the metric filters.

**Note**  
When Security Hub CSPM performs the check for this control, it looks for CloudTrail trails that the current account uses. These trails might be organization trails that belong to another account. Multi-Region trails also might be based in a different Region.  
The check results in `FAILED` findings in the following cases:  
No trail is configured.
The available trails that are in the current Region and that are owned by current account do not meet the control requirements.
The check results in a control status of `NO_DATA` in the following cases:  
A multi-Region trail is based in a different Region. Security Hub CSPM can only generate findings in the Region where the trail is based.
A multi-Region trail belongs to a different account. Security Hub CSPM can only generate findings for the account that owns the trail.  
We recommend organization trails to log events from many accounts in an organization. Organization trails are multi-Region trails by default and can only be managed by the AWS Organizations management account or the CloudTrail delegated administrator account. Using an organization trail results in a control status of `NO_DATA` for controls evaluated in organization member accounts. In member accounts, Security Hub CSPM only generates findings for member-owned resources. Findings that pertain to organization trails are generated in the resource owner's account. You can see these findings in your Security Hub CSPM delegated administrator account by using cross-Region aggregation.
For the alarm, the current account must either own the referenced Amazon SNS topic, or must get access to the Amazon SNS topic by calling `ListSubscriptionsByTopic`. Otherwise Security Hub CSPM generates `WARNING` findings for the control.

### Remediation
<a name="cloudwatch-9-remediation"></a>

To pass this control, follow these steps to create an Amazon SNS topic, an AWS CloudTrail trail, a metric filter, and an alarm for the metric filter.

1. Create an Amazon SNS topic. For instructions, see [Getting started with Amazon SNS](https://docs.aws.amazon.com/sns/latest/dg/sns-getting-started.html#CreateTopic) in the *Amazon Simple Notification Service Developer Guide*. Create a topic that receives all CIS alarms, and create at least one subscription to the topic.

1. Create a CloudTrail trail that applies to all AWS Regions. For instructions, see [Creating a trail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-a-trail-using-the-console-first-time.html) in the *AWS CloudTrail User Guide*.

   Make note of the name of the CloudWatch Logs log group that you associate with the CloudTrail trail. You create the metric filter for that log group in the next step.

1. Create a metric filter. For instructions, see [Create a metric filter for a log group](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CreateMetricFilterProcedure.html) in the *Amazon CloudWatch User Guide*. Use the following values:    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/securityhub/latest/userguide/cloudwatch-controls.html)

1. Create an alarm based on the filter. For instructions, see [Create a CloudWatch alarm based on a log group-metric filter](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Alarm-On-Logs.html) in the *Amazon CloudWatch User Guide*. Use the following values:    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/securityhub/latest/userguide/cloudwatch-controls.html)

## [CloudWatch.10] Ensure a log metric filter and alarm exist for security group changes
<a name="cloudwatch-10"></a>

**Related requirements:** CIS AWS Foundations Benchmark v1.2.0/3.10, CIS AWS Foundations Benchmark v1.4.0/4.10, NIST.800-171.r2 3.14.6, NIST.800-171.r2 3.14.7

**Category:** Detect > Detection services

**Severity:** Low

**Resource type:** `AWS::Logs::MetricFilter`, `AWS::CloudWatch::Alarm`, `AWS::CloudTrail::Trail`, `AWS::SNS::Topic`

**AWS Config rule:** None (custom Security Hub CSPM rule)

**Schedule type:** Periodic

**Parameters:** None

You can do real-time monitoring of API calls by directing CloudTrail logs to CloudWatch Logs and establishing corresponding metric filters and alarms. Security groups are a stateful packet filter that controls ingress and egress traffic in a VPC.

CIS recommends that you create a metric filter and alarm for changes to security groups. Monitoring these changes helps ensure that resources and services aren't unintentionally exposed. 

To run this check, Security Hub CSPM uses custom logic to perform the exact audit steps prescribed for control 4.10 in the [CIS AWS Foundations Benchmark v1.4.0](https://acrobat.adobe.com/link/track?uri=urn:aaid:scds:US:2e5fec5c-5e99-4fb5-b08d-bb46b14754c1#pageNum=1). This control fails if the exact metric filters prescribed by CIS are not used. Additional fields or terms cannot be added to the metric filters.

**Note**  
When Security Hub CSPM performs the check for this control, it looks for CloudTrail trails that the current account uses. These trails might be organization trails that belong to another account. Multi-Region trails also might be based in a different Region.  
The check results in `FAILED` findings in the following cases:  
No trail is configured.
The available trails that are in the current Region and that are owned by current account do not meet the control requirements.
The check results in a control status of `NO_DATA` in the following cases:  
A multi-Region trail is based in a different Region. Security Hub CSPM can only generate findings in the Region where the trail is based.
A multi-Region trail belongs to a different account. Security Hub CSPM can only generate findings for the account that owns the trail.  
We recommend organization trails to log events from many accounts in an organization. Organization trails are multi-Region trails by default and can only be managed by the AWS Organizations management account or the CloudTrail delegated administrator account. Using an organization trail results in a control status of `NO_DATA` for controls evaluated in organization member accounts. In member accounts, Security Hub CSPM only generates findings for member-owned resources. Findings that pertain to organization trails are generated in the resource owner's account. You can see these findings in your Security Hub CSPM delegated administrator account by using cross-Region aggregation.
For the alarm, the current account must either own the referenced Amazon SNS topic, or must get access to the Amazon SNS topic by calling `ListSubscriptionsByTopic`. Otherwise Security Hub CSPM generates `WARNING` findings for the control.

### Remediation
<a name="cloudwatch-10-remediation"></a>

To pass this control, follow these steps to create an Amazon SNS topic, an AWS CloudTrail trail, a metric filter, and an alarm for the metric filter.

1. Create an Amazon SNS topic. For instructions, see [Getting started with Amazon SNS](https://docs.aws.amazon.com/sns/latest/dg/sns-getting-started.html#CreateTopic) in the *Amazon Simple Notification Service Developer Guide*. Create a topic that receives all CIS alarms, and create at least one subscription to the topic.

1. Create a CloudTrail trail that applies to all AWS Regions. For instructions, see [Creating a trail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-a-trail-using-the-console-first-time.html) in the *AWS CloudTrail User Guide*.

   Make note of the name of the CloudWatch Logs log group that you associate with the CloudTrail trail. You create the metric filter for that log group in the next step.

1. Create a metric filter. For instructions, see [Create a metric filter for a log group](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CreateMetricFilterProcedure.html) in the *Amazon CloudWatch User Guide*. Use the following values:    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/securityhub/latest/userguide/cloudwatch-controls.html)

1. Create an alarm based on the filter. For instructions, see [Create a CloudWatch alarm based on a log group-metric filter](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Alarm-On-Logs.html) in the *Amazon CloudWatch User Guide*. Use the following values:    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/securityhub/latest/userguide/cloudwatch-controls.html)

## [CloudWatch.11] Ensure a log metric filter and alarm exist for changes to Network Access Control Lists (NACL)
<a name="cloudwatch-11"></a>

**Related requirements:** CIS AWS Foundations Benchmark v1.2.0/3.11, CIS AWS Foundations Benchmark v1.4.0/4.11, NIST.800-171.r2 3.14.6, NIST.800-171.r2 3.14.7

**Category:** Detect > Detection services

**Severity:** Low

**Resource type:** `AWS::Logs::MetricFilter`, `AWS::CloudWatch::Alarm`, `AWS::CloudTrail::Trail`, `AWS::SNS::Topic`

**AWS Config rule:** None (custom Security Hub CSPM rule)

**Schedule type:** Periodic

**Parameters:** None

You can do real-time monitoring of API calls by directing CloudTrail logs to CloudWatch Logs and establishing corresponding metric filters and alarms. NACLs are used as a stateless packet filter to control ingress and egress traffic for subnets in a VPC.

CIS recommends that you create a metric filter and alarm for changes to NACLs. Monitoring these changes helps ensure that AWS resources and services aren't unintentionally exposed. 

To run this check, Security Hub CSPM uses custom logic to perform the exact audit steps prescribed for control 4.11 in the [CIS AWS Foundations Benchmark v1.4.0](https://acrobat.adobe.com/link/track?uri=urn:aaid:scds:US:2e5fec5c-5e99-4fb5-b08d-bb46b14754c1#pageNum=1). This control fails if the exact metric filters prescribed by CIS are not used. Additional fields or terms cannot be added to the metric filters.

**Note**  
When Security Hub CSPM performs the check for this control, it looks for CloudTrail trails that the current account uses. These trails might be organization trails that belong to another account. Multi-Region trails also might be based in a different Region.  
The check results in `FAILED` findings in the following cases:  
No trail is configured.
The available trails that are in the current Region and that are owned by current account do not meet the control requirements.
The check results in a control status of `NO_DATA` in the following cases:  
A multi-Region trail is based in a different Region. Security Hub CSPM can only generate findings in the Region where the trail is based.
A multi-Region trail belongs to a different account. Security Hub CSPM can only generate findings for the account that owns the trail.  
We recommend organization trails to log events from many accounts in an organization. Organization trails are multi-Region trails by default and can only be managed by the AWS Organizations management account or the CloudTrail delegated administrator account. Using an organization trail results in a control status of `NO_DATA` for controls evaluated in organization member accounts. In member accounts, Security Hub CSPM only generates findings for member-owned resources. Findings that pertain to organization trails are generated in the resource owner's account. You can see these findings in your Security Hub CSPM delegated administrator account by using cross-Region aggregation.
For the alarm, the current account must either own the referenced Amazon SNS topic, or must get access to the Amazon SNS topic by calling `ListSubscriptionsByTopic`. Otherwise Security Hub CSPM generates `WARNING` findings for the control.

### Remediation
<a name="cloudwatch-11-remediation"></a>

To pass this control, follow these steps to create an Amazon SNS topic, an AWS CloudTrail trail, a metric filter, and an alarm for the metric filter.

1. Create an Amazon SNS topic. For instructions, see [Getting started with Amazon SNS](https://docs.aws.amazon.com/sns/latest/dg/sns-getting-started.html#CreateTopic) in the *Amazon Simple Notification Service Developer Guide*. Create a topic that receives all CIS alarms, and create at least one subscription to the topic.

1. Create a CloudTrail trail that applies to all AWS Regions. For instructions, see [Creating a trail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-a-trail-using-the-console-first-time.html) in the *AWS CloudTrail User Guide*.

   Make note of the name of the CloudWatch Logs log group that you associate with the CloudTrail trail. You create the metric filter for that log group in the next step.

1. Create a metric filter. For instructions, see [Create a metric filter for a log group](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CreateMetricFilterProcedure.html) in the *Amazon CloudWatch User Guide*. Use the following values:    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/securityhub/latest/userguide/cloudwatch-controls.html)

1. Create an alarm based on the filter. For instructions, see [Create a CloudWatch alarm based on a log group-metric filter](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Alarm-On-Logs.html) in the *Amazon CloudWatch User Guide*. Use the following values:    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/securityhub/latest/userguide/cloudwatch-controls.html)

## [CloudWatch.12] Ensure a log metric filter and alarm exist for changes to network gateways
<a name="cloudwatch-12"></a>

**Related requirements:** CIS AWS Foundations Benchmark v1.2.0/3.12, CIS AWS Foundations Benchmark v1.4.0/4.12, NIST.800-171.r2 3.3.1, NIST.800-171.r2 3.13.1

**Category:** Detect > Detection services

**Severity:** Low

**Resource type:** `AWS::Logs::MetricFilter`, `AWS::CloudWatch::Alarm`, `AWS::CloudTrail::Trail`, `AWS::SNS::Topic`

**AWS Config rule:** None (custom Security Hub CSPM rule)

**Schedule type:** Periodic

**Parameters:** None

You can do real-time monitoring of API calls by directing CloudTrail logs to CloudWatch Logs and establishing corresponding metric filters and alarms. Network gateways are required to send and receive traffic to a destination outside a VPC.

CIS recommends that you create a metric filter and alarm for changes to network gateways. Monitoring these changes helps ensure that all ingress and egress traffic traverses the VPC border via a controlled path.

To run this check, Security Hub CSPM uses custom logic to perform the exact audit steps prescribed for control 4.12 in the [CIS AWS Foundations Benchmark v1.2](https://acrobat.adobe.com/link/track?uri=urn:aaid:scds:US:2e5fec5c-5e99-4fb5-b08d-bb46b14754c1#pageNum=1). This control fails if the exact metric filters prescribed by CIS are not used. Additional fields or terms cannot be added to the metric filters.

**Note**  
When Security Hub CSPM performs the check for this control, it looks for CloudTrail trails that the current account uses. These trails might be organization trails that belong to another account. Multi-Region trails also might be based in a different Region.  
The check results in `FAILED` findings in the following cases:  
No trail is configured.
The available trails that are in the current Region and that are owned by current account do not meet the control requirements.
The check results in a control status of `NO_DATA` in the following cases:  
A multi-Region trail is based in a different Region. Security Hub CSPM can only generate findings in the Region where the trail is based.
A multi-Region trail belongs to a different account. Security Hub CSPM can only generate findings for the account that owns the trail.  
We recommend organization trails to log events from many accounts in an organization. Organization trails are multi-Region trails by default and can only be managed by the AWS Organizations management account or the CloudTrail delegated administrator account. Using an organization trail results in a control status of `NO_DATA` for controls evaluated in organization member accounts. In member accounts, Security Hub CSPM only generates findings for member-owned resources. Findings that pertain to organization trails are generated in the resource owner's account. You can see these findings in your Security Hub CSPM delegated administrator account by using cross-Region aggregation.
For the alarm, the current account must either own the referenced Amazon SNS topic, or must get access to the Amazon SNS topic by calling `ListSubscriptionsByTopic`. Otherwise Security Hub CSPM generates `WARNING` findings for the control.

### Remediation
<a name="cloudwatch-12-remediation"></a>

To pass this control, follow these steps to create an Amazon SNS topic, an AWS CloudTrail trail, a metric filter, and an alarm for the metric filter.

1. Create an Amazon SNS topic. For instructions, see [Getting started with Amazon SNS](https://docs.aws.amazon.com/sns/latest/dg/sns-getting-started.html#CreateTopic) in the *Amazon Simple Notification Service Developer Guide*. Create a topic that receives all CIS alarms, and create at least one subscription to the topic.

1. Create a CloudTrail trail that applies to all AWS Regions. For instructions, see [Creating a trail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-a-trail-using-the-console-first-time.html) in the *AWS CloudTrail User Guide*.

   Make note of the name of the CloudWatch Logs log group that you associate with the CloudTrail trail. You create the metric filter for that log group in the next step.

1. Create a metric filter. For instructions, see [Create a metric filter for a log group](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CreateMetricFilterProcedure.html) in the *Amazon CloudWatch User Guide*. Use the following values:    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/securityhub/latest/userguide/cloudwatch-controls.html)

1. Create an alarm based on the filter. For instructions, see [Create a CloudWatch alarm based on a log group-metric filter](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Alarm-On-Logs.html) in the *Amazon CloudWatch User Guide*. Use the following values:    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/securityhub/latest/userguide/cloudwatch-controls.html)

## [CloudWatch.13] Ensure a log metric filter and alarm exist for route table changes
<a name="cloudwatch-13"></a>

**Related requirements:** CIS AWS Foundations Benchmark v1.2.0/3.13, CIS AWS Foundations Benchmark v1.4.0/4.13, NIST.800-171.r2 3.3.1, NIST.800-171.r2 3.13.1, NIST.800-171.r2 3.14.6, NIST.800-171.r2 3.14.7

**Category:** Detect > Detection services

**Severity:** Low

**Resource type:** `AWS::Logs::MetricFilter`, `AWS::CloudWatch::Alarm`, `AWS::CloudTrail::Trail`, `AWS::SNS::Topic`

**AWS Config rule:** None (custom Security Hub CSPM rule)

**Schedule type:** Periodic

**Parameters:** None

This control checks whether you monitor API calls in real time by directing CloudTrail logs to CloudWatch Logs and establishing corresponding metric filters and alarms. Routing tables route network traffic between subnets and to network gateways.

CIS recommends that you create a metric filter and alarm for changes to route tables. Monitoring these changes helps ensure that all VPC traffic flows through an expected path.

**Note**  
When Security Hub CSPM performs the check for this control, it looks for CloudTrail trails that the current account uses. These trails might be organization trails that belong to another account. Multi-Region trails also might be based in a different Region.  
The check results in `FAILED` findings in the following cases:  
No trail is configured.
The available trails that are in the current Region and that are owned by current account do not meet the control requirements.
The check results in a control status of `NO_DATA` in the following cases:  
A multi-Region trail is based in a different Region. Security Hub CSPM can only generate findings in the Region where the trail is based.
A multi-Region trail belongs to a different account. Security Hub CSPM can only generate findings for the account that owns the trail.  
We recommend organization trails to log events from many accounts in an organization. Organization trails are multi-Region trails by default and can only be managed by the AWS Organizations management account or the CloudTrail delegated administrator account. Using an organization trail results in a control status of `NO_DATA` for controls evaluated in organization member accounts. In member accounts, Security Hub CSPM only generates findings for member-owned resources. Findings that pertain to organization trails are generated in the resource owner's account. You can see these findings in your Security Hub CSPM delegated administrator account by using cross-Region aggregation.
For the alarm, the current account must either own the referenced Amazon SNS topic, or must get access to the Amazon SNS topic by calling `ListSubscriptionsByTopic`. Otherwise Security Hub CSPM generates `WARNING` findings for the control.

### Remediation
<a name="cloudwatch-13-remediation"></a>

**Note**  
Our recommended filter pattern in these remediation steps differs from the filter pattern in the CIS guidance. Our recommended filters target only events coming from Amazon Elastic Compute Cloud (EC2) API calls.

To pass this control, follow these steps to create an Amazon SNS topic, an AWS CloudTrail trail, a metric filter, and an alarm for the metric filter.

1. Create an Amazon SNS topic. For instructions, see [Getting started with Amazon SNS](https://docs.aws.amazon.com/sns/latest/dg/sns-getting-started.html#CreateTopic) in the *Amazon Simple Notification Service Developer Guide*. Create a topic that receives all CIS alarms, and create at least one subscription to the topic.

1. Create a CloudTrail trail that applies to all AWS Regions. For instructions, see [Creating a trail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-a-trail-using-the-console-first-time.html) in the *AWS CloudTrail User Guide*.

   Make note of the name of the CloudWatch Logs log group that you associate with the CloudTrail trail. You create the metric filter for that log group in the next step.

1. Create a metric filter. For instructions, see [Create a metric filter for a log group](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CreateMetricFilterProcedure.html) in the *Amazon CloudWatch User Guide*. Use the following values:    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/securityhub/latest/userguide/cloudwatch-controls.html)

1. Create an alarm based on the filter. For instructions, see [Create a CloudWatch alarm based on a log group-metric filter](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Alarm-On-Logs.html) in the *Amazon CloudWatch User Guide*. Use the following values:    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/securityhub/latest/userguide/cloudwatch-controls.html)

## [CloudWatch.14] Ensure a log metric filter and alarm exist for VPC changes
<a name="cloudwatch-14"></a>

**Related requirements:** CIS AWS Foundations Benchmark v1.2.0/3.14, CIS AWS Foundations Benchmark v1.4.0/4.14, NIST.800-171.r2 3.3.1, NIST.800-171.r2 3.13.1, NIST.800-171.r2 3.14.6, NIST.800-171.r2 3.14.7

**Category:** Detect > Detection services

**Severity:** Low

**Resource type:** `AWS::Logs::MetricFilter`, `AWS::CloudWatch::Alarm`, `AWS::CloudTrail::Trail`, `AWS::SNS::Topic`

**AWS Config rule:** None (custom Security Hub CSPM rule)

**Schedule type:** Periodic

**Parameters:** None

You can do real-time monitoring of API calls by directing CloudTrail logs to CloudWatch Logs and establishing corresponding metric filters and alarms. You can have more than one VPC in an account, and you can create a peer connection between two VPCs, enabling network traffic to route between VPCs.

CIS recommends that you create a metric filter and alarm for changes to VPCs. Monitoring these changes helps ensure that authentication and authorization controls remain intact.

To run this check, Security Hub CSPM uses custom logic to perform the exact audit steps prescribed for control 4.14 in the [CIS AWS Foundations Benchmark v1.4.0](https://acrobat.adobe.com/link/track?uri=urn:aaid:scds:US:2e5fec5c-5e99-4fb5-b08d-bb46b14754c1#pageNum=1). This control fails if the exact metric filters prescribed by CIS are not used. Additional fields or terms cannot be added to the metric filters.

**Note**  
When Security Hub CSPM performs the check for this control, it looks for CloudTrail trails that the current account uses. These trails might be organization trails that belong to another account. Multi-Region trails also might be based in a different Region.  
The check results in `FAILED` findings in the following cases:  
No trail is configured.
The available trails that are in the current Region and that are owned by current account do not meet the control requirements.
The check results in a control status of `NO_DATA` in the following cases:  
A multi-Region trail is based in a different Region. Security Hub CSPM can only generate findings in the Region where the trail is based.
A multi-Region trail belongs to a different account. Security Hub CSPM can only generate findings for the account that owns the trail.  
We recommend organization trails to log events from many accounts in an organization. Organization trails are multi-Region trails by default and can only be managed by the AWS Organizations management account or the CloudTrail delegated administrator account. Using an organization trail results in a control status of `NO_DATA` for controls evaluated in organization member accounts. In member accounts, Security Hub CSPM only generates findings for member-owned resources. Findings that pertain to organization trails are generated in the resource owner's account. You can see these findings in your Security Hub CSPM delegated administrator account by using cross-Region aggregation.
For the alarm, the current account must either own the referenced Amazon SNS topic, or must get access to the Amazon SNS topic by calling `ListSubscriptionsByTopic`. Otherwise Security Hub CSPM generates `WARNING` findings for the control.

### Remediation
<a name="cloudwatch-14-remediation"></a>

To pass this control, follow these steps to create an Amazon SNS topic, an AWS CloudTrail trail, a metric filter, and an alarm for the metric filter.

1. Create an Amazon SNS topic. For instructions, see [Getting started with Amazon SNS](https://docs.aws.amazon.com/sns/latest/dg/sns-getting-started.html#CreateTopic) in the *Amazon Simple Notification Service Developer Guide*. Create a topic that receives all CIS alarms, and create at least one subscription to the topic.

1. Create a CloudTrail trail that applies to all AWS Regions. For instructions, see [Creating a trail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-a-trail-using-the-console-first-time.html) in the *AWS CloudTrail User Guide*.

   Make note of the name of the CloudWatch Logs log group that you associate with the CloudTrail trail. You create the metric filter for that log group in the next step.

1. Create a metric filter. For instructions, see [Create a metric filter for a log group](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CreateMetricFilterProcedure.html) in the *Amazon CloudWatch User Guide*. Use the following values:    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/securityhub/latest/userguide/cloudwatch-controls.html)

1. Create an alarm based on the filter. For instructions, see [Create a CloudWatch alarm based on a log group-metric filter](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Alarm-On-Logs.html) in the *Amazon CloudWatch User Guide*. Use the following values:    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/securityhub/latest/userguide/cloudwatch-controls.html)

## [CloudWatch.15] CloudWatch alarms should have specified actions configured
<a name="cloudwatch-15"></a>

**Related requirements:** NIST.800-53.r5 AU-6(1), NIST.800-53.r5 AU-6(5), NIST.800-53.r5 CA-7, NIST.800-53.r5 IR-4(1), NIST.800-53.r5 IR-4(5), NIST.800-53.r5 SI-2, NIST.800-53.r5 SI-20, NIST.800-53.r5 SI-4(12), NIST.800-53.r5 SI-4(5), NIST.800-171.r2 3.3.4, NIST.800-171.r2 3.14.6

**Category:** Detect > Detection services

**Severity:** High

**Resource type:** `AWS::CloudWatch::Alarm`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/cloudwatch-alarm-action-check.html](https://docs.aws.amazon.com/config/latest/developerguide/cloudwatch-alarm-action-check.html) ``

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  `alarmActionRequired`  |  The control produces a `PASSED` finding if the parameter is set to `true` and the alarm has an action when the alarm state changes to `ALARM`.  |  Boolean  |  Not customizable  |  `true`  | 
|  `insufficientDataActionRequired`  |  The control produces a `PASSED` finding if the parameter is set to `true` and the alarm has an action when the alarm state changes to `INSUFFICIENT_DATA`.  |  Boolean  |  `true` or `false`  |  `false`  | 
|  `okActionRequired`  |  The control produces a `PASSED` finding if the parameter is set to `true` and the alarm has an action when the alarm state changes to `OK`.  |  Boolean  |  `true` or `false`  |  `false`  | 

This control checks whether an Amazon CloudWatch alarm has at least one action configured for the `ALARM` state. The control fails if the alarm doesn't have an action configured for the `ALARM` state. Optionally, you can include custom parameter values to also require alarm actions for the `INSUFFICIENT_DATA` or `OK` states.

**Note**  
Security Hub CSPM evaluates this control based on CloudWatch metric alarms. Metric alarms may be part of composite alarms that have the specified actions configured. The control generates `FAILED` findings in the following cases:  
The specified actions aren't configured for a metric alarm.
The metric alarm is part of a composite alarm that has the specified actions configured.

This control focuses on whether a CloudWatch alarm has an alarm action configured, whereas [CloudWatch.17](#cloudwatch-17) focuses on the activation status of a CloudWatch alarm action.

We recommend CloudWatch alarm actions to automatically alert you when a monitored metric is outside the defined threshold. Monitoring alarms help you identify unusual activities and quickly respond to security and operational issues when an alarm goes into a specific state. The most common type of alarm action is to notify one or more users by sending a message to an Amazon Simple Notification Service (Amazon SNS) topic.

### Remediation
<a name="cloudwatch-15-remediation"></a>

For information about actions supported by CloudWatch alarms, see [Alarm actions](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-actions) in the *Amazon CloudWatch User Guide*.

## [CloudWatch.16] CloudWatch log groups should be retained for a specified time period
<a name="cloudwatch-16"></a>

**Category:** Identify > Logging

**Related requirements:** NIST.800-53.r5 AU-10, NIST.800-53.r5 AU-11, NIST.800-53.r5 AU-6(3), NIST.800-53.r5 AU-6(4), NIST.800-53.r5 CA-7, NIST.800-53.r5 SI-12

**Severity:** Medium

**Resource type:** `AWS::Logs::LogGroup`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/cw-loggroup-retention-period-check.html](https://docs.aws.amazon.com/config/latest/developerguide/cw-loggroup-retention-period-check.html) ``

**Schedule type:** Periodic

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  `minRetentionTime`  |  Minimum retention period in days for CloudWatch log groups  |  Enum  |  `365, 400, 545, 731, 1827, 3653`  |  `365`  | 

This control checks whether an Amazon CloudWatch log group has a retention period of at least the specified number of days. The control fails if the retention period is less than the specified number. Unless you provide a custom parameter value for the retention period, Security Hub CSPM uses a default value of 365 days.

CloudWatch Logs centralize logs from all of your systems, applications, and AWS services in a single, highly scalable service. You can use CloudWatch Logs to monitor, store, and access your log files from Amazon Elastic Compute Cloud (EC2) instances, AWS CloudTrail, Amazon Route 53, and other sources. Retaining your logs for at least 1 year can help you comply with log retention standards.

### Remediation
<a name="cloudwatch-16-remediation"></a>

To configure log retention settings, see [Change log data retention in CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html#SettingLogRetention) in the *Amazon CloudWatch User Guide*.

## [CloudWatch.17] CloudWatch alarm actions should be activated
<a name="cloudwatch-17"></a>

**Category:** Detect > Detection services

**Related requirements:** NIST.800-53.r5 AU-6(1), NIST.800-53.r5 AU-6(5), NIST.800-53.r5 CA-7, NIST.800-53.r5 SI-2, NIST.800-53.r5 SI-4(12)

**Severity:** High

**Resource type:** `AWS::CloudWatch::Alarm`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/cloudwatch-alarm-action-enabled-check.html](https://docs.aws.amazon.com/config/latest/developerguide/cloudwatch-alarm-action-enabled-check.html) ``

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether CloudWatch alarm actions are activated (`ActionEnabled` should be set to true). The control fails if the alarm action for a CloudWatch alarm is deactivated.

**Note**  
Security Hub CSPM evaluates this control based on CloudWatch metric alarms. Metric alarms may be part of composite alarms that have the alarm actions activated. The control generates `FAILED` findings in the following cases:  
The specified actions aren't configured for a metric alarm.
The metric alarm is part of a composite alarm that has alarm actions activated.

This control focuses on the activation status of a CloudWatch alarm action, whereas [CloudWatch.15](#cloudwatch-15) focuses on whether any `ALARM` action is configured in a CloudWatch alarm.

Alarm actions automatically alert you when a monitored metric is outside the defined threshold. If the alarm action is deactivated, no actions are run when the alarm changes state, and you won't be alerted to changes in monitored metrics. We recommend activating CloudWatch alarm actions to help you quickly respond to security and operational issues.

### Remediation
<a name="cloudwatch-17-remediation"></a>

**To activate a CloudWatch alarm action (console)**

1. Open the CloudWatch console at [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).

1. In the navigation pane, under **Alarms**, choose **All alarms**.

1. Select the alarm that you want to activate actions for.

1. For **Actions**, choose **Alarm actions–new**, and then choose **Enable**.

For more information about activating CloudWatch alarm actions, see [Alarm actions](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-actions) in the *Amazon CloudWatch User Guide*.

# Security Hub CSPM controls for CodeArtifact
<a name="codeartifact-controls"></a>

These Security Hub CSPM controls evaluate the AWS CodeArtifact service and resources.

These controls may not be available in all AWS Regions. For more information, see [Availability of controls by Region](securityhub-regions.md#securityhub-regions-control-support).

## [CodeArtifact.1]CodeArtifact repositories should be tagged
<a name="codeartifact-1"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::CodeArtifact::Repository`

**AWS Config rule:** `tagged-codeartifact-repository` (custom Security Hub CSPM rule)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  | No default value  | 

This control checks whether an AWS CodeArtifact repository has tags with the specific keys defined in the parameter `requiredTagKeys`. The control fails if the repository doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredTagKeys`. If the parameter `requiredTagKeys` isn't provided, the control only checks for the existence of a tag key and fails if the repository isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [What is ABAC for AWS?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Tagging your AWS resources](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *AWS General Reference*.

### Remediation
<a name="codeartifact-1-remediation"></a>

To add tags to a CodeArtifact repository, see [Tag a repository in CodeArtifact](https://docs.aws.amazon.com/codeartifact/latest/ug/tag-repositories.html) in the *AWS CodeArtifact User Guide*.

# Security Hub CSPM controls for CodeBuild
<a name="codebuild-controls"></a>

These Security Hub CSPM controls evaluate the AWS CodeBuild service and resources.

These controls may not be available in all AWS Regions. For more information, see [Availability of controls by Region](securityhub-regions.md#securityhub-regions-control-support).

## [CodeBuild.1] CodeBuild Bitbucket source repository URLs should not contain sensitive credentials
<a name="codebuild-1"></a>

**Related requirements:** NIST.800-53.r5 SA-3, PCI DSS v3.2.1/8.2.1, PCI DSS v4.0.1/8.3.2

**Category:** Protect > Secure development

**Severity:** Critical

**Resource type:** `AWS::CodeBuild::Project`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/codebuild-project-source-repo-url-check.html](https://docs.aws.amazon.com/config/latest/developerguide/codebuild-project-source-repo-url-check.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether an AWS CodeBuild project Bitbucket source repository URL contains personal access tokens or a user name and password. The control fails if the Bitbucket source repository URL contains personal access tokens or a user name and password.

**Note**  
This control evaluates both the primary source and secondary sources of a CodeBuild build project. For more information about project sources, see [Multiple input sources and output artifacts sample](https://docs.aws.amazon.com/codebuild/latest/userguide/sample-multi-in-out.html) in the *AWS CodeBuild User Guide*.

Sign-in credentials shouldn't be stored or transmitted in clear text or appear in the source repository URL. Instead of personal access tokens or sign-in credentials, you should access your source provider in CodeBuild, and change your source repository URL to contain only the path to the Bitbucket repository location. Using personal access tokens or sign-in credentials could result in unintended data exposure or unauthorized access.

### Remediation
<a name="codebuild-1-remediation"></a>

You can update your CodeBuild project to use OAuth.

**To remove basic authentication / (GitHub) Personal Access Token from CodeBuild project source**

1. Open the CodeBuild console at [https://console.aws.amazon.com/codebuild/](https://console.aws.amazon.com/codebuild/).

1. Choose the build project that contains personal access tokens or a user name and password.

1. From **Edit**, choose **Source**.

1. Choose **Disconnect from GitHub / Bitbucket**.

1. Choose **Connect using OAuth**, then choose **Connect to GitHub / Bitbucket**.

1. When prompted, choose **authorize as appropriate**.

1. Reconfigure your repository URL and additional configuration settings, as needed.

1. Choose **Update source**.

For more information, refer to [CodeBuild use case-based samples](https://docs.aws.amazon.com/codebuild/latest/userguide/use-case-based-samples.html) in the *AWS CodeBuild User Guide*.

## [CodeBuild.2] CodeBuild project environment variables should not contain clear text credentials
<a name="codebuild-2"></a>

**Related requirements:** NIST.800-53.r5 IA-5(7), NIST.800-53.r5 SA-3, PCI DSS v3.2.1/8.2.1, PCI DSS v4.0.1/8.3.2

**Category:** Protect > Secure development

**Severity:** Critical

**Resource type:** `AWS::CodeBuild::Project`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/codebuild-project-envvar-awscred-check.html](https://docs.aws.amazon.com/config/latest/developerguide/codebuild-project-envvar-awscred-check.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether the project contains the environment variables `AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY`.

Authentication credentials `AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY` should never be stored in clear text, as this could lead to unintended data exposure and unauthorized access.

### Remediation
<a name="codebuild-2-remediation"></a>

To remove environment variables from a CodeBuild project, see [Change a build project's settings in AWS CodeBuild](https://docs.aws.amazon.com/codebuild/latest/userguide/change-project.html) in the *AWS CodeBuild User Guide*. Ensure nothing is selected for **Environment variables**.

You can store environment variables with sensitive values in the AWS Systems Manager Parameter Store or AWS Secrets Manager and then retrieve them from your build spec. For instructions, see the box labeled **Important** in the [Environment section](https://docs.aws.amazon.com/codebuild/latest/userguide/change-project-console.html#change-project-console-environment) in the *AWS CodeBuild User Guide*.

## [CodeBuild.3] CodeBuild S3 logs should be encrypted
<a name="codebuild-3"></a>

**Related requirements:** NIST.800-53.r5 CA-9(1), NIST.800-53.r5 CM-3(6), NIST.800-53.r5 SC-13, NIST.800-53.r5 SC-28, NIST.800-53.r5 SC-28(1), NIST.800-53.r5 SI-7(6), PCI DSS v4.0.1/10.3.2

**Category:** Protect > Data Protection > Encryption of data-at-rest

**Severity:** Low

**Resource type:** `AWS::CodeBuild::Project`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/codebuild-project-s3-logs-encrypted.html](https://docs.aws.amazon.com/config/latest/developerguide/codebuild-project-s3-logs-encrypted.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks if Amazon S3 logs for an AWS CodeBuild project are encrypted. The control fails if encryption is deactivated for S3 logs for a CodeBuild project.

Encryption of data at rest is a recommended best practice to add a layer of access management around your data. Encrypting the logs at rest reduces the risk that a user not authenticated by AWS will access the data stored on disk. It adds another set of access controls to limit the ability of unauthorized users to access the data. 

### Remediation
<a name="codebuild-3-remediation"></a>

To change the encryption settings for CodeBuild project S3 logs, see [Change a build project's settings in AWS CodeBuild](https://docs.aws.amazon.com/codebuild/latest/userguide/change-project.html) in the *AWS CodeBuild User Guide*.

## [CodeBuild.4] CodeBuild project environments should have a logging AWS Configuration
<a name="codebuild-4"></a>

**Related requirements:** NIST.800-53.r5 AC-2(12), NIST.800-53.r5 AC-2(4), NIST.800-53.r5 AC-4(26), NIST.800-53.r5 AC-6(9), NIST.800-53.r5 AU-10, NIST.800-53.r5 AU-12, NIST.800-53.r5 AU-2, NIST.800-53.r5 AU-3, NIST.800-53.r5 AU-6(3), NIST.800-53.r5 AU-6(4), NIST.800-53.r5 AU-9(7), NIST.800-53.r5 CA-7, NIST.800-53.r5 SC-7(9), NIST.800-53.r5 SI-3(8), NIST.800-53.r5 SI-4, NIST.800-53.r5 SI-4(20), NIST.800-53.r5 SI-7(8)

**Category:** Identify > Logging

**Severity:** Medium

**Resource type:** `AWS::CodeBuild::Project`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/codebuild-project-logging-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/codebuild-project-logging-enabled.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether a CodeBuild project environment has at least one log option, either to S3 or CloudWatch logs enabled. This control fails if a CodeBuild project environment does not have at least one log option enabled. 

From a security perspective, logging is an important feature to enable for future forensics efforts in the case of any security incidents. Correlating anomalies in CodeBuild projects with threat detections can increase confidence in the accuracy of those threat detections.

### Remediation
<a name="codebuild-4-remediation"></a>

For more information on how to configure CodeBuild project log settings, see [Create a build project (console)](https://docs.aws.amazon.com/codebuild/latest/userguide/create-project-console.html#create-project-console-logs) in the CodeBuild User Guide.

## [CodeBuild.5] CodeBuild project environments should not have privileged mode enabled
<a name="codebuild-5"></a>

**Important**  
Security Hub CSPM retired this control in April 2024. For more information, see [Change log for Security Hub CSPM controls](controls-change-log.md).

**Related requirements:** NIST.800-53.r5 AC-2(1), NIST.800-53.r5 AC-3, NIST.800-53.r5 AC-3(15), NIST.800-53.r5 AC-3(7), NIST.800-53.r5 AC-5, NIST.800-53.r5 AC-6, NIST.800-53.r5 AC-6(10), NIST.800-53.r5 AC-6(2)

**Category:** Protect > Secure Access Management

**Severity:** High

**Resource type:** `AWS::CodeBuild::Project`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/codebuild-project-environment-privileged-check.html](https://docs.aws.amazon.com/config/latest/developerguide/codebuild-project-environment-privileged-check.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether an AWS CodeBuild project environment has privileged mode enabled or disabled. The control fails if an CodeBuild project environment has privileged mode enabled.

By default, Docker containers do not allow access to any devices. Privileged mode grants a build project's Docker container access to all devices. Setting `privilegedMode` with value `true` permits the Docker daemon to run inside a Docker container. The Docker daemon listens for Docker API requests and manages Docker objects such as images, containers, networks, and volumes. This parameter should only be set to true if the build project is used to build Docker images. Otherwise, this setting should be disabled to prevent unintended access to Docker APIs as well as the container's underlying hardware. Setting `privilegedMode` to `false` helps protect critical resources from tampering and deletion.

### Remediation
<a name="codebuild-5-remediation"></a>

To configure CodeBuild project environment settings, see [ Create a build project (console)](https://docs.aws.amazon.com/codebuild/latest/userguide/create-project-console.html#create-project-console-environment) in the *CodeBuild User Guide*. In the **Environment** section, don't select the **Privileged** setting.

## [CodeBuild.7] CodeBuild report group exports should be encrypted at rest
<a name="codebuild-7"></a>

**Category:** Protect > Data Protection > Encryption of data-at-rest

**Severity:** Medium

**Resource type:** `AWS::CodeBuild::ReportGroup`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/codebuild-report-group-encrypted-at-rest.html](https://docs.aws.amazon.com/config/latest/developerguide/codebuild-report-group-encrypted-at-rest.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether the test results of an AWS CodeBuild report group that are exported to an Amazon Simple Storage Service (Amazon S3) bucket are encrypted at rest. The control fails if the report group export isn't encrypted at rest.

Data at rest refers to data that's stored in persistent, non-volatile storage for any duration. Encrypting data at rest helps you protect its confidentiality, which reduces the risk that an unauthorized user can access it.

### Remediation
<a name="codebuild-7-remediation"></a>

To encrypt the report group export to S3, see [Update a report group](https://docs.aws.amazon.com/codebuild/latest/userguide/report-group-export-settings.html) in the *AWS CodeBuild User Guide*.

# Security Hub CSPM controls for Amazon CodeGuru Profiler
<a name="codeguruprofiler-controls"></a>

These Security Hub CSPM controls evaluate the Amazon CodeGuru Profiler service and resources.

These controls may not be available in all AWS Regions. For more information, see [Availability of controls by Region](securityhub-regions.md#securityhub-regions-control-support).

## [CodeGuruProfiler.1] CodeGuru Profiler profiling groups should be tagged
<a name="codeguruprofiler-1"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::CodeGuruProfiler::ProfilingGroup`

**AWS Config rule:** `codeguruprofiler-profiling-group-tagged`

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredKeyTags  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  | No default value  | 

This control checks whether an Amazon CodeGuru Profiler profiling group has tags with the specific keys defined in the parameter `requiredKeyTags`. The control fails if the profiling group doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredKeyTags`. If the parameter `requiredKeyTags` isn't provided, the control only checks for the existence of a tag key and fails if the profiling group isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [Define permissions based on attributes with ABAC authorization](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Best practices and strategies](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *Tagging AWS Resources and Tag Editor User Guide*.

### Remediation
<a name="codeguruprofiler-1-remediation"></a>

To add tags to a CodeGuru Profiler profiling group, see [Tagging profiling groups](https://docs.aws.amazon.com/codeguru/latest/profiler-ug/tagging-profiling-groups.html) in the *Amazon CodeGuru Profiler User Guide*.

# Security Hub CSPM controls for Amazon CodeGuru Reviewer
<a name="codegurureviewer-controls"></a>

These Security Hub CSPM controls evaluate the Amazon CodeGuru Reviewer service and resources.

These controls may not be available in all AWS Regions. For more information, see [Availability of controls by Region](securityhub-regions.md#securityhub-regions-control-support).

## [CodeGuruReviewer.1] CodeGuru Reviewer repository associations should be tagged
<a name="codegurureviewer-1"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::CodeGuruReviewer::RepositoryAssociation`

**AWS Config rule:** `codegurureviewer-repository-association-tagged`

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredKeyTags  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  | No default value  | 

This control checks whether an Amazon CodeGuru Reviewer repository association has tags with the specific keys defined in the parameter `requiredKeyTags`. The control fails if the repository association doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredKeyTags`. If the parameter `requiredKeyTags` isn't provided, the control only checks for the existence of a tag key and fails if the repository association isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [Define permissions based on attributes with ABAC authorization](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Best practices and strategies](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *Tagging AWS Resources and Tag Editor User Guide*.

### Remediation
<a name="codegurureviewer-1-remediation"></a>

To add tags to a CodeGuru Reviewer repository association, see [Tagging a repository association](https://docs.aws.amazon.com/codeguru/latest/reviewer-ug/tag-repository-association.html) in the *Amazon CodeGuru Reviewer User Guide*.

# Security Hub CSPM controls for Amazon Cognito
<a name="cognito-controls"></a>

These AWS Security Hub CSPM controls evaluate the Amazon Cognito service and resources. The controls might not be available in all AWS Regions. For more information, see [Availability of controls by Region](securityhub-regions.md#securityhub-regions-control-support).

## [Cognito.1] Cognito user pools should have threat protection activated with full function enforcement mode for standard authentication
<a name="cognito-1"></a>

**Category:** Protect > Secure access management

**Severity:** Medium

**Resource type:** `AWS::Cognito::UserPool`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/cognito-user-pool-advanced-security-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/cognito-user-pool-advanced-security-enabled.html)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  `SecurityMode`  |  The threat protection enforcement mode that the control checks for.  |  String  |  `AUDIT`, `ENFORCED`  |  `ENFORCED`  | 

This control checks whether an Amazon Cognito user pool has threat protection activated with the enforcement mode set to full function for standard authentication. The control fails if the user pool has threat protection deactivated or if the enforcement mode isn't set to full function for standard authentication. Unless you provide custom parameter values, Security Hub CSPM uses the default value of `ENFORCED` for enforcement mode set to full function for standard authentication.

After you create an Amazon Cognito user pool, you can activate threat protection and customize the actions that are taken in response to different risks. Or, you can use audit mode to gather metrics on detected risks without applying any security mitigations. In audit mode, threat protection publishes metrics to Amazon CloudWatch. You can see metrics after Amazon Cognito generates its first event.

### Remediation
<a name="cognito-1-remediation"></a>

For information about activating threat protection for an Amazon Cognito user pool, see [Advanced security with threat protection](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pool-settings-threat-protection.html) in the *Amazon Cognito Developer Guide*.

## [Cognito.2] Cognito identity pools should not allow unauthenticated identities
<a name="cognito-2"></a>

**Category:** Protect > Secure access management > Passwordless authentication

**Severity:** Medium

**Resource type:** `AWS::Cognito::IdentityPool`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/cognito-identity-pool-unauth-access-check.html](https://docs.aws.amazon.com/config/latest/developerguide/cognito-identity-pool-unauth-access-check.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether an Amazon Cognito identity pool is configured to allow unauthenticated identities. The control fails if guest access is activated (the `AllowUnauthenticatedIdentities` parameter is set to `true`) for the identity pool.

If an Amazon Cognito identity pool allows unauthenticated identities, the identity pool provides temporary AWS credentials to users who haven't authenticated through an identity provider (guests). This creates security risks because it allows anonymous access to AWS resources. If you deactivate guest access, you can help ensure that only properly authenticated users can access your AWS resources, which reduces the risk of unauthorized access and potential security breaches. As a best practice, an identity pool should require authentication through supported identity providers. If unauthenticated access is necessary, it's important to carefully restrict permissions for unauthenticated identities, and regularly review and monitor their usage.

### Remediation
<a name="cognito-2-remediation"></a>

For information about deactivating guest access for an Amazon Cognito identity pool, see [Activate or deactivate guest access](https://docs.aws.amazon.com/cognito/latest/developerguide/identity-pools.html#enable-or-disable-unauthenticated-identities) in the *Amazon Cognito Developer Guide*.

## [Cognito.3] Password policies for Cognito user pools should have strong configurations
<a name="cognito-3"></a>

**Category:** Protect > Secure access management

**Severity:** Medium

**Resource type:** `AWS::Cognito::UserPool`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/cognito-user-pool-password-policy-check.html](https://docs.aws.amazon.com/config/latest/developerguide/cognito-user-pool-password-policy-check.html)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  `minLength`  | The minimum number of characters that a password must contain.  | Integer | `8` to `128` | `8 ` | 
|  `requireLowercase`  | Require at least one lowercase character in a password.  | Boolean | `True`, `False` | `True`  | 
|  `requireUppercase`  | Require at least one uppercase character in a password.  | Boolean | `True`, `False` | `True`  | 
|  `requireNumbers`  | Require at least one number in a password.  | Boolean | `True`, `False` | `True`  | 
|  `requireSymbols`  | Require at least one symbol in a password.  | Boolean | `True`, `False` | `True`  | 
|  `temporaryPasswordValidity`  | The maximum number of days that a password can exist before it expires.  | Integer | `1` to `365` | `7`  | 

This control checks whether the password policy for an Amazon Cognito user pool requires the use of strong passwords, based on recommended settings for password policies. The control fails if the password policy for the user pool doesn't require strong passwords. You can optionally specify custom values for the policy settings that the control checks.

Strong passwords are a security best practice for Amazon Cognito user pools. Weak passwords can expose users' credentials to systems that guess passwords and try to access data. This is especially the case for applications that are open to the internet. Password policies are a central element of the security of user directories. By using a password policy, you can configure a user pool to require password complexity and other settings that comply with your security standards and requirements.

### Remediation
<a name="cognito-3-remediation"></a>

For information about creating or updating the password policy for an Amazon Cognito user pool, see [Adding user pool password requirements](https://docs.aws.amazon.com/cognito/latest/developerguide/managing-users-passwords.html#user-pool-settings-policies) in the *Amazon Cognito Developer Guide*.

## [Cognito.4] Cognito user pools should have threat protection activated with full function enforcement mode for custom authentication
<a name="cognito-4"></a>

**Category:** Protect > Secure access management

**Severity:** Medium

**Resource type:** `AWS::Cognito::UserPool`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/cognito-userpool-cust-auth-threat-full-check.html](https://docs.aws.amazon.com/config/latest/developerguide/cognito-userpool-cust-auth-threat-full-check.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether an Amazon Cognito user pool has threat protection activated with the enforcement mode set to full function for custom authentication. The control fails if the user pool has threat protection disabled or if the enforcement mode isn't set to full function for custom authentication.

Threat protection, formerly called advanced security features, is a set of monitoring tools for unwanted activity in your user pool, and configuration tools to automatically shut down potentially malicious activity. After you create an Amazon Cognito user pool, you can activate threat protection with full function enforcement mode for custom authentication and customize the actions that are taken in response to different risks. Full-function mode includes a set of automatic reactions to detect unwanted activity and compromised passwords.

### Remediation
<a name="cognito-4-remediation"></a>

For information about activating threat protection for an Amazon Cognito user pool, see [Advanced security with threat protection](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pool-settings-threat-protection.html) in the *Amazon Cognito Developer Guide*.

## [Cognito.5] MFA should be enabled for Cognito user pools
<a name="cognito-5"></a>

**Category:** Protect > Secure access management > Multi-factor authentication

**Severity:** Medium

**Resource type:** `AWS::Cognito::UserPool`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/cognito-user-pool-mfa-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/cognito-user-pool-mfa-enabled.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether an Amazon Cognito user pool configured with a password-only sign-in policy has multi-factor authentication (MFA) enabled. The control fails if the user pool configured with a password-only sign-in policy does not have MFA enabled.

Multi-factor authentication (MFA) adds a something you have authentication factor to the something you know factor (typically username and password). For federated users, Amazon Cognito delegates authentication to the identity provider (IdP) and doesn't offer additional authentication factors. However, if you have local users with password authentication, configuring MFA for the user pool increases their security.

**Note**  
This control is not applicable for federated users and users signing in with passwordless factors.

### Remediation
<a name="cognito-5-remediation"></a>

For information about how to configure MFA for an Amazon Cognito user pool, see [Adding MFA to a user pool](https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-settings-mfa.html) in the *Amazon Cognito Developer Guide*.

## [Cognito.6] Cognito user pools should have deletion protection enabled
<a name="cognito-6"></a>

**Category:** Protect > Data Protection > Data deletion protection

**Severity:** Medium

**Resource type:** `AWS::Cognito::UserPool`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/cognito-user-pool-deletion-protection-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/cognito-user-pool-deletion-protection-enabled.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether an Amazon Cognito user pool has deletion protection enabled. The control fails if deletion protection is disabled for the user pool.

Deletion protection helps ensure that your user pool is not accidentally deleted. When you configure a user pool with deletion protection, the pool cannot be deleted by any user. Deletion protection prevents you from requesting the deletion of a user pool unless you first modify the pool and deactivate deletion protection.

### Remediation
<a name="cognito-6-remediation"></a>

To configure deletion protection for an Amazon Cognito user pool, see [User pool deletion protection ](https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-settings-deletion-protection.html) in the *Amazon Cognito Developer Guide*.

# Security Hub CSPM controls for AWS Config
<a name="config-controls"></a>

These Security Hub CSPM controls evaluate the AWS Config service and resources.

These controls may not be available in all AWS Regions. For more information, see [Availability of controls by Region](securityhub-regions.md#securityhub-regions-control-support).

## [Config.1] AWS Config should be enabled and use the service-linked role for resource recording
<a name="config-1"></a>

**Related requirements:** CIS AWS Foundations Benchmark v5.0.0/3.3, CIS AWS Foundations Benchmark v1.2.0/2.5, CIS AWS Foundations Benchmark v1.4.0/3.5, CIS AWS Foundations Benchmark v3.0.0/3.3, NIST.800-53.r5 CM-3, NIST.800-53.r5 CM-6(1), NIST.800-53.r5 CM-8, NIST.800-53.r5 CM-8(2), PCI DSS v3.2.1/10.5.2, PCI DSS v3.2.1/11.5

**Category:** Identify > Inventory

**Severity:** Critical

**Resource type:** `AWS::::Account`

**AWS Config rule:** None (custom Security Hub CSPM rule)

**Schedule type:** Periodic

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  `includeConfigServiceLinkedRoleCheck`  |  The control doesn’t evaluate whether AWS Config uses the service-linked role if the parameter is set to `false`.  |  Boolean  |  `true` or `false`  |  `true`  | 

This control checks whether AWS Config is enabled in your account in the current AWS Region, records all resources that correspond to controls that are enabled in the current Region, and uses the [service-linked AWS Config role](https://docs.aws.amazon.com/config/latest/developerguide/using-service-linked-roles.html). The name of the service-linked role is **AWSServiceRoleForConfig**. If you don't use the service-linked role and don't set the `includeConfigServiceLinkedRoleCheck` parameter to `false`, the control fails because other roles might not have the necessary permissions for AWS Config to accurately record your resources.

The AWS Config service performs configuration management of supported AWS resources in your account and delivers log files to you. The recorded information includes the configuration item (AWS resource), relationships between configuration items, and any configuration changes within resources. Global resources are resources that are available in any Region.

The control is evaluated as follows:
+ If the current Region is set as your [aggregation Region](finding-aggregation.md), the control produces `PASSED` findings only if AWS Identity and Access Management (IAM) global resources are recorded (if you have enabled controls that require them).
+ If the current Region is set as a linked Region, the control doesn’t evaluate whether IAM global resources are recorded.
+ If the current Region isn’t in your aggregator, or if cross-Region aggregation isn’t set up in your account, the control produces `PASSED` findings only if IAM global resources are recorded (if you have enabled controls that require them).

Control results aren't impacted by whether you choose daily or continuous recording of changes in resource state in AWS Config. However, the results of this control can change when new controls are released if you have configured automatic enablement of new controls or have a central configuration policy that automatically enables new controls. In these cases, if you don't record all resources, you must configure recording for resources that are associated with new controls in order to receive a `PASSED` finding.

Security Hub CSPM security checks work as intended only if you enable AWS Config in all Regions and configure resource recording for controls that require it.

**Note**  
Config.1 requires that AWS Config is enabled in all Regions in which you use Security Hub CSPM.  
Since Security Hub CSPM is a Regional service, the check performed for this control evaluates only the current Region for the account.  
To allow security checks against IAM global resources in a Region, you must record IAM global resources in that Region. Regions that don’t have IAM global resources recorded will receive a default `PASSED` finding for controls that check IAM global resources. Since IAM global resources are identical across AWS Regions, we recommend that you record IAM global resources in only the home Region (if cross-Region aggregation is enabled in your account). IAM resources will be recorded only in the Region in which global resource recording is turned on.  
The IAM globally recorded resource types that AWS Config supports are IAM users, groups, roles, and customer managed policies. You can consider disabling Security Hub CSPM controls that check these resource types in Regions where global resource recording is turned off. For more information, see [Suggested controls to disable in Security Hub CSPM](controls-to-disable.md).

### Remediation
<a name="config-1-remediation"></a>

In the home Region and Regions that aren’t part of an aggregator, record all resources that are required for controls that are enabled in the current Region, including IAM global resources if you have enabled controls that require IAM global resources.

In linked Regions, you can use any AWS Config recording mode, as long as you are recording all resources that correspond to controls that are enabled in the current Region. In linked Regions, if you have enabled controls that require recording of IAM global resources, you won’t receive a `FAILED` finding (your recording of other resources is sufficient).

The `StatusReasons` field in the `Compliance` object of your finding can help you determine why you have a failed finding for this control. For more information, see [Compliance details for control findings](controls-findings-create-update.md#control-findings-asff-compliance).

For a list of which resources must be recorded for each control, see [Required AWS Config resources for control findings](controls-config-resources.md). For general information about enabling AWS Config and configuring resource recording, see [Enabling and configuring AWS Config for Security Hub CSPM](securityhub-setup-prereqs.md).

# Security Hub CSPM controls for Amazon Connect
<a name="connect-controls"></a>

These Security Hub CSPM controls evaluate the Amazon Connect service and resources.

These controls may not be available in all AWS Regions. For more information, see [Availability of controls by Region](securityhub-regions.md#securityhub-regions-control-support).

## [Connect.1] Amazon Connect Customer Profiles object types should be tagged
<a name="connect-1"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::CustomerProfiles::ObjectType`

**AWS Config rule:** `customerprofiles-object-type-tagged`

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredKeyTags  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  | No default value  | 

This control checks whether an Amazon Connect Customer Profiles object type has tags with the specific keys defined in the parameter `requiredKeyTags`. The control fails if the object type doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredKeyTags`. If the parameter `requiredKeyTags` isn't provided, the control only checks for the existence of a tag key and fails if the object type isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [Define permissions based on attributes with ABAC authorization](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Best practices and strategies](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *Tagging AWS Resources and Tag Editor User Guide*.

### Remediation
<a name="connect-1-remediation"></a>

To add tags to a Customer Profiles object type, see [Add tags to resources in Amazon Connect](https://docs.aws.amazon.com/connect/latest/adminguide/tagging.html) in the *Amazon Connect Administrator Guide*.

## [Connect.2] Amazon Connect instances should have CloudWatch logging enabled
<a name="connect-2"></a>

**Category:** Identify > Logging

**Severity:** Medium

**Resource type:** `AWS::Connect::Instance`

**AWS Config rule:** [connect-instance-logging-enabled](https://docs.aws.amazon.com/config/latest/developerguide/connect-instance-logging-enabled.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether an Amazon Connect instance is configured to generate and store flow logs in an Amazon CloudWatch log group. The control fails if the Amazon Connect instance isn't configured to generate and store flow logs in a CloudWatch log group.

Amazon Connect flow logs provide real-time details about events in Amazon Connect flows. A *flow* defines the customer experience with an Amazon Connect contact center from start to finish. By default, when you create a new Amazon Connect instance, an Amazon CloudWatch log group is created automatically to store flow logs for the instance. Flow logs can help you analyze flows, find errors, and monitor operational metrics. You can also set up alerts for specific events that can occur in a flow.

### Remediation
<a name="connect-2-remediation"></a>

For information about enabling flow logs for an Amazon Connect instance, see [Enable Amazon Connect flow logs in an Amazon CloudWatch log group](https://docs.aws.amazon.com/connect/latest/adminguide/contact-flow-logs.html) in the *Amazon Connect Administrator Guide*.

# Security Hub CSPM controls for Amazon Data Firehose
<a name="datafirehose-controls"></a>

These Security Hub CSPM controls evaluate the Amazon Data Firehose service and resources.

These controls may not be available in all AWS Regions. For more information, see [Availability of controls by Region](securityhub-regions.md#securityhub-regions-control-support).

## [DataFirehose.1] Firehose delivery streams should be encrypted at rest
<a name="datafirehose-1"></a>

**Related requirements:** NIST.800-53.r5 AC-3, NIST.800-53.r5 AU-3, NIST.800-53.r5 SC-12, NIST.800-53.r5 SC-13, NIST.800-53.r5 SC-28

**Category:** Protect > Data Protection > Encryption of data-at-rest

**Severity:** Medium

**Resource type:** `AWS::KinesisFirehose::DeliveryStream`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/kinesis-firehose-delivery-stream-encrypted.html](https://docs.aws.amazon.com/config/latest/developerguide/kinesis-firehose-delivery-stream-encrypted.html)

**Schedule type:** Periodic

**Parameters:** None 

This control checks whether an Amazon Data Firehose delivery stream is encrypted at rest with server-side encryption. This control fails if a Firehose delivery stream isn't encrypted at rest with server-side encryption.

Server-side encryption is a feature in Amazon Data Firehose delivery streams that automatically encrypts data before it's at rest by using a key created in AWS Key Management Service (AWS KMS). Data is encrypted before it's written to the Data Firehose stream storage layer, and decrypted after it’s retrieved from storage. This allows you to comply with regulatory requirements and enhance the security of your data.

### Remediation
<a name="datafirehose-1-remediation"></a>

To enable server-side encryption on Firehose delivery streams,, see [Data Protection in Amazon Data Firehose](https://docs.aws.amazon.com/firehose/latest/dev/encryption.html) in the *Amazon Data Firehose Developer Guide*.

# Security Hub CSPM controls for AWS Database Migration Service
<a name="dms-controls"></a>

These AWS Security Hub CSPM controls evaluate the AWS Database Migration Service (AWS DMS) and AWS DMS resources. The controls might not be available in all AWS Regions. For more information, see [Availability of controls by Region](securityhub-regions.md#securityhub-regions-control-support).

## [DMS.1] Database Migration Service replication instances should not be public
<a name="dms-1"></a>

**Related requirements:** NIST.800-53.r5 AC-21, NIST.800-53.r5 AC-3, NIST.800-53.r5 AC-3(7), NIST.800-53.r5 AC-4, NIST.800-53.r5 AC-4(21), NIST.800-53.r5 AC-6, NIST.800-53.r5 SC-7, NIST.800-53.r5 SC-7(11), NIST.800-53.r5 SC-7(16), NIST.800-53.r5 SC-7(20), NIST.800-53.r5 SC-7(21), NIST.800-53.r5 SC-7(3), NIST.800-53.r5 SC-7(4), NIST.800-53.r5 SC-7(9), PCI DSS v3.2.1/1.2.1,PCI DSS v3.2.1/1.3.1,PCI DSS v3.2.1/1.3.4,PCI DSS v3.2.1/1.3.2,PCI DSS v3.2.1/1.3.6, PCI DSS v4.0.1/1.4.4

**Category:** Protect > Secure network configuration

**Severity:** Critical

**Resource type:** `AWS::DMS::ReplicationInstance`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/dms-replication-not-public.html](https://docs.aws.amazon.com/config/latest/developerguide/dms-replication-not-public.html)

**Schedule type:** Periodic

**Parameters:** None

This control checks whether AWS DMS replication instances are public. To do this, it examines the value of the `PubliclyAccessible` field.

A private replication instance has a private IP address that you cannot access outside of the replication network. A replication instance should have a private IP address when the source and target databases are in the same network. The network must also be connected to the replication instance's VPC using a VPN, Direct Connect, or VPC peering. To learn more about public and private replication instances, see [Public and private replication instances](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_ReplicationInstance.html#CHAP_ReplicationInstance.PublicPrivate) in the *AWS Database Migration Service User Guide*.

You should also ensure that access to your AWS DMS instance configuration is limited to only authorized users. To do this, restrict users' IAM permissions to modify AWS DMS settings and resources.

### Remediation
<a name="dms-1-remediation"></a>

You can't change the public access setting for a DMS replication instance after creating it. To change the public access setting, [delete your current instance](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_ReplicationInstance.Deleting.html), and then [recreate it](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_ReplicationInstance.Creating.html). Don't select the **Publicly accessible** option.

## [DMS.2] DMS certificates should be tagged
<a name="dms-2"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::DMS::Certificate`

**AWS Config rule:** `tagged-dms-certificate` (custom Security Hub CSPM rule)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  |  No default value  | 

This control checks whether an AWS DMS certificate has tags with the specific keys defined in the parameter `requiredTagKeys`. The control fails if the certificate doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredTagKeys`. If the parameter `requiredTagKeys` isn't provided, the control only checks for the existence of a tag key and fails if the certificate isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [What is ABAC for AWS?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Tagging your AWS resources](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *AWS General Reference*.

### Remediation
<a name="dms-2-remediation"></a>

To add tags to a DMS certificate, see [Tagging resources in AWS Database Migration Service](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Tagging.html) in the *AWS Database Migration Service User Guide*.

## [DMS.3] DMS event subscriptions should be tagged
<a name="dms-3"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::DMS::EventSubscription`

**AWS Config rule:** `tagged-dms-eventsubscription` (custom Security Hub CSPM rule)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  |  No default value  | 

This control checks whether an AWS DMS event subscription has tags with the specific keys defined in the parameter `requiredTagKeys`. The control fails if the event subscription doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredTagKeys`. If the parameter `requiredTagKeys` isn't provided, the control only checks for the existence of a tag key and fails if the event subscription isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [What is ABAC for AWS?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Tagging your AWS resources](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *AWS General Reference*.

### Remediation
<a name="dms-3-remediation"></a>

To add tags to a DMS event subscription, see [Tagging resources in AWS Database Migration Service](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Tagging.html) in the *AWS Database Migration Service User Guide*.

## [DMS.4] DMS replication instances should be tagged
<a name="dms-4"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::DMS::ReplicationInstance`

**AWS Config rule:** `tagged-dms-replicationinstance` (custom Security Hub CSPM rule)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  |  No default value  | 

This control checks whether an AWS DMS replication instance has tags with the specific keys defined in the parameter `requiredTagKeys`. The control fails if the replication instance doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredTagKeys`. If the parameter `requiredTagKeys` isn't provided, the control only checks for the existence of a tag key and fails if the replication instance isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [What is ABAC for AWS?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Tagging your AWS resources](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *AWS General Reference*.

### Remediation
<a name="dms-4-remediation"></a>

To add tags to a DMS replication instance, see [Tagging resources in AWS Database Migration Service](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Tagging.html) in the *AWS Database Migration Service User Guide*.

## [DMS.5] DMS replication subnet groups should be tagged
<a name="dms-5"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::DMS::ReplicationSubnetGroup`

**AWS Config rule:** `tagged-dms-replicationsubnetgroup` (custom Security Hub CSPM rule)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  |  No default value  | 

This control checks whether an AWS DMS replication subnet group has tags with the specific keys defined in the parameter `requiredTagKeys`. The control fails if the replication subnet group doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredTagKeys`. If the parameter `requiredTagKeys` isn't provided, the control only checks for the existence of a tag key and fails if the replication subnet group isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [What is ABAC for AWS?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Tagging your AWS resources](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *AWS General Reference*.

### Remediation
<a name="dms-5-remediation"></a>

To add tags to a DMS replication subnet group, see [Tagging resources in AWS Database Migration Service](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Tagging.html) in the *AWS Database Migration Service User Guide*.

## [DMS.6] DMS replication instances should have automatic minor version upgrade enabled
<a name="dms-6"></a>

**Related requirements:** NIST.800-53.r5 SI-2, NIST.800-53.r5 SI-2(2), NIST.800-53.r5 SI-2(4), NIST.800-53.r5 SI-2(5), PCI DSS v4.0.1/6.3.3

**Category:** Identify > Vulnerability, patch, and version management

**Severity:** Medium

**Resource type:** `AWS::DMS::ReplicationInstance`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/dms-auto-minor-version-upgrade-check.html](https://docs.aws.amazon.com/config/latest/developerguide/dms-auto-minor-version-upgrade-check.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks if automatic minor version upgrade is enabled for an AWS DMS replication instance. The control fails if automatic minor version upgrade isn't enabled for a DMS replication instance.

DMS provides automatic minor version upgrade to each supported replication engine so that you can keep your replication instance up-to-date. Minor versions can introduce new software features, bug fixes, security patches, and performance improvements. By enabling automatic minor version upgrade on DMS replication instances, minor upgrades are applied automatically during the maintenance window or immediately if the **Apply changes immediately option is chosen**.

### Remediation
<a name="dms-6-remediation"></a>

To enable automatic minor version upgrade on DMS replication instances, see [Modifying a replication instance](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_ReplicationInstance.Modifying.html) in the *AWS Database Migration Service User Guide*.

## [DMS.7] DMS replication tasks for the target database should have logging enabled
<a name="dms-7"></a>

**Related requirements:** NIST.800-53.r5 AC-2(4), NIST.800-53.r5 AC-4(26), NIST.800-53.r5 AC-6(9), NIST.800-53.r5 AU-10, NIST.800-53.r5 AU-12, NIST.800-53.r5 AU-2, NIST.800-53.r5 AU-3, NIST.800-53.r5 AU-6(3), NIST.800-53.r5 AU-6(4), NIST.800-53.r5 CA-7, NIST.800-53.r5 SC-7(9), NIST.800-53.r5 SI-3(8), NIST.800-53.r5 SI-4(20), NIST.800-53.r5 SI-7(8), PCI DSS v4.0.1/10.4.2

**Category:** Identify > Logging

**Severity:** Medium

**Resource type:** `AWS::DMS::ReplicationTask`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/dms-replication-task-targetdb-logging.html](https://docs.aws.amazon.com/config/latest/developerguide/dms-replication-task-targetdb-logging.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether logging is enabled with the minimum severity level of `LOGGER_SEVERITY_DEFAULT` for DMS replication tasks `TARGET_APPLY` and `TARGET_LOAD`. The control fails if logging isn't enabled for these tasks or if the minimum severity level is less than `LOGGER_SEVERITY_DEFAULT`.

DMS uses Amazon CloudWatch to log information during the migration process. Using logging task settings, you can specify which component activities are logged and how much information is logged. You should specify logging for the following tasks:
+ `TARGET_APPLY` – Data and data definition language (DDL) statements are applied to the target database.
+ `TARGET_LOAD` – Data is loaded into the target database.

Logging plays a critical role in DMS replication tasks by enabling monitoring, troubleshooting, auditing, performance analysis, error detection, and recovery, as well as historical analysis and reporting. It helps ensure the successful replication of data between databases while maintaining data integrity and compliance with regulatory requirements. Logging levels other than `DEFAULT` are rarely needed for these components during troubleshooting. We recommend keeping the logging level as `DEFAULT` for these components unless specifically requested to change it by Support. A minimal logging level of `DEFAULT` ensures that informational messages, warnings, and error messages are written to the logs. This control checks if the logging level is at least one of the following for the preceding replication tasks: `LOGGER_SEVERITY_DEFAULT`, `LOGGER_SEVERITY_DEBUG`, or `LOGGER_SEVERITY_DETAILED_DEBUG`.

### Remediation
<a name="dms-7-remediation"></a>

To enable logging for target database DMS replication tasks, see [Viewing and managing AWS DMS task logs](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Monitoring.html#CHAP_Monitoring.ManagingLogs) in the *AWS Database Migration Service User Guide*.

## [DMS.8] DMS replication tasks for the source database should have logging enabled
<a name="dms-8"></a>

**Related requirements:** NIST.800-53.r5 AC-2(4), NIST.800-53.r5 AC-4(26), NIST.800-53.r5 AC-6(9), NIST.800-53.r5 AU-10, NIST.800-53.r5 AU-12, NIST.800-53.r5 AU-2, NIST.800-53.r5 AU-3, NIST.800-53.r5 AU-6(3), NIST.800-53.r5 AU-6(4), NIST.800-53.r5 CA-7, NIST.800-53.r5 SC-7(9), NIST.800-53.r5 SI-3(8), NIST.800-53.r5 SI-4(20), NIST.800-53.r5 SI-7(8), PCI DSS v4.0.1/10.4.2

**Category:** Identify > Logging

**Severity:** Medium

**Resource type:** `AWS::DMS::ReplicationTask`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/dms-replication-task-sourcedb-logging.html](https://docs.aws.amazon.com/config/latest/developerguide/dms-replication-task-sourcedb-logging.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether logging is enabled with the minimum severity level of `LOGGER_SEVERITY_DEFAULT` for DMS replication tasks `SOURCE_CAPTURE` and `SOURCE_UNLOAD`. The control fails if logging isn't enabled for these tasks or if the minimum severity level is less than `LOGGER_SEVERITY_DEFAULT`.

DMS uses Amazon CloudWatch to log information during the migration process. Using logging task settings, you can specify which component activities are logged and how much information is logged. You should specify logging for the following tasks:
+ `SOURCE_CAPTURE` – Ongoing replication or change data capture (CDC) data is captured from the source database or service, and passed to the `SORTER` service component.
+ `SOURCE_UNLOAD` – Data is unloaded from the source database or service during full load.

Logging plays a critical role in DMS replication tasks by enabling monitoring, troubleshooting, auditing, performance analysis, error detection, and recovery, as well as historical analysis and reporting. It helps ensure the successful replication of data between databases while maintaining data integrity and compliance with regulatory requirements. Logging levels other than `DEFAULT` are rarely needed for these components during troubleshooting. We recommend keeping the logging level as `DEFAULT` for these components unless specifically requested to change it by Support. A minimal logging level of `DEFAULT` ensures that informational messages, warnings, and error messages are written to the logs. This control checks if the logging level is at least one of the following for the preceding replication tasks: `LOGGER_SEVERITY_DEFAULT`, `LOGGER_SEVERITY_DEBUG`, or `LOGGER_SEVERITY_DETAILED_DEBUG`.

### Remediation
<a name="dms-8-remediation"></a>

To enable logging for source database DMS replication tasks, see [Viewing and managing AWS DMS task logs](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Monitoring.html#CHAP_Monitoring.ManagingLogs) in the *AWS Database Migration Service User Guide*.

## [DMS.9] DMS endpoints should use SSL
<a name="dms-9"></a>

**Related requirements:** NIST.800-53.r5 AC-4, NIST.800-53.r5 SC-13, NIST.800-53.r5 SC-23, NIST.800-53.r5 SC-23(3), NIST.800-53.r5 SC-7(4), NIST.800-53.r5 SC-8, NIST.800-53.r5 SC-8(1), NIST.800-53.r5 SC-8(2), PCI DSS v4.0.1/4.2.1

**Category:** Protect > Data Protection > Encryption of data-in-transit

**Severity:** Medium

**Resource type:** `AWS::DMS::Endpoint`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/dms-endpoint-ssl-configured.html](https://docs.aws.amazon.com/config/latest/developerguide/dms-endpoint-ssl-configured.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether an AWS DMS endpoint uses an SSL connection. The control fails if the endpoint doesn't use SSL.

SSL/TLS connections provide a layer of security by encrypting connections between DMS replication instances and your database. Using certificates provides an extra layer of security by validating that the connection is being made to the expected database. It does so by checking the server certificate that is automatically installed on all database instances that you provision. By enabling SSL connection on your DMS endpoints, you protect the confidentiality of the data during the migration.

### Remediation
<a name="dms-9-remediation"></a>

To add an SSL connection to a new or existing DMS endpoint, see [Using SSL with AWS Database Migration Service](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Security.SSL.html#CHAP_Security.SSL.Procedure) in the *AWS Database Migration Service User Guide*.

## [DMS.10] DMS endpoints for Neptune databases should have IAM authorization enabled
<a name="dms-10"></a>

**Related requirements:** NIST.800-53.r5 AC-2, NIST.800-53.r5 AC-3, NIST.800-53.r5 AC-6, NIST.800-53.r5 AC-17, NIST.800-53.r5 IA-2, NIST.800-53.r5 IA-5, PCI DSS v4.0.1/7.3.1

**Category:** Protect > Secure access management > Passwordless authentication

**Severity:** Medium

**Resource type:** `AWS::DMS::Endpoint`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/dms-neptune-iam-authorization-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/dms-neptune-iam-authorization-enabled.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether an AWS DMS endpoint for an Amazon Neptune database is configured with IAM authorization. The control fails if the DMS endpoint doesn't have IAM authorization enabled.

AWS Identity and Access Management (IAM) provides fine-grained access control across AWS. With IAM, you can specify who can access which services and resources, and under which conditions. With IAM policies, you manage permissions to your workforce and systems to ensure least-privilege permissions. By enabling IAM authorization on AWS DMS endpoints for Neptune databases, you can grant authorization privileges to IAM users by using a service role specified by the `ServiceAccessRoleARN` parameter.

### Remediation
<a name="dms-10-remediation"></a>

To enable IAM authorization on DMS endpoints for Neptune databases, see [Using Amazon Neptune as a target for AWS Database Migration Service](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Target.Neptune.html) in the *AWS Database Migration Service User Guide*.

## [DMS.11] DMS endpoints for MongoDB should have an authentication mechanism enabled
<a name="dms-11"></a>

**Related requirements:** NIST.800-53.r5 AC-3, NIST.800-53.r5 AC-6, NIST.800-53.r5 IA-2, NIST.800-53.r5 IA-5, PCI DSS v4.0.1/7.3.1

**Category:** Protect > Secure access management > Passwordless authentication

**Severity:** Medium

**Resource type:** `AWS::DMS::Endpoint`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/dms-mongo-db-authentication-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/dms-mongo-db-authentication-enabled.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether an AWS DMS endpoint for MongoDB is configured with an authentication mechanism. The control fails if an authentication type isn't set for the endpoint.

AWS Database Migration Service supports two authentications methods for MongoDB—**MONGODB-CR** for MongoDB version 2.x, and **SCRAM-SHA-1** for MongoDB version 3.x or later. These authentication methods are used to authenticate and encrypt MongoDB passwords if users want to use the passwords to access the databases. Authentication on AWS DMS endpoints ensures that only authorized users can access and modify the data being migrated between databases. Without proper authentication, unauthorized users may be able to gain access to sensitive data during the migration process. This can result in data breaches, data loss, or other security incidents.

### Remediation
<a name="dms-11-remediation"></a>

To enable an authentication mechanism on DMS endpoints for MongoDB, see [Using MongoDB as a source for AWS DMS](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Source.MongoDB.html) in the *AWS Database Migration Service User Guide*.

## [DMS.12] DMS endpoints for Redis OSS should have TLS enabled
<a name="dms-12"></a>

**Related requirements:** NIST.800-53.r5 SC-8, NIST.800-53.r5 SC-13, PCI DSS v4.0.1/4.2.1

**Category:** Protect > Data Protection > Encryption of data-in-transit

**Severity:** Medium

**Resource type:** `AWS::DMS::Endpoint`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/dms-redis-tls-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/dms-redis-tls-enabled.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether an AWS DMS endpoint for Redis OSS is configured with a TLS connection. The control fails if the endpoint doesn't have TLS enabled.

TLS provides end-to-end security when data is sent between applications or databases over the internet. When you configure SSL encryption for your DMS endpoint, it enables encrypted communication between the source and target databases during the migration process. This helps prevent eavesdropping and interception of sensitive data by malicious actors. Without SSL encryption, sensitive data may be accessed, resulting in data breaches, data loss, or other security incidents.

### Remediation
<a name="dms-12-remediation"></a>

To enable a TLS connection on DMS endpoints for Redis, see [Using Redis as a target for AWS Database Migration Service](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Target.Redis.html) in the *AWS Database Migration Service User Guide*.

## [DMS.13] DMS replication instances should be configured to use multiple Availability Zones
<a name="dms-13"></a>

**Category:** Recover > Resilience > High availability

**Severity:** Medium

**Resource type:** `AWS::DMS::ReplicationInstance`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/dms-replication-instance-multi-az-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/dms-replication-instance-multi-az-enabled.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether an AWS Database Migration Service (AWS DMS) replication instance is configured to use multiple Availability Zones (Multi-AZ deployment). The control fails if the AWS DMS replication instance isn't configured to use a Multi-AZ deployment.

In a Multi-AZ deployment, AWS DMS automatically provisions and maintains a standby replica of a replication instance in a different Availability Zone (AZ). The primary replication instance is then synchronously replicated to the standby replica. If the primary replication instance fails or becomes unresponsive, the standby resumes any running tasks with minimal interruption. For more information, see [Working with a replication instance](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_ReplicationInstance.html) in the *AWS Database Migration Service User Guide*.

### Remediation
<a name="dms-13-remediation"></a>

After you create an AWS DMS replication instance, you can change the Multi-AZ deployment setting for it. For information about changing this and other settings for an existing replication instance, see [Modifying a replication instance](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_ReplicationInstance.Modifying.html) in the *AWS Database Migration Service User Guide*.

# Security Hub CSPM controls for AWS DataSync
<a name="datasync-controls"></a>

These Security Hub CSPM controls evaluate the AWS DataSync service and resources. The controls might not be available in all AWS Regions. For more information, see [Availability of controls by Region](securityhub-regions.md#securityhub-regions-control-support).

## [DataSync.1] DataSync tasks should have logging enabled
<a name="datasync-1"></a>

**Category:** Identify > Logging

**Severity:** Medium

**Resource type:** `AWS::DataSync::Task`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/datasync-task-logging-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/datasync-task-logging-enabled.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether an AWS DataSync task has logging enabled. The control fails if the task doesn't have logging enabled.

Audit logs track and monitor system activities. They provide a record of events that can help you detect security breaches, investigate incidents, and comply with regulations. Audit logs also enhance the overall accountability and transparency of your organization.

### Remediation
<a name="datasync-1-remediation"></a>

For information about configuring logging for AWS DataSync tasks, see [Monitoring data transfers with Amazon CloudWatch Logs](https://docs.aws.amazon.com/datasync/latest/userguide/configure-logging.html) in the *AWS DataSync User Guide*.

## [DataSync.2] DataSync tasks should be tagged
<a name="datasync-2"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::DataSync::Task`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/datasync-task-tagged.html](https://docs.aws.amazon.com/config/latest/developerguide/datasync-task-tagged.html)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
| requiredKeyTags | A list of non-system tag keys that must be assigned to an evaluated resource. Tag keys are case sensitive. | StringList (maximum of 6 items) | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions). | No default value | 

This control checks whether an AWS DataSync task has the tag keys specified by the `requiredKeyTags` parameter. The control fails if the task doesn't have any tag keys, or it doesn't have all the keys specified by the `requiredKeyTags` parameter. If you don't specify any values for the `requiredKeyTags` parameter, the control checks only for the existence of a tag key and fails if the task doesn't have any tag keys. The control ignores system tags, which are applied automatically and have the `aws:` prefix.

A tag is a label that you create and assign to an AWS resource. Each tag consists of a required tag key and an optional tag value. You can use tags to categorize resources by purpose, owner, environment, or other criteria. They can help you identify, organize, search for, and filter resources. They can also help you track resource owners for actions and notifications. You can also use tags to implement attribute-based access control (ABAC) as an authorization strategy. For more information about ABAC strategies, see [Define permissions based on attributes with ABAC authorization](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*. For more information about tags, see the [Tagging AWS Resources and Tag Editor User Guide](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html).

**Note**  
Do not store personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible from many AWS services. They aren't intended to be used for private or sensitive data.

### Remediation
<a name="datasync-2-remediation"></a>

For information about adding tags to an AWS DataSync task, see [Tagging your AWS DataSync tasks](https://docs.aws.amazon.com/datasync/latest/userguide/tagging-tasks.html) in the *AWS DataSync User Guide*.

# Security Hub CSPM controls for Amazon Detective
<a name="detective-controls"></a>

This AWS Security Hub CSPM control evaluates the Amazon Detective service and resources. The control might not be available in all AWS Regions. For more information, see [Availability of controls by Region](securityhub-regions.md#securityhub-regions-control-support).

## [Detective.1] Detective behavior graphs should be tagged
<a name="detective-1"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::Detective::Graph`

**AWS Config rule:** `tagged-detective-graph` (custom Security Hub CSPM rule)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  |  No default value  | 

This control checks whether an Amazon Detective behavior graph has tags with the specific keys defined in the parameter `requiredTagKeys`. The control fails if the behavior graph doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredTagKeys`. If the parameter `requiredTagKeys` isn't provided, the control only checks for the existence of a tag key and fails if the behavior graph isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [What is ABAC for AWS?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Tagging your AWS resources](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *AWS General Reference*.

### Remediation
<a name="detective-1-remediation"></a>

To add tags to a Detective behavior graph, see [Adding tags to a behavior graph](https://docs.aws.amazon.com/detective/latest/adminguide/graph-tags.html#graph-tags-add-console) in the *Amazon Detective Administration Guide*.

# Security Hub CSPM controls for Amazon DocumentDB
<a name="documentdb-controls"></a>

These AWS Security Hub CSPM controls evaluate the Amazon DocumentDB (with MongoDB compatibility) service and resources. The controls might not be available in all AWS Regions. For more information, see [Availability of controls by Region](securityhub-regions.md#securityhub-regions-control-support).

## [DocumentDB.1] Amazon DocumentDB clusters should be encrypted at rest
<a name="documentdb-1"></a>

**Related requirements:** NIST.800-53.r5 CA-9(1), NIST.800-53.r5 CM-3(6), NIST.800-53.r5 SC-13, NIST.800-53.r5 SC-28, NIST.800-53.r5 SC-28(1), NIST.800-53.r5 SC-7(10), NIST.800-53.r5 SI-7(6)

**Category:** Protect > Data Protection > Encryption of data-at-rest

**Severity:** Medium

**Resource type:** `AWS::RDS::DBCluster`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/docdb-cluster-encrypted.html](https://docs.aws.amazon.com/config/latest/developerguide/docdb-cluster-encrypted.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether an Amazon DocumentDB cluster is encrypted at rest. The control fails if an Amazon DocumentDB cluster isn't encrypted at rest.

Data at rest refers to any data that's stored in persistent, non-volatile storage for any duration. Encryption helps you protect the confidentiality of such data, reducing the risk that an unauthorized user gets access to it. Data in Amazon DocumentDB clusters should be encrypted at rest for an added layer of security. Amazon DocumentDB uses the 256-bit Advanced Encryption Standard (AES-256) to encrypt your data using encryption keys stored in AWS Key Management Service (AWS KMS).

### Remediation
<a name="documentdb-1-remediation"></a>

You can enable encryption at rest when you create an Amazon DocumentDB cluster. You can't change encryption settings after creating a cluster. For more information, see [Enabling encryption at rest for an Amazon DocumentDB cluster](https://docs.aws.amazon.com/documentdb/latest/developerguide/encryption-at-rest.html#encryption-at-rest-enabling) in the *Amazon DocumentDB Developer Guide*.

## [DocumentDB.2] Amazon DocumentDB clusters should have an adequate backup retention period
<a name="documentdb-2"></a>

**Related requirements:** NIST.800-53.r5 SI-12, PCI DSS v4.0.1/3.2.1

**Category:** Recover > Resilience > Backups enabled

**Severity:** Medium

**Resource type:** `AWS::RDS::DBCluster`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/docdb-cluster-backup-retention-check.html](https://docs.aws.amazon.com/config/latest/developerguide/docdb-cluster-backup-retention-check.html)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  `minimumBackupRetentionPeriod`  |  Minimum backup retention period in days  |  Integer  |  `7` to `35`  |  `7`  | 

This control checks whether an Amazon DocumentDB cluster has a backup retention period greater than or equal to the specified time frame. The control fails if the backup retention period is less than the specified time frame. Unless you provide a custom parameter value for the backup retention period, Security Hub CSPM uses a default value of 7 days.

Backups help you recover more quickly from a security incident and strengthen the resilience of your systems. By automating backups for your Amazon DocumentDB clusters, you'll be able to restore your systems to a point in time and minimize downtime and data loss. In Amazon DocumentDB, clusters have a default backup retention period of 1 day. This must be increased to a value between 7 and 35 days to pass this control.

### Remediation
<a name="documentdb-2-remediation"></a>

To change the backup retention period for your Amazon DocumentDB clusters, see [Modifying an Amazon DocumentDB cluster](https://docs.aws.amazon.com/documentdb/latest/developerguide/db-cluster-modify.html) in the *Amazon DocumentDB Developer Guide*. For **Backup**, choose the backup retention period.

## [DocumentDB.3] Amazon DocumentDB manual cluster snapshots should not be public
<a name="documentdb-3"></a>

**Related requirements:** NIST.800-53.r5 AC-21, NIST.800-53.r5 AC-3, NIST.800-53.r5 AC-3(7), NIST.800-53.r5 AC-4, NIST.800-53.r5 AC-4(21), NIST.800-53.r5 AC-6, NIST.800-53.r5 SC-7, NIST.800-53.r5 SC-7(11), NIST.800-53.r5 SC-7(16), NIST.800-53.r5 SC-7(20), NIST.800-53.r5 SC-7(21), NIST.800-53.r5 SC-7(3), NIST.800-53.r5 SC-7(4), NIST.800-53.r5 SC-7(9), PCI DSS v4.0.1/1.4.4

**Category:** Protect > Secure network configuration

**Severity:** Critical

**Resource type:** `AWS::RDS::DBClusterSnapshot`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/docdb-cluster-snapshot-public-prohibited.html](https://docs.aws.amazon.com/config/latest/developerguide/docdb-cluster-snapshot-public-prohibited.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether an Amazon DocumentDB manual cluster snapshot is public. The control fails if the manual cluster snapshot is public.

An Amazon DocumentDB manual cluster snapshot should not be public unless intended. If you share an unencrypted manual snapshot as public, the snapshot is available to all AWS accounts. Public snapshots may result in unintended data exposure.

**Note**  
This control evaluates manual cluster snapshots. You can't share an Amazon DocumentDB automated cluster snapshot. However, you can create a manual snapshot by copying the automated snapshot, and then share the copy.

### Remediation
<a name="documentdb-3-remediation"></a>

To remove public access for Amazon DocumentDB manual cluster snapshots, see [Sharing a snapshot](https://docs.aws.amazon.com/documentdb/latest/developerguide/backup_restore-share_cluster_snapshots.html#backup_restore-share_snapshots) in the *Amazon DocumentDB Developer Guide*. Programmatically, you can use the Amazon DocumentDB operation `modify-db-snapshot-attribute`. Set `attribute-name` as `restore` and `values-to-remove` as `all`.

## [DocumentDB.4] Amazon DocumentDB clusters should publish audit logs to CloudWatch Logs
<a name="documentdb-4"></a>

**Related requirements:** NIST.800-53.r5 AC-2(4), NIST.800-53.r5 AC-4(26), NIST.800-53.r5 AC-6(9), NIST.800-53.r5 AU-10, NIST.800-53.r5 AU-12, NIST.800-53.r5 AU-2, NIST.800-53.r5 AU-3, NIST.800-53.r5 AU-6(3), NIST.800-53.r5 AU-6(4), NIST.800-53.r5 CA-7, NIST.800-53.r5 SC-7(9), NIST.800-53.r5 SI-3(8), NIST.800-53.r5 SI-4(20), NIST.800-53.r5 SI-7(8), PCI DSS v4.0.1/10.3.3

**Category:** Identify > Logging

**Severity:** Medium

**Resource type:** `AWS::RDS::DBCluster`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/docdb-cluster-audit-logging-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/docdb-cluster-audit-logging-enabled.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether an Amazon DocumentDB cluster publishes audit logs to Amazon CloudWatch Logs. The control fails if the cluster doesn't publish audit logs to CloudWatch Logs.

Amazon DocumentDB (with MongoDB compatibility) allows you to audit events that were performed in your cluster. Examples of logged events include successful and failed authentication attempts, dropping a collection in a database, or creating an index. By default, auditing is disabled in Amazon DocumentDB and requires that you take action to enable it.

### Remediation
<a name="documentdb-4-remediation"></a>

To publish Amazon DocumentDB audit logs to CloudWatch Logs, see [Enabling auditing](https://docs.aws.amazon.com/documentdb/latest/developerguide/event-auditing.html#event-auditing-enabling-auditing) in the *Amazon DocumentDB Developer Guide*.

## [DocumentDB.5] Amazon DocumentDB clusters should have deletion protection enabled
<a name="documentdb-5"></a>

**Related requirements:** NIST.800-53.r5 CA-9(1), NIST.800-53.r5 CM-2, NIST.800-53.r5 CM-2(2), NIST.800-53.r5 CM-3, NIST.800-53.r5 SC-5(2)

**Category:** Protect > Data protection > Data deletion protection

**Severity:** Medium

**Resource type:** `AWS::RDS::DBCluster`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/docdb-cluster-deletion-protection-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/docdb-cluster-deletion-protection-enabled.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether an Amazon DocumentDB cluster has deletion protection enabled. The control fails if the cluster doesn't have deletion protection enabled.

Enabling cluster deletion protection offers an additional layer of protection against accidental database deletion or deletion by an unauthorized user. An Amazon DocumentDB cluster can't be deleted while deletion protection is enabled. You must first disable deletion protection before a delete request can succeed. Deletion protection is enabled by default when you create a cluster in the Amazon DocumentDB console.

### Remediation
<a name="documentdb-5-remediation"></a>

To enable deletion protection for an existing Amazon DocumentDB cluster, see [Modifying an Amazon DocumentDB cluster](https://docs.aws.amazon.com/documentdb/latest/developerguide/db-cluster-modify.html) in the *Amazon DocumentDB Developer Guide*. In the **Modify Cluster** section, choose **Enable** for **Deletion protection**.

## [DocumentDB.6] Amazon DocumentDB clusters should be encrypted in transit
<a name="documentdb-6"></a>

**Category:** Protect > Data Protection > Encryption of data-in-transit

**Severity:** Medium

**Resource type:** `AWS::RDS::DBCluster`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/docdb-cluster-encrypted-in-transit.html](https://docs.aws.amazon.com/config/latest/developerguide/docdb-cluster-encrypted-in-transit.html)

**Schedule type:** Periodic

**Parameters:** `excludeTlsParameters`: `disabled`, `enabled` (not customizable)

This controls checks whether an Amazon DocumentDB cluster requires TLS for connections to the cluster. The control fails if the cluster parameter group associated with the cluster is not in sync, or the TLS cluster parameter is set to `disabled` or `enabled`.

You can use TLS to encrypt the connection between an application and an Amazon DocumentDB cluster. Use of TLS can help protect data from being intercepted while the data is in transit between an application and an Amazon DocumentDB cluster. Encryption in transit for an Amazon DocumentDB cluster is managed using the TLS parameter in the cluster parameter group that's associated with the cluster. When encryption in transit is enabled, secure connections using TLS are required to connect to the cluster. We recommend using the following TLS parameters: `tls1.2+`, `tls1.3+`, and `fips-140-3`.

### Remediation
<a name="documentdb-6-remediation"></a>

For information about changing the TLS settings for an Amazon DocumentDB cluster, see [Encrypting data in transit](https://docs.aws.amazon.com/documentdb/latest/developerguide/security.encryption.ssl.html) in the *Amazon DocumentDB Developer Guide*.

# Security Hub CSPM controls for DynamoDB
<a name="dynamodb-controls"></a>

These AWS Security Hub CSPM controls evaluate the Amazon DynamoDB service and resources. The controls might not be available in all AWS Regions. For more information, see [Availability of controls by Region](securityhub-regions.md#securityhub-regions-control-support).

## [DynamoDB.1] DynamoDB tables should automatically scale capacity with demand
<a name="dynamodb-1"></a>

**Related requirements:** NIST.800-53.r5 CP-10, NIST.800-53.r5 CP-2(2), NIST.800-53.r5 CP-6(2), NIST.800-53.r5 SC-36, NIST.800-53.r5 SC-5(2), NIST.800-53.r5 SI-13(5)

**Category:** Recover > Resilience > High availability

**Severity:** Medium

**Resource type:** `AWS::DynamoDB::Table`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/dynamodb-autoscaling-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/dynamodb-autoscaling-enabled.html)

**Schedule type:** Periodic

**Parameters:**


| Parameter | Description | Type | Valid custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  `minProvisionedReadCapacity`  |  Minimum number of provisioned read capacity units for DynamoDB auto scaling  |  Integer  |  `1` to `40000`  |  No default value  | 
|  `targetReadUtilization`  |  Target utilization percentage for read capacity  |  Integer  |  `20` to `90`  |  No default value  | 
|  `minProvisionedWriteCapacity`  |  Minimum number of provisioned write capacity units for DynamoDB auto scaling  |  Integer  |  `1` to `40000`  |  No default value  | 
|  `targetWriteUtilization`  |  Target utilization percentage for write capacity  |  Integer  |  `20` to `90`  |  No default value  | 

This control checks whether an Amazon DynamoDB table can scale its read and write capacity as needed. The control fails if the table doesn't use on-demand capacity mode or provisioned mode with auto scaling configured. By default, this control only requires that one of these modes be configured, without regard to specific levels of read or write capacity. Optionally, you can provide custom parameter values to require specific levels of read and write capacity or target utilization.

Scaling capacity with demand avoids throttling exceptions, which helps to maintain availability of your applications. DynamoDB tables that use on-demand capacity mode are limited only by the DynamoDB throughput default table quotas. To raise these quotas, you can file a support ticket with Support. DynamoDB tables that use provisioned mode with auto scaling adjust the provisioned throughput capacity dynamically in response to traffic patterns. For more information about DynamoDB request throttling, see [Request throttling and burst capacity](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/ProvisionedThroughput.html#ProvisionedThroughput.Throttling) in the *Amazon DynamoDB Developer Guide*.

### Remediation
<a name="dynamodb-1-remediation"></a>

To enable DynamoDB automatic scaling on existing tables in capacity mode, see [Enabling DynamoDB auto scaling on existing tables](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.Console.html#AutoScaling.Console.ExistingTable) in the *Amazon DynamoDB Developer Guide*.

## [DynamoDB.2] DynamoDB tables should have point-in-time recovery enabled
<a name="dynamodb-2"></a>

**Related requirements:** NIST.800-53.r5 CP-10, NIST.800-53.r5 CP-6(2), NIST.800-53.r5 CP-9, NIST.800-53.r5 SC-5(2), NIST.800-53.r5 SI-12, NIST.800-53.r5 SI-13(5)

**Category:** Recover > Resilience > Backups enabled

**Severity:** Medium

**Resource type:** `AWS::DynamoDB::Table`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/dynamodb-pitr-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/dynamodb-pitr-enabled.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether point-in-time recovery (PITR) is enabled for an Amazon DynamoDB table.

Backups help you to recover more quickly from a security incident. They also strengthen the resilience of your systems. DynamoDB point-in-time recovery automates backups for DynamoDB tables. It reduces the time to recover from accidental delete or write operations. DynamoDB tables that have PITR enabled can be restored to any point in time in the last 35 days.

### Remediation
<a name="dynamodb-2-remediation"></a>

To restore a DynamoDB table to a point in time, see [Restoring a DynamoDB table to a point in time](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/PointInTimeRecovery.Tutorial.html) in the *Amazon DynamoDB Developer Guide*.

## [DynamoDB.3] DynamoDB Accelerator (DAX) clusters should be encrypted at rest
<a name="dynamodb-3"></a>

**Related requirements:** NIST.800-53.r5 CA-9(1), NIST.800-53.r5 CM-3(6), NIST.800-53.r5 SC-13, NIST.800-53.r5 SC-28, NIST.800-53.r5 SC-28(1), NIST.800-53.r5 SC-7(10), NIST.800-53.r5 SI-7(6)

**Category:** Protect > Data Protection > Encryption of data-at-rest

**Severity:** Medium

**Resource type:** `AWS::DAX::Cluster`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/dax-encryption-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/dax-encryption-enabled.html)

**Schedule type:** Periodic

**Parameters:** None

This control checks whether an Amazon DynamoDB Accelerator (DAX) cluster is encrypted at rest. The control fails if the DAX cluster isn't encrypted at rest.

Encrypting data at rest reduces the risk of data stored on disk being accessed by a user not authenticated to AWS. The encryption adds another set of access controls to limit the ability of unauthorized users to access to the data. For example, API permissions are required to decrypt the data before it can be read.

### Remediation
<a name="dynamodb-3-remediation"></a>

You cannot enable or disable encryption at rest after a cluster is created. You must recreate the cluster in order to enable encryption at rest. For detailed instructions on how to create a DAX cluster with encryption at rest enabled, see[ Enabling encryption at rest using the AWS Management Console](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/DAXEncryptionAtRest.html#dax.encryption.tutorial-console) in the *Amazon DynamoDB Developer Guide*.

## [DynamoDB.4] DynamoDB tables should be present in a backup plan
<a name="dynamodb-4"></a>

**Related requirements:** NIST.800-53.r5 CP-10, NIST.800-53.r5 CP-6, NIST.800-53.r5 CP-6(1), NIST.800-53.r5 CP-6(2), NIST.800-53.r5 CP-9, NIST.800-53.r5 SC-5(2), NIST.800-53.r5 SI-12, NIST.800-53.r5 SI-13(5)

**Category:** Recover > Resilience > Backups enabled

**Severity:** Medium

**Resource type:** `AWS::DynamoDB::Table`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/dynamodb-resources-protected-by-backup-plan.html](https://docs.aws.amazon.com/config/latest/developerguide/dynamodb-resources-protected-by-backup-plan.html) ``

**Schedule type:** Periodic

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  `backupVaultLockCheck`  |  The control produces a `PASSED` finding if the parameter is set to `true` and the resource uses AWS Backup Vault Lock.  |  Boolean  |  `true` or `false`  |  No default value  | 

This control evaluates whether an Amazon DynamoDB table in `ACTIVE` state is covered by a backup plan. The control fails if the DynamoDB table isn't covered by a backup plan. If you set the `backupVaultLockCheck` parameter equal to `true`, the control passes only if the DynamoDB table is backed up in an AWS Backup locked vault.

AWS Backup is a fully managed backup service that helps you centralize and automate the backing up of data across AWS services. With AWS Backup, you can create backup plans that define your backup requirements, such as how frequently to back up your data and how long to retain those backups. Including DynamoDB tables in your backup plans helps you protect your data from unintended loss or deletion.

### Remediation
<a name="dynamodb-4-remediation"></a>

To add a DynamoDB table to an AWS Backup backup plan, see [Assigning resources to a backup plan](https://docs.aws.amazon.com/aws-backup/latest/devguide/assigning-resources.html) in the *AWS Backup Developer Guide*.

## [DynamoDB.5] DynamoDB tables should be tagged
<a name="dynamodb-5"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::DynamoDB::Table`

**AWS Config rule:** `tagged-dynamodb-table` (custom Security Hub CSPM rule)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  |  No default value  | 

This control checks whether an Amazon DynamoDB table has tags with the specific keys defined in the parameter `requiredTagKeys`. The control fails if the table doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredTagKeys`. If the parameter `requiredTagKeys` isn't provided, the control only checks for the existence of a tag key and fails if the table isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [What is ABAC for AWS?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Tagging your AWS resources](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *AWS General Reference*.

### Remediation
<a name="dynamodb-5-remediation"></a>

To add tags to a DynamoDB table, see [Tagging resources in DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Tagging.Operations.html) in the *Amazon DynamoDB Developer Guide*.

## [DynamoDB.6] DynamoDB tables should have deletion protection enabled
<a name="dynamodb-6"></a>

**Related requirements:** NIST.800-53.r5 CA-9(1), NIST.800-53.r5 CM-2, NIST.800-53.r5 CM-2(2), NIST.800-53.r5 CM-3, NIST.800-53.r5 SC-5(2)

**Category:** Protect > Data protection > Data deletion protection

**Severity:** Medium

**Resource type:** `AWS::DynamoDB::Table`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/dynamodb-table-deletion-protection-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/dynamodb-table-deletion-protection-enabled.html) ``

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether an Amazon DynamoDB table has deletion protection enabled. The control fails if a DynamoDB table doesn't have deletion protection enabled.

You can protect a DynamoDB table from accidental deletion with the deletion protection property. Enabling this property for tables helps ensure that tables don't get accidentally deleted during regular table management operations by your administrators. This helps prevent disruption to your normal business operations.

### Remediation
<a name="dynamodb-6-remediation"></a>

To enable deletion protection for a DynamoDB table, see [Using deletion protection](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/WorkingWithTables.Basics.html#WorkingWithTables.Basics.DeletionProtection) in the *Amazon DynamoDB Developer Guide*.

## [DynamoDB.7] DynamoDB Accelerator clusters should be encrypted in transit
<a name="dynamodb-7"></a>

**Related requirements:** NIST.800-53.r5 AC-17, NIST.800-53.r5 SC-8, NIST.800-53.r5 SC-13, NIST.800-53.r5 SC-23, PCI DSS v4.0.1/4.2.1

**Category:** Protect > Data Protection > Encryption of data-in-transit

**Severity:** Medium

**Resource type:** `AWS::DAX::Cluster`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/dax-tls-endpoint-encryption.html](https://docs.aws.amazon.com/config/latest/developerguide/dax-tls-endpoint-encryption.html)

**Schedule type:** Periodic

**Parameters:** None

This control checks whether an Amazon DynamoDB Accelerator (DAX) cluster is encrypted in transit, with the endpoint encryption type set to TLS. The control fails if the DAX cluster isn't encrypted in transit.

HTTPS (TLS) can be used to help prevent potential attackers from using person-in-the-middle or similar attacks to eavesdrop on or manipulate network traffic. You should only allow encrypted connections over TLS to access DAX clusters. However, encrypting data in transit can affect performance. You should test your application with encryption turned on to understand the performance profile and the impact of TLS.

### Remediation
<a name="dynamodb-7-remediation"></a>

You can't change the TLS encryption setting after creating a DAX cluster. To encrypt an existing DAX cluster, create a new cluster with encryption in transit enabled, shift your application's traffic to it, and then delete the old cluster. For more information, see [Using deletion protection](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/WorkingWithTables.Basics.html#WorkingWithTables.Basics.DeletionProtection) in the *Amazon DynamoDB Developer Guide*.

# Security Hub CSPM controls for Amazon EC2
<a name="ec2-controls"></a>

These AWS Security Hub CSPM controls evaluate the Amazon Elastic Compute Cloud (Amazon EC2) service and resources. The controls might not be available in all AWS Regions. For more information, see [Availability of controls by Region](securityhub-regions.md#securityhub-regions-control-support).

## [EC2.1] Amazon EBS snapshots should not be configured to be publicly restorable
<a name="ec2-1"></a>

**Related requirements:** PCI DSS v3.2.1/1.2.1,PCI DSS v3.2.1/1.3.1,PCI DSS v3.2.1/1.3.4,PCI DSS v3.2.1/7.2.1, NIST.800-53.r5 AC-21, NIST.800-53.r5 AC-3, NIST.800-53.r5 AC-3(7), NIST.800-53.r5 AC-4, NIST.800-53.r5 AC-4(21), NIST.800-53.r5 AC-6, NIST.800-53.r5 SC-7, NIST.800-53.r5 SC-7(11), NIST.800-53.r5 SC-7(16), NIST.800-53.r5 SC-7(20), NIST.800-53.r5 SC-7(21), NIST.800-53.r5 SC-7(3), NIST.800-53.r5 SC-7(4), NIST.800-53.r5 SC-7(9)

**Category:** Protect > Secure network configuration

**Severity:** Critical 

**Resource type:** `AWS::::Account`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/ebs-snapshot-public-restorable-check.html](https://docs.aws.amazon.com/config/latest/developerguide/ebs-snapshot-public-restorable-check.html)

**Schedule type:** Periodic

**Parameters:** None

This control checks whether Amazon Elastic Block Store snapshots are configured to be publicly restorable. The control fails if Amazon EBS snapshots are configured to be restorable by all.

EBS snapshots are used to back up the data on your EBS volumes to Amazon S3 at a specific point in time. You can use the snapshots to restore previous states of EBS volumes. It is rarely acceptable to share a snapshot with the public. Typically the decision to share a snapshot publicly was made in error or without a complete understanding of the implications. This check helps ensure that all such sharing was fully planned and intentional.

### Remediation
<a name="ec2-1-remediation"></a>

To make a public EBS snapshot private, see [Share a snapshot](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-modifying-snapshot-permissions.html#share-unencrypted-snapshot) in the *Amazon EC2 User Guide*. For **Actions, Modify permissions**, choose **Private**.

## [EC2.2] VPC default security groups should not allow inbound or outbound traffic
<a name="ec2-2"></a>

**Related requirements:** CIS AWS Foundations Benchmark v5.0.0/5.5, PCI DSS v3.2.1/1.2.1,PCI DSS v3.2.1/1.3.4,PCI DSS v3.2.1/2.1, CIS AWS Foundations Benchmark v1.2.0/4.3, CIS AWS Foundations Benchmark v1.4.0/5.3, CIS AWS Foundations Benchmark v3.0.0/5.4, NIST.800-53.r5 AC-4, NIST.800-53.r5 AC-4(21), NIST.800-53.r5 SC-7, NIST.800-53.r5 SC-7(11), NIST.800-53.r5 SC-7(16), NIST.800-53.r5 SC-7(21), NIST.800-53.r5 SC-7(4), NIST.800-53.r5 SC-7(5)

**Category:** Protect > Secure network configuration

**Severity:** High 

**Resource type:** `AWS::EC2::SecurityGroup`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/vpc-default-security-group-closed.html](https://docs.aws.amazon.com/config/latest/developerguide/vpc-default-security-group-closed.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether the default security group of a VPC allows inbound or outbound traffic. The control fails if the security group allows inbound or outbound traffic.

The rules for the [default security group](https://docs.aws.amazon.com/vpc/latest/userguide/default-security-group.html) allow all outbound and inbound traffic from network interfaces (and their associated instances) that are assigned to the same security group. We recommend that you don't use the default security group. Because the default security group cannot be deleted, you should change the default security group rules setting to restrict inbound and outbound traffic. This prevents unintended traffic if the default security group is accidentally configured for resources such as EC2 instances.

### Remediation
<a name="ec2-2-remediation"></a>

To remediate this issue, start by creating new least-privilege security groups. For instructions, see [Create a security group](https://docs.aws.amazon.com/vpc/latest/userguide/security-groups.html#creating-security-groups) in the *Amazon VPC User Guide*. Then, assign the new security groups to your EC2 instances. For instructions, see [Change an instance's security group](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/working-with-security-groups.html#changing-security-group) in the *Amazon EC2 User Guide*.

After you assign the new security groups to your resources, remove all inbound and outbound rules from the default security groups. For instructions, see [Configure security group rules](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-security-group-rules.html) in the *Amazon VPC User Guide*.

## [EC2.3] Attached Amazon EBS volumes should be encrypted at-rest
<a name="ec2-3"></a>

**Related requirements:** NIST.800-53.r5 CA-9(1), NIST.800-53.r5 CM-3(6), NIST.800-53.r5 SC-13, NIST.800-53.r5 SC-28, NIST.800-53.r5 SC-28(1), NIST.800-53.r5 SC-7(10), NIST.800-53.r5 SI-7(6)

**Category:** Protect > Data Protection > Encryption of data-at-rest

**Severity:** Medium

**Resource type:** `AWS::EC2::Volume`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/encrypted-volumes.html](https://docs.aws.amazon.com/config/latest/developerguide/encrypted-volumes.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether the EBS volumes that are in an attached state are encrypted. To pass this check, EBS volumes must be in use and encrypted. If the EBS volume is not attached, then it is not subject to this check.

For an added layer of security of your sensitive data in EBS volumes, you should enable EBS encryption at rest. Amazon EBS encryption offers a straightforward encryption solution for your EBS resources that doesn't require you to build, maintain, and secure your own key management infrastructure. It uses KMS keys when creating encrypted volumes and snapshots.

To learn more about Amazon EBS encryption, see [Amazon EBS encryption](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html) in the *Amazon EC2 User Guide*.

### Remediation
<a name="ec2-3-remediation"></a>

There's no direct way to encrypt an existing unencrypted volume or snapshot. You can only encrypt a new volume or snapshot when you create it.

If you enabled encryption by default, Amazon EBS encrypts the resulting new volume or snapshot using your default key for Amazon EBS encryption. Even if you have not enabled encryption by default, you can enable encryption when you create an individual volume or snapshot. In both cases, you can override the default key for Amazon EBS encryption and choose a symmetric customer managed key.

For more information, see [Creating an Amazon EBS volume](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-creating-volume.html) and [Copying an Amazon EBS snapshot](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-copy-snapshot.html) in the *Amazon EC2 User Guide*.

## [EC2.4] Stopped EC2 instances should be removed after a specified time period
<a name="ec2-4"></a>

**Related requirements:** NIST.800-53.r5 CA-9(1), NIST.800-53.r5 CM-2, NIST.800-53.r5 CM-2(2)

**Category:** Identify > Inventory

**Severity:** Medium

**Resource type:** `AWS::EC2::Instance`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/ec2-stopped-instance.html](https://docs.aws.amazon.com/config/latest/developerguide/ec2-stopped-instance.html)

**Schedule type:** Periodic

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  `AllowedDays`  |  Number of days the EC2 instance is allowed to be in a stopped state before generating a failed finding.  |  Integer  |  `1` to `365`  |  `30`  | 

This control checks whether an Amazon EC2 instance has been stopped for longer than the allowed number of days. The control fails if an EC2 instance is stopped for longer than the maximum allowed time period. Unless you provide a custom parameter value for the maximum allowed time period, Security Hub CSPM uses a default value of 30 days.

When an EC2 instance has not run for a significant period of time, it creates a security risk because the instance is not being actively maintained (analyzed, patched, updated). If it is later launched, the lack of proper maintenance could result in unexpected issues in your AWS environment. To safely maintain an EC2 instance over time in an inactive state, start it periodically for maintenance and then stop it after maintenance. Ideally, this should be an automated process.

### Remediation
<a name="ec2-4-remediation"></a>

To terminate an inactive EC2 instance, see [Terminate an instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/terminating-instances.html#terminating-instances-console) in the *Amazon EC2 User Guide*.

## [EC2.6] VPC flow logging should be enabled in all VPCs
<a name="ec2-6"></a>

**Related requirements:** CIS AWS Foundations Benchmark v5.0.0/3.7, CIS AWS Foundations Benchmark v1.2.0/2.9, CIS AWS Foundations Benchmark v1.4.0/3.9, CIS AWS Foundations Benchmark v3.0.0/3.7, NIST.800-53.r5 AC-4(26), NIST.800-53.r5 AU-12, NIST.800-53.r5 AU-2, NIST.800-53.r5 AU-3, NIST.800-53.r5 AU-6(3), NIST.800-53.r5 AU-6(4), NIST.800-53.r5 CA-7, NIST.800-53.r5 SI-7(8), NIST.800-171.r2 3.1.20, NIST.800-171.r2 3.3.1, NIST.800-171.r2 3.13.1, PCI DSS v3.2.1/10.3.3, PCI DSS v3.2.1/10.3.4, PCI DSS v3.2.1/10.3.5, PCI DSS v3.2.1/10.3.6

**Category:** Identify > Logging

**Severity:** Medium

**Resource type:** `AWS::EC2::VPC`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/vpc-flow-logs-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/vpc-flow-logs-enabled.html)

**Schedule type:** Periodic

**Parameters:**
+ `trafficType`: `REJECT` (not customizable)

This control checks whether Amazon VPC Flow Logs are found and enabled for VPCs. The traffic type is set to `Reject`. The control fails if VPC Flow Logs aren't enabled for VPCs in your account.

**Note**  
This control doesn't check whether Amazon VPC Flow Logs are enabled through Amazon Security Lake for the AWS account.

With the VPC Flow Logs feature, you can capture information about the IP address traffic going to and from network interfaces in your VPC. After you create a flow log, you can view and retrieve its data in CloudWatch Logs. To reduce cost, you can also send your flow logs to Amazon S3. 

Security Hub CSPM recommends that you enable flow logging for packet rejects for VPCs. Flow logs provide visibility into network traffic that traverses the VPC and can detect anomalous traffic or provide insight during security workflows.

By default, the record includes values for the different components of the IP address flow, including the source, destination, and protocol. For more information and descriptions of the log fields, see [VPC Flow Logs](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html) in the *Amazon VPC User Guide*.

### Remediation
<a name="ec2-6-remediation"></a>

To create a VPC Flow Log, see [Create a Flow Log](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-flow-logs.html#create-flow-log) in the *Amazon VPC User Guide*. After you open the Amazon VPC console, choose **Your VPCs**. For **Filter**, choose **Reject** or **All**.

## [EC2.7] EBS default encryption should be enabled
<a name="ec2-7"></a>

**Related requirements:** CIS AWS Foundations Benchmark v5.0.0/5.1.1, CIS AWS Foundations Benchmark v1.4.0/2.2.1, CIS AWS Foundations Benchmark v3.0.0/2.2.1, NIST.800-53.r5 CA-9(1), NIST.800-53.r5 CM-3(6), NIST.800-53.r5 SC-13, NIST.800-53.r5 SC-28, NIST.800-53.r5 SC-28(1), NIST.800-53.r5 SC-7(10), NIST.800-53.r5 SI-7(6)

**Category:** Protect > Data Protection > Encryption of data-at-rest

**Severity:** Medium

**Resource type:** `AWS::::Account`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/ec2-ebs-encryption-by-default.html](https://docs.aws.amazon.com/config/latest/developerguide/ec2-ebs-encryption-by-default.html)

**Schedule type:** Periodic

**Parameters:** None

This control checks whether account-level encryption is enabled by default for Amazon Elastic Block Store (Amazon EBS) volumes. The control fails if the account level encryption isn't enabled for EBS volumes. 

When encryption is enabled for your account, Amazon EBS volumes and snapshot copies are encrypted at rest. This adds an additional layer of protection for your data. For more information, see [Encryption by default](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html#encryption-by-default) in the *Amazon EC2 User Guide*.

### Remediation
<a name="ec2-7-remediation"></a>

To configure default encryption for Amazon EBS volumes, see [Encryption by default](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html#encryption-by-default) in the *Amazon EC2 User Guide*.

## [EC2.8] EC2 instances should use Instance Metadata Service Version 2 (IMDSv2)
<a name="ec2-8"></a>

**Related requirements:** CIS AWS Foundations Benchmark v5.0.0/5.7, CIS AWS Foundations Benchmark v3.0.0/5.6, NIST.800-53.r5 AC-3, NIST.800-53.r5 AC-3(15), NIST.800-53.r5 AC-3(7), NIST.800-53.r5 AC-6, PCI DSS v4.0.1/2.2.6

**Category:** Protect > Network Security

**Severity:** High

**Resource type:** `AWS::EC2::Instance`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/ec2-imdsv2-check.html](https://docs.aws.amazon.com/config/latest/developerguide/ec2-imdsv2-check.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether your EC2 instance metadata version is configured with Instance Metadata Service Version 2 (IMDSv2). The control passes if `HttpTokens` is set to required for IMDSv2. The control fails if `HttpTokens` is set to `optional`.

You use instance metadata to configure or manage the running instance. The IMDS provides access to temporary, frequently rotated credentials. These credentials remove the need to hard code or distribute sensitive credentials to instances manually or programmatically. The IMDS is attached locally to every EC2 instance. It runs on a special "link local" IP address of 169.254.169.254. This IP address is only accessible by software that runs on the instance.

Version 2 of the IMDS adds new protections for the following types of vulnerabilities. These vulnerabilities could be used to try to access the IMDS.
+ Open website application firewalls
+ Open reverse proxies
+ Server-side request forgery (SSRF) vulnerabilities
+ Open Layer 3 firewalls and network address translation (NAT)

Security Hub CSPM recommends that you configure your EC2 instances with IMDSv2.

### Remediation
<a name="ec2-8-remediation"></a>

To configure EC2 instances with IMDSv2, see [Recommended path to requiring IMDSv2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-metadata-transition-to-version-2.html#recommended-path-for-requiring-imdsv2) in the *Amazon EC2 User Guide*.

## [EC2.9] Amazon EC2 instances should not have a public IPv4 address
<a name="ec2-9"></a>

**Related requirements:** NIST.800-53.r5 AC-21, NIST.800-53.r5 AC-3, NIST.800-53.r5 AC-3(7), NIST.800-53.r5 AC-4, NIST.800-53.r5 AC-4(21), NIST.800-53.r5 AC-6, NIST.800-53.r5 SC-7, NIST.800-53.r5 SC-7(11), NIST.800-53.r5 SC-7(16), NIST.800-53.r5 SC-7(20), NIST.800-53.r5 SC-7(21), NIST.800-53.r5 SC-7(3), NIST.800-53.r5 SC-7(4), NIST.800-53.r5 SC-7(9)

**Category:** Protect > Secure network configuration > Resources not publicly accessible

**Severity:** High

**Resource type:** `AWS::EC2::Instance`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/ec2-instance-no-public-ip.html](https://docs.aws.amazon.com/config/latest/developerguide/ec2-instance-no-public-ip.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether EC2 instances have a public IP address. The control fails if the `publicIp` field is present in the EC2 instance configuration item. This control applies to IPv4 addresses only. 

A public IPv4 address is an IP address that is reachable from the internet. If you launch your instance with a public IP address, then your EC2 instance is reachable from the internet. A private IPv4 address is an IP address that is not reachable from the internet. You can use private IPv4 addresses for communication between EC2 instances in the same VPC or in your connected private network.

IPv6 addresses are globally unique, and therefore are reachable from the internet. However, by default all subnets have the IPv6 addressing attribute set to false. For more information about IPv6, see [IP addressing in your VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html) in the *Amazon VPC User Guide*.

If you have a legitimate use case to maintain EC2 instances with public IP addresses, then you can suppress the findings from this control. For more information about front-end architecture options, see the [AWS Architecture Blog](https://aws.amazon.com/blogs/architecture/) or the [This Is My Architecture series](https://aws.amazon.com/this-is-my-architecture/?tma.sort-by=item.additionalFields.airDate&tma.sort-order=desc&awsf.category=categories%23mobile) AWS video series.

### Remediation
<a name="ec2-9-remediation"></a>

Use a non-default VPC so that your instance isn't assigned a public IP address by default.

When you launch an EC2 instance into a default VPC, it is assigned a public IP address. When you launch an EC2 instance into a non-default VPC, the subnet configuration determines whether it receives a public IP address. The subnet has an attribute to determine if new EC2 instances in the subnet receive a public IP address from the public IPv4 address pool.

You can disassociate an automatically-assigned public IP address from your EC2 instance. For more information, see [Public IPv4 addresses and external DNS hostnames](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-instance-addressing.html#concepts-public-addresses) in the *Amazon EC2 User Guide*.

## [EC2.10] Amazon EC2 should be configured to use VPC endpoints that are created for the Amazon EC2 service
<a name="ec2-10"></a>

**Related requirements:** NIST.800-53.r5 AC-21, NIST.800-53.r5 AC-3, NIST.800-53.r5 AC-3(7), NIST.800-53.r5 AC-4, NIST.800-53.r5 AC-4(21), NIST.800-53.r5 AC-6, NIST.800-53.r5 SC-7, NIST.800-53.r5 SC-7(11), NIST.800-53.r5 SC-7(16), NIST.800-53.r5 SC-7(20), NIST.800-53.r5 SC-7(21), NIST.800-53.r5 SC-7(3), NIST.800-53.r5 SC-7(4), NIST.800-171.r2 3.1.3, NIST.800-171.r2 3.13.1

**Category:** Protect > Secure network configuration > API private access

**Severity:** Medium

**Resource type:** `AWS::EC2::VPC`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/service-vpc-endpoint-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/service-vpc-endpoint-enabled.html)

**Schedule type:** Periodic

**Parameters:** 
+ `serviceName`: `ec2` (not customizable)

This control checks whether a service endpoint for Amazon EC2 is created for each VPC. The control fails if a VPC does not have a VPC endpoint created for the Amazon EC2 service. 

This control evaluates resources in single account. It cannot describe resources that are outside of the account. Because AWS Config and Security Hub CSPM do not conduct cross-account checks, you will see `FAILED` findings for VPCs that are shared across accounts. Security Hub CSPM recommends that you suppress these `FAILED` findings.

To improve the security posture of your VPC, you can configure Amazon EC2 to use an interface VPC endpoint. Interface endpoints are powered by AWS PrivateLink, a technology that enables you to access Amazon EC2 API operations privately. It restricts all network traffic between your VPC and Amazon EC2 to the Amazon network. Because endpoints are supported within the same Region only, you cannot create an endpoint between a VPC and a service in a different Region. This prevents unintended Amazon EC2 API calls to other Regions. 

To learn more about creating VPC endpoints for Amazon EC2, see [Amazon EC2 and interface VPC endpoints ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/interface-vpc-endpoints.html)in the *Amazon EC2 User Guide*.

### Remediation
<a name="ec2-10-remediation"></a>

To create an interface endpoint to Amazon EC2 from the Amazon VPC console, see [Create a VPC endpoint ](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#create-interface-endpoint-aws)in the *AWS PrivateLink Guide*. For **Service name**, choose **com.amazonaws.*region*.ec2**.

You can also create and attach an endpoint policy to your VPC endpoint to control access to the Amazon EC2 API. For instructions on creating a VPC endpoint policy, see [Create an endpoint policy](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/interface-vpc-endpoints.html#endpoint-policy) in the *Amazon EC2 User Guide*.

## [EC2.12] Unused Amazon EC2 EIPs should be removed
<a name="ec2-12"></a>

**Related requirements:** PCI DSS v3.2.1/2.4, NIST.800-53.r5 CM-8(1)

**Category:** Protect > Secure network configuration

**Severity:** Low

**Resource type:** `AWS::EC2::EIP`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/eip-attached.html](https://docs.aws.amazon.com/config/latest/developerguide/eip-attached.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether Elastic IP (EIP) addresses that are allocated to a VPC are attached to EC2 instances or in-use elastic network interfaces (ENIs).

A failed finding indicates you may have unused EC2 EIPs.

This will help you maintain an accurate asset inventory of EIPs in your cardholder data environment (CDE).

### Remediation
<a name="ec2-12-remediation"></a>

To release an unused EIP, see [Release an Elastic IP address](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/elastic-ip-addresses-eip.html#using-instance-addressing-eips-releasing) in the *Amazon EC2 User Guide*.

## [EC2.13] Security groups should not allow ingress from 0.0.0.0/0 or ::/0 to port 22
<a name="ec2-13"></a>

**Related requirements:** CIS AWS Foundations Benchmark v1.2.0/4.1, NIST.800-53.r5 AC-4, NIST.800-53.r5 AC-4(21), NIST.800-53.r5 CM-7, NIST.800-53.r5 SC-7, NIST.800-53.r5 SC-7(11), NIST.800-53.r5 SC-7(16), NIST.800-53.r5 SC-7(21), NIST.800-53.r5 SC-7(4), NIST.800-53.r5 SC-7(5), NIST.800-171.r2 3.1.3, NIST.800-171.r2 3.13.1, PCI DSS v3.2.1/1.2.1, PCI DSS v3.2.1/1.3.1, PCI DSS v3.2.1/2.2.2, PCI DSS v4.0.1/1.3.1

**Category:** Protect > Secure network configuration

**Severity:** High

**Resource type:** `AWS::EC2::SecurityGroup`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/restricted-ssh.html](https://docs.aws.amazon.com/config/latest/developerguide/restricted-ssh.html)

**Schedule type:** Change triggered and periodic

**Parameters:** None

This control checks whether an Amazon EC2 security group allows ingress from 0.0.0.0/0 or ::/0 to port 22. The control fails if the security group allows ingress from 0.0.0.0/0 or ::/0 to port 22.

Security groups provide stateful filtering of ingress and egress network traffic to AWS resources. We recommend that no security group allow unrestricted ingress access to port 22. Removing unfettered connectivity to remote console services, such as SSH, reduces a server's exposure to risk.

### Remediation
<a name="ec2-13-remediation"></a>

To prohibit ingress to port 22, remove the rule that allows such access for each security group associated with a VPC. For instructions, see [Update security group rules](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/working-with-security-groups.html#updating-security-group-rules) in the *Amazon EC2 User Guide*. After selecting a security group in the Amazon EC2 console, choose **Actions, Edit inbound rules**. Remove the rule that allows access to port 22.

## [EC2.14] Security groups should not allow ingress from 0.0.0.0/0 or ::/0 to port 3389
<a name="ec2-14"></a>

**Related requirements:** CIS AWS Foundations Benchmark v1.2.0/4.2, PCI DSS v4.0.1/1.3.1

**Category:** Protect > Secure network configuration

**Severity:** High

**Resource type:** `AWS::EC2::SecurityGroup`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/restricted-common-ports.html](https://docs.aws.amazon.com/config/latest/developerguide/restricted-common-ports.html) (created rule is `restricted-rdp`)

**Schedule type:** Change triggered and periodic

**Parameters:** None

This control checks whether an Amazon EC2 security group allows ingress from 0.0.0.0/0 or ::/0 to port 3389. The control fails if the security group allows ingress from 0.0.0.0/0 or ::/0 to port 3389.

Security groups provide stateful filtering of ingress and egress network traffic to AWS resources. We recommend that no security group allow unrestricted ingress access to port 3389. Removing unfettered connectivity to remote console services, such as RDP, reduces a server's exposure to risk.

### Remediation
<a name="ec2-14-remediation"></a>

To prohibit ingress to port 3389, remove the rule that allows such access for each security group associated with a VPC. For instructions, see [Update security group rules](https://docs.aws.amazon.com/vpc/latest/userguide/security-group-rules.html#updating-security-group-rules) in the *Amazon VPC User Guide*. After selecting a security group in the Amazon VPC Console, choose **Actions, Edit inbound rules**. Remove the rule that allows access to port 3389.

## [EC2.15] Amazon EC2 subnets should not automatically assign public IP addresses
<a name="ec2-15"></a>

**Related requirements:** NIST.800-53.r5 AC-21, NIST.800-53.r5 AC-3, NIST.800-53.r5 AC-3(7), NIST.800-53.r5 AC-4, NIST.800-53.r5 AC-4(21), NIST.800-53.r5 AC-6, NIST.800-53.r5 SC-7, NIST.800-53.r5 SC-7(11), NIST.800-53.r5 SC-7(16), NIST.800-53.r5 SC-7(20), NIST.800-53.r5 SC-7(21), NIST.800-53.r5 SC-7(3), NIST.800-53.r5 SC-7(4), NIST.800-53.r5 SC-7(9), PCI DSS v4.0.1/1.4.4

**Category:** Protect > Network Security

**Severity:** Medium

**Resource type:** `AWS::EC2::Subnet`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/subnet-auto-assign-public-ip-disabled.html](https://docs.aws.amazon.com/config/latest/developerguide/subnet-auto-assign-public-ip-disabled.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether an Amazon Virtual Private Cloud (Amazon VPC) subnet is configured to automatically assign public IP addresses. The control fails if the subnet is configured to automatically assign public IPv4 or IPv6 addresses.

Subnets have attributes that determine whether network interfaces automatically receive public IPv4 and IPv6 addresses. For IPv4, this attribute is set to `TRUE` for default subnets and `FALSE` for nondefault subnets (with an exception for nondefault subnets created through the EC2 launch instance wizard, where it's set to `TRUE`). For IPv6, this attribute is set to `FALSE` for all subnets by default. When these attributes are enabled, instances launched in the subnet automatically receive the corresponding IP addresses (IPv4 or IPv6) on their primary network interface.

### Remediation
<a name="ec2-15-remediation"></a>

To configure a subnet to not assign public IP addresses, see [Modify the IP addressing attributes of your subnet](https://docs.aws.amazon.com/vpc/latest/userguide/subnet-public-ip.html) in the *Amazon VPC User Guide*.

## [EC2.16] Unused Network Access Control Lists should be removed
<a name="ec2-16"></a>

**Related requirements:** NIST.800-53.r5 CM-8(1), NIST.800-171.r2 3.4.7, PCI DSS v4.0.1/1.2.7

**Category:** Protect > Network Security

**Severity:** Low

**Resource type:** `AWS::EC2::NetworkAcl`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/vpc-network-acl-unused-check.html](https://docs.aws.amazon.com/config/latest/developerguide/vpc-network-acl-unused-check.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether there are any unused network access control lists (network ACLs) in your virtual private cloud (VPC). The control fails if the network ACL isn't associated with a subnet. The control doesn't generate findings for an unused default network ACL.

The control checks the item configuration of the resource `AWS::EC2::NetworkAcl` and determines the relationships of the network ACL.

If the only relationship is the VPC of the network ACL, the control fails.

If other relationships are listed, then the control passes.

### Remediation
<a name="ec2-16-remediation"></a>

For instructions on deleting an unused network ACL, see [Deleting a network ACL](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html#DeleteNetworkACL) in the *Amazon VPC User Guide*. You can't delete the default network ACL or an ACL that is associated with subnets.

## [EC2.17] Amazon EC2 instances should not use multiple ENIs
<a name="ec2-17"></a>

**Related requirements:** NIST.800-53.r5 AC-4(21)

**Category:** Protect > Network Security

**Severity:** Low

**Resource type:** `AWS::EC2::Instance`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/ec2-instance-multiple-eni-check.html](https://docs.aws.amazon.com/config/latest/developerguide/ec2-instance-multiple-eni-check.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether an EC2 instance uses multiple Elastic Network Interfaces (ENIs) or Elastic Fabric Adapters (EFAs). This control passes if a single network adapter is used. The control includes an optional parameter list to identify the allowed ENIs. This control also fails if an EC2 instance that belongs to an Amazon EKS cluster uses more than one ENI. If your EC2 instances need to have multiple ENIs as part of an Amazon EKS cluster, you can suppress those control findings.

Multiple ENIs can cause dual-homed instances, meaning instances that have multiple subnets. This can add network security complexity and introduce unintended network paths and access.

### Remediation
<a name="ec2-17-remediation"></a>

To detach a network interface from an EC2 instance, see [Detach a network interface from an instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html#detach_eni) in the *Amazon EC2 User Guide*.

## [EC2.18] Security groups should only allow unrestricted incoming traffic for authorized ports
<a name="ec2-18"></a>

**Related requirements:** NIST.800-53.r5 AC-4, NIST.800-53.r5 AC-4(21), NIST.800-53.r5 SC-7, NIST.800-53.r5 SC-7(11), NIST.800-53.r5 SC-7(16), NIST.800-53.r5 SC-7(21), NIST.800-53.r5 SC-7(4), NIST.800-53.r5 SC-7(5), NIST.800-171.r2 3.1.3, NIST.800-171.r2 3.1.20, NIST.800-171.r2 3.13.1

**Category:** Protect > Secure network configuration > Security group configuration

**Severity:** High

**Resource type:** `AWS::EC2::SecurityGroup`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/vpc-sg-open-only-to-authorized-ports.html](https://docs.aws.amazon.com/config/latest/developerguide/vpc-sg-open-only-to-authorized-ports.html)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  `authorizedTcpPorts`  |  List of authorized TCP ports  |  IntegerList (minimum of 1 item and maximum of 32 items)  |  `1` to `65535`  |  `[80,443]`  | 
|  `authorizedUdpPorts`  |  List of authorized UDP ports  |  IntegerList (minimum of 1 item and maximum of 32 items)  |  `1` to `65535`  |  No default value  | 

This control checks whether an Amazon EC2 security group permits unrestricted incoming traffic from unauthorized ports. The control status is determined as follows:
+ If you use the default value for `authorizedTcpPorts`, the control fails if the security group permits unrestricted incoming traffic from any port other than ports 80 and 443.
+ If you provide custom values for `authorizedTcpPorts` or `authorizedUdpPorts`, the control fails if the security group permits unrestricted incoming traffic from any unlisted port.

Security groups provide stateful filtering of ingress and egress network traffic to AWS. Security group rules should follow the principal of least privileged access. Unrestricted access (IP address with a /0 suffix) increases the opportunity for malicious activity such as hacking, denial-of-service attacks, and loss of data. Unless a port is specifically allowed, the port should deny unrestricted access.

### Remediation
<a name="ec2-18-remediation"></a>

To modify a security group, see [Work with security groups](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-security-groups.html) in the *Amazon VPC User Guide*.

## [EC2.19] Security groups should not allow unrestricted access to ports with high risk
<a name="ec2-19"></a>

**Related requirements:** NIST.800-53.r5 AC-4, NIST.800-53.r5 AC-4(21), NIST.800-53.r5 CA-9(1), NIST.800-53.r5 CM-2, NIST.800-53.r5 CM-2(2), NIST.800-53.r5 CM-7, NIST.800-53.r5 SC-7, NIST.800-53.r5 SC-7(11), NIST.800-53.r5 SC-7(16), NIST.800-53.r5 SC-7(21), NIST.800-53.r5 SC-7(4), NIST.800-53.r5 SC-7(5), NIST.800-171.r2 3.1.3, NIST.800-171.r2 3.1.20, NIST.800-171.r2 3.13.1

**Category:** Protect > Restricted network access

**Severity:** Critical

**Resource type:** `AWS::EC2::SecurityGroup`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/restricted-common-ports.html](https://docs.aws.amazon.com/config/latest/developerguide/restricted-common-ports.html) (created rule is `vpc-sg-restricted-common-ports`)

**Schedule type:** Change triggered and periodic

**Parameters:** `"blockedPorts": "20,21,22,23,25,110,135,143,445,1433,1434,3000,3306,3389,4333,5000,5432,5500,5601,8080,8088,8888,9200,9300"` (not customizable)

This control checks whether unrestricted incoming traffic for an Amazon EC2 security group is accessible to the specified ports that are considered to be high risk. This control fails if any of the rules in a security group allow ingress traffic from '0.0.0.0/0' or '::/0' to those ports.

Security groups provide stateful filtering of ingress and egress network traffic to AWS resources. Unrestricted access (0.0.0.0/0) increases opportunities for malicious activity, such as hacking, denial-of-service attacks, and loss of data. No security group should allow unrestricted ingress access to the following ports:
+ 20, 21 (FTP)
+ 22 (SSH)
+ 23 (Telnet)
+ 25 (SMTP)
+ 110 (POP3)
+ 135 (RPC)
+ 143 (IMAP)
+ 445 (CIFS)
+ 1433, 1434 (MSSQL)
+ 3000 (Go, Node.js, and Ruby web development frameworks)
+ 3306 (mySQL)
+ 3389 (RDP)
+ 4333 (ahsp)
+ 5000 (Python web development frameworks)
+ 5432 (postgresql)
+ 5500 (fcp-addr-srvr1) 
+ 5601 (OpenSearch Dashboards)
+ 8080 (proxy)
+ 8088 (legacy HTTP port)
+ 8888 (alternative HTTP port)
+ 9200 or 9300 (OpenSearch)

### Remediation
<a name="ec2-19-remediation"></a>

To delete rules from a security group, see [Delete rules from a security group](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/working-with-security-groups.html#deleting-security-group-rule) in the *Amazon EC2 User Guide*.

## [EC2.20] Both VPN tunnels for an AWS Site-to-Site VPN connection should be up
<a name="ec2-20"></a>

**Related requirements:** NIST.800-53.r5 CP-10, NIST.800-53.r5 CP-6(2), NIST.800-53.r5 SC-36, NIST.800-53.r5 SC-5(2), NIST.800-53.r5 SI-13(5), NIST.800-171.r2 3.1.13, NIST.800-171.r2 3.1.20

**Category:** Recover > Resilience > High availability

**Severity:** Medium 

**Resource type:**`AWS::EC2::VPNConnection`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/vpc-vpn-2-tunnels-up.html](https://docs.aws.amazon.com/config/latest/developerguide/vpc-vpn-2-tunnels-up.html)

**Schedule type:** Change triggered

**Parameters:** None

A VPN tunnel is an encrypted link where data can pass from the customer network to or from AWS within an AWS Site-to-Site VPN connection. Each VPN connection includes two VPN tunnels which you can simultaneously use for high availability. Ensuring that both VPN tunnels are up for a VPN connection is important for confirming a secure and highly available connection between an AWS VPC and your remote network.

This control checks that both VPN tunnels provided by AWS Site-to-Site VPN are in UP status. The control fails if one or both tunnels are in DOWN status.

### Remediation
<a name="ec2-20-remediation"></a>

To modify VPN tunnel options, see [Modifying Site-to-Site VPN tunnel options](https://docs.aws.amazon.com/vpn/latest/s2svpn/modify-vpn-tunnel-options.html) in the AWS Site-to-Site VPN User Guide.

## [EC2.21] Network ACLs should not allow ingress from 0.0.0.0/0 to port 22 or port 3389
<a name="ec2-21"></a>

**Related requirements:** CIS AWS Foundations Benchmark v5.0.0/5.2, CIS AWS Foundations Benchmark v1.4.0/5.1, CIS AWS Foundations Benchmark v3.0.0/5.1, NIST.800-53.r5 AC-4(21), NIST.800-53.r5 CA-9(1), NIST.800-53.r5 CM-2, NIST.800-53.r5 CM-2(2), NIST.800-53.r5 CM-7, NIST.800-53.r5 SC-7, NIST.800-53.r5 SC-7(21), NIST.800-53.r5 SC-7(5), NIST.800-171.r2 3.1.3, NIST.800-171.r2 3.1.20, NIST.800-171.r2 3.13.1, PCI DSS v4.0.1/1.3.1

**Category:** Protect > Secure Network Configuration

**Severity:** Medium 

**Resource type:**`AWS::EC2::NetworkAcl`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/nacl-no-unrestricted-ssh-rdp.html](https://docs.aws.amazon.com/config/latest/developerguide/nacl-no-unrestricted-ssh-rdp.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether a network access control list (network ACL) allows unrestricted access to the default TCP ports for SSH/RDP ingress traffic. The control fails if the network ACL inbound entry allows a source CIDR block of '0.0.0.0/0' or '::/0' for TCP ports 22 or 3389. The control doesn't generate findings for a default network ACL.

Access to remote server administration ports, such as port 22 (SSH) and port 3389 (RDP), should not be publicly accessible, as this may allow unintended access to resources within your VPC.

### Remediation
<a name="ec2-21-remediation"></a>

To edit network ACL traffic rules, see [Work with network ACLs](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html#nacl-tasks) in the *Amazon VPC User Guide*.

## [EC2.22] Unused Amazon EC2 security groups should be removed
<a name="ec2-22"></a>

**Category:** Identify > Inventory

**Severity:** Medium 

**Resource type:** `AWS::EC2::NetworkInterface`, `AWS::EC2::SecurityGroup`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/ec2-security-group-attached-to-eni-periodic.html](https://docs.aws.amazon.com/config/latest/developerguide/ec2-security-group-attached-to-eni-periodic.html)

**Schedule type:** Periodic

**Parameters:** None

This control checks whether security groups are attached to Amazon Elastic Compute Cloud (Amazon EC2) instances or to an elastic network interface. The control fails if the security group is not associated with an Amazon EC2 instance or an elastic network interface.

**Important**  
On September 20, 2023, Security Hub CSPM removed this control from the AWS Foundational Security Best Practices and NIST SP 800-53 Revision 5 standards. This control continues to be part of the AWS Control Tower service-managed standard. This control produces a passed finding if security groups are attached to EC2 instances or an elastic network interface. However, for certain use cases, unattached security groups don't pose a security risk. You can use other EC2 controls—such as EC2.2, EC2.13, EC2.14, EC2.18, and EC2.19—to monitor your security groups.

### Remediation
<a name="ec2-22-remediation"></a>

To create, assign and delete security groups, see [Security groups for your EC2 instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-security-groups.html) in the *Amazon EC2 User Guide*.

## [EC2.23] Amazon EC2 Transit Gateways should not automatically accept VPC attachment requests
<a name="ec2-23"></a>

**Related requirements:** NIST.800-53.r5 AC-4(21), NIST.800-53.r5 CA-9(1), NIST.800-53.r5 CM-2

**Category:** Protect > Secure network configuration

**Severity:** High 

**Resource type:**`AWS::EC2::TransitGateway`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/ec2-transit-gateway-auto-vpc-attach-disabled.html](https://docs.aws.amazon.com/config/latest/developerguide/ec2-transit-gateway-auto-vpc-attach-disabled.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks if EC2 transit gateways are automatically accepting shared VPC attachments. This control fails for a transit gateway that automatically accepts shared VPC attachment requests.

Turning on `AutoAcceptSharedAttachments` configures a transit gateway to automatically accept any cross-account VPC attachment requests without verifying the request or the account the attachment is originating from. To follow the best practices of authorization and authentication, we recommended turning off this feature to ensure that only authorized VPC attachment requests are accepted.

### Remediation
<a name="ec2-23-remediation"></a>

To modify a transit gateway, see [Modify a transit gateway](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-transit-gateways.html#tgw-modifying) in the Amazon VPC Developer Guide.

## [EC2.24] Amazon EC2 paravirtual instance types should not be used
<a name="ec2-24"></a>

**Related requirements:** NIST.800-53.r5 CM-2, NIST.800-53.r5 CM-2(2)

**Category:** Identify > Vulnerability, patch, and version management

**Severity:** Medium 

**Resource type:**`AWS::EC2::Instance`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/ec2-paravirtual-instance-check.html](https://docs.aws.amazon.com/config/latest/developerguide/ec2-paravirtual-instance-check.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether the virtualization type of an EC2 instance is paravirtual. The control fails if the `virtualizationType` of the EC2 instance is set to `paravirtual`.

Linux Amazon Machine Images (AMIs) use one of two types of virtualization: paravirtual (PV) or hardware virtual machine (HVM). The main differences between PV and HVM AMIs are the way in which they boot and whether they can take advantage of special hardware extensions (CPU, network, and storage) for better performance.

Historically, PV guests had better performance than HVM guests in many cases, but because of enhancements in HVM virtualization and the availability of PV drivers for HVM AMIs, this is no longer true. For more information, see [Linux AMI virtualization types](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/virtualization_types.html) in the Amazon EC2 User Guide.

### Remediation
<a name="ec2-24-remediation"></a>

To update an EC2 instance to a new instance type, see [Change the instance type](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-resize.html) in the *Amazon EC2 User Guide*.

## [EC2.25] Amazon EC2 launch templates should not assign public IPs to network interfaces
<a name="ec2-25"></a>

**Related requirements:** NIST.800-53.r5 AC-21, NIST.800-53.r5 AC-3, NIST.800-53.r5 AC-3(7), NIST.800-53.r5 AC-4, NIST.800-53.r5 AC-4(21), NIST.800-53.r5 AC-6, NIST.800-53.r5 SC-7, NIST.800-53.r5 SC-7(11), NIST.800-53.r5 SC-7(16), NIST.800-53.r5 SC-7(20), NIST.800-53.r5 SC-7(21), NIST.800-53.r5 SC-7(3), NIST.800-53.r5 SC-7(4), NIST.800-53.r5 SC-7(9), PCI DSS v4.0.1/1.4.4

**Category:** Protect > Secure network configuration > Resources not publicly accessible

**Severity:** High 

**Resource type:**`AWS::EC2::LaunchTemplate`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/ec2-launch-template-public-ip-disabled.html](https://docs.aws.amazon.com/config/latest/developerguide/ec2-launch-template-public-ip-disabled.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks if Amazon EC2 launch templates are configured to assign public IP addresses to network interfaces upon launch. The control fails if an EC2 launch template is configured to assign a public IP address to network interfaces or if there is at least one network interface that has a public IP address.

A public IP address is one that is reachable from the internet. If you configure your network interfaces with a public IP address, then the resources associated with those network interfaces may be reachable from the internet. EC2 resources shouldn't be publicly accessible because this may permit unintended access to your workloads.

### Remediation
<a name="ec2-25-remediation"></a>

To update an EC2 launch template, see [Change the default network interface settings](https://docs.aws.amazon.com/autoscaling/ec2/userguide/create-launch-template.html#change-network-interface) in the *Amazon EC2 Auto Scaling User Guide*.

## [EC2.28] EBS volumes should be covered by a backup plan
<a name="ec2-28"></a>

**Category:** Recover > Resilience > Backups enabled

**Related requirements:** NIST.800-53.r5 CP-10, NIST.800-53.r5 CP-6, NIST.800-53.r5 CP-6(1), NIST.800-53.r5 CP-6(2), NIST.800-53.r5 CP-9, NIST.800-53.r5 SC-5(2), NIST.800-53.r5 SI-12, NIST.800-53.r5 SI-13(5)

**Severity:** Low

**Resource type:** `AWS::EC2::Volume`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/ebs-resources-protected-by-backup-plan.html](https://docs.aws.amazon.com/config/latest/developerguide/ebs-resources-protected-by-backup-plan.html) ``

**Schedule type:** Periodic

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  `backupVaultLockCheck`  |  The control produces a `PASSED` finding if the parameter is set to `true` and the resource uses AWS Backup Vault Lock.  |  Boolean  |  `true` or `false`  |  No default value  | 

This control evaluates if an Amazon EBS volume in `in-use` state is covered by a backup plan. The control fails if an EBS volume isn't covered by a backup plan. If you set the `backupVaultLockCheck` parameter equal to `true`, the control passes only if the EBS volume is backed up in an AWS Backup locked vault.

Backups help you recover more quickly from a security incident. They also strengthen the resilience of your systems. Including Amazon EBS volumes in a backup plan helps you protect your data from unintended loss or deletion.

### Remediation
<a name="ec2-28-remediation"></a>

To add an Amazon EBS volume to an AWS Backup backup plan, see [Assigning resources to a backup plan](https://docs.aws.amazon.com/aws-backup/latest/devguide/assigning-resources.html) in the *AWS Backup Developer Guide*.

## [EC2.33] EC2 transit gateway attachments should be tagged
<a name="ec2-33"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::EC2::TransitGatewayAttachment`

**AWS Config rule:** `tagged-ec2-transitgatewayattachment` (custom Security Hub CSPM rule)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  | No default value  | 

This control checks whether an Amazon EC2 transit gateway attachment has tags with the specific keys defined in the parameter `requiredTagKeys`. The control fails if the transit gateway attachment doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredTagKeys`. If the parameter `requiredTagKeys` isn't provided, the control only checks for the existence of a tag key and fails if the transit gateway attachment isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [What is ABAC for AWS?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Tagging your AWS resources](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *AWS General Reference*.

### Remediation
<a name="ec2-33-remediation"></a>

To add tags to an EC2 transit gateway attachment, see [Tag your Amazon EC2 resources](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#Using_Tags_Console) in the *Amazon EC2 User Guide*.

## [EC2.34] EC2 transit gateway route tables should be tagged
<a name="ec2-34"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::EC2::TransitGatewayRouteTable`

**AWS Config rule:** `tagged-ec2-transitgatewayroutetable` (custom Security Hub CSPM rule)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  | No default value  | 

This control checks whether an Amazon EC2 transit gateway route table has tags with the specific keys defined in the parameter `requiredTagKeys`. The control fails if the transit gateway route table doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredTagKeys`. If the parameter `requiredTagKeys` isn't provided, the control only checks for the existence of a tag key and fails if the transit gateway route table isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [What is ABAC for AWS?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Tagging your AWS resources](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *AWS General Reference*.

### Remediation
<a name="ec2-34-remediation"></a>

To add tags to an EC2 transit gateway route table, see [Tag your Amazon EC2 resources](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#Using_Tags_Console) in the *Amazon EC2 User Guide*.

## [EC2.35] EC2 network interfaces should be tagged
<a name="ec2-35"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::EC2::NetworkInterface`

**AWS Config rule:** `tagged-ec2-networkinterface` (custom Security Hub CSPM rule)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  | No default value  | 

This control checks whether an Amazon EC2 network interface has tags with the specific keys defined in the parameter `requiredTagKeys`. The control fails if the network interface doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredTagKeys`. If the parameter `requiredTagKeys` isn't provided, the control only checks for the existence of a tag key and fails if the network interface isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [What is ABAC for AWS?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Tagging your AWS resources](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *AWS General Reference*.

### Remediation
<a name="ec2-35-remediation"></a>

To add tags to an EC2 network interface, see [Tag your Amazon EC2 resources](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#Using_Tags_Console) in the *Amazon EC2 User Guide*.

## [EC2.36] EC2 customer gateways should be tagged
<a name="ec2-36"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::EC2::CustomerGateway`

**AWS Config rule:** `tagged-ec2-customergateway` (custom Security Hub CSPM rule)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  | No default value  | 

This control checks whether an Amazon EC2 customer gateway has tags with the specific keys defined in the parameter `requiredTagKeys`. The control fails if the customer gateway doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredTagKeys`. If the parameter `requiredTagKeys` isn't provided, the control only checks for the existence of a tag key and fails if the customer gateway isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [What is ABAC for AWS?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Tagging your AWS resources](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *AWS General Reference*.

### Remediation
<a name="ec2-36-remediation"></a>

To add tags to an EC2 customer gateway, see [Tag your Amazon EC2 resources](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#Using_Tags_Console) in the *Amazon EC2 User Guide*.

## [EC2.37] EC2 Elastic IP addresses should be tagged
<a name="ec2-37"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::EC2::EIP`

**AWS Config rule:** `tagged-ec2-eip` (custom Security Hub CSPM rule)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  | No default value  | 

This control checks whether an Amazon EC2 Elastic IP address has tags with the specific keys defined in the parameter `requiredTagKeys`. The control fails if the Elastic IP address doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredTagKeys`. If the parameter `requiredTagKeys` isn't provided, the control only checks for the existence of a tag key and fails if the Elastic IP address isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [What is ABAC for AWS?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Tagging your AWS resources](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *AWS General Reference*.

### Remediation
<a name="ec2-37-remediation"></a>

To add tags to an EC2 Elastic IP address, see [Tag your Amazon EC2 resources](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#Using_Tags_Console) in the *Amazon EC2 User Guide*.

## [EC2.38] EC2 instances should be tagged
<a name="ec2-38"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::EC2::Instance`

**AWS Config rule:** `tagged-ec2-instance` (custom Security Hub CSPM rule)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  | No default value  | 

This control checks whether an Amazon EC2 instance has tags with the specific keys defined in the parameter `requiredTagKeys`. The control fails if the instance doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredTagKeys`. If the parameter `requiredTagKeys` isn't provided, the control only checks for the existence of a tag key and fails if the instance isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [What is ABAC for AWS?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Tagging your AWS resources](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *AWS General Reference*.

### Remediation
<a name="ec2-38-remediation"></a>

To add tags to an EC2 instance, see [Tag your Amazon EC2 resources](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#Using_Tags_Console) in the *Amazon EC2 User Guide*.

## [EC2.39] EC2 internet gateways should be tagged
<a name="ec2-39"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::EC2::InternetGateway`

**AWS Config rule:** `tagged-ec2-internetgateway` (custom Security Hub CSPM rule)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  | No default value  | 

This control checks whether an Amazon EC2 internet gateway has tags with the specific keys defined in the parameter `requiredTagKeys`. The control fails if the internet gateway doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredTagKeys`. If the parameter `requiredTagKeys` isn't provided, the control only checks for the existence of a tag key and fails if the internet gateway isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [What is ABAC for AWS?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Tagging your AWS resources](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *AWS General Reference*.

### Remediation
<a name="ec2-39-remediation"></a>

To add tags to an EC2 internet gateway, see [Tag your Amazon EC2 resources](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#Using_Tags_Console) in the *Amazon EC2 User Guide*.

## [EC2.40] EC2 NAT gateways should be tagged
<a name="ec2-40"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::EC2::NatGateway`

**AWS Config rule:** `tagged-ec2-natgateway` (custom Security Hub CSPM rule)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  | No default value  | 

This control checks whether an Amazon EC2 network address translation (NAT) gateway has tags with the specific keys defined in the parameter `requiredTagKeys`. The control fails if the NAT gateway doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredTagKeys`. If the parameter `requiredTagKeys` isn't provided, the control only checks for the existence of a tag key and fails if the NAT gateway isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [What is ABAC for AWS?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Tagging your AWS resources](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *AWS General Reference*.

### Remediation
<a name="ec2-40-remediation"></a>

To add tags to an EC2 NAT gateway, see [Tag your Amazon EC2 resources](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#Using_Tags_Console) in the *Amazon EC2 User Guide*.

## [EC2.41] EC2 network ACLs should be tagged
<a name="ec2-41"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::EC2::NetworkAcl`

**AWS Config rule:** `tagged-ec2-networkacl` (custom Security Hub CSPM rule)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  | No default value  | 

This control checks whether an Amazon EC2 network access control list (network ACL) has tags with the specific keys defined in the parameter `requiredTagKeys`. The control fails if the network ACL doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredTagKeys`. If the parameter `requiredTagKeys` isn't provided, the control only checks for the existence of a tag key and fails if the network ACL isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [What is ABAC for AWS?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Tagging your AWS resources](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *AWS General Reference*.

### Remediation
<a name="ec2-41-remediation"></a>

To add tags to an EC2 network ACL, see [Tag your Amazon EC2 resources](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#Using_Tags_Console) in the *Amazon EC2 User Guide*.

## [EC2.42] EC2 route tables should be tagged
<a name="ec2-42"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::EC2::RouteTable`

**AWS Config rule:** `tagged-ec2-routetable` (custom Security Hub CSPM rule)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  | No default value  | 

This control checks whether an Amazon EC2 route table has tags with the specific keys defined in the parameter `requiredTagKeys`. The control fails if the route table doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredTagKeys`. If the parameter `requiredTagKeys` isn't provided, the control only checks for the existence of a tag key and fails if the route table isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [What is ABAC for AWS?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Tagging your AWS resources](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *AWS General Reference*.

### Remediation
<a name="ec2-42-remediation"></a>

To add tags to an EC2 route table, see [Tag your Amazon EC2 resources](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#Using_Tags_Console) in the *Amazon EC2 User Guide*.

## [EC2.43] EC2 security groups should be tagged
<a name="ec2-43"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::EC2::SecurityGroup`

**AWS Config rule:** `tagged-ec2-securitygroup` (custom Security Hub CSPM rule)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  | No default value  | 

This control checks whether an Amazon EC2 security group has tags with the specific keys defined in the parameter `requiredTagKeys`. The control fails if the security group doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredTagKeys`. If the parameter `requiredTagKeys` isn't provided, the control only checks for the existence of a tag key and fails if the security group isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [What is ABAC for AWS?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Tagging your AWS resources](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *AWS General Reference*.

### Remediation
<a name="ec2-43-remediation"></a>

To add tags to an EC2 security group, see [Tag your Amazon EC2 resources](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#Using_Tags_Console) in the *Amazon EC2 User Guide*.

## [EC2.44] EC2 subnets should be tagged
<a name="ec2-44"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::EC2::Subnet`

**AWS Config rule:** `tagged-ec2-subnet` (custom Security Hub CSPM rule)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  | No default value  | 

This control checks whether an Amazon EC2 subnet has tags with the specific keys defined in the parameter `requiredTagKeys`. The control fails if the subnet doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredTagKeys`. If the parameter `requiredTagKeys` isn't provided, the control only checks for the existence of a tag key and fails if the subnet isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [What is ABAC for AWS?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Tagging your AWS resources](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *AWS General Reference*.

### Remediation
<a name="ec2-44-remediation"></a>

To add tags to an EC2 subnet, see [Tag your Amazon EC2 resources](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#Using_Tags_Console) in the *Amazon EC2 User Guide*.

## [EC2.45] EC2 volumes should be tagged
<a name="ec2-45"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::EC2::Volume`

**AWS Config rule:** `tagged-ec2-volume` (custom Security Hub CSPM rule)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  | No default value  | 

This control checks whether an Amazon EC2 volume has tags with the specific keys defined in the parameter `requiredTagKeys`. The control fails if the volume doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredTagKeys`. If the parameter `requiredTagKeys` isn't provided, the control only checks for the existence of a tag key and fails if the volume isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [What is ABAC for AWS?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Tagging your AWS resources](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *AWS General Reference*.

### Remediation
<a name="ec2-45-remediation"></a>

To add tags to an EC2 volume, see [Tag your Amazon EC2 resources](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#Using_Tags_Console) in the *Amazon EC2 User Guide*.

## [EC2.46] Amazon VPCs should be tagged
<a name="ec2-46"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::EC2::VPC`

**AWS Config rule:** `tagged-ec2-vpc` (custom Security Hub CSPM rule)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  | No default value  | 

This control checks whether an Amazon Virtual Private Cloud (Amazon VPC) has tags with the specific keys defined in the parameter `requiredTagKeys`. The control fails if the Amazon VPC doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredTagKeys`. If the parameter `requiredTagKeys` isn't provided, the control only checks for the existence of a tag key and fails if the Amazon VPC isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [What is ABAC for AWS?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Tagging your AWS resources](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *AWS General Reference*.

### Remediation
<a name="ec2-46-remediation"></a>

To add tags to a VPC, see [Tag your Amazon EC2 resources](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#Using_Tags_Console) in the *Amazon EC2 User Guide*.

## [EC2.47] Amazon VPC endpoint services should be tagged
<a name="ec2-47"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::EC2::VPCEndpointService`

**AWS Config rule:** `tagged-ec2-vpcendpointservice` (custom Security Hub CSPM rule)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  | No default value  | 

This control checks whether an Amazon VPC endpoint service has tags with the specific keys defined in the parameter `requiredTagKeys`. The control fails if the endpoint service doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredTagKeys`. If the parameter `requiredTagKeys` isn't provided, the control only checks for the existence of a tag key and fails if the endpoint service isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [What is ABAC for AWS?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Tagging your AWS resources](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *AWS General Reference*.

### Remediation
<a name="ec2-47-remediation"></a>

To add tags to an Amazon VPC endpoint service, see [Manage Tags](https://docs.aws.amazon.com/vpc/latest/privatelink/configure-endpoint-service.html#add-remove-endpoint-service-tags) in the [Configure an endpoint service](https://docs.aws.amazon.com/vpc/latest/privatelink/configure-endpoint-service.html) section of the *AWS PrivateLink Guide*.

## [EC2.48] Amazon VPC flow logs should be tagged
<a name="ec2-48"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::EC2::FlowLog`

**AWS Config rule:** `tagged-ec2-flowlog` (custom Security Hub CSPM rule)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  | No default value  | 

This control checks whether an Amazon VPC flow log has tags with the specific keys defined in the parameter `requiredTagKeys`. The control fails if the flow log doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredTagKeys`. If the parameter `requiredTagKeys` isn't provided, the control only checks for the existence of a tag key and fails if the flow log isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [What is ABAC for AWS?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Tagging your AWS resources](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *AWS General Reference*.

### Remediation
<a name="ec2-48-remediation"></a>

To add tags to an Amazon VPC flow log, see [Tag a flow log](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-flow-logs.html#modify-tags-flow-logs) in the *Amazon VPC User Guide*.

## [EC2.49] Amazon VPC peering connections should be tagged
<a name="ec2-49"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::EC2::VPCPeeringConnection`

**AWS Config rule:** `tagged-ec2-vpcpeeringconnection` (custom Security Hub CSPM rule)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  | No default value  | 

This control checks whether an Amazon VPC peering connection has tags with the specific keys defined in the parameter `requiredTagKeys`. The control fails if the peering connection doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredTagKeys`. If the parameter `requiredTagKeys` isn't provided, the control only checks for the existence of a tag key and fails if the peering connection isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [What is ABAC for AWS?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Tagging your AWS resources](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *AWS General Reference*.

### Remediation
<a name="ec2-49-remediation"></a>

To add tags to an Amazon VPC peering connection, see [Tag your Amazon EC2 resources](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html) in the *Amazon EC2 User Guide*.

## [EC2.50] EC2 VPN gateways should be tagged
<a name="ec2-50"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::EC2::VPNGateway`

**AWS Config rule:** `tagged-ec2-vpngateway` (custom Security Hub CSPM rule)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  | No default value  | 

This control checks whether an Amazon EC2 VPN gateway has tags with the specific keys defined in the parameter `requiredTagKeys`. The control fails if the VPN gateway doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredTagKeys`. If the parameter `requiredTagKeys` isn't provided, the control only checks for the existence of a tag key and fails if the VPN gateway isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [What is ABAC for AWS?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Tagging your AWS resources](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *AWS General Reference*.

### Remediation
<a name="ec2-50-remediation"></a>

To add tags to an EC2 VPN gateway, see [Tag your Amazon EC2 resources](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html) in the *Amazon EC2 User Guide*.

## [EC2.51] EC2 Client VPN endpoints should have client connection logging enabled
<a name="ec2-51"></a>

**Related requirements:** NIST.800-53.r5 AC-2(12), NIST.800-53.r5 AC-2(4), NIST.800-53.r5 AC-4(26), NIST.800-53.r5 AC-6(9), NIST.800-53.r5 AU-10, NIST.800-53.r5 AU-12, NIST.800-53.r5 AU-2, NIST.800-53.r5 AU-3, NIST.800-53.r5 AU-6(3), NIST.800-53.r5 AU-6(4), NIST.800-53.r5 AU-9(7), NIST.800-53.r5 CA-7, NIST.800-53.r5 SC-7(9), NIST.800-53.r5 SI-3(8), NIST.800-53.r5 SI-4, NIST.800-53.r5 SI-4(20), NIST.800-53.r5 SI-7(8), NIST.800-171.r2 3.1.12, NIST.800-171.r2 3.1.20, PCI DSS v4.0.1/10.2.1

**Category:** Identify > Logging

**Severity:** Low

**Resource type:** `AWS::EC2::ClientVpnEndpoint`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/ec2-client-vpn-connection-log-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/ec2-client-vpn-connection-log-enabled.html) ``

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether an AWS Client VPN endpoint has client connection logging enabled. The control fails if the endpoint doesn't have client connection logging enabled.

Client VPN endpoints allow remote clients to securely connect to resources in a Virtual Private Cloud (VPC) in AWS. Connection logs allow you to track user activity on the VPN endpoint and provides visibility. When you enable connection logging, you can specify the name of a log stream in the log group. If you don't specify a log stream, the Client VPN service creates one for you.

### Remediation
<a name="ec2-51-remediation"></a>

To enable connection logging, see [Enable connection logging for an existing Client VPN endpoint](https://docs.aws.amazon.com/vpn/latest/clientvpn-admin/cvpn-working-with-connection-logs.html#create-connection-log-existing) in the *AWS Client VPN Administrator Guide*.

## [EC2.52] EC2 transit gateways should be tagged
<a name="ec2-52"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::EC2::TransitGateway`

**AWS Config rule:** `tagged-ec2-transitgateway` (custom Security Hub CSPM rule)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  |  No default value  | 

This control checks whether an Amazon EC2 transit gateway has tags with the specific keys defined in the parameter `requiredTagKeys`. The control fails if the transit gateway doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredTagKeys`. If the parameter `requiredTagKeys` isn't provided, the control only checks for the existence of a tag key and fails if the transit gateway isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [What is ABAC for AWS?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Tagging your AWS resources](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *AWS General Reference*.

### Remediation
<a name="ec2-52-remediation"></a>

To add tags to an EC2 transit gateway, see [Tag your Amazon EC2 resources](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#Using_Tags_Console) in the *Amazon EC2 User Guide*.

## [EC2.53] EC2 security groups should not allow ingress from 0.0.0.0/0 to remote server administration ports
<a name="ec2-53"></a>

**Related requirements:** CIS AWS Foundations Benchmark v5.0.0/5.3, CIS AWS Foundations Benchmark v3.0.0/5.2, PCI DSS v4.0.1/1.3.1

**Category:** Protect > Secure network configuration > Security group configuration

**Severity:** High

**Resource type:** `AWS::EC2::SecurityGroup`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/vpc-sg-port-restriction-check.html](https://docs.aws.amazon.com/config/latest/developerguide/vpc-sg-port-restriction-check.html)

**Schedule type:** Periodic

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  `ipType`  |  The IP version  |  String  |  Not customizable  |  `IPv4`  | 
|  `restrictPorts`  |  List of ports that should reject ingress traffic  |  IntegerList  |  Not customizable  |  `22,3389`  | 

This control checks whether an Amazon EC2 security group allows ingress from 0.0.0.0/0 to remote server administration ports (ports 22 and 3389). The control fails if the security group allows ingress from 0.0.0.0/0 to port 22 or 3389.

Security groups provide stateful filtering of ingress and egress network traffic to AWS resources. We recommend that no security group allow unrestricted ingress access to remote server administration ports, such as SSH to port 22 and RDP to port 3389, using either the TDP (6), UDP (17), or ALL (-1) protocols. Permitting public access to these ports increases resource attack surface and the risk of resource compromise.

### Remediation
<a name="ec2-53-remediation"></a>

To update an EC2 security group rule to prohibit ingress traffic to the specified ports, see [Update security group rules](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/working-with-security-groups.html#updating-security-group-rules) in the *Amazon EC2 User Guide*. After selecting a security group in the Amazon EC2 console, choose **Actions, Edit inbound rules**. Remove the rule that allows access to port 22 or port 3389.

## [EC2.54] EC2 security groups should not allow ingress from ::/0 to remote server administration ports
<a name="ec2-54"></a>

**Related requirements:** CIS AWS Foundations Benchmark v5.0.0/5.4, CIS AWS Foundations Benchmark v3.0.0/5.3, PCI DSS v4.0.1/1.3.1

**Category:** Protect > Secure network configuration > Security group configuration

**Severity:** High

**Resource type:** `AWS::EC2::SecurityGroup`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/vpc-sg-port-restriction-check.html](https://docs.aws.amazon.com/config/latest/developerguide/vpc-sg-port-restriction-check.html)

**Schedule type:** Periodic

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  `ipType`  |  The IP version  |  String  |  Not customizable  |  `IPv6`  | 
|  `restrictPorts`  |  List of ports that should reject ingress traffic  |  IntegerList  |  Not customizable  |  `22,3389`  | 

This control checks whether an Amazon EC2 security group allows ingress from ::/0 to remote server administration ports (ports 22 and 3389). The control fails if the security group allows ingress from ::/0 to port 22 or 3389.

Security groups provide stateful filtering of ingress and egress network traffic to AWS resources. We recommend that no security group allow unrestricted ingress access to remote server administration ports, such as SSH to port 22 and RDP to port 3389, using either the TDP (6), UDP (17), or ALL (-1) protocols. Permitting public access to these ports increases resource attack surface and the risk of resource compromise.

### Remediation
<a name="ec2-54-remediation"></a>

To update an EC2 security group rule to prohibit ingress traffic to the specified ports, see [Update security group rules](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/working-with-security-groups.html#updating-security-group-rules) in the *Amazon EC2 User Guide*. After selecting a security group in the Amazon EC2 console, choose **Actions, Edit inbound rules**. Remove the rule that allows access to port 22 or port 3389.

## [EC2.55] VPCs should be configured with an interface endpoint for ECR API
<a name="ec2-55"></a>

**Related requirements:** NIST.800-53.r5 AC-21, NIST.800-53.r5 AC-3, NIST.800-53.r5 AC-3(7), NIST.800-53.r5 AC-4, NIST.800-53.r5 AC-4(21), NIST.800-53.r5 AC-6, NIST.800-53.r5 SC-7, NIST.800-53.r5 SC-7(11), NIST.800-53.r5 SC-7(16), NIST.800-53.r5 SC-7(20), NIST.800-53.r5 SC-7(21), NIST.800-53.r5 SC-7(3), NIST.800-53.r5 SC-7(4)

**Category:** Protect > Secure access management > Access control

**Severity:** Medium

**Resource type:** `AWS::EC2::VPC`, `AWS::EC2::VPCEndpoint`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/vpc-endpoint-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/vpc-endpoint-enabled.html)

**Schedule type:** Periodic

**Parameters:**


| Parameter | Required | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | --- | 
| serviceNames  | Required  | The name of the service that the control evaluates  | String  | Not customizable  | ecr.api | 
| vpcIds  | Optional  | Comma-separated list of Amazon VPC IDs for VPC endpoints. If provided, the control fails if the services specified in the serviceName parameter don't have one of these VPC endpoints.  | StringList  | Customize with one or more VPC IDs  | No default value  | 

This control checks whether a virtual private cloud (VPC) that you manage has an interface VPC endpoint for Amazon ECR API. The control fails if the VPC doesn't have an interface VPC endpoint for ECR API. This control evaluates resources in a single account.

AWS PrivateLink enables customers to access services hosted on AWS in a highly available and scalable manner, while keeping all the network traffic within the AWS network. Service users can privately access services powered by PrivateLink from their VPC or their on-premises, without using public IPs, and without requiring traffic to traverse across the internet.

### Remediation
<a name="ec2-55-remediation"></a>

To configure a VPC endpoint, see [Access an AWS service using an interface VPC endpoint](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html) in the *AWS PrivateLink Guide*.

## [EC2.56] VPCs should be configured with an interface endpoint for Docker Registry
<a name="ec2-56"></a>

**Related requirements:** NIST.800-53.r5 AC-21, NIST.800-53.r5 AC-3, NIST.800-53.r5 AC-3(7), NIST.800-53.r5 AC-4, NIST.800-53.r5 AC-4(21), NIST.800-53.r5 AC-6, NIST.800-53.r5 SC-7, NIST.800-53.r5 SC-7(11), NIST.800-53.r5 SC-7(16), NIST.800-53.r5 SC-7(20), NIST.800-53.r5 SC-7(21), NIST.800-53.r5 SC-7(3), NIST.800-53.r5 SC-7(4)

**Category:** Protect > Secure access management > Access control

**Severity:** Medium

**Resource type:** `AWS::EC2::VPC`, `AWS::EC2::VPCEndpoint`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/vpc-endpoint-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/vpc-endpoint-enabled.html)

**Schedule type:** Periodic

**Parameters:**


| Parameter | Required | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | --- | 
| serviceNames  | Required  | The name of the service that the control evaluates  | String  | Not customizable  | ecr.dkr | 
| vpcIds  | Optional  | Comma-separated list of Amazon VPC IDs for VPC endpoints. If provided, the control fails if the services specified in the serviceName parameter don't have one of these VPC endpoints.  | StringList  | Customize with one or more VPC IDs  | No default value  | 

This control checks whether a virtual private cloud (VPC) that you manage has an interface VPC endpoint for Docker Registry. The control fails if the VPC doesn't have an interface VPC endpoint for Docker Registry. This control evaluates resources in a single account.

AWS PrivateLink enables customers to access services hosted on AWS in a highly available and scalable manner, while keeping all the network traffic within the AWS network. Service users can privately access services powered by PrivateLink from their VPC or their on-premises, without using public IPs, and without requiring traffic to traverse across the internet.

### Remediation
<a name="ec2-56-remediation"></a>

To configure a VPC endpoint, see [Access an AWS service using an interface VPC endpoint](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html) in the *AWS PrivateLink Guide*.

## [EC2.57] VPCs should be configured with an interface endpoint for Systems Manager
<a name="ec2-57"></a>

**Related requirements:** NIST.800-53.r5 AC-21, NIST.800-53.r5 AC-3, NIST.800-53.r5 AC-3(7), NIST.800-53.r5 AC-4, NIST.800-53.r5 AC-4(21), NIST.800-53.r5 AC-6, NIST.800-53.r5 SC-7, NIST.800-53.r5 SC-7(11), NIST.800-53.r5 SC-7(16), NIST.800-53.r5 SC-7(20), NIST.800-53.r5 SC-7(21), NIST.800-53.r5 SC-7(3), NIST.800-53.r5 SC-7(4)

**Category:** Protect > Secure access management > Access control

**Severity:** Medium

**Resource type:** `AWS::EC2::VPC`, `AWS::EC2::VPCEndpoint`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/vpc-endpoint-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/vpc-endpoint-enabled.html)

**Schedule type:** Periodic

**Parameters:**


| Parameter | Required | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | --- | 
| serviceNames  | Required  | The name of the service that the control evaluates  | String  | Not customizable  | ssm | 
| vpcIds  | Optional  | Comma-separated list of Amazon VPC IDs for VPC endpoints. If provided, the control fails if the services specified in the serviceName parameter don't have one of these VPC endpoints.  | StringList  | Customize with one or more VPC IDs  | No default value  | 

This control checks whether a virtual private cloud (VPC) that you manage has an interface VPC endpoint for AWS Systems Manager. The control fails if the VPC doesn't have an interface VPC endpoint for Systems Manager. This control evaluates resources in a single account.

AWS PrivateLink enables customers to access services hosted on AWS in a highly available and scalable manner, while keeping all the network traffic within the AWS network. Service users can privately access services powered by PrivateLink from their VPC or their on-premises, without using public IPs, and without requiring traffic to traverse across the internet.

### Remediation
<a name="ec2-57-remediation"></a>

To configure a VPC endpoint, see [Access an AWS service using an interface VPC endpoint](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html) in the *AWS PrivateLink Guide*.

## [EC2.58] VPCs should be configured with an interface endpoint for Systems Manager Incident Manager Contacts
<a name="ec2-58"></a>

**Related requirements:** NIST.800-53.r5 AC-21, NIST.800-53.r5 AC-3, NIST.800-53.r5 AC-3(7), NIST.800-53.r5 AC-4, NIST.800-53.r5 AC-4(21), NIST.800-53.r5 AC-6, NIST.800-53.r5 SC-7, NIST.800-53.r5 SC-7(11), NIST.800-53.r5 SC-7(16), NIST.800-53.r5 SC-7(20), NIST.800-53.r5 SC-7(21), NIST.800-53.r5 SC-7(3), NIST.800-53.r5 SC-7(4)

**Category:** Protect > Secure access management > Access control

**Severity:** Medium

**Resource type:** `AWS::EC2::VPC`, `AWS::EC2::VPCEndpoint`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/vpc-endpoint-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/vpc-endpoint-enabled.html)

**Schedule type:** Periodic

**Parameters:**


| Parameter | Required | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | --- | 
| serviceNames  | Required  | The name of the service that the control evaluates  | String  | Not customizable  | ssm-contacts | 
| vpcIds  | Optional  | Comma-separated list of Amazon VPC IDs for VPC endpoints. If provided, the control fails if the services specified in the serviceName parameter don't have one of these VPC endpoints.  | StringList  | Customize with one or more VPC IDs  | No default value  | 

This control checks whether a virtual private cloud (VPC) that you manage has an interface VPC endpoint for AWS Systems Manager Incident Manager Contacts. The control fails if the VPC doesn't have an interface VPC endpoint for Systems Manager Incident Manager Contacts. This control evaluates resources in a single account.

AWS PrivateLink enables customers to access services hosted on AWS in a highly available and scalable manner, while keeping all the network traffic within the AWS network. Service users can privately access services powered by PrivateLink from their VPC or their on-premises, without using public IPs, and without requiring traffic to traverse across the internet.

### Remediation
<a name="ec2-58-remediation"></a>

To configure a VPC endpoint, see [Access an AWS service using an interface VPC endpoint](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html) in the *AWS PrivateLink Guide*.

## [EC2.60] VPCs should be configured with an interface endpoint for Systems Manager Incident Manager
<a name="ec2-60"></a>

**Related requirements:** NIST.800-53.r5 AC-21, NIST.800-53.r5 AC-3, NIST.800-53.r5 AC-3(7), NIST.800-53.r5 AC-4, NIST.800-53.r5 AC-4(21), NIST.800-53.r5 AC-6, NIST.800-53.r5 SC-7, NIST.800-53.r5 SC-7(11), NIST.800-53.r5 SC-7(16), NIST.800-53.r5 SC-7(20), NIST.800-53.r5 SC-7(21), NIST.800-53.r5 SC-7(3), NIST.800-53.r5 SC-7(4)

**Category:** Protect > Secure access management > Access control

**Severity:** Medium

**Resource type:** `AWS::EC2::VPC`, `AWS::EC2::VPCEndpoint`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/vpc-endpoint-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/vpc-endpoint-enabled.html)

**Schedule type:** Periodic

**Parameters:**


| Parameter | Required | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | --- | 
| serviceNames  | Required  | The name of the service that the control evaluates  | String  | Not customizable  | ssm-incidents | 
| vpcIds  | Optional  | Comma-separated list of Amazon VPC IDs for VPC endpoints. If provided, the control fails if the services specified in the serviceName parameter don't have one of these VPC endpoints.  | StringList  | Customize with one or more VPC IDs  | No default value  | 

This control checks whether a virtual private cloud (VPC) that you manage has an interface VPC endpoint for AWS Systems Manager Incident Manager. The control fails if the VPC doesn't have an interface VPC endpoint for Systems Manager Incident Manager. This control evaluates resources in a single account.

AWS PrivateLink enables customers to access services hosted on AWS in a highly available and scalable manner, while keeping all the network traffic within the AWS network. Service users can privately access services powered by PrivateLink from their VPC or their on-premises, without using public IPs, and without requiring traffic to traverse across the internet.

### Remediation
<a name="ec2-60-remediation"></a>

To configure a VPC endpoint, see [Access an AWS service using an interface VPC endpoint](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html) in the *AWS PrivateLink Guide*.

## [EC2.170] EC2 launch templates should use Instance Metadata Service Version 2 (IMDSv2)
<a name="ec2-170"></a>

**Related requirements:** PCI DSS v4.0.1/2.2.6

**Category:** Protect > Network Security

**Severity:** Low

**Resource type:** `AWS::EC2::LaunchTemplate`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/ec2-launch-template-imdsv2-check.html](https://docs.aws.amazon.com/config/latest/developerguide/ec2-launch-template-imdsv2-check.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether an Amazon EC2 launch template is configured with Instance Metadata Service Version 2 (IMDSv2). The control fails if `HttpTokens` is set to `optional`.

Running resources on supported software versions ensures optimal performance, security, and access to the latest features. Regular updates safeguard against vulnerabilities, which help ensure a stable and efficient user experience.

### Remediation
<a name="ec2-170-remediation"></a>

To require IMDSv2 on an EC2 launch template, see [Configure the Instance Metadata Service options](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-options.html) in the *Amazon EC2 User Guide*.

## [EC2.171] EC2 VPN connections should have logging enabled
<a name="ec2-171"></a>

**Related requirements:** CIS AWS Foundations Benchmark v3.0.0/5.3, PCI DSS v4.0.1/10.4.2

**Category:** Identify > Logging

**Severity:** Medium

**Resource type:** `AWS::EC2::VPNConnection`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/ec2-vpn-connection-logging-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/ec2-vpn-connection-logging-enabled.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether an AWS Site-to-Site VPN connection has Amazon CloudWatch Logs enabled for both tunnels. The control fails if a Site-to-Site VPN connection doesn't have CloudWatch Logs enabled for both tunnels.

AWS Site-to-Site VPN logs provide you with deeper visibility into your Site-to-Site VPN deployments. With this feature, you have access to Site-to-Site VPN connection logs that provide details on IP Security (IPsec) tunnel establishment, Internet Key Exchange (IKE) negotiations, and dead peer detection (DPD) protocol messages. Site-to-Site VPN logs can be published to CloudWatch Logs. This feature provides customers with a single consistent way to access and analyze detailed logs for all of their Site-to-Site VPN connections.

### Remediation
<a name="ec2-171-remediation"></a>

To enable tunnel logging on an EC2 VPN connection, see [AWS Site-to-Site VPN logs](https://docs.aws.amazon.com/vpn/latest/s2svpn/monitoring-logs.html#enable-logs) in the *AWS Site-to-Site VPN User Guide*.

## [EC2.172] EC2 VPC Block Public Access settings should block internet gateway traffic
<a name="ec2-172"></a>

**Category:** Protect > Secure network configuration > Resources not publicly accessible

**Severity:** Medium

**Resource type:** `AWS::EC2::VPCBlockPublicAccessOptions`

**AWS Config rule:** `ec2-vpc-bpa-internet-gateway-blocked` (custom Security Hub CSPM rule)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  `vpcBpaInternetGatewayBlockMode`  |  String value of the VPC BPA options mode.  |  Enum  |  `block-bidirectional`, `block-ingress`  |  No default value  | 

This control checks whether Amazon EC2 VPC Block Public Access (BPA) settings are configured to block internet gateway traffic for all Amazon VPCs in the AWS account. The control fails if VPC BPA settings aren't configured to block internet gateway traffic. For the control to pass, the VPC BPA `InternetGatewayBlockMode` must be set to `block-bidirectional` or `block-ingress`. If the parameter `vpcBpaInternetGatewayBlockMode` is provided, the control passes only if the VPC BPA value for `InternetGatewayBlockMode` matches the parameter.

Configuring the VPC BPA settings for your account in an AWS Region lets you block resources in VPCs and subnets that you own in that Region from reaching or being reached from the internet through internet gateways and egress-only internet gateways. If you need specific VPCs and subnets to be able to reach or be reachable from the internet, you can exclude them by configuring VPC BPA exclusions. For instructions on creating and deleting exclusions, see [Create and delete exclusions](https://docs.aws.amazon.com/vpc/latest/userguide/security-vpc-bpa-basics.html#security-vpc-bpa-exclusions) in the *Amazon VPC User Guide*.

### Remediation
<a name="ec2-172-remediation"></a>

To enable bi-directional BPA at the account level, see [Enable BPA bidirectional mode for your account](https://docs.aws.amazon.com/vpc/latest/userguide/security-vpc-bpa-basics.html#security-vpc-bpa-enable-bidir) in the *Amazon VPC User Guide*. To enable ingress-only BPA, see [Change VPC BPA mode to ingress-only](https://docs.aws.amazon.com/vpc/latest/userguide/security-vpc-bpa-basics.html#security-vpc-bpa-ingress-only). To enable VPC BPA at the Organization level, see [Enable VPC BPA at the Organization level](https://docs.aws.amazon.com/vpc/latest/userguide/security-vpc-bpa-basics.html#security-vpc-bpa-exclusions-orgs).

## [EC2.173] EC2 Spot Fleet requests with launch parameters should enable encryption for attached EBS volumes
<a name="ec2-173"></a>

**Category:** Protect > Data Protection > Encryption of data-at-rest

**Severity:** Medium

**Resource type:** `AWS::EC2::SpotFleet`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/ec2-spot-fleet-request-ct-encryption-at-rest.html](https://docs.aws.amazon.com/config/latest/developerguide/ec2-spot-fleet-request-ct-encryption-at-rest.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether an Amazon EC2 Spot Fleet request that specifies launch parameters is configured to enable encryption for all Amazon Elastic Block Store (Amazon EBS) volumes attached to EC2 instances. The control fails if the Spot Fleet request specifies launch parameters and doesn't enable encryption for one or more EBS volumes specified in the request.

For an additional layer of security, you should enable encryption for Amazon EBS volumes. Encryption operations then occur on the servers that host Amazon EC2 instances, which helps ensure the security of both data at rest and data in transit between an instance and its attached EBS storage. Amazon EBS encryption is a straightforward encryption solution for EBS resources associated with your EC2 instances. With EBS encryption, you aren't required to build, maintain, and secure your own key management infrastructure. EBS encryption uses AWS KMS keys when creating encrypted volumes.

**Notes**  
This control doesn't generate findings for Amazon EC2 Spot Fleet requests that use launch templates. It also doesn't generate findings for Spot Fleet requests that don't explicitly specify a value for the `encrypted` parameter.

### Remediation
<a name="ec2-173-remediation"></a>

There's no direct way to encrypt an existing, unencrypted Amazon EBS volume. You can encrypt a new volume only when you create it.

However, if you enable encryption by default, Amazon EBS encrypts new volumes by using your default key for EBS encryption. If you don't enable encryption by default, you can enable encryption when you create an individual volume. In both cases, you can override the default key for EBS encryption and choose a customer managed AWS KMS key. For more information about EBS encryption, see [Amazon EBS encryption](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-encryption.html) in the *Amazon EBS User Guide*.

For information about creating an Amazon EC2 Spot Fleet request, see [Create a Spot Fleet](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/create-spot-fleet.html) in the *Amazon Elastic Compute Cloud User Guide*.

## [EC2.174] EC2 DHCP option sets should be tagged
<a name="ec2-174"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::EC2::DHCPOptions`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/ec2-dhcp-options-tagged.html](https://docs.aws.amazon.com/config/latest/developerguide/ec2-dhcp-options-tagged.html)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
| requiredKeyTags | A list of non-system tag keys that must be assigned to an evaluated resource. Tag keys are case sensitive. | StringList (maximum of 6 items) | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions). | No default value | 

This control checks whether an Amazon EC2 DHCP option set has the tag keys specified by the `requiredKeyTags` parameter. The control fails if the option set doesn't have any tag keys, or it doesn't have all the keys specified by the `requiredKeyTags` parameter. If you don't specify any values for the `requiredKeyTags` parameter, the control checks only for the existence of a tag key and fails if the option set doesn't have any tag keys. The control ignores system tags, which are applied automatically and have the `aws:` prefix.

A tag is a label that you create and assign to an AWS resource. Each tag consists of a required tag key and an optional tag value. You can use tags to categorize resources by purpose, owner, environment, or other criteria. They can help you identify, organize, search for, and filter resources. They can also help you track resource owners for actions and notifications. You can also use tags to implement attribute-based access control (ABAC) as an authorization strategy. For more information about ABAC strategies, see [Define permissions based on attributes with ABAC authorization](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*. For more information about tags, see the [Tagging AWS Resources and Tag Editor User Guide](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html).

**Note**  
Do not store personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible from many AWS services. They aren't intended to be used for private or sensitive data.

### Remediation
<a name="ec2-174-remediation"></a>

For information about adding tags to an Amazon EC2 DHCP option set, see [Tag your Amazon EC2 resources](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html) in the *Amazon EC2 User Guide*.

## [EC2.175] EC2 launch templates should be tagged
<a name="ec2-175"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::EC2::LaunchTemplate`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/ec2-launch-template-tagged.html](https://docs.aws.amazon.com/config/latest/developerguide/ec2-launch-template-tagged.html)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
| requiredKeyTags | A list of non-system tag keys that must be assigned to an evaluated resource. Tag keys are case sensitive. | StringList (maximum of 6 items) | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions). | No default value | 

This control checks whether an Amazon EC2 launch template has the tag keys specified by the `requiredKeyTags` parameter. The control fails if the launch template doesn't have any tag keys, or it doesn't have all the keys specified by the `requiredKeyTags` parameter. If you don't specify any values for the `requiredKeyTags` parameter, the control checks only for the existence of a tag key and fails if the launch template doesn't have any tag keys. The control ignores system tags, which are applied automatically and have the `aws:` prefix.

A tag is a label that you create and assign to an AWS resource. Each tag consists of a required tag key and an optional tag value. You can use tags to categorize resources by purpose, owner, environment, or other criteria. They can help you identify, organize, search for, and filter resources. They can also help you track resource owners for actions and notifications. You can also use tags to implement attribute-based access control (ABAC) as an authorization strategy. For more information about ABAC strategies, see [Define permissions based on attributes with ABAC authorization](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*. For more information about tags, see the [Tagging AWS Resources and Tag Editor User Guide](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html).

**Note**  
Do not store personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible from many AWS services. They aren't intended to be used for private or sensitive data.

### Remediation
<a name="ec2-175-remediation"></a>

For information about adding tags to an Amazon EC2 launch template, see [Tag your Amazon EC2 resources](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html) in the *Amazon EC2 User Guide*.

## [EC2.176] EC2 prefix lists should be tagged
<a name="ec2-176"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::EC2::PrefixList`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/ec2-prefix-list-tagged.html](https://docs.aws.amazon.com/config/latest/developerguide/ec2-prefix-list-tagged.html)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
| requiredKeyTags | A list of non-system tag keys that must be assigned to an evaluated resource. Tag keys are case sensitive. | StringList (maximum of 6 items) | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions). | No default value | 

This control checks whether an Amazon EC2 prefix list has the tag keys specified by the `requiredKeyTags` parameter. The control fails if the prefix list doesn't have any tag keys, or it doesn't have all the keys specified by the `requiredKeyTags` parameter. If you don't specify any values for the `requiredKeyTags` parameter, the control checks only for the existence of a tag key and fails if the prefix list doesn't have any tag keys. The control ignores system tags, which are applied automatically and have the `aws:` prefix.

A tag is a label that you create and assign to an AWS resource. Each tag consists of a required tag key and an optional tag value. You can use tags to categorize resources by purpose, owner, environment, or other criteria. They can help you identify, organize, search for, and filter resources. They can also help you track resource owners for actions and notifications. You can also use tags to implement attribute-based access control (ABAC) as an authorization strategy. For more information about ABAC strategies, see [Define permissions based on attributes with ABAC authorization](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*. For more information about tags, see the [Tagging AWS Resources and Tag Editor User Guide](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html).

**Note**  
Do not store personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible from many AWS services. They aren't intended to be used for private or sensitive data.

### Remediation
<a name="ec2-176-remediation"></a>

For information about adding tags to an Amazon EC2 prefix list, see [Tag your Amazon EC2 resources](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html) in the *Amazon EC2 User Guide*.

## [EC2.177] EC2 traffic mirror sessions should be tagged
<a name="ec2-177"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::EC2::TrafficMirrorSession`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/ec2-traffic-mirror-session-tagged.html](https://docs.aws.amazon.com/config/latest/developerguide/ec2-traffic-mirror-session-tagged.html)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
| requiredKeyTags | A list of non-system tag keys that must be assigned to an evaluated resource. Tag keys are case sensitive. | StringList (maximum of 6 items) | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions). | No default value | 

This control checks whether an Amazon EC2 traffic mirror session has the tag keys specified by the `requiredKeyTags` parameter. The control fails if the session doesn't have any tag keys, or it doesn't have all the keys specified by the `requiredKeyTags` parameter. If you don't specify any values for the `requiredKeyTags` parameter, the control checks only for the existence of a tag key and fails if the session doesn't have any tag keys. The control ignores system tags, which are applied automatically and have the `aws:` prefix.

A tag is a label that you create and assign to an AWS resource. Each tag consists of a required tag key and an optional tag value. You can use tags to categorize resources by purpose, owner, environment, or other criteria. They can help you identify, organize, search for, and filter resources. They can also help you track resource owners for actions and notifications. You can also use tags to implement attribute-based access control (ABAC) as an authorization strategy. For more information about ABAC strategies, see [Define permissions based on attributes with ABAC authorization](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*. For more information about tags, see the [Tagging AWS Resources and Tag Editor User Guide](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html).

**Note**  
Do not store personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible from many AWS services. They aren't intended to be used for private or sensitive data.

### Remediation
<a name="ec2-177-remediation"></a>

For information about adding tags to an Amazon EC2 traffic mirror session, see [Tag your Amazon EC2 resources](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html) in the *Amazon EC2 User Guide*.

## [EC2.178] EC2 traffic mirror filters should be tagged
<a name="ec2-178"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::EC2::TrafficMirrorFilter`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/ec2-traffic-mirror-filter-tagged.html](https://docs.aws.amazon.com/config/latest/developerguide/ec2-traffic-mirror-filter-tagged.html)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
| requiredKeyTags | A list of non-system tag keys that must be assigned to an evaluated resource. Tag keys are case sensitive. | StringList (maximum of 6 items) | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions). | No default value | 

This control checks whether an Amazon EC2 traffic mirror filter has the tag keys specified by the `requiredKeyTags` parameter. The control fails if the filter doesn't have any tag keys, or it doesn't have all the keys specified by the `requiredKeyTags` parameter. If you don't specify any values for the `requiredKeyTags` parameter, the control checks only for the existence of a tag key and fails if the filter doesn't have any tag keys. The control ignores system tags, which are applied automatically and have the `aws:` prefix.

A tag is a label that you create and assign to an AWS resource. Each tag consists of a required tag key and an optional tag value. You can use tags to categorize resources by purpose, owner, environment, or other criteria. They can help you identify, organize, search for, and filter resources. They can also help you track resource owners for actions and notifications. You can also use tags to implement attribute-based access control (ABAC) as an authorization strategy. For more information about ABAC strategies, see [Define permissions based on attributes with ABAC authorization](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*. For more information about tags, see the [Tagging AWS Resources and Tag Editor User Guide](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html).

**Note**  
Do not store personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible from many AWS services. They aren't intended to be used for private or sensitive data.

### Remediation
<a name="ec2-178-remediation"></a>

For information about adding tags to an Amazon EC2 traffic mirror filter, see [Tag your Amazon EC2 resources](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html) in the *Amazon EC2 User Guide*.

## [EC2.179] EC2 traffic mirror targets should be tagged
<a name="ec2-179"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::EC2::TrafficMirrorTarget`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/ec2-traffic-mirror-target-tagged.html](https://docs.aws.amazon.com/config/latest/developerguide/ec2-traffic-mirror-target-tagged.html)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
| requiredKeyTags | A list of non-system tag keys that must be assigned to an evaluated resource. Tag keys are case sensitive. | StringList (maximum of 6 items) | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions). | No default value | 

This control checks whether an Amazon EC2 traffic mirror target has the tag keys specified by the `requiredKeyTags` parameter. The control fails if the target doesn't have any tag keys, or it doesn't have all the keys specified by the `requiredKeyTags` parameter. If you don't specify any values for the `requiredKeyTags` parameter, the control checks only for the existence of a tag key and fails if the target doesn't have any tag keys. The control ignores system tags, which are applied automatically and have the `aws:` prefix.

A tag is a label that you create and assign to an AWS resource. Each tag consists of a required tag key and an optional tag value. You can use tags to categorize resources by purpose, owner, environment, or other criteria. They can help you identify, organize, search for, and filter resources. They can also help you track resource owners for actions and notifications. You can also use tags to implement attribute-based access control (ABAC) as an authorization strategy. For more information about ABAC strategies, see [Define permissions based on attributes with ABAC authorization](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*. For more information about tags, see the [Tagging AWS Resources and Tag Editor User Guide](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html).

**Note**  
Do not store personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible from many AWS services. They aren't intended to be used for private or sensitive data.

### Remediation
<a name="ec2-179-remediation"></a>

For information about adding tags to an Amazon EC2 traffic mirror target, see [Tag your Amazon EC2 resources](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html) in the *Amazon EC2 User Guide*.

## [EC2.180] EC2 network interfaces should have source/destination checking enabled
<a name="ec2-180"></a>

**Category:** Protect > Network Security

**Severity:** Medium

**Resource type:** `AWS::EC2::NetworkInterface`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/ec2-enis-source-destination-check-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/ec2-enis-source-destination-check-enabled.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether source/destination checking is enabled for an Amazon EC2 elastic network interface (ENI) that's managed by users. The control fails if source/destination checking is disabled for the user-managed ENI. This control checks only the following types of ENIs: `aws_codestar_connections_managed`, `branch`, `efa`, `interface`, `lambda`, and `quicksight`.

Source/destination checking for Amazon EC2 instances and attached ENIs should be enabled and configured consistently across your EC2 instances. Each ENI has its own setting for source/destination checks. If source/destination checking is enabled, Amazon EC2 enforces source/destination address validation, which ensures that an instance is either the source or the destination of any traffic that it receives. This provides an additional layer of network security by preventing resources from handling unintended traffic and preventing IP address spoofing.

**Note**  
If you're using an EC2 instance as a NAT instance and you disabled source/destination checking for its ENI, you can use a [NAT gateway](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html) instead.

### Remediation
<a name="ec2-180-remediation"></a>

For information about enabling source/destination checks for an Amazon EC2 ENI, see [Modify network interface attributes](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/modify-network-interface-attributes.html#modify-source-dest-check) in the *Amazon EC2 User Guide*.

## [EC2.181] EC2 launch templates should enable encryption for attached EBS volumes
<a name="ec2-181"></a>

**Category:** Protect > Data Protection > Encryption of data-at-rest

**Severity:** Medium

**Resource type:** `AWS::EC2::LaunchTemplate`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/ec2-launch-templates-ebs-volume-encrypted.html](https://docs.aws.amazon.com/config/latest/developerguide/ec2-launch-templates-ebs-volume-encrypted.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether an Amazon EC2 launch template enables encryption for all attached EBS volumes. The control fails if the encryption parameter is set to `False` for any EBS volumes specified by the EC2 launch template.

Amazon EBS encryption is a straightforward encryption solution for EBS resources that are associated with Amazon EC2 instances. With EBS encryption, you aren't required to build, maintain, and secure your own key management infrastructure. EBS encryption uses AWS KMS keys when creating encrypted volumes and snapshots. Encryption operations occur on the servers that host EC2 instances, which helps ensure the security of data at rest and data in transit between an EC2 instance and its attached EBS storage. For more information, see [Amazon EBS encryption](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-encryption.html) in the *Amazon EBS User Guide*.

You can enable EBS encryption during manual launches of individual EC2 instances. However, there are several benefits to using EC2 launch templates and configuring encryption settings in those templates. You can enforce encryption as a standard and ensure the use of consistent encryption settings. You can also reduce the risk of error and security gaps that might occur with manual launches of instances.

**Note**  
When this control checks an EC2 launch template, it only evaluates EBS encryption settings that are explicitly specified by the template. The evaluation doesn’t include encryption settings that are inherited from account-level EBS encryption settings, AMI block device mappings, or source snapshot encryption statuses.

### Remediation
<a name="ec2-181-remediation"></a>

After you create an Amazon EC2 launch template, you can't modify it. However, you can create a new version of a launch template and change the encryption settings in that new version of the template. You can also specify the new version as the default version of the launch template. Then, if you launch an EC2 instance from a launch template and don't specify a template version, EC2 uses the settings of the default version when it launches the instance. For more information, see [Modify a launch template](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/manage-launch-template-versions.html) in the *Amazon EC2 User Guide*.

## [EC2.182] Block public access settings should be enabled for Amazon EBS snapshots
<a name="ec2-182"></a>

**Category:** Protect > Secure network configuration > Resources not publicly accessible

**Severity:** High

**Resource type:** `AWS::EC2::SnapshotBlockPublicAccess`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/ebs-snapshot-block-public-access.html](https://docs.aws.amazon.com/config/latest/developerguide/ebs-snapshot-block-public-access.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether account level block public access is enabled to prevent sharing of Amazon EBS snapshots to all. The control fails if block public access is not enabled to block sharing of Amazon EBS snapshots to all.

To prevent public sharing of your Amazon EBS snapshots, you can enable block public access for snapshots. Once block public access for snapshots is enabled in a Region, any attempt to publicly share snapshots in that Region is automatically blocked. This helps improve the security of the snapshots and protect the snapshot data from unauthorized or unintended access. 

### Remediation
<a name="ec2-182-remediation"></a>

To enable block public access for snapshots, see [Configure block public access for Amazon EBS snapshots](https://docs.aws.amazon.com/ebs/latest/userguide/block-public-access-snapshots-enable.html) in the *Amazon EBS User Guide*. For **Block public access**, choose **Block all public access**.

## [EC2.183] EC2 VPN connections should use IKEv2 protocol
<a name="ec2-183"></a>

**Category:** Protect > Data Protection > Encryption of data-in-transit

**Severity:** Medium

**Resource type:** `AWS::EC2::VPNConnection`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/ec2-vpn-connection-ike-version-check.html](https://docs.aws.amazon.com/config/latest/developerguide/ec2-vpn-connection-ike-version-check.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether an AWS Site-to-Site VPN connection is configured to use IKEv2 protocol. The control fails if a Site-to-Site VPN connection allows IKEv1 protocol or does not explicitly restrict to IKEv2 on all VPN tunnels.

IKEv2 provides stronger cryptographic algorithms and improved security features compared to the legacy IKEv1 protocol, including built-in protection against denial-of-service attacks and enhanced authentication mechanisms. IKEv1 has known vulnerabilities and weaknesses in its key exchange process that can be exploited by attackers to compromise VPN tunnel security. By enforcing IKEv2-only connections, you reduce your attack surface and ensure VPN communications use modern, industry-standard encryption protocols that better protect data in transit.

### Remediation
<a name="ec2-183-remediation"></a>

To update the IKE version for a VPN tunnel on an EC2 VPN connection, see [Modify AWS Site-to-Site VPN tunnel options](https://docs.aws.amazon.com/vpn/latest/s2svpn/modify-vpn-tunnel-options.html) in the *AWS Site-to-Site VPN User Guide*.

# Security Hub CSPM controls for Auto Scaling
<a name="autoscaling-controls"></a>

These Security Hub CSPM controls evaluate the Amazon EC2 Auto Scaling service and resources.

These controls may not be available in all AWS Regions. For more information, see [Availability of controls by Region](securityhub-regions.md#securityhub-regions-control-support).

## [AutoScaling.1] Auto Scaling groups associated with a load balancer should use ELB health checks
<a name="autoscaling-1"></a>

**Related requirements:** PCI DSS v3.2.1/2.2, NIST.800-53.r5 CA-7, NIST.800-53.r5 CP-2(2), NIST.800-53.r5 SI-2

**Category:** Identify > Inventory

**Severity:** Low

**Resource type:** `AWS::AutoScaling::AutoScalingGroup`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/autoscaling-group-elb-healthcheck-required.html](https://docs.aws.amazon.com/config/latest/developerguide/autoscaling-group-elb-healthcheck-required.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether an Amazon EC2 Auto Scaling group that is associated with a load balancer uses Elastic Load Balancing (ELB) health checks. The control fails if the Auto Scaling group doesn't use ELB health checks.

ELB health checks help ensure that an Auto Scaling group can determine an instance's health based on additional tests provided by the load balancer. Using Elastic Load Balancing health checks also helps support the availability of applications that use EC2 Auto Scaling groups.

### Remediation
<a name="autoscaling-1-remediation"></a>

To add Elastic Load Balancing health checks, see [Add Elastic Load Balancing health checks](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-add-elb-healthcheck.html#as-add-elb-healthcheck-console) in the *Amazon EC2 Auto Scaling User Guide*.

## [AutoScaling.2] Amazon EC2 Auto Scaling group should cover multiple Availability Zones
<a name="autoscaling-2"></a>

**Related requirements:** NIST.800-53.r5 CP-10, NIST.800-53.r5 CP-2(2), NIST.800-53.r5 CP-6(2), NIST.800-53.r5 SC-36, NIST.800-53.r5 SC-5(2), NIST.800-53.r5 SI-13(5)

**Category:** Recover > Resilience > High availability

**Severity:** Medium

**Resource type:** `AWS::AutoScaling::AutoScalingGroup`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/autoscaling-multiple-az.html](https://docs.aws.amazon.com/config/latest/developerguide/autoscaling-multiple-az.html)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  `minAvailabilityZones`  |  Minimum number of Availability Zones  |  Enum  |  `2, 3, 4, 5, 6`  |  `2`  | 

This control checks whether an Amazon EC2 Auto Scaling group spans at least the specified number of Availability Zones (AZs). The control fails if an Auto Scaling group doesn't span at least the specified number of AZs. Unless you provide a custom parameter value for the minimum number of AZs, Security Hub CSPM uses a default value of two AZs.

An Auto Scaling group that doesn't span multiple AZs can't launch instances in another AZ to compensate if the configured single AZ becomes unavailable. However, an Auto Scaling group with a single Availability Zone may be preferred in some use cases, such as batch jobs or when inter-AZ transfer costs need to be kept to a minimum. In such cases, you can disable this control or suppress its findings. 

### Remediation
<a name="autoscaling-2-remediation"></a>

To add AZs to an existing Auto Scaling group, see [Add and remove Availability Zones](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-add-availability-zone.html) in the *Amazon EC2 Auto Scaling User Guide*.

## [AutoScaling.3] Auto Scaling group launch configurations should configure EC2 instances to require Instance Metadata Service Version 2 (IMDSv2)
<a name="autoscaling-3"></a>

**Related requirements:** NIST.800-53.r5 AC-3, NIST.800-53.r5 AC-3(15), NIST.800-53.r5 AC-3(7), NIST.800-53.r5 AC-6, NIST.800-53.r5 CA-9(1), NIST.800-53.r5 CM-2, PCI DSS v4.0.1/2.2.6

**Category:** Protect > Secure network configuration

**Severity:** High

**Resource type:** `AWS::AutoScaling::LaunchConfiguration`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/autoscaling-launchconfig-requires-imdsv2.html](https://docs.aws.amazon.com/config/latest/developerguide/autoscaling-launchconfig-requires-imdsv2.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether IMDSv2 is enabled on all instances launched by Amazon EC2 Auto Scaling groups. The control fails if the Instance Metadata Service (IMDS) version isn't included in the launch configuration or is configured as `token optional`, which is a setting that allows either IMDSv1 or IMDSv2.

IMDS provides data about your instance that you can use to configure or manage the running instance.

Version 2 of the IMDS adds new protections that weren't available in IMDSv1 to further safeguard your EC2 instances.

### Remediation
<a name="autoscaling-3-remediation"></a>

An Auto Scaling group is associated with one launch configuration at a time. You cannot modify a launch configuration after you create it. To change the launch configuration for an Auto Scaling group, use an existing launch configuration as the basis for a new launch configuration with IMDSv2 enabled. For more information, see [Configure instance metadata options for new instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-IMDS-new-instances.html) in the *Amazon EC2 User Guide*.

## [AutoScaling.4] Auto Scaling group launch configuration should not have a metadata response hop limit greater than 1
<a name="autoscaling-4"></a>

**Important**  
Security Hub CSPM retired this control in April 2024. For more information, see [Change log for Security Hub CSPM controls](controls-change-log.md).

**Related requirements:** NIST.800-53.r5 CA-9(1), NIST.800-53.r5 CM-2, NIST.800-53.r5 CM-2(2)

**Category:** Protect > Secure network configuration

**Severity:** High

**Resource type:** `AWS::AutoScaling::LaunchConfiguration`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/autoscaling-launch-config-hop-limit.html](https://docs.aws.amazon.com/config/latest/developerguide/autoscaling-launch-config-hop-limit.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks the number of network hops that a metadata token can travel. The control fails if the metadata response hop limit is greater than `1`.

The Instance Metadata Service (IMDS) provides metadata information about an Amazon EC2 instance and is useful for application configuration. Restricting the HTTP `PUT` response for the metadata service to only the EC2 instance protects the IMDS from unauthorized use.

The Time To Live (TTL) field in the IP packet is reduced by one on every hop. This reduction can be used to ensure that the packet does not travel outside EC2. IMDSv2 protects EC2 instances that may have been misconfigured as open routers, layer 3 firewalls, VPNs, tunnels, or NAT devices, which prevents unauthorized users from retrieving metadata. With IMDSv2, the `PUT` response that contains the secret token cannot travel outside the instance because the default metadata response hop limit is set to `1`. However, if this value is greater than `1`, the token can leave the EC2 instance. 

### Remediation
<a name="autoscaling-4-remediation"></a>

To modify the metadata response hop limit for an existing launch configuration, see [Modify instance metadata options for existing instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-options.html#configuring-IMDS-existing-instances) in the *Amazon EC2 User Guide*.

## [Autoscaling.5] Amazon EC2 instances launched using Auto Scaling group launch configurations should not have Public IP addresses
<a name="autoscaling-5"></a>

**Related requirements:** NIST.800-53.r5 AC-21, NIST.800-53.r5 AC-3, NIST.800-53.r5 AC-3(7), NIST.800-53.r5 AC-4, NIST.800-53.r5 AC-4(21), NIST.800-53.r5 AC-6, NIST.800-53.r5 SC-7, NIST.800-53.r5 SC-7(11), NIST.800-53.r5 SC-7(16), NIST.800-53.r5 SC-7(20), NIST.800-53.r5 SC-7(21), NIST.800-53.r5 SC-7(3), NIST.800-53.r5 SC-7(4), NIST.800-53.r5 SC-7(9), PCI DSS v4.0.1/1.4.4

**Category:** Protect > Secure network configuration > Resources not publicly accessible

**Severity:** High

**Resource type:** `AWS::AutoScaling::LaunchConfiguration`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/autoscaling-launch-config-public-ip-disabled.html](https://docs.aws.amazon.com/config/latest/developerguide/autoscaling-launch-config-public-ip-disabled.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether an Auto Scaling group's associated launch configuration assigns a [public IP address](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-instance-addressing.html#public-ip-addresses) to the group's instances. The control fails if the associated launch configuration assigns a public IP address.

Amazon EC2 instances in an Auto Scaling group launch configuration should not have an associated public IP address, except for in limited edge cases. Amazon EC2 instances should only be accessible from behind a load balancer instead of being directly exposed to the internet.

### Remediation
<a name="autoscaling-5-remediation"></a>

An Auto Scaling group is associated with one launch configuration at a time. You cannot modify a launch configuration after you create it. To change the launch configuration for an Auto Scaling group, use an existing launch configuration as the basis for a new launch configuration. Then, update the Auto Scaling group to use the new launch configuration. For step-by-step instructions, see [Change the launch configuration for an Auto Scaling group](https://docs.aws.amazon.com/autoscaling/ec2/userguide/change-launch-config.html) in the *Amazon EC2 Auto Scaling User Guide*. When creating the new launch configuration, under **Additional configuration**, for **Advanced details, IP address type**, choose **Do not assign a public IP address to any instances**.

After you change the launch configuration, Auto Scaling launches new instances with the new configuration options. Existing instances aren't affected. To update an existing instance, we recommend that you refresh your instance, or allow automatic scaling to gradually replace older instances with newer instances based on your termination policies. For more information about updating Auto Scaling instances, see [Update Auto Scaling instances](https://docs.aws.amazon.com/autoscaling/ec2/userguide/update-auto-scaling-group.html#update-auto-scaling-instances) in the *Amazon EC2 Auto Scaling User Guide*.

## [AutoScaling.6] Auto Scaling groups should use multiple instance types in multiple Availability Zones
<a name="autoscaling-6"></a>

**Related requirements:** NIST.800-53.r5 CP-10, NIST.800-53.r5 CP-2(2), NIST.800-53.r5 CP-6(2), NIST.800-53.r5 SC-36, NIST.800-53.r5 SC-5(2), NIST.800-53.r5 SI-13(5)

**Category:** Recover > Resilience > High availability

**Severity:** Medium

**Resource type:** `AWS::AutoScaling::AutoScalingGroup`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/autoscaling-multiple-instance-types.html](https://docs.aws.amazon.com/config/latest/developerguide/autoscaling-multiple-instance-types.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether an Amazon EC2 Auto Scaling group uses multiple instance types. The control fails if the Auto Scaling group has only one instance type defined.

You can enhance availability by deploying your application across multiple instance types running in multiple Availability Zones. Security Hub CSPM recommends using multiple instance types so that the Auto Scaling group can launch another instance type if there is insufficient instance capacity in your chosen Availability Zones.

### Remediation
<a name="autoscaling-6-remediation"></a>

To create an Auto Scaling group with multiple instance types, see [Auto Scaling groups with multiple instance types and purchase options](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-mixed-instances-groups.html) in the *Amazon EC2 Auto Scaling User Guide*.

## [AutoScaling.9] Amazon EC2 Auto Scaling groups should use Amazon EC2 launch templates
<a name="autoscaling-9"></a>

**Related requirements:** NIST.800-53.r5 CA-9(1), NIST.800-53.r5 CM-2, NIST.800-53.r5 CM-2(2)

**Category:** Identify > Resource Configuration

**Severity:** Medium

**Resource type:** `AWS::AutoScaling::AutoScalingGroup`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/autoscaling-launch-template.html](https://docs.aws.amazon.com/config/latest/developerguide/autoscaling-launch-template.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether an Amazon EC2 Auto Scaling group is created from an EC2 launch template. This control fails if an Amazon EC2 Auto Scaling group is not created with a launch template or if a launch template is not specified in a mixed instances policy.

An EC2 Auto Scaling group can be created from either an EC2 launch template or a launch configuration. However, using a launch template to create an Auto Scaling group ensures that you have access to the latest features and improvements.

### Remediation
<a name="autoscaling-9-remediation"></a>

To create an Auto Scaling group with an EC2 launch template, see [Create an Auto Scaling group using a launch template](https://docs.aws.amazon.com/autoscaling/ec2/userguide/create-asg-launch-template.html) in the *Amazon EC2 Auto Scaling User Guide*. For information about how to replace a launch configuration with a launch template, see [Replace a launch configuration with a launch template](https://docs.aws.amazon.com/autoscaling/ec2/userguide/replace-launch-config.html) in the *Amazon EC2 User Guide*.

## [AutoScaling.10] EC2 Auto Scaling groups should be tagged
<a name="autoscaling-10"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::AutoScaling::AutoScalingGroup`

**AWS Config rule:** `tagged-autoscaling-autoscalinggroup` (custom Security Hub CSPM rule)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  | No default value  | 

This control checks whether an Amazon EC2 Auto Scaling group has tags with the specific keys defined in the parameter `requiredTagKeys`. The control fails if the Auto Scaling group doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredTagKeys`. If the parameter `requiredTagKeys` isn't provided, the control only checks for the existence of a tag key and fails if the Auto Scaling group isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [What is ABAC for AWS?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Tagging your AWS resources](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *AWS General Reference*.

### Remediation
<a name="autoscaling-10-remediation"></a>

To add tags to an Auto Scaling group, see [Tag Auto Scaling groups and instances](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-tagging.html) in the *Amazon EC2 Auto Scaling User Guide*.

# Security Hub CSPM controls for Amazon ECR
<a name="ecr-controls"></a>

These Security Hub CSPM controls evaluate the Amazon Elastic Container Registry (Amazon ECR) service and resources.

These controls may not be available in all AWS Regions. For more information, see [Availability of controls by Region](securityhub-regions.md#securityhub-regions-control-support).

## [ECR.1] ECR private repositories should have image scanning configured
<a name="ecr-1"></a>

**Related requirements:** NIST.800-53.r5 RA-5, PCI DSS v4.0.1/6.2.3, PCI DSS v4.0.1/6.2.4

**Category:** Identify > Vulnerability, patch, and version management

**Severity:** High

**Resource type:** `AWS::ECR::Repository`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/ecr-private-image-scanning-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/ecr-private-image-scanning-enabled.html)

**Schedule type:** Periodic

**Parameters:** None

This control checks whether a private Amazon ECR repository has image scanning configured. The control fails if the private ECR repository isn't configured for scan on push or continuous scanning.

ECR image scanning helps in identifying software vulnerabilities in your container images. Configuring image scanning on ECR repositories adds a layer of verification for the integrity and safety of the images being stored.

### Remediation
<a name="ecr-1-remediation"></a>

To configure image scanning for an ECR repository, see [Image scanning](https://docs.aws.amazon.com//AmazonECR/latest/userguide/image-scanning.html) in the *Amazon Elastic Container Registry User Guide*.

## [ECR.2] ECR private repositories should have tag immutability configured
<a name="ecr-2"></a>

**Related requirements:** NIST.800-53.r5 CA-9(1), NIST.800-53.r5 CM-2, NIST.800-53.r5 CM-8(1)

**Category:** Identify > Inventory > Tagging

**Severity:** Medium

**Resource type:** `AWS::ECR::Repository`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/ecr-private-tag-immutability-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/ecr-private-tag-immutability-enabled.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether a private ECR repository has tag immutability enabled. This control fails if a private ECR repository has tag immutability disabled. This rule passes if tag immutability is enabled and has the value `IMMUTABLE`.

Amazon ECR Tag Immutability enables customers to rely on the descriptive tags of an image as a reliable mechanism to track and uniquely identify images. An immutable tag is static, which means each tag refers to a unique image. This improves reliability and scalability as the use of a static tag will always result in the same image being deployed. When configured, tag immutability prevents the tags from being overridden, which reduces the attack surface.

### Remediation
<a name="ecr-2-remediation"></a>

To create a repository with immutable tags configured or to update the image tag mutability settings for an existing repository, see [Image tag mutability](https://docs.aws.amazon.com//AmazonECR/latest/userguide/image-tag-mutability.html) in the *Amazon Elastic Container Registry User Guide*.

## [ECR.3] ECR repositories should have at least one lifecycle policy configured
<a name="ecr-3"></a>

**Related requirements:** NIST.800-53.r5 CA-9(1), NIST.800-53.r5 CM-2, NIST.800-53.r5 CM-2(2)

**Category:** Identify > Resource configuration

**Severity:** Medium

**Resource type:** `AWS::ECR::Repository`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/ecr-private-lifecycle-policy-configured.html](https://docs.aws.amazon.com/config/latest/developerguide/ecr-private-lifecycle-policy-configured.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether an Amazon ECR repository has at least one lifecycle policy configured. This control fails if an ECR repository does not have any lifecycle policies configured.

Amazon ECR lifecycle policies enable you to specify the lifecycle management of images in a repository. By configuring lifecycle policies, you can automate the cleanup of unused images and the expiration of images based on age or count. Automating these tasks can help you avoid unintentionally using outdated images in your repository.

### Remediation
<a name="ecr-3-remediation"></a>

To configure a lifecycle policy, see [Creating a lifecycle policy preview](https://docs.aws.amazon.com//AmazonECR/latest/userguide/lpp_creation.html) in the *Amazon Elastic Container Registry User Guide*.

## [ECR.4] ECR public repositories should be tagged
<a name="ecr-4"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::ECR::PublicRepository`

**AWS Config rule:** `tagged-ecr-publicrepository` (custom Security Hub CSPM rule)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  | No default value  | 

This control checks whether an Amazon ECR public repository has tags with the specific keys defined in the parameter `requiredTagKeys`. The control fails if the public repository doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredTagKeys`. If the parameter `requiredTagKeys` isn't provided, the control only checks for the existence of a tag key and fails if the public repository isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [What is ABAC for AWS?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Tagging your AWS resources](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *AWS General Reference*.

### Remediation
<a name="ecr-4-remediation"></a>

To add tags to an ECR public repository, see [Tagging an Amazon ECR public repository](https://docs.aws.amazon.com/AmazonECR/latest/public/ecr-public-using-tags.html) in the *Amazon Elastic Container Registry User Guide*.

## [ECR.5] ECR repositories should be encrypted with customer managed AWS KMS keys
<a name="ecr-5"></a>

**Related requirements:** NIST.800-53.r5 SC-12(2), NIST.800-53.r5 CM-3(6), NIST.800-53.r5 SC-13, NIST.800-53.r5 SC-28, NIST.800-53.r5 SC-28(1), NIST.800-53.r5 SC-7(10), NIST.800-53.r5 CA-9(1), NIST.800-53.r5 SI-7(6), NIST.800-53.r5 AU-9

**Category:** Protect > Data Protection > Encryption of data-at-rest

**Severity:** Medium

**Resource type:** `AWS::ECR::Repository`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/ecr-repository-cmk-encryption-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/ecr-repository-cmk-encryption-enabled.html)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  `kmsKeyArns`  |  A list of Amazon Resource Names (ARNs) of AWS KMS keys to include in the evaluation. The control generates a `FAILED` finding if an ECR repository isn't encrypted with a KMS key in the list.  |  StringList (maximum of 10 items)  |  1–10 ARNs of existing KMS keys. For example: `arn:aws:kms:us-west-2:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab`  |  No default value  | 

This control checks whether an Amazon ECR repository is encrypted at rest with a customer managed AWS KMS key. The control fails if the ECR repository isn't encrypted with a customer managed KMS key. You can optionally specify a list of KMS keys for the control to include in the evaluation.

By default, Amazon ECR encrypts repository data with Amazon S3 managed keys (SSE-S3), using an AES-256 algorithm. For additional control, you can configure Amazon ECR to encrypt the data with an AWS KMS key (SSE-KMS or DSSE-KMS) instead. The KMS key can be: an AWS managed key that Amazon ECR creates and manages for you and has the alias `aws/ecr`, or a customer managed key that you create and manage in your AWS account. With a customer managed KMS key, you have full control of the key. This includes defining and maintaining the key policy, managing grants, rotating cryptographic material, assigning tags, creating aliases, and enabling and disabling the key.

**Note**  
AWS KMS supports cross-account access to KMS keys. If an ECR repository is encrypted with a KMS key that’s owned by another account, this control doesn’t perform cross-account checks when it evaluates the repository. The control doesn’t assess whether Amazon ECR can access and use the key when performing cryptographic operations for the repository.

### Remediation
<a name="ecr-5-remediation"></a>

You can't change the encryption settings for an existing ECR repository. However, you can specify different encryption settings for ECR repositories that you subsequently create. Amazon ECR supports the use of different encryption settings for individual repositories.

For more information about encryption options for ECR repositories, see [Encryption at rest](https://docs.aws.amazon.com/AmazonECR/latest/userguide/encryption-at-rest.html) in the *Amazon ECR User Guide*. For more information about customer managed AWS KMS keys, see [AWS KMS keys](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html) in the *AWS Key Management Service Developer Guide*.

# Security Hub CSPM controls for Amazon ECS
<a name="ecs-controls"></a>

These Security Hub CSPM controls evaluate the Amazon Elastic Container Service (Amazon ECS) service and resources. The controls might not be available in all AWS Regions. For more information, see [Availability of controls by Region](securityhub-regions.md#securityhub-regions-control-support).

## [ECS.1] Amazon ECS task definitions should have secure networking modes and user definitions
<a name="ecs-1"></a>

**Important**  
Security Hub CSPM retired this control in March 2026. For more information, see [Change log for Security Hub CSPM controls](controls-change-log.md). You can refer to the following controls for evaluation of privileged configuration, network mode configuration, and user configuration:   
 [[ECS.4] ECS containers should run as non-privileged](#ecs-4) 
 [[ECS.17] ECS task definitions should not use host network mode](#ecs-17) 
 [[ECS.20] ECS Task Definitions should configure non-root users in Linux container definitions](#ecs-20) 
 [[ECS.21] ECS Task Definitions should configure non-administrator users in Windows container definitions](#ecs-21) 

**Related requirements:** NIST.800-53.r5 AC-2(1), NIST.800-53.r5 AC-3, NIST.800-53.r5 AC-3(15), NIST.800-53.r5 AC-3(7), NIST.800-53.r5 AC-5, NIST.800-53.r5 AC-6

**Category:** Protect > Secure access management

**Severity:** High

**Resource type:** `AWS::ECS::TaskDefinition`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/ecs-task-definition-user-for-host-mode-check.html](https://docs.aws.amazon.com/config/latest/developerguide/ecs-task-definition-user-for-host-mode-check.html)

**Schedule type:** Change triggered

**Parameters:**
+ `SkipInactiveTaskDefinitions`: `true` (not customizable)

This control checks whether an active Amazon ECS task definition with host networking mode has `privileged` or `user` container definitions. The control fails for task definitions that have host network mode and container definitions of `privileged=false`, empty and `user=root`, or empty.

This control only evaluates the latest active revision of an Amazon ECS task definition.

The purpose of this control is to ensure that access is defined intentionally when you run tasks that use the host network mode. If a task definition has elevated privileges, it is because you have chosen that configuration. This control checks for unexpected privilege escalation when a task definition has host networking enabled, and you don't choose elevated privileges.

### Remediation
<a name="ecs-1-remediation"></a>

For information about how to update a task definition, see [Updating a task definition](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/update-task-definition.html) in the *Amazon Elastic Container Service Developer Guide*.

When you update a task definition, it doesn't update running tasks that were launched from the previous task definition. To update a running task, you must redeploy the task with the new task definition.

## [ECS.2] ECS services should not have public IP addresses assigned to them automatically
<a name="ecs-2"></a>

**Related requirements:** NIST.800-53.r5 AC-21, NIST.800-53.r5 AC-3, NIST.800-53.r5 AC-3(7), NIST.800-53.r5 AC-4, NIST.800-53.r5 AC-4(21), NIST.800-53.r5 AC-6, NIST.800-53.r5 SC-7, NIST.800-53.r5 SC-7(11), NIST.800-53.r5 SC-7(16), NIST.800-53.r5 SC-7(20), NIST.800-53.r5 SC-7(21), NIST.800-53.r5 SC-7(3), NIST.800-53.r5 SC-7(4), NIST.800-53.r5 SC-7(9), PCI DSS v4.0.1/1.4.4

**Category:** Protect > Secure network configuration > Resources not publicly accessible

**Severity:** High

**Resource type:** `AWS::ECS::Service`

**AWS Config rule:** `ecs-service-assign-public-ip-disabled` (custom Security Hub CSPM rule)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether Amazon ECS services are configured to automatically assign public IP addresses. This control fails if `AssignPublicIP` is `ENABLED`. This control passes if `AssignPublicIP` is `DISABLED`.

A public IP address is an IP address that is reachable from the internet. If you launch your Amazon ECS instances with a public IP address, then your Amazon ECS instances are reachable from the internet. Amazon ECS services should not be publicly accessible, as this may allow unintended access to your container application servers.

### Remediation
<a name="ecs-2-remediation"></a>

First, you must create a task definition for your cluster that uses the `awsvpc` network mode and specifies **FARGATE** for `requiresCompatibilities`. Then, for **Compute configuration**, choose **Launch type** and **FARGATE**. Finally, for the **Networking** field, turn off **Public IP** to disable automatic public IP assignment for your service.

## [ECS.3] ECS task definitions should not share the host's process namespace
<a name="ecs-3"></a>

**Related requirements:** NIST.800-53.r5 CA-9(1), NIST.800-53.r5 CM-2

**Category:** Identify > Resource configuration

**Severity:** High

**Resource type:** `AWS::ECS::TaskDefinition`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/ecs-task-definition-pid-mode-check.html](https://docs.aws.amazon.com/config/latest/developerguide/ecs-task-definition-pid-mode-check.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks if Amazon ECS task definitions are configured to share a host's process namespace with its containers. The control fails if the task definition shares the host's process namespace with the containers running on it. This control only evaluates the latest active revision of an Amazon ECS task definition.

A process ID (PID) namespace provides separation between processes. It prevents system processes from being visible, and allows PIDs to be reused, including PID 1. If the host's PID namespace is shared with containers, it would allow containers to see all of the processes on the host system. This reduces the benefit of process level isolation between the host and the containers. These circumstances could lead to unauthorized access to processes on the host itself, including the ability to manipulate and terminate them. Customers shouldn't share the host's process namespace with containers running on it.

### Remediation
<a name="ecs-3-remediation"></a>

To configure the `pidMode` on a task definition, see [Task definition parameters](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html#task_definition_pidmode) in the Amazon Elastic Container Service Developer Guide.

## [ECS.4] ECS containers should run as non-privileged
<a name="ecs-4"></a>

**Related requirements:** NIST.800-53.r5 AC-2(1), NIST.800-53.r5 AC-3, NIST.800-53.r5 AC-3(15), NIST.800-53.r5 AC-3(7), NIST.800-53.r5 AC-5, NIST.800-53.r5 AC-6

**Category:** Protect > Secure access management > Root user access restrictions

**Severity:** High

**Resource type:** `AWS::ECS::TaskDefinition`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/ecs-containers-nonprivileged.html](https://docs.aws.amazon.com/config/latest/developerguide/ecs-containers-nonprivileged.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks if the `privileged` parameter in the container definition of Amazon ECS Task Definitions is set to `true`. The control fails if this parameter is equal to `true`. This control only evaluates the latest active revision of an Amazon ECS task definition.

We recommend that you remove elevated privileges from your ECS task definitions. When the privilege parameter is `true`, the container is given elevated privileges on the host container instance (similar to the root user).

### Remediation
<a name="ecs-4-remediation"></a>

To configure the `privileged` parameter on a task definition, see [Advanced container definition parameters](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html#container_definition_security) in the Amazon Elastic Container Service Developer Guide.

## [ECS.5] ECS task definitions should configure containers to be limited to read-only access to root filesystems
<a name="ecs-5"></a>

**Related requirements:** NIST.800-53.r5 AC-2(1), NIST.800-53.r5 AC-3, NIST.800-53.r5 AC-3(15), NIST.800-53.r5 AC-3(7), NIST.800-53.r5 AC-5, NIST.800-53.r5 AC-6

**Category:** Protect > Secure access management

**Severity:** High

**Resource type:** `AWS::ECS::TaskDefinition`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/ecs-containers-readonly-access.html](https://docs.aws.amazon.com/config/latest/developerguide/ecs-containers-readonly-access.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether ECS task definitions configure containers to be limited to read-only access to mounted root file systems. The control fails if the `readonlyRootFilesystem` parameter in the container definitions of ECS task definition is set to `false`, or the parameter doesn't exist in the container definition within the task definition. This control evaluates only the latest active revision of an Amazon ECS task definition.

If the `readonlyRootFilesystem` parameter is set to `true` in an Amazon ECS task definition, the ECS container is given read-only access to its root file system. This reduces security attack vectors because the container instance's root file system can't be tampered with or written to without explicit volume mounts that have read-write permissions for file system folders and directories. Enabling this option also adheres to the principle of least privilege.

**Note**  
The `readonlyRootFilesystem` parameter is not supported for Windows containers. Task definitions with `runtimePlatform` configured to specify a `WINDOWS_SERVER` OS family are marked as `NOT_APPLICABLE` and will not generate findings for this control. 

### Remediation
<a name="ecs-5-remediation"></a>

To give an Amazon ECS container read-only access to its root file system, add the `readonlyRootFilesystem` parameter to the task definition for the container, and set the value for the parameter to `true`. For information about task definition parameters and how to add them to a task definition, see [Amazon ECS task definitions](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definitions.html) and [Updating a task definition](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/update-task-definition-console-v2.html) in the *Amazon Elastic Container Service Developer Guide*.

## [ECS.8] Secrets should not be passed as container environment variables
<a name="ecs-8"></a>

**Related requirements:** NIST.800-53.r5 CA-9(1), NIST.800-53.r5 CM-2, PCI DSS v4.0.1/8.6.2

**Category:** Protect > Secure development > Credentials not hard-coded

**Severity:** High

**Resource type:** `AWS::ECS::TaskDefinition`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/ecs-no-environment-secrets.html](https://docs.aws.amazon.com/config/latest/developerguide/ecs-no-environment-secrets.html) 

**Schedule type:** Change triggered

**Parameters:** `secretKeys`: `AWS_ACCESS_KEY_ID`,`AWS_SECRET_ACCESS_KEY`,`ECS_ENGINE_AUTH_DATA` (not customizable) 

This control checks if the key value of any variables in the `environment` parameter of container definitions includes `AWS_ACCESS_KEY_ID`, `AWS_SECRET_ACCESS_KEY`, or `ECS_ENGINE_AUTH_DATA`. This control fails if a single environment variable in any container definition equals `AWS_ACCESS_KEY_ID`, `AWS_SECRET_ACCESS_KEY`, or `ECS_ENGINE_AUTH_DATA`. This control does not cover environmental variables passed in from other locations such as Amazon S3. This control only evaluates the latest active revision of an Amazon ECS task definition.

AWS Systems Manager Parameter Store can help you improve the security posture of your organization. We recommend using the Parameter Store to store secrets and credentials instead of directly passing them into your container instances or hard coding them into your code.

### Remediation
<a name="ecs-8-remediation"></a>

To create parameters using SSM, see [Creating Systems Manager parameters](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-paramstore-su-create.html) in the *AWS Systems Manager User Guide*. For more information about creating a task definition that specifies a secret, see [Specifying sensitive data using Secrets Manager](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/specifying-sensitive-data-secrets.html#secrets-create-taskdefinition) in the *Amazon Elastic Container Service Developer Guide*.

## [ECS.9] ECS task definitions should have a logging configuration
<a name="ecs-9"></a>

**Related requirements:** NIST.800-53.r5 AC-4(26), NIST.800-53.r5 AU-10, NIST.800-53.r5 AU-12, NIST.800-53.r5 AU-2, NIST.800-53.r5 AU-3, NIST.800-53.r5 AU-6(3), NIST.800-53.r5 AU-6(4), NIST.800-53.r5 CA-7, NIST.800-53.r5 SC-7(9), NIST.800-53.r5 SI-7(8)

**Category:** Identify > Logging

**Severity:** High

**Resource type:** `AWS::ECS::TaskDefinition`

**AWS Config rule:** [ecs-task-definition-log-configuration](https://docs.aws.amazon.com/config/latest/developerguide/ecs-task-definition-log-configuration.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks if the latest active Amazon ECS task definition has a logging configuration specified. The control fails if the task definition doesn't have the `logConfiguration` property defined or if the value for `logDriver` is null in at least one container definition.

Logging helps you maintain the reliability, availability, and performance of Amazon ECS. Collecting data from task definitions provides visibility, which can help you debug processes and find the root cause of errors. If you are using a logging solution that does not have to be defined in the ECS task definition (such as a third party logging solution), you can disable this control after ensuring that your logs are properly captured and delivered.

### Remediation
<a name="ecs-9-remediation"></a>

To define a log configuration for your Amazon ECS task definitions, see [Specifying a log configuration in your task definition](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using_awslogs.html#specify-log-config) in the *Amazon Elastic Container Service Developer Guide*.

## [ECS.10] ECS Fargate services should run on the latest Fargate platform version
<a name="ecs-10"></a>

**Related requirements:** NIST.800-53.r5 SI-2, NIST.800-53.r5 SI-2(2), NIST.800-53.r5 SI-2(4), NIST.800-53.r5 SI-2(5), PCI DSS v4.0.1/6.3.3

**Category:** Identify > Vulnerability, patch, and version management

**Severity:** Medium

**Resource type:** `AWS::ECS::Service`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/ecs-fargate-latest-platform-version.html](https://docs.aws.amazon.com/config/latest/developerguide/ecs-fargate-latest-platform-version.html)

**Schedule type:** Change triggered

**Parameters:**
+ `latestLinuxVersion: 1.4.0` (not customizable)
+ `latestWindowsVersion: 1.0.0` (not customizable)

This control checks if Amazon ECS Fargate services are running the latest Fargate platform version. This control fails if the platform version is not the latest.

AWS Fargate platform versions refer to a specific runtime environment for Fargate task infrastructure, which is a combination of kernel and container runtime versions. New platform versions are released as the runtime environment evolves. For example, a new version may be released for kernel or operating system updates, new features, bug fixes, or security updates. Security updates and patches are deployed automatically for your Fargate tasks. If a security issue is found that affects a platform version, AWS patches the platform version. 

### Remediation
<a name="ecs-10-remediation"></a>

To update an existing service, including its platform version, see [Updating a service](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/update-service.html) in the *Amazon Elastic Container Service Developer Guide*.

## [ECS.12] ECS clusters should use Container Insights
<a name="ecs-12"></a>

**Related requirements:** NIST.800-53.r5 AU-6(3), NIST.800-53.r5 AU-6(4), NIST.800-53.r5 CA-7, NIST.800-53.r5 SI-2

**Category:** Identify > Logging

**Severity:** Medium

**Resource type:** `AWS::ECS::Cluster`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/ecs-container-insights-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/ecs-container-insights-enabled.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks if ECS clusters use Container Insights. This control fails if Container Insights are not set up for a cluster.

Monitoring is an important part of maintaining the reliability, availability, and performance of Amazon ECS clusters. Use CloudWatch Container Insights to collect, aggregate, and summarize metrics and logs from your containerized applications and microservices. CloudWatch automatically collects metrics for many resources, such as CPU, memory, disk, and network. Container Insights also provides diagnostic information, such as container restart failures, to help you isolate issues and resolve them quickly. You can also set CloudWatch alarms on metrics that Container Insights collects.

### Remediation
<a name="ecs-12-remediation"></a>

To use Container Insights, see [Updating a service](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/deploy-container-insights-ECS.html) in the *Amazon CloudWatch User Guide*.

## [ECS.13] ECS services should be tagged
<a name="ecs-13"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::ECS::Service`

**AWS Config rule:** `tagged-ecs-service` (custom Security Hub CSPM rule)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  | No default value  | 

This control checks whether an Amazon ECS service has tags with the specific keys defined in the parameter `requiredTagKeys`. The control fails if the service doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredTagKeys`. If the parameter `requiredTagKeys` isn't provided, the control only checks for the existence of a tag key and fails if the service isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [What is ABAC for AWS?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Tagging your AWS resources](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *AWS General Reference*.

### Remediation
<a name="ecs-13-remediation"></a>

To add tags to an ECS service, see [Tagging your Amazon ECS resources](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-using-tags.html) in the *Amazon Elastic Container Service Developer Guide*.

## [ECS.14] ECS clusters should be tagged
<a name="ecs-14"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::ECS::Cluster`

**AWS Config rule:** `tagged-ecs-cluster` (custom Security Hub CSPM rule)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  | No default value  | 

This control checks whether an Amazon ECS cluster has tags with the specific keys defined in the parameter `requiredTagKeys`. The control fails if the cluster doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredTagKeys`. If the parameter `requiredTagKeys` isn't provided, the control only checks for the existence of a tag key and fails if the cluster isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [What is ABAC for AWS?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Tagging your AWS resources](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *AWS General Reference*.

### Remediation
<a name="ecs-14-remediation"></a>

To add tags to an ECS cluster, see [Tagging your Amazon ECS resources](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-using-tags.html) in the *Amazon Elastic Container Service Developer Guide*.

## [ECS.15] ECS task definitions should be tagged
<a name="ecs-15"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::ECS::TaskDefinition`

**AWS Config rule:** `tagged-ecs-taskdefinition` (custom Security Hub CSPM rule)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  | No default value  | 

This control checks whether an Amazon ECS task definition has tags with the specific keys defined in the parameter `requiredTagKeys`. The control fails if the task definition doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredTagKeys`. If the parameter `requiredTagKeys` isn't provided, the control only checks for the existence of a tag key and fails if the task definition isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [What is ABAC for AWS?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Tagging your AWS resources](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *AWS General Reference*.

### Remediation
<a name="ecs-15-remediation"></a>

To add tags to an ECS task definition, see [Tagging your Amazon ECS resources](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-using-tags.html) in the *Amazon Elastic Container Service Developer Guide*.

## [ECS.16] ECS task sets should not automatically assign public IP addresses
<a name="ecs-16"></a>

**Related requirements:** PCI DSS v4.0.1/1.4.4

**Category:** Protect > Secure network configuration > Resources not publicly accessible

**Severity:** High

**Resource type:** `AWS::ECS::TaskSet`

**AWS Config rule:** `ecs-taskset-assign-public-ip-disabled` (custom Security Hub CSPM rule)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether an Amazon ECS task set is configured to automatically assign public IP addresses. The control fails if `AssignPublicIP` is set to `ENABLED`.

A public IP address is reachable from the internet. If you configure your task set with a public IP address, the resources associated with the task set can be reached from the internet. ECS task sets shouldn't be publicly accessible, as this may allow unintended access to your container application servers.

### Remediation
<a name="ecs-16-remediation"></a>

To update an ECS task set so that it doesn't use a public IP address, see [Updating an Amazon ECS task definition using the console](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/update-task-definition-console-v2.html) in the *Amazon Elastic Container Service Developer Guide*.

## [ECS.17] ECS task definitions should not use host network mode
<a name="ecs-17"></a>

**Related requirements:** NIST.800-53.r5 AC-2(1), NIST.800-53.r5 AC-3, NIST.800-53.r5 AC-3(7), NIST.800-53.r5 AC-3(15), NIST.800-53.r5 AC-5, NIST.800-53.r5 AC-6

**Category:** Protect > Secure network configuration

**Severity:** Medium

**Resource type:** `AWS::ECS::TaskDefinition`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/ecs-task-definition-network-mode-not-host.html](https://docs.aws.amazon.com/config/latest/developerguide/ecs-task-definition-network-mode-not-host.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether the latest active revision of an Amazon ECS task definition uses `host` network mode. The control fails if the latest active revision of the ECS task definition uses `host` network mode.

When using `host` network mode, the networking of an Amazon ECS container is tied directly to the underlying host that's running the container. Consequently, this mode allows containers to connect to private loopback network services on the host and to impersonate the host. Other significant drawbacks are that there's no way to remap a container port when using `host` network mode, and you can't run more than a single instantiation of a task on each host.

### Remediation
<a name="ecs-17-remediation"></a>

For information about networking modes and options for Amazon ECS tasks that are hosted on Amazon EC2 instances, see [Amazon ECS task networking options for the EC2 launch type](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-networking.html) in the *Amazon Elastic Container Service Developer Guide*. For information about creating a new revision of a task definition and specifying a different network mode, see [Updating an Amazon ECS task definition](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/update-task-definition-console-v2.html) in that guide.

If the Amazon ECS task definition was created by AWS Batch, see [Networking modes for AWS Batch jobs](https://docs.aws.amazon.com/batch/latest/userguide/networking-modes-jobs.html) to learn about networking modes and typical usage for AWS Batch job types and to choose a secure option.

## [ECS.18] ECS Task Definitions should use in-transit encryption for EFS volumes
<a name="ecs-18"></a>

**Category:** Protect > Encryption of data-in-transit

**Severity:** Medium

**Resource type:** `AWS::ECS::TaskDefinition`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/ecs-task-definition-efs-encryption-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/ecs-task-definition-efs-encryption-enabled.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether the latest active revision of an Amazon ECS task definition uses in-transit encryption for EFS volumes. The control fails if the latest active revision of the ECS task definition has in-transit encryption disabled for EFS volumes.

Amazon EFS volumes provide simple, scalable, and persistent shared file storage for use with your Amazon ECS tasks. Amazon EFS supports encryption of data in transit with Transport Layer Security (TLS). When encryption of data in transit is declared as a mount option for your EFS file system, Amazon EFS establishes a secure TLS connection with your EFS file system upon mounting your file system.

### Remediation
<a name="ecs-18-remediation"></a>

For information about enabling in-transit encryption for Amazon ECS Task Definition with EFS volumes, see [Step 5: Create a task definition](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/tutorial-efs-volumes.html#efs-task-def) in the *Amazon Elastic Container Service Developer Guide*.

## [ECS.19] ECS capacity providers should have managed termination protection enabled
<a name="ecs-19"></a>

**Category:** Protect > Data Protection

**Severity:** Medium

**Resource type:** `AWS::ECS::CapacityProvider`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/ecs-capacity-provider-termination-check.html](https://docs.aws.amazon.com/config/latest/developerguide/ecs-capacity-provider-termination-check.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether an Amazon ECS capacity provider has managed termination protection enabled. The control fails if managed termination protection is not enabled on an ECS capacity provider.

Amazon ECS capacity providers manage the scaling of infrastructure for tasks in your clusters. When you use EC2 instances for your capacity, you use Auto Scaling group to manage the EC2 instances. Managed termination protection allows cluster auto scaling to control which instances are terminated. When you used managed termination protection, Amazon ECS only terminates EC2 instances that don't have any running Amazon ECS tasks.

**Note**  
When using managed termination protection, managed scaling must also be used otherwise managed termination protection doesn't work.

### Remediation
<a name="ecs-19-remediation"></a>

To enable managed termination protection for an Amazon ECS capacity provider, see [Updating managed termination protection for Amazon ECS capacity providers](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/update-managed-termination-protection.html) in the *Amazon Elastic Container Service Developer Guide*.

## [ECS.20] ECS Task Definitions should configure non-root users in Linux container definitions
<a name="ecs-20"></a>

**Category:** Protect > Secure access management > Root user access restrictions

**Severity:** Medium

**Resource type:** `AWS::ECS::TaskDefinition`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/ecs-task-definition-linux-user-non-root.html](https://docs.aws.amazon.com/config/latest/developerguide/ecs-task-definition-linux-user-non-root.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether the latest active revision of an Amazon ECS task definition configures Linux containers to run as non-root users. The control fails if a default root user is configured or user configuration is absent for any container.

When Linux containers run with root privileges, they pose several significant security risks. Root users have unrestricted access within the container. This elevated access increases the risk of container escape attacks, where an attacker could potentially break out of container isolation and access the underlying host system. If a container running as root is compromised, attackers may exploit this to access or modify host system resources, affecting other containers or the host itself. Furthermore, root access could enable privilege escalation attacks, allowing attackers to gain additional permissions beyond the container's intended scope. The user parameter in ECS task definitions can specify users in several formats, including username, user ID, username with group, or UID with group ID. It's important to be aware of these various formats when configuring task definitions to ensure no root access is inadvertently granted. Following the principle of least privilege, containers should run with the minimum required permissions using non-root users. This approach significantly reduces the potential attack surface and mitigates the impact of potential security breaches. 

**Note**  
This control only evaluates the container definitions in a task definition if the `operatingSystemFamily` is configured as `LINUX` or `operatingSystemFamily` is not configured in the task definition. The control will generate a `FAILED` finding for an evaluated task definition if any container definition in the task definition has `user` not configured or `user` configured as default root user. The default root users for `LINUX` containers are `"root"` and `"0"`.

### Remediation
<a name="ecs-20-remediation"></a>

For information about creating a new revision of an Amazon ECS Task Definition and updating the `user` parameter in the container definition, see [Updating an Amazon ECS task defintion](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/update-task-definition-console-v2.html) in the *Amazon Elastic Container Service Developer Guide*.

## [ECS.21] ECS Task Definitions should configure non-administrator users in Windows container definitions
<a name="ecs-21"></a>

**Category:** Protect > Secure access management > Root user access restrictions

**Severity:** Medium

**Resource type:** `AWS::ECS::TaskDefinition`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/ecs-task-definition-windows-user-non-admin.html](https://docs.aws.amazon.com/config/latest/developerguide/ecs-task-definition-windows-user-non-admin.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether the latest active revision of an Amazon ECS task definition configures Windows containers to run as users that are not default administrators. The control fails if a default administrator is configured as user or user configuration is absent for any container.

When Windows containers run with administrator privileges, they pose several significant security risks. Administrators have unrestricted access within the container. This elevated access increases the risk of container escape attacks, where an attacker could potentially break out of container isolation and access the underlying host system.

**Note**  
This control only evaluates the container definitions in a task definition if the `operatingSystemFamily` is configured as `WINDOWS_SERVER` or `operatingSystemFamily` is not configured in the task definition. The control will generate a `FAILED` finding for an evaluated task definition if any container definition in the task definition has `user` not configured or `user` configured as default administrator for `WINDOWS_SERVER` containers which is `"containeradministrator"`.

### Remediation
<a name="ecs-21-remediation"></a>

For information about creating a new revision of an Amazon ECS Task Definition and updating the `user` parameter in the container definition, see [Updating an Amazon ECS task defintion](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/update-task-definition-console-v2.html) in the *Amazon Elastic Container Service Developer Guide*.

# Security Hub CSPM controls for Amazon EFS
<a name="efs-controls"></a>

These Security Hub CSPM controls evaluate the Amazon Elastic File System (Amazon EFS) service and resources. The controls might not be available in all AWS Regions. For more information, see [Availability of controls by Region](securityhub-regions.md#securityhub-regions-control-support).

## [EFS.1] Elastic File System should be configured to encrypt file data at-rest using AWS KMS
<a name="efs-1"></a>

**Related requirements:** CIS AWS Foundations Benchmark v5.0.0/2.3.1, CIS AWS Foundations Benchmark v3.0.0/2.4.1, NIST.800-53.r5 CA-9(1), NIST.800-53.r5 CM-3(6), NIST.800-53.r5 SC-13, NIST.800-53.r5 SC-28, NIST.800-53.r5 SC-28(1), NIST.800-53.r5 SC-7(10), NIST.800-53.r5 SI-7(6)

**Category:** Protect > Data Protection > Encryption of data-at-rest

**Severity:** Medium

**Resource type:** `AWS::EFS::FileSystem`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/efs-encrypted-check.html](https://docs.aws.amazon.com/config/latest/developerguide/efs-encrypted-check.html)

**Schedule type:** Periodic

**Parameters:** None

This control checks whether Amazon Elastic File System is configured to encrypt the file data using AWS KMS. The check fails in the following cases.
+ `Encrypted` is set to `false` in the [https://docs.aws.amazon.com/efs/latest/ug/API_DescribeFileSystems.html](https://docs.aws.amazon.com/efs/latest/ug/API_DescribeFileSystems.html) response.
+ The `KmsKeyId` key in the [https://docs.aws.amazon.com/efs/latest/ug/API_DescribeFileSystems.html](https://docs.aws.amazon.com/efs/latest/ug/API_DescribeFileSystems.html) response does not match the `KmsKeyId` parameter for [https://docs.aws.amazon.com/config/latest/developerguide/efs-encrypted-check.html](https://docs.aws.amazon.com/config/latest/developerguide/efs-encrypted-check.html).

Note that this control does not use the `KmsKeyId` parameter for [https://docs.aws.amazon.com/config/latest/developerguide/efs-encrypted-check.html](https://docs.aws.amazon.com/config/latest/developerguide/efs-encrypted-check.html). It only checks the value of `Encrypted`.

For an added layer of security for your sensitive data in Amazon EFS, you should create encrypted file systems. Amazon EFS supports encryption for file systems at-rest. You can enable encryption of data at rest when you create an Amazon EFS file system. To learn more about Amazon EFS encryption, see[ Data encryption in Amazon EFS](https://docs.aws.amazon.com/efs/latest/ug/encryption.html) in the *Amazon Elastic File System User Guide*.

### Remediation
<a name="efs-1-remediation"></a>

For details on how to encrypt a new Amazon EFS file system, see [Encrypting data at rest](https://docs.aws.amazon.com/efs/latest/ug/encryption-at-rest.html) in the *Amazon Elastic File System User Guide*.

## [EFS.2] Amazon EFS volumes should be in backup plans
<a name="efs-2"></a>

**Related requirements:** NIST.800-53.r5 CP-10, NIST.800-53.r5 CP-6, NIST.800-53.r5 CP-6(1), NIST.800-53.r5 CP-6(2), NIST.800-53.r5 CP-9, NIST.800-53.r5 SC-5(2), NIST.800-53.r5 SI-12, NIST.800-53.r5 SI-13(5)

**Category:** Recover > Resilience > Backup

**Severity:** Medium

**Resource type:** `AWS::EFS::FileSystem`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/efs-in-backup-plan.html](https://docs.aws.amazon.com/config/latest/developerguide/efs-in-backup-plan.html)

**Schedule type:** Periodic

**Parameters:** None

This control checks whether Amazon Elastic File System (Amazon EFS) file systems are added to the backup plans in AWS Backup. The control fails if Amazon EFS file systems are not included in the backup plans. 

Including EFS file systems in the backup plans helps you to protect your data from deletion and data loss.

### Remediation
<a name="efs-2-remediation"></a>

To enable automatic backups for an existing Amazon EFS file system, see [Getting started 4: Create Amazon EFS automatic backups](https://docs.aws.amazon.com/aws-backup/latest/devguide/create-auto-backup.html) in the *AWS Backup Developer Guide*.

## [EFS.3] EFS access points should enforce a root directory
<a name="efs-3"></a>

**Related requirements:** NIST.800-53.r5 AC-6(10)

**Category:** Protect > Secure access management

**Severity:** Medium

**Resource type:** `AWS::EFS::AccessPoint`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/efs-access-point-enforce-root-directory.html](https://docs.aws.amazon.com/config/latest/developerguide/efs-access-point-enforce-root-directory.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks if Amazon EFS access points are configured to enforce a root directory. The control fails if the value of `Path` is set to `/` (the default root directory of the file system).

When you enforce a root directory, the NFS client using the access point uses the root directory configured on the access point instead of the file system's root directory. Enforcing a root directory for an access point helps restrict data access by ensuring that users of the access point can only reach files of the specified subdirectory.

### Remediation
<a name="efs-3-remediation"></a>

For instructions on how to enforce a root directory for an Amazon EFS access point, see [Enforcing a root directory with an access point](https://docs.aws.amazon.com/efs/latest/ug/efs-access-points.html#enforce-root-directory-access-point) in the *Amazon Elastic File System User Guide*. 

## [EFS.4] EFS access points should enforce a user identity
<a name="efs-4"></a>

**Related requirements:** NIST.800-53.r5 AC-6(2), PCI DSS v4.0.1/7.3.1

**Category:** Protect > Secure access management

**Severity:** Medium

**Resource type:** `AWS::EFS::AccessPoint`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/efs-access-point-enforce-user-identity.html](https://docs.aws.amazon.com/config/latest/developerguide/efs-access-point-enforce-user-identity.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether Amazon EFS access points are configured to enforce a user identity. This control fails if a POSIX user identity is not defined while creating the EFS access point.

Amazon EFS access points are application-specific entry points into an EFS file system that make it easier to manage application access to shared datasets. Access points can enforce a user identity, including the user's POSIX groups, for all file system requests that are made through the access point. Access points can also enforce a different root directory for the file system so that clients can only access data in the specified directory or its subdirectories.

### Remediation
<a name="efs-4-remediation"></a>

To enforce a user identity for an Amazon EFS access point, see [Enforcing a user identity using an access point](https://docs.aws.amazon.com/efs/latest/ug/efs-access-points.html#enforce-identity-access-points) in the *Amazon Elastic File System User Guide*. 

## [EFS.5] EFS access points should be tagged
<a name="efs-5"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::EFS::AccessPoint`

**AWS Configrule:** `tagged-efs-accesspoint` (custom Security Hub CSPM rule)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  | No default value  | 

This control checks whether an Amazon EFS access point has tags with the specific keys defined in the parameter `requiredTagKeys`. The control fails if the access point doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredTagKeys`. If the parameter `requiredTagKeys` isn't provided, the control only checks for the existence of a tag key and fails if the access point isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [What is ABAC for AWS?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Tagging your AWS resources](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *AWS General Reference*.

### Remediation
<a name="efs-5-remediation"></a>

To add tags to an EFS access point, see [Tagging Amazon EFS resources](https://docs.aws.amazon.com/efs/latest/ug/manage-fs-tags.html) in the *Amazon Elastic File System User Guide*.

## [EFS.6] EFS mount targets should not be associated with subnets that assign public IP addresses on launch
<a name="efs-6"></a>

**Category:** Protect > Network security > Resources not publicly accessible

**Severity:** Medium

**Resource type:** `AWS::EFS::FileSystem`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/efs-mount-target-public-accessible.html](https://docs.aws.amazon.com/config/latest/developerguide/efs-mount-target-public-accessible.html)

**Schedule type:** Periodic

**Parameters:** None

This control checks whether an Amazon EFS mount target is associated with subnets that assign public IP addresses on launch. The control fails if the mount target is associated with subnets that assign public IP addresses on launch.

Subnets have attributes that determine whether network interfaces automatically receive public IPv4 and IPv6 addresses. For IPv4, this attribute is set to `TRUE` for default subnets and `FALSE` for nondefault subnets (with an exception for nondefault subnets created through the EC2 launch instance wizard, where it's set to `TRUE`). For IPv6, this attribute is set to `FALSE` for all subnets by default. When these attributes are enabled, instances launched in the subnet automatically receive the corresponding IP addresses (IPv4 or IPv6) on their primary network interface. Amazon EFS mount targets that are launched into subnets that have this attribute enabled have a public IP address assigned to their primary network interface.

### Remediation
<a name="efs-6-remediation"></a>

To associate an existing mount target with a different subnet, you must create a new mount target in a subnet that does not assign public IP addresses on launch and then remove the old mount target. For information about managing mount targets, see [Creating and managing mount targets and security groups](https://docs.aws.amazon.com/efs/latest/ug/accessing-fs.html) in the *Amazon Elastic File System User Guide*. 

## [EFS.7] EFS file systems should have automatic backups enabled
<a name="efs-7"></a>

**Category:** Recover > Resilience > Backups enabled

**Severity:** Medium

**Resource type:** `AWS::EFS::FileSystem`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/efs-automatic-backups-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/efs-automatic-backups-enabled.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether an Amazon EFS file system has automatic backups enabled. This control fails if the EFS file system doesn't have automatic backups enabled.

A data backup is a copy of your system, configuration, or application data that's stored separately from the original. Enabling regular backups helps you safeguard valuable data against unforeseen events like system failures, cyberattacks, or accidental deletions. Having a robust backup strategy also facilitates quicker recovery, business continuity, and peace of mind in the face of potential data loss.

### Remediation
<a name="efs-7-remediation"></a>

For information about using AWS Backup for EFS file systems, see [Backing up EFS file systems](https://docs.aws.amazon.com/efs/latest/ug/awsbackup.html) in the *Amazon Elastic File System User Guide*.

## [EFS.8] EFS file systems should be encrypted at rest
<a name="efs-8"></a>

**Related requirements:** CIS AWS Foundations Benchmark v5.0.0/2.3.1

**Category:** Protect > Data Protection > Encryption of data-at-rest

**Severity:** Medium

**Resource type:** `AWS::EFS::FileSystem`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/efs-filesystem-ct-encrypted.html](https://docs.aws.amazon.com/config/latest/developerguide/efs-filesystem-ct-encrypted.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether an Amazon EFS file system encrypts data with AWS Key Management Service (AWS KMS). The control fails if a file system isn't encrypted.

Data at rest refers to data that's stored in persistent, non-volatile storage for any duration. Encrypting data at rest helps you protect its confidentiality, which reduces the risk that an unauthorized user can access it.

### Remediation
<a name="efs-8-remediation"></a>

To enable encryption at rest for a new EFS file system, see [Encrypting data at rest](https://docs.aws.amazon.com/efs/latest/ug/encryption-at-rest.html) in the *Amazon Elastic File System User Guide*.

# Security Hub CSPM controls for Amazon EKS
<a name="eks-controls"></a>

These Security Hub CSPM controls evaluate the Amazon Elastic Kubernetes Service (Amazon EKS) service and resources. The controls might not be available in all AWS Regions. For more information, see [Availability of controls by Region](securityhub-regions.md#securityhub-regions-control-support).

## [EKS.1] EKS cluster endpoints should not be publicly accessible
<a name="eks-1"></a>

**Related requirements:** NIST.800-53.r5 AC-21, NIST.800-53.r5 AC-3, NIST.800-53.r5 AC-3(7), NIST.800-53.r5 AC-4, NIST.800-53.r5 AC-4(21), NIST.800-53.r5 AC-6, NIST.800-53.r5 SC-7, NIST.800-53.r5 SC-7(11), NIST.800-53.r5 SC-7(16), NIST.800-53.r5 SC-7(20), NIST.800-53.r5 SC-7(21), NIST.800-53.r5 SC-7(3), NIST.800-53.r5 SC-7(4), NIST.800-53.r5 SC-7(9), PCI DSS v4.0.1/1.4.4

**Category:** Protect > Secure network configuration > Resources not publicly accessible

**Severity:** High

**Resource type:** `AWS::EKS::Cluster`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/eks-endpoint-no-public-access.html](https://docs.aws.amazon.com/config/latest/developerguide/eks-endpoint-no-public-access.html)

**Schedule type:** Periodic

**Parameters:** None

This control checks whether an Amazon EKS cluster endpoint is publicly accessible. The control fails if an EKS cluster has an endpoint that is publicly accessible.

When you create a new cluster, Amazon EKS creates an endpoint for the managed Kubernetes API server that you use to communicate with your cluster. By default, this API server endpoint is publicly available to the internet. Access to the API server is secured using a combination of AWS Identity and Access Management (IAM) and native Kubernetes Role Based Access Control (RBAC). By removing public access to the endpoint, you can avoid unintentional exposure and access to your cluster.

### Remediation
<a name="eks-1-remediation"></a>

To modify endpoint access for an existing EKS cluster, see [Modifying cluster endpoint access](https://docs.aws.amazon.com/eks/latest/userguide/cluster-endpoint.html#modify-endpoint-access) in the **Amazon EKS User Guide**. You can set up endpoint access for a new EKS cluster when creating it. For instructions on creating a new Amazon EKS cluster, see [Creating an Amazon EKS cluster](https://docs.aws.amazon.com/eks/latest/userguide/create-cluster.html) in the **Amazon EKS User Guide**. 

## [EKS.2] EKS clusters should run on a supported Kubernetes version
<a name="eks-2"></a>

**Related requirements:** NIST.800-53.r5 CA-9(1), NIST.800-53.r5 CM-2, NIST.800-53.r5 SI-2, NIST.800-53.r5 SI-2(2), NIST.800-53.r5 SI-2(4), NIST.800-53.r5 SI-2(5), PCI DSS v4.0.1/12.3.4

**Category:** Identify > Vulnerability, patch, and version management

**Severity:** High

**Resource type:** `AWS::EKS::Cluster`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/eks-cluster-supported-version.html](https://docs.aws.amazon.com/config/latest/developerguide/eks-cluster-supported-version.html)

**Schedule type:** Change triggered

**Parameters:**
+ `oldestVersionSupported`: `1.33` (not customizable)

This control checks whether an Amazon Elastic Kubernetes Service (Amazon EKS) cluster runs on a supported Kubernetes version. The control fails if the EKS cluster runs on an unsupported version.

If your application doesn't require a specific version of Kubernetes, we recommend that you use the latest available Kubernetes version that's supported by EKS for your clusters. For more information, see [Amazon EKS Kubernetes release calendar](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html#kubernetes-release-calendar) and [Understand the Kubernetes version lifecycle on Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html#version-deprecation) in the **Amazon EKS User Guide**.

### Remediation
<a name="eks-2-remediation"></a>

To update an EKS cluster, see [Update an existing cluster to a new Kubernetes version](https://docs.aws.amazon.com/eks/latest/userguide/update-cluster.html) in the **Amazon EKS User Guide**. 

## [EKS.3] EKS clusters should use encrypted Kubernetes secrets
<a name="eks-3"></a>

**Related requirements:** NIST.800-53.r5 SC-8, NIST.800-53.r5 SC-12, NIST.800-53.r5 SC-13, NIST.800-53.r5 SC-28, PCI DSS v4.0.1/8.3.2

**Category:** Protect > Data Protection > Encryption of data-at-rest

**Severity:** Medium

**Resource type:** `AWS::EKS::Cluster`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/eks-cluster-secrets-encrypted.html](https://docs.aws.amazon.com/config/latest/developerguide/eks-cluster-secrets-encrypted.html)

**Schedule type:** Periodic

**Parameters:** None

This control checks whether an Amazon EKS cluster uses encrypted Kubernetes secrets. The control fails if the cluster's Kubernetes secrets aren't encrypted.

When you encrypt secrets, you can use AWS Key Management Service (AWS KMS) keys to provide envelope encryption of Kubernetes secrets stored in etcd for your cluster. This encryption is in addition to the EBS volume encryption that is enabled by default for all data (including secrets) that is stored in etcd as part of an EKS cluster. Using secrets encryption for your EKS cluster allows you to deploy a defense in depth strategy for Kubernetes applications by encrypting Kubernetes secrets with a KMS key that you define and manage.

### Remediation
<a name="eks-3-remediation"></a>

To enable secrets encryption on an EKS cluster, see [Enabling secret encryption on an existing cluster](https://docs.aws.amazon.com/eks/latest/userguide/enable-kms.html) in the **Amazon EKS User Guide**. 

## [EKS.6] EKS clusters should be tagged
<a name="eks-6"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::EKS::Cluster`

**AWS Config rule:** `tagged-eks-cluster` (custom Security Hub CSPM rule)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  | No default value  | 

This control checks whether an Amazon EKS cluster has tags with the specific keys defined in the parameter `requiredTagKeys`. The control fails if the cluster doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredTagKeys`. If the parameter `requiredTagKeys` isn't provided, the control only checks for the existence of a tag key and fails if the cluster isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [What is ABAC for AWS?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Tagging your AWS resources](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *AWS General Reference*.

### Remediation
<a name="eks-6-remediation"></a>

To add tags to an EKS cluster, see [Tagging your Amazon EKS resources](https://docs.aws.amazon.com/eks/latest/userguide/eks-using-tags.html) in the **Amazon EKS User Guide**.

## [EKS.7] EKS identity provider configurations should be tagged
<a name="eks-7"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::EKS::IdentityProviderConfig`

**AWS Config rule:** `tagged-eks-identityproviderconfig` (custom Security Hub CSPM rule)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  | No default value  | 

This control checks whether an Amazon EKS identity provider configuration has tags with the specific keys defined in the parameter `requiredTagKeys`. The control fails if the configuration doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredTagKeys`. If the parameter `requiredTagKeys` isn't provided, the control only checks for the existence of a tag key and fails if the configuration isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [What is ABAC for AWS?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Tagging your AWS resources](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *AWS General Reference*.

### Remediation
<a name="eks-7-remediation"></a>

To add tags to an EKS identity provider configurations, see [Tagging your Amazon EKS resources](https://docs.aws.amazon.com/eks/latest/userguide/eks-using-tags.html) in the **Amazon EKS User Guide**.

## [EKS.8] EKS clusters should have audit logging enabled
<a name="eks-8"></a>

**Related requirements:** NIST.800-53.r5 AC-2(12), NIST.800-53.r5 AC-2(4), NIST.800-53.r5 AC-4(26), NIST.800-53.r5 AC-6(9), NIST.800-53.r5 AU-10, NIST.800-53.r5 AU-12, NIST.800-53.r5 AU-2, NIST.800-53.r5 AU-3, NIST.800-53.r5 AU-6(3), NIST.800-53.r5 AU-6(4), NIST.800-53.r5 AU-9(7), NIST.800-53.r5 CA-7, NIST.800-53.r5 SC-7(9), NIST.800-53.r5 SI-3(8), NIST.800-53.r5 SI-4, NIST.800-53.r5 SI-4(20), NIST.800-53.r5 SI-7(8), PCI DSS v4.0.1/10.2.1

**Category:** Identify > Logging

**Severity:** Medium

**Resource type:** `AWS::EKS::Cluster`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/eks-cluster-log-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/eks-cluster-log-enabled.html)

**Schedule type:** Change triggered

**Parameters:**
+ `logTypes: audit` (not customizable)

This control checks whether an Amazon EKS cluster has audit logging enabled. The control fails if audit logging isn't enabled for the cluster.

**Note**  
This control doesn't check whether Amazon EKS audit logging is enabled through Amazon Security Lake for the AWS account.

EKS control plane logging provides audit and diagnostic logs directly from the EKS control plane to Amazon CloudWatch Logs in your account. You can select the log types you need, and logs are sent as log streams to a group for each EKS cluster in CloudWatch. Logging provides visibility into the access and performance of EKS clusters. By sending EKS control plane logs for your EKS clusters to CloudWatch Logs, you can record operations for audit and diagnostic purposes in a central location.

### Remediation
<a name="eks-8-remediation"></a>

To enable audit logs for your EKS cluster, see [Enabling and disabling control plane logs ](https://docs.aws.amazon.com/eks/latest/userguide/control-plane-logs.html#enabling-control-plane-log-export) in the **Amazon EKS User Guide**. 

## [EKS.9] EKS node groups should run on a supported Kubernetes version
<a name="eks-9"></a>

**Category:** Identify > Vulnerability, patch, and version management

**Severity:** High

**Resource type:** `AWS::EKS::Nodegroup`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/eks-nodegroup-supported-version-check.html](https://docs.aws.amazon.com/config/latest/developerguide/eks-nodegroup-supported-version-check.html)

**Schedule type:** Change triggered

**Parameters:**
+ `oldestVersionSupported`: `1.33` (not customizable)

This control checks whether an Amazon EKS node group runs on a supported Kubernetes version. The control fails if the EKS node group runs on an unsupported version.

Running EKS node groups on unsupported Kubernetes versions means those nodes no longer receive security patches, bug fixes, or compatibility updates from AWS. Unsupported versions may contain known vulnerabilities that have been addressed in newer releases, and they may experience compatibility issues with updated AWS services, container images, and third-party tools in the Kubernetes ecosystem. If your application doesn't require a specific version of Kubernetes, we recommend that you use the latest available Kubernetes version that's supported by Amazon EKS for your node groups. For more information, see [Amazon EKS Kubernetes release calendar](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html#kubernetes-release-calendar) and [Understand each phase of node updates](https://docs.aws.amazon.com/eks/latest/userguide/managed-node-update-behavior.html) in the **Amazon EKS User Guide**.

### Remediation
<a name="eks-9-remediation"></a>

To update an EKS node group, see [Update a managed node group for your cluster](https://docs.aws.amazon.com/eks/latest/userguide/update-managed-node-group.html) in the **Amazon EKS User Guide**.

# Security Hub CSPM controls for ElastiCache
<a name="elasticache-controls"></a>

These AWS Security Hub CSPM controls evaluate the Amazon ElastiCache service and resources. The controls might not be available in all AWS Regions. For more information, see [Availability of controls by Region](securityhub-regions.md#securityhub-regions-control-support).

## [ElastiCache.1] ElastiCache (Redis OSS) clusters should have automatic backups enabled
<a name="elasticache-1"></a>

**Related requirements:** NIST.800-53.r5 CP-10, NIST.800-53.r5 CP-6, NIST.800-53.r5 CP-6(1), NIST.800-53.r5 CP-6(2), NIST.800-53.r5 CP-9, NIST.800-53.r5 SC-5(2), NIST.800-53.r5 SI-12, NIST.800-53.r5 SI-13(5)

**Category:** Recover > Resilience > Backups enabled

**Severity:** High

**Resource type:** `AWS::ElastiCache::CacheCluster`, `AWS:ElastiCache:ReplicationGroup`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/elasticache-redis-cluster-automatic-backup-check.html](https://docs.aws.amazon.com/config/latest/developerguide/elasticache-redis-cluster-automatic-backup-check.html)

**Schedule type:** Periodic

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  `snapshotRetentionPeriod`  |  Minimum snapshot retention period in days  |  Integer  |  `1` to `35`  |  `1`  | 

This control evaluates whether an Amazon ElastiCache (Redis OSS) cluster has automatic backups enabled. The control fails if the `SnapshotRetentionLimit` for the Redis OSS cluster is less than the specified time period. Unless you provide a custom parameter value for the snapshot retention period, Security Hub CSPM uses a default value of 1 day.

ElastiCache (Redis OSS) clusters can back up their data. You can use the backup to restore a cluster or seed a new cluster. The backup consists of the cluster's metadata, along with all the data in the cluster. All backups are written to Amazon S3, which provides durable storage. You can restore your data by creating a new ElastiCache cluster and populating it with data from a backup. You can manage backups using the AWS Management Console, the AWS CLI, and the ElastiCache API.

**Note**  
This control also evaluates ElastiCache (Redis OSS and Valkey) replication groups.

### Remediation
<a name="elasticache-1-remediation"></a>

For information about scheduling automatic backups for an ElastiCache cluster, see [Scheduling automatic backups](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/backups-automatic.html) in the *Amazon ElastiCache User Guide*.

## [ElastiCache.2] ElastiCache clusters should have automatic minor version upgrades enabled
<a name="elasticache-2"></a>

**Related requirements:** NIST.800-53.r5 SI-2, NIST.800-53.r5 SI-2(2), NIST.800-53.r5 SI-2(4), NIST.800-53.r5 SI-2(5) PCI DSS v4.0.1/6.3.3

**Category:** Identify > Vulnerability, patch, and version management

**Severity:** High

**Resource type:** `AWS::ElastiCache::CacheCluster`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/elasticache-auto-minor-version-upgrade-check.html](https://docs.aws.amazon.com/config/latest/developerguide/elasticache-auto-minor-version-upgrade-check.html)

**Schedule type:** Periodic

**Parameters:** None

This control evaluates whether Amazon ElastiCache automatically applies minor version upgrades to a cache cluster. The control fails if the cache cluster doesn't have minor version upgrades automatically applied.

**Note**  
This control doesn't apply to ElastiCache Memcached clusters.

Automatic minor version upgrade is a feature that you can enable in Amazon ElastiCache to automatically upgrade your cache clusters when a new minor cache engine version is available. These upgrades might include security patches and bug fixes. Staying up-to-date with patch installation is an important step in securing systems.

### Remediation
<a name="elasticache-2-remediation"></a>

To automatically apply minor version upgrades to an existing ElastiCache cache cluster, see [Version management for ElastiCache](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/VersionManagement.html) in the *Amazon ElastiCache User Guide*.

## [ElastiCache.3] ElastiCache replication groups should have automatic failover enabled
<a name="elasticache-3"></a>

**Related requirements:** NIST.800-53.r5 CP-10, NIST.800-53.r5 SC-36, NIST.800-53.r5 SC-5(2), NIST.800-53.r5 SI-13(5)

**Category:** Recover > Resilience > High availability

**Severity:** Medium

**Resource type:** `AWS::ElastiCache::ReplicationGroup`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/elasticache-repl-grp-auto-failover-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/elasticache-repl-grp-auto-failover-enabled.html)

**Schedule type:** Periodic

**Parameters:** None

This control checks whether an ElastiCache replication groups has automatic failover enabled. The control fails if automatic failover isn't enabled for a replication group.

When automatic failover is enabled for a replication group, the role of primary node will automatically fail over to one of the read replicas. This failover and replica promotion ensure that you can resume writing to the new primary after promotion is complete, which reduces overall downtime in case of failure.

### Remediation
<a name="elasticache-3-remediation"></a>

To enable automatic failover for an existing ElastiCache replication group,, see [Modifying an ElastiCache cluster](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/Clusters.Modify.html#Clusters.Modify.CON) in the *Amazon ElastiCache User Guide*. If you use the ElastiCache console, set **Auto failover** to enabled.

## [ElastiCache.4] ElastiCache replication groups should be encrypted at rest
<a name="elasticache-4"></a>

**Related requirements:** NIST.800-53.r5 CA-9(1), NIST.800-53.r5 CM-3(6), NIST.800-53.r5 SC-13, NIST.800-53.r5 SC-28, NIST.800-53.r5 SC-28(1), NIST.800-53.r5 SC-7(10), NIST.800-53.r5 SI-7(6)

**Category:** Protect > Data Protection > Encryption of data-at-rest

**Severity:** Medium

**Resource type:** `AWS::ElastiCache::ReplicationGroup`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/elasticache-repl-grp-encrypted-at-rest.html](https://docs.aws.amazon.com/config/latest/developerguide/elasticache-repl-grp-encrypted-at-rest.html)

**Schedule type:** Periodic

**Parameters:** None

This control checks whether an ElastiCache replication group is encrypted at rest. The control fails if the replication group isn't encrypted at rest.

Encrypting data at rest reduces the risk that an unauthenticated user gets access to data that is stored on disk. ElastiCache (Redis OSS) replication groups should be encrypted at rest for an added layer of security.

### Remediation
<a name="elasticache-4-remediation"></a>

To configure at-rest encryption on an ElastiCache replication group, see [Enabling at-rest encryption](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/at-rest-encryption.html#at-rest-encryption-enable) in the *Amazon ElastiCache User Guide*.

## [ElastiCache.5] ElastiCache replication groups should be encrypted in transit
<a name="elasticache-5"></a>

**Related requirements:** NIST.800-53.r5 AC-17(2), NIST.800-53.r5 AC-4, NIST.800-53.r5 IA-5(1), NIST.800-53.r5 SC-12(3), NIST.800-53.r5 SC-13, NIST.800-53.r5 SC-23, NIST.800-53.r5 SC-23(3), NIST.800-53.r5 SC-7(4), NIST.800-53.r5 SC-8, NIST.800-53.r5 SC-8(1), NIST.800-53.r5 SC-8(2), NIST.800-53.r5 SI-7(6), PCI DSS v4.0.1/4.2.1

**Category:** Protect > Data Protection > Encryption of data-in-transit

**Severity:** Medium

**Resource type:** `AWS::ElastiCache::ReplicationGroup`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/elasticache-repl-grp-encrypted-in-transit.html](https://docs.aws.amazon.com/config/latest/developerguide/elasticache-repl-grp-encrypted-in-transit.html)

**Schedule type:** Periodic

**Parameters:** None

This control checks whether an ElastiCache replication group is encrypted in transit. The control fails if the replication group isn't encrypted in transit.

Encrypting data in transit reduces the risk that an unauthorized user can eavesdrop on network traffic. Enabling encryption in transit on an ElastiCache replication group encrypts your data whenever it's moving from one place to another, such as between nodes in your cluster or between your cluster and your application.

### Remediation
<a name="elasticache-5-remediation"></a>

To configure in-transit encryption on an ElastiCache replication group, see [Enabling in-transit encryption](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/in-transit-encryption.html) in the *Amazon ElastiCache User Guide*.

## [ElastiCache.6] ElastiCache (Redis OSS) replication groups of earlier versions should have Redis OSS AUTH enabled
<a name="elasticache-6"></a>

**Related requirements:** NIST.800-53.r5 AC-2(1), NIST.800-53.r5 AC-3, NIST.800-53.r5 AC-3(15), NIST.800-53.r5 AC-3(7), NIST.800-53.r5 AC-6, PCI DSS v4.0.1/8.3.1

**Category:** Protect > Secure access management

**Severity:** Medium

**Resource type:** `AWS::ElastiCache::ReplicationGroup`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/elasticache-repl-grp-redis-auth-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/elasticache-repl-grp-redis-auth-enabled.html)

**Schedule type:** Periodic

**Parameters:** None

This control checks whether an ElastiCache (Redis OSS) replication group has Redis OSS AUTH enabled. The control fails if the Redis OSS version of the replication group nodes is below 6.0 and `AuthToken` isn't in use.

When you use Redis authentication tokens, or passwords, Redis requires a password before allowing clients to run commands, which improves data security. For Redis 6.0 and later versions, we recommend using Role-Based Access Control (RBAC). Since RBAC is not supported for Redis versions earlier than 6.0, this control only evaluates versions which can't use the RBAC feature.

### Remediation
<a name="elasticache-6-remediation"></a>

To use Redis AUTH on an ElastiCache (Redis OSS) replication group, see [Modifying the AUTH token on an existing ElastiCache (Redis OSS) cluster](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/auth.html#auth-modifyng-token) in the *Amazon ElastiCache User Guide*.

## [ElastiCache.7] ElastiCache clusters should not use the default subnet group
<a name="elasticache-7"></a>

**Related requirements:** NIST.800-53.r5 AC-4, NIST.800-53.r5 AC-4(21), NIST.800-53.r5 SC-7, NIST.800-53.r5 SC-7(11), NIST.800-53.r5 SC-7(16), NIST.800-53.r5 SC-7(21), NIST.800-53.r5 SC-7(4), NIST.800-53.r5 SC-7(5)

**Category:** Protect > Secure network configuration

**Severity:** High

**Resource type:** `AWS::ElastiCache::CacheCluster`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/elasticache-subnet-group-check.html](https://docs.aws.amazon.com/config/latest/developerguide/elasticache-subnet-group-check.html)

**Schedule type:** Periodic

**Parameters:** None

This control checks whether an ElastiCache cluster is configured with a custom subnet group. The control fails if `CacheSubnetGroupName` for an ElastiCache cluster has the value `default`.

When launching an ElastiCache cluster, a default subnet group is created if one doesn't exist already. The default group uses subnets from the default Virtual Private Cloud (VPC). We recommend using custom subnet groups that are more restrictive of the subnets that the cluster resides in, and the networking that the cluster inherits from the subnets.

### Remediation
<a name="elasticache-7-remediation"></a>

To create a new subnet group for an ElastiCache cluster, see [Creating a subnet group](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/SubnetGroups.Creating.html) in the *Amazon ElastiCache User Guide*.

# Security Hub CSPM controls for Elastic Beanstalk
<a name="elasticbeanstalk-controls"></a>

These AWS Security Hub CSPM controls evaluate the AWS Elastic Beanstalk service and resources.

These controls may not be available in all AWS Regions. For more information, see [Availability of controls by Region](securityhub-regions.md#securityhub-regions-control-support).

## [ElasticBeanstalk.1] Elastic Beanstalk environments should have enhanced health reporting enabled
<a name="elasticbeanstalk-1"></a>

**Related requirements:** NIST.800-53.r5 CA-7,NIST.800-53.r5 SI-2

**Category:** Detect > Detection services > Application monitoring

**Severity:** Low

**Resource type:** `AWS::ElasticBeanstalk::Environment`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/beanstalk-enhanced-health-reporting-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/beanstalk-enhanced-health-reporting-enabled.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether enhanced health reporting is enabled for your AWS Elastic Beanstalk environments.

Elastic Beanstalk enhanced health reporting enables a more rapid response to changes in the health of the underlying infrastructure. These changes could result in a lack of availability of the application.

Elastic Beanstalk enhanced health reporting provides a status descriptor to gauge the severity of the identified issues and identify possible causes to investigate. The Elastic Beanstalk health agent, included in supported Amazon Machine Images (AMIs), evaluates logs and metrics of environment EC2 instances.

For additional information, see [Enhanced health reporting and monitoring](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/health-enhanced.html) in the *AWS Elastic Beanstalk Developer Guide*.

### Remediation
<a name="elasticbeanstalk-1-remediation"></a>

For instructions on how to enable enhanced health reporting, see [Enabling enhanced health reporting using the Elastic Beanstalk console](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/health-enhanced-enable.html#health-enhanced-enable-console) in the *AWS Elastic Beanstalk Developer Guide*.

## [ElasticBeanstalk.2] Elastic Beanstalk managed platform updates should be enabled
<a name="elasticbeanstalk-2"></a>

**Related requirements:** NIST.800-53.r5 SI-2,NIST.800-53.r5 SI-2(2),NIST.800-53.r5 SI-2(4),NIST.800-53.r5 SI-2(5), PCI DSS v4.0.1/6.3.3

**Category:** Identify > Vulnerability, patch, and version management

**Severity:** High

**Resource type:** `AWS::ElasticBeanstalk::Environment`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/elastic-beanstalk-managed-updates-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/elastic-beanstalk-managed-updates-enabled.html)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  `UpdateLevel`  |  Version update level  |  Enum  |  `minor`, `patch`  |  No default value  | 

This control checks whether managed platform updates are enabled for an Elastic Beanstalk environment. The control fails if no managed platform updates are enabled. By default, the control passes if any type of platform update is enabled. Optionally, you can provide a custom parameter value to require a specific update level.

Enabling managed platform updates ensures that the latest available platform fixes, updates, and features for the environment are installed. Keeping up to date with patch installation is an important step in securing systems.

### Remediation
<a name="elasticbeanstalk-2-remediation"></a>

To enable managed platform updates, see [To configure managed platform updates under Managed platform updates](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/environment-platform-update-managed.html) in the *AWS Elastic Beanstalk Developer Guide*.

## [ElasticBeanstalk.3] Elastic Beanstalk should stream logs to CloudWatch
<a name="elasticbeanstalk-3"></a>

**Related requirements:** PCI DSS v4.0.1/10.4.2

**Category:** Identify > Logging

**Severity:** High

**Resource type:** `AWS::ElasticBeanstalk::Environment`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/elastic-beanstalk-logs-to-cloudwatch.html](https://docs.aws.amazon.com/config/latest/developerguide/elastic-beanstalk-logs-to-cloudwatch.html)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  `RetentionInDays`  |  Number of days to keep log events before expiration  |  Enum  |  `1`, `3`, `5`, `7`, `14`, `30`, `60`, `90`, `120`, `150`, `180`, `365` , `400`, `545`, `731`, `1827`, `3653`   |  No default value  | 

This control checks whether an Elastic Beanstalk environment is configured to send logs to CloudWatch Logs. The control fails if an Elastic Beanstalk environment isn't configured to send logs to CloudWatch Logs. Optionally, you can provide a custom value for the `RetentionInDays` parameter if you want the control to pass only if logs are retained for the specified number of days before expiration.

CloudWatch helps you collect and monitor various metrics for your applications and infrastructure resources. You can also use CloudWatch to configure alarm actions based on specific metrics. We recommend integrating Elastic Beanstalk with CloudWatch to get increased visibility into your Elastic Beanstalk environment. Elastic Beanstalk logs include the eb-activity.log, access logs from the environment nginx or Apache proxy server, and logs that are specific to an environment.

### Remediation
<a name="elasticbeanstalk-3-remediation"></a>

To integrate Elastic Beanstalk with CloudWatch Logs, see [Streaming instance logs to CloudWatch Logs](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/AWSHowTo.cloudwatchlogs.html#AWSHowTo.cloudwatchlogs.streaming) in the *AWS Elastic Beanstalk Developer Guide*.

# Security Hub CSPM controls for Elastic Load Balancing
<a name="elb-controls"></a>

These AWS Security Hub CSPM controls evaluate the Elastic Load Balancing service and resources. The controls might not be available in all AWS Regions. For more information, see [Availability of controls by Region](securityhub-regions.md#securityhub-regions-control-support).

## [ELB.1] Application Load Balancer should be configured to redirect all HTTP requests to HTTPS
<a name="elb-1"></a>

**Related requirements:** PCI DSS v3.2.1/2.3,PCI DSS v3.2.1/4.1, NIST.800-53.r5 AC-17(2), NIST.800-53.r5 AC-4, NIST.800-53.r5 IA-5(1), NIST.800-53.r5 SC-12(3), NIST.800-53.r5 SC-13, NIST.800-53.r5 SC-23, NIST.800-53.r5 SC-23(3), NIST.800-53.r5 SC-7(4), NIST.800-53.r5 SC-8, NIST.800-53.r5 SC-8(1), NIST.800-53.r5 SC-8(2), NIST.800-53.r5 SI-7(6)

**Category:** Detect > Detection services

**Severity:** Medium

**Resource type:** `AWS::ElasticLoadBalancingV2::LoadBalancer`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/alb-http-to-https-redirection-check.html](https://docs.aws.amazon.com/config/latest/developerguide/alb-http-to-https-redirection-check.html) 

**Schedule type:** Periodic

**Parameters:** None

This control checks whether HTTP to HTTPS redirection is configured on all HTTP listeners of Application Load Balancers. The control fails if any of the HTTP listeners of Application Load Balancers do not have HTTP to HTTPS redirection configured.

Before you start to use your Application Load Balancer, you must add one or more listeners. A listener is a process that uses the configured protocol and port to check for connection requests. Listeners support both the HTTP and HTTPS protocols. You can use an HTTPS listener to offload the work of encryption and decryption to your load balancer. To enforce encryption in transit, you should use redirect actions with Application Load Balancers to redirect client HTTP requests to an HTTPS request on port 443.

To learn more, see [Listeners for your Application Load Balancers](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-listeners.html) in *User Guide for Application Load Balancers*.

### Remediation
<a name="elb-1-remediation"></a>

To redirect HTTP requests to HTTPS, you must add an Application Load Balancer listener rule or edit an existing rule.

For instructions on adding a new rule, see [Add a rule](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/listener-update-rules.html#add-rule) in the *User Guide for Application Load Balancers*. For **Protocol : Port**, choose **HTTP**, and then enter **80**. For **Add action, Redirect to**, choose **HTTPS**, and then enter **443**.

For instructions on editing an existing rule, see [Edit a rule](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/listener-update-rules.html#edit-rule) in the *User Guide for Application Load Balancers*. For **Protocol : Port**, choose **HTTP**, and then enter **80**. For **Add action, Redirect to**, choose **HTTPS**, and then enter **443**.

## [ELB.2] Classic Load Balancers with SSL/HTTPS listeners should use a certificate provided by AWS Certificate Manager
<a name="elb-2"></a>

**Related requirements:** NIST.800-53.r5 AC-17(2), NIST.800-53.r5 AC-4, NIST.800-53.r5 IA-5(1), NIST.800-53.r5 SC-12(3), NIST.800-53.r5 SC-13, NIST.800-53.r5 SC-23, NIST.800-53.r5 SC-23(5), NIST.800-53.r5 SC-7(4), NIST.800-53.r5 SC-8, NIST.800-53.r5 SC-8(1), NIST.800-53.r5 SC-8(2), NIST.800-53.r5 SI-7(6), NIST.800-171.r2 3.13.8

**Category:** Protect > Data Protection > Encryption of data-in-transit

**Severity:** Medium

**Resource type:** `AWS::ElasticLoadBalancing::LoadBalancer`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/elb-acm-certificate-required.html](https://docs.aws.amazon.com/config/latest/developerguide/elb-acm-certificate-required.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether the Classic Load Balancer uses HTTPS/SSL certificates provided by AWS Certificate Manager (ACM). The control fails if the Classic Load Balancer configured with HTTPS/SSL listener does not use a certificate provided by ACM.

To create a certificate, you can use either ACM or a tool that supports the SSL and TLS protocols, such as OpenSSL. Security Hub CSPM recommends that you use ACM to create or import certificates for your load balancer.

ACM integrates with Classic Load Balancers so that you can deploy the certificate on your load balancer. You also should automatically renew these certificates.

### Remediation
<a name="elb-2-remediation"></a>

For information about how to associate an ACM SSL/TLS certificate with a Classic Load Balancer, see the AWS Knowledge Center article [How can I associate an ACM SSL/TLS certificate with a Classic, Application, or Network Load Balancer?](https://aws.amazon.com/premiumsupport/knowledge-center/associate-acm-certificate-alb-nlb/)

## [ELB.3] Classic Load Balancer listeners should be configured with HTTPS or TLS termination
<a name="elb-3"></a>

**Related requirements:** NIST.800-53.r5 AC-17(2), NIST.800-53.r5 AC-4, NIST.800-53.r5 IA-5(1), NIST.800-53.r5 SC-12(3), NIST.800-53.r5 SC-13, NIST.800-53.r5 SC-23, NIST.800-53.r5 SC-23(3), NIST.800-53.r5 SC-7(4), NIST.800-53.r5 SC-8, NIST.800-53.r5 SC-8(1), NIST.800-53.r5 SC-8(2), NIST.800-53.r5 SI-7(6), NIST.800-171.r2 3.13.8, NIST.800-171.r2 3.13.15, PCI DSS v4.0.1/4.2.1

**Category:** Protect > Data Protection > Encryption of data-in-transit

**Severity:** Medium

**Resource type:** `AWS::ElasticLoadBalancing::LoadBalancer`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/elb-tls-https-listeners-only.html](https://docs.aws.amazon.com/config/latest/developerguide/elb-tls-https-listeners-only.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether your Classic Load Balancer listeners are configured with HTTPS or TLS protocol for front-end (client to load balancer) connections. The control is applicable if a Classic Load Balancer has listeners. If your Classic Load Balancer does not have a listener configured, then the control does not report any findings.

The control passes if the Classic Load Balancer listeners are configured with TLS or HTTPS for front-end connections.

The control fails if the listener is not configured with TLS or HTTPS for front-end connections.

Before you start to use a load balancer, you must add one or more listeners. A listener is a process that uses the configured protocol and port to check for connection requests. Listeners can support both HTTP and HTTPS/TLS protocols. You should always use an HTTPS or TLS listener, so that the load balancer does the work of encryption and decryption in transit.

### Remediation
<a name="elb-3-remediation"></a>

To remediate this issue, update your listeners to use the TLS or HTTPS protocol.

**To change all noncompliant listeners to TLS/HTTPS listeners**

1. Open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).

1. In the navigation pane, under **Load Balancing**, choose **Load Balancers**.

1. Select your Classic Load Balancer.

1. On the **Listeners** tab, choose **Edit**.

1. For all listeners where **Load Balancer Protocol** is not set to HTTPS or SSL, change the setting to HTTPS or SSL.

1. For all modified listeners, on the **Certificates** tab, choose **Change default**.

1. For **ACM and IAM certificates**, select a certificate.

1. Choose **Save as default**.

1. After you update all of the listeners, choose **Save**.

## [ELB.4] Application Load Balancer should be configured to drop invalid http headers
<a name="elb-4"></a>

**Related requirements:** NIST.800-53.r5 SC-7(4), NIST.800-53.r5 SC-8(2), PCI DSS v4.0.1/6.2.4

**Category:** Protect > Network Security

**Severity:** Medium

**Resource type:** `AWS::ElasticLoadBalancingV2::LoadBalancer`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/alb-http-drop-invalid-header-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/alb-http-drop-invalid-header-enabled.html)

**Schedule type:** Change triggered

**Parameters:** None

This control evaluates whether an Application Load Balancer is configured to drop invalid HTTP headers. The control fails if the value of `routing.http.drop_invalid_header_fields.enabled` is set to `false`.

By default, Application Load Balancers are not configured to drop invalid HTTP header values. Removing these header values prevents HTTP desync attacks.

**Note**  
We recommend disabling this control if ELB.12 is enabled in your account. For more information, see [[ELB.12] Application Load Balancer should be configured with defensive or strictest desync mitigation mode](#elb-12).

### Remediation
<a name="elb-4-remediation"></a>

To remediate this issue, configure your load balancer to drop invalid header fields.

**To configure the load balancer to drop invalid header fields**

1. Open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).

1. In the navigation pane, choose **Load balancers**.

1. Choose an Application Load Balancer.

1. From **Actions**, choose **Edit attributes**.

1. Under **Drop Invalid Header Fields**, choose **Enable**.

1. Choose **Save**.

## [ELB.5] Application and Classic Load Balancers logging should be enabled
<a name="elb-5"></a>

**Related requirements:** NIST.800-53.r5 AC-4(26), NIST.800-53.r5 AU-10, NIST.800-53.r5 AU-12, NIST.800-53.r5 AU-2, NIST.800-53.r5 AU-3, NIST.800-53.r5 AU-6(3), NIST.800-53.r5 AU-6(4), NIST.800-53.r5 CA-7, NIST.800-53.r5 SC-7(9), NIST.800-53.r5 SI-7(8)

**Category:** Identify > Logging

**Severity:** Medium

**Resource type:** `AWS::ElasticLoadBalancing::LoadBalancer`, `AWS::ElasticLoadBalancingV2::LoadBalancer`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/elb-logging-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/elb-logging-enabled.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether the Application Load Balancer and the Classic Load Balancerhave logging enabled. The control fails if `access_logs.s3.enabled` is `false`.

Elastic Load Balancing provides access logs that capture detailed information about requests sent to your load balancer. Each log contains information such as the time the request was received, the client's IP address, latencies, request paths, and server responses. You can use these access logs to analyze traffic patterns and to troubleshoot issues. 

To learn more, see [Access logs for your Classic Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/access-log-collection.html) in *User Guide for Classic Load Balancers*.

### Remediation
<a name="elb-5-remediation"></a>

To enable access logs, see [Step 3: Configure access logs](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/enable-access-logging.html#enable-access-logs) in the *User Guide for Application Load Balancers*.

## [ELB.6] Application, Gateway, and Network Load Balancers should have deletion protection enabled
<a name="elb-6"></a>

**Related requirements:** NIST.800-53.r5 CA-9(1), NIST.800-53.r5 CM-2, NIST.800-53.r5 CM-2(2), NIST.800-53.r5 CM-3, NIST.800-53.r5 SC-5(2)

**Category:** Recover > Resilience > High availability

**Severity:** Medium

**Resource type:** `AWS::ElasticLoadBalancingV2::LoadBalancer`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/elb-deletion-protection-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/elb-deletion-protection-enabled.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether an Application, Gateway, or Network Load Balancer has deletion protection enabled. The control fails if deletion protection is disabled.

Enable deletion protection to protect your Application, Gateway, or Network Load Balancer from deletion.

### Remediation
<a name="elb-6-remediation"></a>

To prevent your load balancer from being deleted accidentally, you can enable deletion protection. By default, deletion protection is disabled for your load balancer.

If you enable deletion protection for your load balancer, you must disable delete protection before you can delete the load balancer.

To enable deletion protection for an Application Load Balancer, see [Deletion protection](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/application-load-balancers.html#deletion-protection) in the *User Guide for Application Load Balancers*. To enable deletion protection for a Gateway Load Balancer, see [Deletion protection](https://docs.aws.amazon.com/elasticloadbalancing/latest/gateway/gateway-load-balancers.html#deletion-protection) in the *User Guide for Gateway Load Balancers*. To enable deletion protection for a Network Load Balancer, see [Deletion protection](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/network-load-balancers.html#deletion-protection) in the *User Guide for Network Load Balancers*.

## [ELB.7] Classic Load Balancers should have connection draining enabled
<a name="elb-7"></a>

**Related requirements:** NIST.800-53.r5 CA-9(1), NIST.800-53.r5 CM-2

**Category:** Recover > Resilience

**Severity:** Low

**Resource type:** `AWS::ElasticLoadBalancing::LoadBalancer`

**AWS Config rule:** `elb-connection-draining-enabled` (custom Security Hub CSPM rule)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether Classic Load Balancers have connection draining enabled.

Enabling connection draining on Classic Load Balancers ensures that the load balancer stops sending requests to instances that are de-registering or unhealthy. It keeps the existing connections open. This is particularly useful for instances in Auto Scaling groups, to ensure that connections aren't severed abruptly.

### Remediation
<a name="elb-7-remediation"></a>

To enable connection draining on Classic Load Balancers, see [Configure connection draining for your Classic Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/config-conn-drain.html) in *User Guide for Classic Load Balancers*.

## [ELB.8] Classic Load Balancers with SSL listeners should use a predefined security policy that has strong AWS Configuration
<a name="elb-8"></a>

**Related requirements:** NIST.800-53.r5 AC-17(2), NIST.800-53.r5 AC-4, NIST.800-53.r5 IA-5(1), NIST.800-53.r5 SC-12(3), NIST.800-53.r5 SC-13, NIST.800-53.r5 SC-23, NIST.800-53.r5 SC-23(3), NIST.800-53.r5 SC-7(4), NIST.800-53.r5 SC-8, NIST.800-53.r5 SC-8(1), NIST.800-53.r5 SC-8(2), NIST.800-53.r5 SI-7(6), NIST.800-171.r2 3.13.8, NIST.800-171.r2 3.13.15, PCI DSS v4.0.1/4.2.1

**Category:** Protect > Data Protection > Encryption of data-in-transit

**Severity:** Medium

**Resource type:** `AWS::ElasticLoadBalancing::LoadBalancer`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/elb-predefined-security-policy-ssl-check.html](https://docs.aws.amazon.com/config/latest/developerguide/elb-predefined-security-policy-ssl-check.html)

**Schedule type:** Change triggered

**Parameters:**
+ `predefinedPolicyName`: `ELBSecurityPolicy-TLS-1-2-2017-01` (not customizable)

This control checks whether your Classic Load Balancer HTTPS/SSL listeners use the predefined policy `ELBSecurityPolicy-TLS-1-2-2017-01`. The control fails if the Classic Load Balancer HTTPS/SSL listeners do not use `ELBSecurityPolicy-TLS-1-2-2017-01`.

A security policy is a combination of SSL protocols, ciphers, and the Server Order Preference option. Predefined policies control the ciphers, protocols, and preference orders to support during SSL negotiations between a client and load balancer.

Using `ELBSecurityPolicy-TLS-1-2-2017-01` can help you to meet compliance and security standards that require you to disable specific versions of SSL and TLS. For more information, see [Predefined SSL security policies for Classic Load Balancers](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-security-policy-table.html) in *User Guide for Classic Load Balancers*.

### Remediation
<a name="elb-8-remediation"></a>

For information on how to use the predefined security policy `ELBSecurityPolicy-TLS-1-2-2017-01` with a Classic Load Balancer, see [Configure security settings](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-create-https-ssl-load-balancer.html#config-backend-auth) in *User Guide for Classic Load Balancers*.

## [ELB.9] Classic Load Balancers should have cross-zone load balancing enabled
<a name="elb-9"></a>

**Related requirements:** NIST.800-53.r5 CP-10, NIST.800-53.r5 CP-6(2), NIST.800-53.r5 SC-36, NIST.800-53.r5 SC-5(2), NIST.800-53.r5 SI-13(5)

**Category:** Recover > Resilience > High availability

**Severity:** Medium

**Resource type:** `AWS::ElasticLoadBalancing::LoadBalancer`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/elb-cross-zone-load-balancing-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/elb-cross-zone-load-balancing-enabled.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks if cross-zone load balancing is enabled for the Classic Load Balancers (CLBs). The control fails if cross-zone load balancing is not enabled for a CLB.

A load balancer node distributes traffic only across the registered targets in its Availability Zone. When cross-zone load balancing is disabled, each load balancer node distributes traffic only across the registered targets in its Availability Zone. If the number of registered targets is not same across the Availability Zones, traffic wont be distributed evenly and the instances in one zone may end up over utilized compared to the instances in another zone. With cross-zone load balancing enabled, each load balancer node for your Classic Load Balancer distributes requests evenly across the registered instances in all enabled Availability Zones. For details see [Cross-zone load balancing](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/how-elastic-load-balancing-works.html#cross-zone-load-balancing) in the Elastic Load Balancing User Guide.

### Remediation
<a name="elb-9-remediation"></a>

To enable cross-zone load balancing in a Classic Load Balancer, see [Enable cross-zone load balancing](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/enable-disable-crosszone-lb.html#enable-cross-zone) in the *User Guide for Classic Load Balancers*.

## [ELB.10] Classic Load Balancer should span multiple Availability Zones
<a name="elb-10"></a>

**Related requirements:** NIST.800-53.r5 CP-10, NIST.800-53.r5 CP-6(2), NIST.800-53.r5 SC-36, NIST.800-53.r5 SC-5(2), NIST.800-53.r5 SI-13(5)

**Category:** Recover > Resilience > High availability

**Severity:** Medium

**Resource type:** `AWS::ElasticLoadBalancing::LoadBalancer`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/clb-multiple-az.html](https://docs.aws.amazon.com/config/latest/developerguide/clb-multiple-az.html)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  `minAvailabilityZones`  |  Minimum number of Availability Zones  |  Enum  |  `2, 3, 4, 5, 6`  |  `2`  | 

This control checks whether a Classic Load Balancer has been configured to span at least the specified number of Availability Zones (AZs). The control fails if the Classic Load Balancer does not span at least the specified number of AZs. Unless you provide a custom parameter value for the minimum number of AZs, Security Hub CSPM uses a default value of two AZs.

 A Classic Load Balancer can be set up to distribute incoming requests across Amazon EC2 instances in a single Availability Zone or multiple Availability Zones. A Classic Load Balancer that does not span multiple Availability Zones is unable to redirect traffic to targets in another Availability Zone if the sole configured Availability Zone becomes unavailable. 

### Remediation
<a name="elb-10-remediation"></a>

 To add Availability Zones to a Classic Load Balancer, see [Add or remove subnets for your Classic Load Balancer](https://docs.aws.amazon.com//elasticloadbalancing/latest/classic/elb-manage-subnets.html) in the *User Guide for Classic Load Balancers*. 

## [ELB.12] Application Load Balancer should be configured with defensive or strictest desync mitigation mode
<a name="elb-12"></a>

**Related requirements:** NIST.800-53.r5 AC-4(21), NIST.800-53.r5 CA-9(1), NIST.800-53.r5 CM-2, PCI DSS v4.0.1/6.2.4

**Category:** Protect > Data Protection > Data integrity

**Severity:** Medium

**Resource type:** `AWS::ElasticLoadBalancingV2::LoadBalancer`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/alb-desync-mode-check.html](https://docs.aws.amazon.com/config/latest/developerguide/alb-desync-mode-check.html)

**Schedule type:** Change triggered

**Parameters:**
+ `desyncMode`: `defensive, strictest` (not customizable)

This control checks whether an Application Load Balancer is configured with defensive or strictest desync mitigation mode. The control fails if an Application Load Balancer is not configured with defensive or strictest desync mitigation mode.

HTTP Desync issues can lead to request smuggling and make applications vulnerable to request queue or cache poisoning. In turn, these vulnerabilities can lead to credential stuffing or execution of unauthorized commands. Application Load Balancers configured with defensive or strictest desync mitigation mode protect your application from security issues that may be caused by HTTP Desync. 

### Remediation
<a name="elb-12-remediation"></a>

To update desync mitigation mode of an Application Load Balancer, see [Desync mitigation mode](https://docs.aws.amazon.com//elasticloadbalancing/latest/application/application-load-balancers.html#desync-mitigation-mode) in the *User Guide for Application Load Balancers*. 

## [ELB.13] Application, Network and Gateway Load Balancers should span multiple Availability Zones
<a name="elb-13"></a>

**Related requirements:** NIST.800-53.r5 CP-10, NIST.800-53.r5 CP-6(2), NIST.800-53.r5 SC-36, NIST.800-53.r5 SC-5(2), NIST.800-53.r5 SI-13(5)

**Category:** Recover > Resilience > High availability 

**Severity:** Medium

**Resource type:** `AWS::ElasticLoadBalancingV2::LoadBalancer`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/elbv2-multiple-az.html](https://docs.aws.amazon.com/config/latest/developerguide/elbv2-multiple-az.html)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  `minAvailabilityZones`  |  Minimum number of Availability Zones  |  Enum  |  `2, 3, 4, 5, 6`  |  `2`  | 

This control checks whether an Elastic Load Balancer V2 (Application, Network, or Gateway Load Balancer) has registered instances from at least the specified number of Availability Zones (AZs). The control fails if an Elastic Load Balancer V2 doesn't have instances registered in at least the specified number of AZs. Unless you provide a custom parameter value for the minimum number of AZs, Security Hub CSPM uses a default value of two AZs.

Elastic Load Balancing automatically distributes your incoming traffic across multiple targets, such as EC2 instances, containers, and IP addresses, in one or more Availability Zones. Elastic Load Balancing scales your load balancer as your incoming traffic changes over time. It is recommended to configure at least two availability zones to ensure availability of services, as the Elastic Load Balancer will be able to direct traffic to another availability zone if one becomes unavailable. Having multiple availability zones configured will help eliminate having a single point of failure for the application. 

### Remediation
<a name="elb-13-remediation"></a>

To add an Availability Zone to an Application Load Balancer, see [Availability Zones for your Application Load Balancer](https://docs.aws.amazon.com//elasticloadbalancing/latest/application/load-balancer-subnets.html) in the *User Guide for Application Load Balancers*. To add an Availability Zone to an Network Load Balancer, see [Network Load Balancers](https://docs.aws.amazon.com//elasticloadbalancing/latest/network/network-load-balancers.html#availability-zones) in the *User Guide for Network Load Balancers*. To add an Availability Zone to a Gateway Load Balancer, see [Create a Gateway Load Balancer](https://docs.aws.amazon.com//elasticloadbalancing/latest/gateway/create-load-balancer.html) in the *User Guide for Gateway Load Balancers*. 

## [ELB.14] Classic Load Balancer should be configured with defensive or strictest desync mitigation mode
<a name="elb-14"></a>

**Related requirements:** NIST.800-53.r5 AC-4(21), NIST.800-53.r5 CA-9(1), NIST.800-53.r5 CM-2, PCI DSS v4.0.1/6.2.4

**Category:** Protect > Data Protection > Data integrity

**Severity:** Medium

**Resource type:** `AWS::ElasticLoadBalancing::LoadBalancer`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/clb-desync-mode-check.html](https://docs.aws.amazon.com/config/latest/developerguide/clb-desync-mode-check.html)

**Schedule type:** Change triggered

**Parameters:**
+ `desyncMode`: `defensive, strictest` (not customizable)

This control checks whether a Classic Load Balancer is configured with defensive or strictest desync mitigation mode. The control fails if the Classic Load Balancer isn't configured with defensive or strictest desync mitigation mode.

HTTP Desync issues can lead to request smuggling and make applications vulnerable to request queue or cache poisoning. In turn, these vulnerabilities can lead to credential hijacking or execution of unauthorized commands. Classic Load Balancers configured with defensive or strictest desync mitigation mode protect your application from security issues that may be caused by HTTP Desync. 

### Remediation
<a name="elb-14-remediation"></a>

To update desync mitigation mode on a Classic Load Balancer, see [Modify desync mitigation mode](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/config-desync-mitigation-mode.html#update-desync-mitigation-mode) in the *User Guide for Classic Load Balancers*. 

## [ELB.16] Application Load Balancers should be associated with an AWS WAF web ACL
<a name="elb-16"></a>

**Related requirements:** NIST.800-53.r5 AC-4(21)

**Category:** Protect > Protective services

**Severity:** Medium

**Resource type:** `AWS::ElasticLoadBalancingV2::LoadBalancer`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/alb-waf-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/alb-waf-enabled.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether an Application Load Balancer is associated with an AWS WAF Classic or AWS WAF web access control list (web ACL). The control fails if the `Enabled` field for the AWS WAF configuration is set to `false`.

AWS WAF is a web application firewall that helps protect web applications and APIs from attacks. With AWS WAF, you can configure a web ACL, which is a set of rules that allow, block, or count web requests based on customizable web security rules and conditions that you define. We recommend associating your Application Load Balancer with an AWS WAF web ACL to help protect it from malicious attacks.

### Remediation
<a name="elb-16-remediation"></a>

To associate an Application Load Balancer with a web ACL, see [Associating or disassociating a web ACL with an AWS resource](https://docs.aws.amazon.com/waf/latest/developerguide/web-acl-associating-aws-resource.html) in the *AWS WAF Developer Guide*. 

## [ELB.17] Application and Network Load Balancers with listeners should use recommended security policies
<a name="elb-17"></a>

**Related requirements:** NIST.800-53.r5 AC-17(2), NIST.800-53.r5 AC-4, NIST.800-53.r5 IA-5(1), NIST.800-53.r5 SC-12(3), NIST.800-53.r5 SC-13, NIST.800-53.r5 SC-23, NIST.800-53.r5 SC-23(3), NIST.800-53.r5 SC-7(4), NIST.800-53.r5 SC-8, NIST.800-53.r5 SC-8(1), NIST.800-53.r5 SC-8(2), NIST.800-53.r5 SI-7(6)

**Category:** Protect > Data Protection > Encryption of data-in-transit

**Severity:** Medium

**Resource type:** `AWS::ElasticLoadBalancingV2::Listener`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/elbv2-predefined-security-policy-ssl-check.html](https://docs.aws.amazon.com/config/latest/developerguide/elbv2-predefined-security-policy-ssl-check.html)

**Schedule type:** Change triggered

**Parameters:** `sslPolicies`: `ELBSecurityPolicy-TLS13-1-3-2021-06, ELBSecurityPolicy-TLS13-1-3-FIPS-2023-04, ELBSecurityPolicy-TLS13-1-2-Res-2021-06, ELBSecurityPolicy-TLS13-1-2-Res-FIPS-2023-04, ELBSecurityPolicy-TLS13-1-2-Res-PQ-2025-09, ELBSecurityPolicy-TLS13-1-3-PQ-2025-09, ELBSecurityPolicy-TLS13-1-2-Res-FIPS-PQ-2025-09, ELBSecurityPolicy-TLS13-1-3-FIPS-PQ-2025-09` (not customizable)

This control checks whether the HTTPS listener for an Application Load Balancer or the TLS listener for a Network Load Balancer is configured to encrypt data in transit by using a recommended security policy. The control fails if the HTTPS or TLS listener for a load balancer isn't configured to use a recommended security policy.

Elastic Load Balancing uses an SSL negotiation configuration, known as a *security policy*, to negotiate connections between a client and a load balancer. The security policy specifies a combination of protocols and ciphers. The protocol establishes a secure connection between a client and a server. A cipher is an encryption algorithm that uses encryption keys to create a coded message. During the connection negotiation process, the client and the load balancer present a list of ciphers and protocols that they each support, in order of preference. Using a recommended security policy for a load balancer can help you meet compliance and security standards.

### Remediation
<a name="elb-17-remediation"></a>

For information about recommended security policies and how to update listeners, see the following sections of the *Elastic Load Balancing User Guides*: [Security policies for Application Load Balancers](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/describe-ssl-policies.html), [Security policies for Network Load Balancers](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/describe-ssl-policies.html), [Update an HTTPS listener for your Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/listener-update-certificates.html), and [Update a listener for your Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/listener-update-rules.html).

## [ELB.18] Application and Network Load Balancer listeners should use secure protocols to encrypt data in transit
<a name="elb-18"></a>

**Category:** Protect > Data Protection > Encryption of data-in-transit

**Severity:** Medium

**Resource type:** `AWS::ElasticLoadBalancingV2::Listener`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/elbv2-listener-encryption-in-transit.html](https://docs.aws.amazon.com/config/latest/developerguide/elbv2-listener-encryption-in-transit.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether the listener for an Application Load Balancer or Network Load Balancer is configured to use a secure protocol for encryption of data in transit. The control fails if an Application Load Balancer listener isn't configured to use the HTTPS protocol, or a Network Load Balancer listener isn't configured to use the TLS protocol.

To encrypt data that's transmitted between a client and a load balancer, Elastic Load Balancer listeners should be configured to use industry-standard security protocols: HTTPS for Application Load Balancers, or TLS for Network Load Balancers. Otherwise, data that's transmitted between a client and a load balancer is vulnerable to interception, tampering, and unauthorized access. Use of HTTPS or TLS by a listener aligns with security best practices and helps ensure the confidentiality and integrity of data during transmission. This is particularly important for applications that handle sensitive information, or must comply with security standards that require encryption of data in transit.

### Remediation
<a name="elb-18-remediation"></a>

For information about configuring security protocols for listeners, see the following sections of the *Elastic Load Balancing User Guides*: [Create an HTTPS listener for your Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-https-listener.html) and [Create a listener for your Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/create-listener.html).

## [ELB.21] Application and Network Load Balancer target groups should use encrypted health check protocols
<a name="elb-21"></a>

**Category:** Protect > Data Protection > Encryption of data-in-transit

**Severity:** Medium

**Resource type:** `AWS::ElasticLoadBalancingV2::TargetGroup`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/elbv2-targetgroup-healthcheck-protocol-encrypted.html](https://docs.aws.amazon.com/config/latest/developerguide/elbv2-targetgroup-healthcheck-protocol-encrypted.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether the target group for application and network load balancer health checks use an encrypted transport protocol. The control fails if the health check protocol does not use HTTPS. This control is not applicable to Lambda target types.

 Load Balancers send health check requests to registered targets to determine their status and route traffic accordingly. The health check protocol specified in the target group configuration determines how these checks are performed. When health check protocols use unencrypted communication such as HTTP, the requests and responses can be intercepted or manipulated during transmission. This allows attackers to gain insights into infrastructure configuration, tamper with health check results, or conduct man-in-the-middle attacks that affect routing decisions. Using HTTPS for health checks provides encrypted communication between the load balancer and its targets, protecting the integrity and confidentiality of health status information.

### Remediation
<a name="elb-21-remediation"></a>

To configure encrypted health checks for your Application Load Balancer target group, see [Update the health check settings of an Application Load Balancer target group](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/modify-health-check-settings.html) in the *Elastic Load Balancing User Guide*. To configure encrypted health checks for your Network Load Balancer target group, see [Update the health check settings of an Network Load Balancer target group](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/modify-health-check-settings.html) in the *Elastic Load Balancing User Guide*.

## [ELB.22] ELB target groups should use encrypted transport protocols
<a name="elb-22"></a>

**Category:** Protect > Data Protection > Encryption of data-in-transit

**Severity:** Medium

**Resource type:** `AWS::ElasticLoadBalancingV2::TargetGroup`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/elbv2-targetgroup-protocol-encrypted.html](https://docs.aws.amazon.com/config/latest/developerguide/elbv2-targetgroup-protocol-encrypted.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether an Elastic Load Balancing target group uses an encrypted transport protocol. This control does not apply to target groups with a target type of Lambda or ALB, or target groups using the GENEVE protocol. The control fails if the target group does not use HTTPS, TLS, or QUIC protocol.

 Encrypting data in transit protects it from interception by unauthorized users. Target groups that use unencrypted protocols (HTTP, TCP, UDP) transmit data without encryption, making it vulnerable to eavesdropping. Using encrypted protocols (HTTPS, TLS, QUIC) ensures that data transmitted between load balancers and targets is protected.

### Remediation
<a name="elb-22-remediation"></a>

To use an encrypted protocol, you must create a new target group with HTTPS, TLS, or QUIC protocol. Target group protocol cannot be modified after creation. To create Application Load Balancer target group, see [Create a target group for your Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-target-group.html) in the *Elastic Load Balancing User Guide*. To create Network Load Balancer target group, see [Create a target group for your Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/create-target-group.html) in the *Elastic Load Balancing User Guide*. 

# Security Hub CSPM for Elasticsearch
<a name="es-controls"></a>

These AWS Security Hub CSPM controls evaluate the Elasticsearch service and resources.

These controls may not be available in all AWS Regions. For more information, see [Availability of controls by Region](securityhub-regions.md#securityhub-regions-control-support).

## [ES.1] Elasticsearch domains should have encryption at-rest enabled
<a name="es-1"></a>

**Related requirements:** PCI DSS v3.2.1/3.4, NIST.800-53.r5 CA-9(1), NIST.800-53.r5 CM-3(6), NIST.800-53.r5 SC-13, NIST.800-53.r5 SC-28, NIST.800-53.r5 SC-28(1), NIST.800-53.r5 SC-7(10), NIST.800-53.r5 SI-7(6)

**Category:** Protect > Data Protection > Encryption of data-at-rest

**Severity:** Medium

**Resource type:** `AWS::Elasticsearch::Domain`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/elasticsearch-encrypted-at-rest.html](https://docs.aws.amazon.com/config/latest/developerguide/elasticsearch-encrypted-at-rest.html)

**Schedule type:** Periodic

**Parameters:** None

This control checks whether Elasticsearch domains have encryption at rest configuration enabled. The check fails if encryption at rest is not enabled.

For an added layer of security for your sensitive data in OpenSearch, you should configure your OpenSearch to be encrypted at rest. Elasticsearch domains offer encryption of data at rest. The feature uses AWS KMS to store and manage your encryption keys. To perform the encryption, it uses the Advanced Encryption Standard algorithm with 256-bit keys (AES-256).

To learn more about OpenSearch encryption at rest, see [Encryption of data at rest for Amazon OpenSearch Service](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/encryption-at-rest.html) in the *Amazon OpenSearch Service Developer Guide*.

Certain instance types, such as `t.small` and `t.medium`, don't support encryption of data at rest. For details, see [Supported instance types](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/supported-instance-types.html) in the *Amazon OpenSearch Service Developer Guide*.

### Remediation
<a name="es-1-remediation"></a>

To enable encryption at rest for new and existing Elasticsearch domains, see [Enabling encryption of data at rest](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/encryption-at-rest.html#enabling-ear) in the *Amazon OpenSearch Service Developer Guide*.

## [ES.2] Elasticsearch domains should not be publicly accessible
<a name="es-2"></a>

**Related requirements:** PCI DSS v3.2.1/1.2.1,PCI DSS v3.2.1/1.3.1,PCI DSS v3.2.1/1.3.2,PCI DSS v3.2.1/1.3.4,PCI DSS v3.2.1/1.3.6, NIST.800-53.r5 AC-21, NIST.800-53.r5 AC-3, NIST.800-53.r5 AC-3(7), NIST.800-53.r5 AC-4, NIST.800-53.r5 AC-4(21), NIST.800-53.r5 AC-6, NIST.800-53.r5 SC-7, NIST.800-53.r5 SC-7(11), NIST.800-53.r5 SC-7(16), NIST.800-53.r5 SC-7(20), NIST.800-53.r5 SC-7(21), NIST.800-53.r5 SC-7(3), NIST.800-53.r5 SC-7(4), NIST.800-53.r5 SC-7(9), PCI DSS v4.0.1/1.4.4

**Category:** Protect > Secure network configuration > Resources within VPC 

**Severity:** Critical

**Resource type:** `AWS::Elasticsearch::Domain`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/elasticsearch-in-vpc-only.html](https://docs.aws.amazon.com/config/latest/developerguide/elasticsearch-in-vpc-only.html)

**Schedule type:** Periodic

**Parameters:** None

This control checks whether Elasticsearch domains are in a VPC. It does not evaluate the VPC subnet routing configuration to determine public access. You should ensure that Elasticsearch domains are not attached to public subnets. See [Resource-based policies](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/ac.html#ac-types-resource) in the *Amazon OpenSearch Service Developer Guide*. You should also ensure that your VPC is configured according to the recommended best practices. See [Security best practices for your VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-best-practices.html) in the *Amazon VPC User Guide*.

Elasticsearch domains deployed within a VPC can communicate with VPC resources over the private AWS network, without the need to traverse the public internet. This configuration increases the security posture by limiting access to the data in transit. VPCs provide a number of network controls to secure access to Elasticsearch domains, including network ACL and security groups. Security Hub CSPM recommends that you migrate public Elasticsearch domains to VPCs to take advantage of these controls.

### Remediation
<a name="es-2-remediation"></a>

If you create a domain with a public endpoint, you cannot later place it within a VPC. Instead, you must create a new domain and migrate your data. The reverse is also true. If you create a domain within a VPC, it cannot have a public endpoint. Instead, you must either [create another domain](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/createupdatedomains.html) or disable this control.

See [Launching your Amazon OpenSearch Service domains within a VPC](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/vpc.html) in the *Amazon OpenSearch Service Developer Guide*.

## [ES.3] Elasticsearch domains should encrypt data sent between nodes
<a name="es-3"></a>

**Related requirements:** NIST.800-53.r5 AC-4, NIST.800-53.r5 SC-13, NIST.800-53.r5 SC-23, NIST.800-53.r5 SC-23(3), NIST.800-53.r5 SC-7(4), NIST.800-53.r5 SC-8, NIST.800-53.r5 SC-8(1), NIST.800-53.r5 SC-8(2), PCI DSS v4.0.1/4.2.1

**Category:** Protect > Data Protection > Encryption of data-in-transit

**Severity:** Medium

**Resource type:** `AWS::Elasticsearch::Domain`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/elasticsearch-node-to-node-encryption-check.html](https://docs.aws.amazon.com/config/latest/developerguide/elasticsearch-node-to-node-encryption-check.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether an Elasticsearch domain has node-to-node encryption enabled. The control fails if the Elasticsearch domain doesn't have node-to-node encryption enabled. The control also produces failed findings if an Elasticsearch version doesn't support node-to-node encryption checks. 

HTTPS (TLS) can be used to help prevent potential attackers from eavesdropping on or manipulating network traffic using person-in-the-middle or similar attacks. Only encrypted connections over HTTPS (TLS) should be allowed. Enabling node-to-node encryption for Elasticsearch domains ensures that intra-cluster communications are encrypted in transit.

There can be a performance penalty associated with this configuration. You should be aware of and test the performance trade-off before enabling this option. 

### Remediation
<a name="es-3-remediation"></a>

For information about enabling node-to-node encryption on new and existing domains, see [Enabling node-to-node encryption](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/ntn.html#enabling-ntn) in the *Amazon OpenSearch Service Developer Guide*.

## [ES.4] Elasticsearch domain error logging to CloudWatch Logs should be enabled
<a name="es-4"></a>

**Related requirements:** NIST.800-53.r5 AC-2(4), NIST.800-53.r5 AC-4(26), NIST.800-53.r5 AC-6(9), NIST.800-53.r5 AU-10, NIST.800-53.r5 AU-12, NIST.800-53.r5 AU-2, NIST.800-53.r5 AU-3, NIST.800-53.r5 AU-6(3), NIST.800-53.r5 AU-6(4), NIST.800-53.r5 CA-7, NIST.800-53.r5 SC-7(9), NIST.800-53.r5 SI-3(8), NIST.800-53.r5 SI-4(20), NIST.800-53.r5 SI-7(8)

**Category:** Identify - Logging

**Severity:** Medium

**Resource type:** `AWS::Elasticsearch::Domain`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/elasticsearch-logs-to-cloudwatch.html](https://docs.aws.amazon.com/config/latest/developerguide/elasticsearch-logs-to-cloudwatch.html)

**Schedule type:** Change triggered

**Parameters:**
+ `logtype = 'error'` (not customizable)

This control checks whether Elasticsearch domains are configured to send error logs to CloudWatch Logs.

You should enable error logs for Elasticsearch domains and send those logs to CloudWatch Logs for retention and response. Domain error logs can assist with security and access audits, and can help to diagnose availability issues.

### Remediation
<a name="es-4-remediation"></a>

For information on how to enable log publishing, see [Enabling log publishing (console)](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/createdomain-configure-slow-logs.html#createdomain-configure-slow-logs-console) in the *Amazon OpenSearch Service Developer Guide*.

## [ES.5] Elasticsearch domains should have audit logging enabled
<a name="es-5"></a>

**Related requirements:** NIST.800-53.r5 AC-2(4), NIST.800-53.r5 AC-4(26), NIST.800-53.r5 AC-6(9), NIST.800-53.r5 AU-10, NIST.800-53.r5 AU-12, NIST.800-53.r5 AU-2, NIST.800-53.r5 AU-3, NIST.800-53.r5 AU-6(3), NIST.800-53.r5 AU-6(4), NIST.800-53.r5 CA-7, NIST.800-53.r5 SC-7(9), NIST.800-53.r5 SI-3(8), NIST.800-53.r5 SI-4(20), NIST.800-53.r5 SI-7(8), PCI DSS v4.0.1/10.4.2

**Category:** Identify > Logging

**Severity:** Medium

**Resource type:** `AWS::Elasticsearch::Domain`

**AWS Config rule:** `elasticsearch-audit-logging-enabled` (custom Security Hub CSPM rule)

**Schedule type:** Change triggered

**Parameters:**
+ `cloudWatchLogsLogGroupArnList` (not customizable). Security Hub CSPM does not populate this parameter. Comma-separated list of CloudWatch Logs log groups that should be configured for audit logs.

  This rule is `NON_COMPLIANT` if the CloudWatch Logs log group of the Elasticsearch domain is not specified in this parameter list.

This control checks whether Elasticsearch domains have audit logging enabled. This control fails if an Elasticsearch domain does not have audit logging enabled. 

Audit logs are highly customizable. They allow you to track user activity on your Elasticsearch clusters, including authentication successes and failures, requests to OpenSearch, index changes, and incoming search queries.

### Remediation
<a name="es-5-remediation"></a>

For detailed instructions on enabling audit logs, see [Enabling audit logs](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/audit-logs.html#audit-log-enabling) in the *Amazon OpenSearch Service Developer Guide*.

## [ES.6] Elasticsearch domains should have at least three data nodes
<a name="es-6"></a>

**Related requirements:** NIST.800-53.r5 CP-10, NIST.800-53.r5 CP-6(2), NIST.800-53.r5 SC-36, NIST.800-53.r5 SC-5(2), NIST.800-53.r5 SI-13(5)

**Category:** Recover > Resilience > High availability

**Severity:** Medium

**Resource type:** `AWS::Elasticsearch::Domain`

**AWS Config rule:** `elasticsearch-data-node-fault-tolerance` (custom Security Hub CSPM rule)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether Elasticsearch domains are configured with at least three data nodes and `zoneAwarenessEnabled` is `true`.

An Elasticsearch domain requires at least three data nodes for high availability and fault-tolerance. Deploying an Elasticsearch domain with at least three data nodes ensures cluster operations if a node fails.

### Remediation
<a name="es-6-remediation"></a>

**To modify the number of data nodes in an Elasticsearch domain**

1. Open the Amazon OpenSearch Service console at [https://console.aws.amazon.com/aos/](https://console.aws.amazon.com/aos/).

1. Under **Domains**, choose the name of the domain you want to edit.

1. Choose **Edit domain**.

1. Under **Data nodes**, set **Number of nodes** to a number greater than or equal to `3`.

   For three Availability Zone deployments, set to a multiple of three to ensure equal distribution across Availability Zones.

1. Choose **Submit**.

## [ES.7] Elasticsearch domains should be configured with at least three dedicated master nodes
<a name="es-7"></a>

**Related requirements:** NIST.800-53.r5 CP-10, NIST.800-53.r5 CP-6(2), NIST.800-53.r5 SC-36, NIST.800-53.r5 SC-5(2), NIST.800-53.r5 SI-13(5)

**Category:** Recover > Resilience > High availability

**Severity:** Medium

**Resource type:** `AWS::Elasticsearch::Domain`

**AWS Configrule:** `elasticsearch-primary-node-fault-tolerance` (custom Security Hub CSPM rule)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether Elasticsearch domains are configured with at least three dedicated primary nodes. This control fails if the domain does not use dedicated primary nodes. This control passes if Elasticsearch domains have five dedicated primary nodes. However, using more than three primary nodes might be unnecessary to mitigate the availability risk, and will result in additional cost.

An Elasticsearch domain requires at least three dedicated primary nodes for high availability and fault-tolerance. Dedicated primary node resources can be strained during data node blue/green deployments because there are additional nodes to manage. Deploying an Elasticsearch domain with at least three dedicated primary nodes ensures sufficient primary node resource capacity and cluster operations if a node fails.

### Remediation
<a name="es-7-remediation"></a>

**To modify the number of dedicated primary nodes in an OpenSearch domain**

1. Open the Amazon OpenSearch Service console at [https://console.aws.amazon.com/aos/](https://console.aws.amazon.com/aos/).

1. Under **Domains**, choose the name of the domain you want to edit.

1. Choose **Edit domain**.

1. Under **Dedicated master nodes**, set **Instance type** to the desired instance type.

1. Set **Number of master nodes** equal to three or greater.

1. Choose **Submit**.

## [ES.8] Connections to Elasticsearch domains should be encrypted using the latest TLS security policy
<a name="es-8"></a>

**Related requirements:** NIST.800-53.r5 AC-17(2), NIST.800-53.r5 AC-4, NIST.800-53.r5 IA-5(1), NIST.800-53.r5 SC-12(3), NIST.800-53.r5 SC-13, NIST.800-53.r5 SC-23, NIST.800-53.r5 SC-23(3), NIST.800-53.r5 SC-7(4), NIST.800-53.r5 SC-8, NIST.800-53.r5 SC-8(1), NIST.800-53.r5 SC-8(2), NIST.800-53.r5 SI-7(6), PCI DSS v4.0.1/4.2.1

**Category:** Protect > Data Protection > Encryption of data-in-transit

**Severity:** Medium

**Resource type:** `AWS::Elasticsearch::Domain`

**AWS Config rule:** `elasticsearch-https-required` (custom Security Hub CSPM rule)

**Schedule type:** Change triggered

**Parameters:** None

This controls checks whether an Elasticsearch domain endpoint is configured to use the latest TLS security policy. The control fails if the Elasticsearch domain endpoint isn't configured to use the latest supported policy or if HTTPs isn't enabled. The current latest supported TLS security policy is `Policy-Min-TLS-1-2-PFS-2023-10`.

HTTPS (TLS) can be used to help prevent potential attackers from using person-in-the-middle or similar attacks to eavesdrop on or manipulate network traffic. Only encrypted connections over HTTPS (TLS) should be allowed. Encrypting data in transit can affect performance. You should test your application with this feature to understand the performance profile and the impact of TLS. TLS 1.2 provides several security enhancements over previous versions of TLS.

### Remediation
<a name="es-8-remediation"></a>

To enable TLS encryption, use the [https://docs.aws.amazon.com/opensearch-service/latest/APIReference/API_UpdateDomainConfig.html](https://docs.aws.amazon.com/opensearch-service/latest/APIReference/API_UpdateDomainConfig.html) API operation to configure the [https://docs.aws.amazon.com/opensearch-service/latest/APIReference/API_DomainEndpointOptions.html](https://docs.aws.amazon.com/opensearch-service/latest/APIReference/API_DomainEndpointOptions.html) object. This sets the `TLSSecurityPolicy`.

## [ES.9] Elasticsearch domains should be tagged
<a name="es-9"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::Elasticsearch::Domain`

**AWS Config rule:** `tagged-elasticsearch-domain` (custom Security Hub CSPM rule)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  |  No default value  | 

This control checks whether an Elasticsearch domain has tags with the specific keys defined in the parameter `requiredTagKeys`. The control fails if the domain doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredTagKeys`. If the parameter `requiredTagKeys` isn't provided, the control only checks for the existence of a tag key and fails if the domain isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [What is ABAC for AWS?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Tagging your AWS resources](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *AWS General Reference*.

### Remediation
<a name="es-9-remediation"></a>

To add tags to an Elasticsearch domain, see [Working with tags](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/managedomains-awsresourcetagging.html#managedomains-awsresourcetagging-console) in the *Amazon OpenSearch Service Developer Guide*.

# Security Hub CSPM controls for Amazon EMR
<a name="emr-controls"></a>

These AWS Security Hub CSPM controls evaluate the Amazon EMR (previously called Amazon Elastic MapReduce) service and resources. The controls might not be available in all AWS Regions. For more information, see [Availability of controls by Region](securityhub-regions.md#securityhub-regions-control-support).

## [EMR.1] Amazon EMR cluster primary nodes should not have public IP addresses
<a name="emr-1"></a>

**Related requirements:** PCI DSS v3.2.1/1.2.1,PCI DSS v3.2.1/1.3.1,PCI DSS v3.2.1/1.3.2,PCI DSS v3.2.1/1.3.4,PCI DSS v3.2.1/1.3.6, PCI DSS v4.0.1/1.4.4, NIST.800-53.r5 AC-21, NIST.800-53.r5 AC-3, NIST.800-53.r5 AC-3(7), NIST.800-53.r5 AC-4, NIST.800-53.r5 AC-4(21), NIST.800-53.r5 AC-6, NIST.800-53.r5 SC-7, NIST.800-53.r5 SC-7(11), NIST.800-53.r5 SC-7(16), NIST.800-53.r5 SC-7(20), NIST.800-53.r5 SC-7(21), NIST.800-53.r5 SC-7(3), NIST.800-53.r5 SC-7(4), NIST.800-53.r5 SC-7(9)

**Category:** Protect > Secure network configuration

**Severity:** High

**Resource type:** `AWS::EMR::Cluster`

**AWS Config rule:** [emr-master-no-public-ip](https://docs.aws.amazon.com/config/latest/developerguide/emr-master-no-public-ip.html)

**Schedule type:** Periodic

**Parameters:** None

This control checks whether master nodes on Amazon EMR clusters have public IP addresses. The control fails if public IP addresses are associated with any of the master node instances.

Public IP addresses are designated in the `PublicIp` field of the `NetworkInterfaces` configuration for the instance. This control only checks Amazon EMR clusters that are in a `RUNNING` or `WAITING` state.

### Remediation
<a name="emr-1-remediation"></a>

During launch, you can control whether your instance in a default or nondefault subnet is assigned a public IPv4 address. By default, default subnets have this attribute set to `true`. Nondefault subnets have the IPv4 public addressing attribute set to `false`, unless it was created by the Amazon EC2 launch instance wizard. In that case, the attribute is set to `true`.

After launch, you can't manually disassociate a public IPv4 address from your instance.

To remediate a failed finding, you must launch a new cluster in a VPC with a private subnet that has the IPv4 public addressing attribute set to `false`. For instructions, see [Launch clusters into a VPC](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-vpc-launching-job-flows.html) in the *Amazon EMR Management Guide*.

## [EMR.2] Amazon EMR block public access setting should be enabled
<a name="emr-2"></a>

**Related requirements:** PCI DSS v4.0.1/1.4.4, NIST.800-53.r5 AC-21, NIST.800-53.r5 AC-3, NIST.800-53.r5 AC-3(7), NIST.800-53.r5 AC-4, NIST.800-53.r5 AC-4(21), NIST.800-53.r5 AC-6, NIST.800-53.r5 SC-7, NIST.800-53.r5 SC-7(11), NIST.800-53.r5 SC-7(16), NIST.800-53.r5 SC-7(20), NIST.800-53.r5 SC-7(21), NIST.800-53.r5 SC-7(3), NIST.800-53.r5 SC-7(4), NIST.800-53.r5 SC-7(9)

**Category:** Protect > Secure access management > Resource not publicly accessible

**Severity:** Critical

**Resource type:** `AWS::::Account`

**AWS Config rule:** [emr-block-public-access](https://docs.aws.amazon.com/config/latest/developerguide/emr-block-public-access.html)

**Schedule type:** Periodic

**Parameters:** None

This control checks whether your account is configured with Amazon EMR block public access. The control fails if the block public access setting isn't enabled or if any port other than port 22 is allowed.

Amazon EMR block public access prevents you from launching a cluster in a public subnet if the cluster has a security configuration that allows inbound traffic from public IP addresses on a port. When a user from your AWS account launches a cluster, Amazon EMR checks the port rules in the security group for the cluster and compares them with your inbound traffic rules. If the security group has an inbound rule that opens ports to the public IP addresses IPv4 0.0.0.0/0 or IPv6 ::/0, and those ports aren't specified as exceptions for your account, Amazon EMR doesn't let the user create the cluster.

**Note**  
Block public access is enabled by default. To increase account protection, we recommend that you keep it enabled.

### Remediation
<a name="emr-2-remediation"></a>

To configure block public access for Amazon EMR, see [Using Amazon EMR block public access](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-block-public-access.html) in the *Amazon EMR Management Guide*.

## [EMR.3] Amazon EMR security configurations should be encrypted at rest
<a name="emr-3"></a>

**Related requirements:** NIST.800-53.r5 CA-9(1), NIST.800-53.r5 CP-9(8), NIST.800-53.r5 SI-12

**Category:** Protect > Data Protection > Encryption of data-at-rest

**Severity:** Medium

**Resource type:** `AWS::EMR::SecurityConfiguration`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/emr-security-configuration-encryption-rest.html](https://docs.aws.amazon.com/config/latest/developerguide/emr-security-configuration-encryption-rest.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether an Amazon EMR security configuration has encryption at rest enabled. The control fails if the security configuration doesn't enable encryption at rest.

Data at rest refers to data that's stored in persistent, non-volatile storage for any duration. Encrypting data at rest helps you protect its confidentiality, which reduces the risk that an unauthorized user can access it.

### Remediation
<a name="emr-3-remediation"></a>

To enable encryption at rest in an Amazon EMR security configuration, see [Configure data encryption](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-create-security-configuration.html#emr-security-configuration-encryption.html) in the *Amazon EMR Management Guide*.

## [EMR.4] Amazon EMR security configurations should be encrypted in transit
<a name="emr-4"></a>

**Related requirements:** NIST.800-53.r5 AC-4, NIST.800-53.r5 SC-7(4), NIST.800-53.r5 SC-8, NIST.800-53.r5 SC-8(1), NIST.800-53.r5 SC-8(2), NIST.800-53.r5 SC-13, NIST.800-53.r5 SC-23, NIST.800-53.r5 SC-23(3)

**Category:** Protect > Data Protection > Encryption of data-in-transit

**Severity:** Medium

**Resource type:** `AWS::EMR::SecurityConfiguration`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/emr-security-configuration-encryption-transit.html](https://docs.aws.amazon.com/config/latest/developerguide/emr-security-configuration-encryption-transit.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether an Amazon EMR security configuration has encryption in transit enabled. The control fails if the security configuration doesn't enable encryption in transit.

Data in transit refers to data that moves from one location to another, such as between nodes in your cluster or between your cluster and your application. Data may move across the internet or within a private network. Encrypting data in transit reduces the risk that an unauthorized user can eavesdrop on network traffic.

### Remediation
<a name="emr-4-remediation"></a>

To enable encryption in transit in an Amazon EMR security configuration, see [Configure data encryption](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-create-security-configuration.html#emr-security-configuration-encryption.html) in the *Amazon EMR Management Guide*.

# Security Hub CSPM controls for EventBridge
<a name="eventbridge-controls"></a>

These AWS Security Hub CSPM controls evaluate the Amazon EventBridge service and resources.

These controls may not be available in all AWS Regions. For more information, see [Availability of controls by Region](securityhub-regions.md#securityhub-regions-control-support).

## [EventBridge.2] EventBridge event buses should be tagged
<a name="eventbridge-2"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::Events::EventBus`

**AWS Config rule:**`tagged-events-eventbus` (custom Security Hub CSPM rule)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  | No default value  | 

This control checks whether an Amazon EventBridge event bus has tags with the specific keys defined in the parameter `requiredTagKeys`. The control fails if the event bus doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredTagKeys`. If the parameter `requiredTagKeys` isn't provided, the control only checks for the existence of a tag key and fails if the event bus isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [What is ABAC for AWS?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Tagging your AWS resources](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *AWS General Reference*.

### Remediation
<a name="eventbridge-2-remediation"></a>

To add tags to an EventBridge event bus, see [Amazon EventBridge tags](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-tagging.html) in the *Amazon EventBridge User Guide*.

## [EventBridge.3] EventBridge custom event buses should have a resource-based policy attached
<a name="eventbridge-3"></a>

**Related requirements:** NIST.800-53.r5 AC-2, NIST.800-53.r5 AC-2(1), NIST.800-53.r5 AC-3, NIST.800-53.r5 AC-3(15), NIST.800-53.r5 AC-3(7), NIST.800-53.r5 AC-5, NIST.800-53.r5 AC-6, NIST.800-53.r5 AC-6(3), PCI DSS v4.0.1/10.3.1

**Category:** Protect > Secure access management > Resource not publicly accessible

**Severity:** Low

**Resource type:** `AWS::Events::EventBus`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/custom-eventbus-policy-attached.html](https://docs.aws.amazon.com/config/latest/developerguide/custom-eventbus-policy-attached.html) 

**Schedule type:** Change triggered

**Parameters:** None

This control checks if an Amazon EventBridge custom event bus has a resource-based policy attached. This control fails if the custom event bus doesn't have a resource-based policy.

By default, an EventBridge custom event bus doesn't have a resource-based policy attached. This allows principals in the account to access the event bus. By attaching a resource-based policy to the event bus, you can limit access to the event bus to specified accounts, as well as intentionally grant access to entities in another account.

### Remediation
<a name="eventbridge-3-remediation"></a>

To attach a resource-based policy to an EventBridge custom event bus, see [Using resource-based policies for Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-use-resource-based.html) in the *Amazon EventBridge User Guide*.

## [EventBridge.4] EventBridge global endpoints should have event replication enabled
<a name="eventbridge-4"></a>

**Related requirements:** NIST.800-53.r5 CP-10, NIST.800-53.r5 CP-6(2), NIST.800-53.r5 SC-36, NIST.800-53.r5 SC-5(2), NIST.800-53.r5 SI-13(5)

**Category:** Recover > Resilience > High availability

**Severity:** Medium

**Resource type:** `AWS::Events::Endpoint`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/global-endpoint-event-replication-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/global-endpoint-event-replication-enabled.html) 

**Schedule type:** Change triggered

**Parameters:** None

This control checks if event replication is enabled for an Amazon EventBridge global endpoint. The control fails if event replication isn't enabled for a global endpoint.

Global endpoints help make your application Regional-fault tolerant. To start, you assign an Amazon Route 53 health check to the endpoint. When failover is initiated, the health check reports an "unhealthy" state. Within minutes of failover initiation, all custom events are routed to an event bus in the secondary Region and are processed by that event bus. When you use global endpoints, you can enable event replication. Event replication sends all custom events to the event buses in the primary and secondary Regions using managed rules. We recommend enabling event replication when setting up global endpoints. Event replication helps you verify that your global endpoints are configured correctly. Event replication is required to automatically recover from a failover event. If you don’t have event replication enabled, you’ll have to manually reset the Route 53 health check to "healthy" before events are rerouted back to the primary Region.

**Note**  
If you're using custom event buses, you'll need a custom even bus in each Region with the same name and in the same account for failover to work properly. Enabling event replication can increase your monthly cost. For information about pricing, see [Amazon EventBridge pricing](https://aws.amazon.com/eventbridge/pricing/).

### Remediation
<a name="eventbridge-4-remediation"></a>

To enable event replication for EventBridge global endpoints, see [Create a global endpoint](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-global-endpoints.html#eb-ge-create-endpoint) in the *Amazon EventBridge User Guide*. For **Event replication**, select **Event replication enabled**.

# Security Hub CSPM controls for Amazon Fraud Detector
<a name="frauddetector-controls"></a>

These Security Hub CSPM controls evaluate the Amazon Fraud Detector service and resources.

These controls may not be available in all AWS Regions. For more information, see [Availability of controls by Region](securityhub-regions.md#securityhub-regions-control-support).

## [FraudDetector.1] Amazon Fraud Detector entity types should be tagged
<a name="frauddetector-1"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::FraudDetector::EntityType`

**AWS Config rule:** `frauddetector-entity-type-tagged`

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredKeyTags  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  | No default value  | 

This control checks whether an Amazon Fraud Detector entity type has tags with the specific keys defined in the parameter `requiredKeyTags`. The control fails if the entity type doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredKeyTags`. If the parameter `requiredKeyTags` isn't provided, the control only checks for the existence of a tag key and fails if the entity type isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [Define permissions based on attributes with ABAC authorization](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Best practices and strategies](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *Tagging AWS Resources and Tag Editor User Guide*.

### Remediation
<a name="frauddetector-1-remediation"></a>

**To add tags to an Amazon Fraud Detector entity type (console)**

1. Open the Amazon Fraud Detector console at [https://console.aws.amazon.com/frauddetector](https://console.aws.amazon.com/frauddetector/).

1. In the navigation pane, choose **Entities**.

1. Select an entity type from the list.

1. In the **entity type tags** section, choose **Manage tags**.

1. Choose **Add new tag**. Enter the key and value for the tag. Repeat for additional key-value pairs.

1. When you are finished adding tags, choose **Save**.

## [FraudDetector.2] Amazon Fraud Detector labels should be tagged
<a name="frauddetector-2"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::FraudDetector::Label`

**AWS Config rule:** `frauddetector-label-tagged`

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredKeyTags  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  | No default value  | 

This control checks whether an Amazon Fraud Detector label has tags with the specific keys defined in the parameter `requiredKeyTags`. The control fails if the label doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredKeyTags`. If the parameter `requiredKeyTags` isn't provided, the control only checks for the existence of a tag key and fails if the label isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [Define permissions based on attributes with ABAC authorization](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Best practices and strategies](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *Tagging AWS Resources and Tag Editor User Guide*.

### Remediation
<a name="frauddetector-2-remediation"></a>

**To add tags to an Amazon Fraud Detector label (console)**

1. Open the Amazon Fraud Detector console at [https://console.aws.amazon.com/frauddetector](https://console.aws.amazon.com/frauddetector/).

1. In the navigation pane, choose **Labels**.

1. Select a label from the list.

1. In the **labels tags** section, choose **Manage tags**.

1. Choose **Add new tag**. Enter the key and value for the tag. Repeat for additional key-value pairs.

1. When you are finished adding tags, choose **Save**.

## [FraudDetector.3] Amazon Fraud Detector outcomes should be tagged
<a name="frauddetector-3"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::FraudDetector::Outcome`

**AWS Config rule:** `frauddetector-outcome-tagged`

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredKeyTags  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  | No default value  | 

This control checks whether an Amazon Fraud Detector outcome has tags with the specific keys defined in the parameter `requiredKeyTags`. The control fails if the outcome doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredKeyTags`. If the parameter `requiredKeyTags` isn't provided, the control only checks for the existence of a tag key and fails if the outcome isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [Define permissions based on attributes with ABAC authorization](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Best practices and strategies](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *Tagging AWS Resources and Tag Editor User Guide*.

### Remediation
<a name="frauddetector-3-remediation"></a>

**To add tags to an Amazon Fraud Detector outcome (console)**

1. Open the Amazon Fraud Detector console at [https://console.aws.amazon.com/frauddetector](https://console.aws.amazon.com/frauddetector/).

1. In the navigation pane, choose **Outcomes**.

1. Select an outcome from the list.

1. In the **outcomes tags** section, choose **Manage tags**.

1. Choose **Add new tag**. Enter the key and value for the tag. Repeat for additional key-value pairs.

1. When you are finished adding tags, choose **Save**.

## [FraudDetector.4] Amazon Fraud Detector variables should be tagged
<a name="frauddetector-4"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::FraudDetector::Variable`

**AWS Config rule:** `frauddetector-variable-tagged`

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredKeyTags  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  | No default value  | 

This control checks whether an Amazon Fraud Detector variable has tags with the specific keys defined in the parameter `requiredKeyTags`. The control fails if the variable doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredKeyTags`. If the parameter `requiredKeyTags` isn't provided, the control only checks for the existence of a tag key and fails if the variable isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [Define permissions based on attributes with ABAC authorization](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Best practices and strategies](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *Tagging AWS Resources and Tag Editor User Guide*.

### Remediation
<a name="frauddetector-4-remediation"></a>

**To add tags to an Amazon Fraud Detector variable (console)**

1. Open the Amazon Fraud Detector console at [https://console.aws.amazon.com/frauddetector](https://console.aws.amazon.com/frauddetector/).

1. In the navigation pane, choose **Variables**.

1. Select a variable from the list.

1. In the **variables tags** section, choose **Manage tags**.

1. Choose **Add new tag**. Enter the key and value for the tag. Repeat for additional key-value pairs.

1. When you are finished adding tags, choose **Save**.

# Security Hub CSPM controls for Amazon FSx
<a name="fsx-controls"></a>

These AWS Security Hub CSPM controls evaluate the Amazon FSx service and resources. The controls might not be available in all AWS Regions. For more information, see [Availability of controls by Region](securityhub-regions.md#securityhub-regions-control-support).

## [FSx.1] FSx for OpenZFS file systems should be configured to copy tags to backups and volumes
<a name="fsx-1"></a>

**Related requirements:** NIST.800-53.r5 CA-9(1), NIST.800-53.r5 CM-2, NIST.800-53.r5 CM-2(2)

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::FSx::FileSystem`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/fsx-openzfs-copy-tags-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/fsx-openzfs-copy-tags-enabled.html)

**Schedule type:** Periodic

**Parameters:** None

This control checks whether an Amazon FSx for OpenZFS file system is configured to copy tags to backups and volumes. The control fails if the OpenZFS file system isn't configured to copy tags to backups and volumes.

Identification and inventory of your IT assets is an important aspect of governance and security. Tags help you categorize your AWS resources in different ways, for example, by purpose, owner, or environment. This is useful when you have many resources of the same type because you can quickly identify a specific resource based on the tags that you assigned to it.

### Remediation
<a name="fsx-1-remediation"></a>

For information about configuring an FSx for OpenZFS file system to copy tags to backups and volumes, see [Updating a file system](https://docs.aws.amazon.com/fsx/latest/OpenZFSGuide/updating-file-system.html) in the *Amazon FSx for OpenZFS User Guide*.

## [FSx.2] FSx for Lustre file systems should be configured to copy tags to backups
<a name="fsx-2"></a>

**Related requirements:** NIST.800-53.r5 CP-9, NIST.800-53.r5 CM-8

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::FSx::FileSystem`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/fsx-lustre-copy-tags-to-backups.html](https://docs.aws.amazon.com/config/latest/developerguide/fsx-lustre-copy-tags-to-backups.html)

**Schedule type:** Periodic

**Parameters:** None

This control checks whether an Amazon FSx for Lustre file system is configured to copy tags to backups and volumes. The control fails if the Lustre file system isn't configured to copy tags to backups and volumes.

Identification and inventory of your IT assets is an important aspect of governance and security. Tags help you categorize your AWS resources in different ways, for example, by purpose, owner, or environment. This is useful when you have many resources of the same type because you can quickly identify a specific resource based on the tags that you assigned to it.

### Remediation
<a name="fsx-2-remediation"></a>

For information about configuring an FSx for Lustre file system to copy tags to backups, see [Copying backups within the same AWS account](https://docs.aws.amazon.com/fsx/latest/LustreGuide/copying-backups-same-account.html) in the *Amazon FSx for Lustre User Guide*.

## [FSx.3] FSx for OpenZFS file systems should be configured for Multi-AZ deployment
<a name="fsx-3"></a>

**Category:** Recover > Resilience > High availability

**Severity:** Medium

**Resource type:** `AWS::FSx::FileSystem`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/fsx-openzfs-deployment-type-check.html](https://docs.aws.amazon.com/config/latest/developerguide/fsx-openzfs-deployment-type-check.html)

**Schedule type:** Periodic

**Parameters:** `deploymentTypes: MULTI_AZ_1` (not customizable)

This control checks whether an Amazon FSx for OpenZFS file system is configured to use the multiple Availability Zones (Multi-AZ) deployment type. The control fails if the file system isn't configured to use the Multi-AZ deployment type.

Amazon FSx for OpenZFS supports several deployment types for file systems: *Multi-AZ (HA)*, *Single-AZ (HA)*, and *Single-AZ (non-HA)*. The deployment types offer different levels of availability and durability. Multi-AZ (HA) file systems are composed of a high-availability (HA) pair of file servers that are spread across two Availability Zones (AZs). We recommend using the Multi-AZ (HA) deployment type for most production workloads due to the high availability and durability model that it provides.

### Remediation
<a name="fsx-3-remediation"></a>

You can configure an Amazon FSx for OpenZFS file system to use the Multi-AZ deployment type when you create the file system. You can't change the deployment type for an existing FSx for OpenZFS file system.

For information about deployment types and options for FSx for OpenZFS file systems, see [Availability and durability for Amazon FSx for OpenZFS](https://docs.aws.amazon.com/fsx/latest/OpenZFSGuide/availability-durability.html) and [Managing file system resources](https://docs.aws.amazon.com/fsx/latest/OpenZFSGuide/managing-file-systems.html) in the *Amazon FSx for OpenZFS User Guide*.

## [FSx.4] FSx for NetApp ONTAP file systems should be configured for Multi-AZ deployment
<a name="fsx-4"></a>

**Category:** Recover > Resilience > High availability

**Severity:** Medium

**Resource type:** `AWS::FSx::FileSystem`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/fsx-ontap-deployment-type-check.html](https://docs.aws.amazon.com/config/latest/developerguide/fsx-ontap-deployment-type-check.html)

**Schedule type:** Periodic

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  `deploymentTypes`  |  A list of deployment types to include in the evaluation. The control generates a `FAILED` finding if a file system isn't configured to use a deployment type specified in the list.  |  Enum  |  `MULTI_AZ_1`, `MULTI_AZ_2`  |  `MULTI_AZ_1`, `MULTI_AZ_2`  | 

This control checks whether an Amazon FSx for NetApp ONTAP file system is configured to use a multiple Availability Zones (Multi-AZ) deployment type. The control fails if the file system isn't configured to use a Multi-AZ deployment type. You can optionally specify a list of deployment types to include in the evaluation.

Amazon FSx for NetApp ONTAP supports several deployment types for file systems: *Single-AZ 1*, *Single-AZ 2*, *Multi-AZ 1*, and *Multi-AZ 2*. The deployment types offer different levels of availability and durability. We recommend using a Multi-AZ deployment type for most production workloads due to the high availability and durability model that Multi-AZ deployment types provide. Multi-AZ file systems support all the availability and durability features of Single-AZ file systems. In addition, they're designed to provide continuous availability to data even when an Availability Zone (AZ) is unavailable.

### Remediation
<a name="fsx-4-remediation"></a>

You can't change the deployment type for an existing Amazon FSx for NetApp ONTAP file system. However, you can back up the data, and then restore it on a new file system that uses a Multi-AZ deployment type.

For information about deployment types and options for FSx for ONTAP file systems, see [Availability, durability, and deployment options](https://docs.aws.amazon.com/fsx/latest/ONTAPGuide/high-availability-AZ.html) and [Managing file systems](https://docs.aws.amazon.com/fsx/latest/ONTAPGuide/managing-file-systems.html) in the *FSx for ONTAP User Guide*. 

## [FSx.5] FSx for Windows File Server file systems should be configured for Multi-AZ deployment
<a name="fsx-5"></a>

**Category:** Recover > Resilience > High availability

**Severity:** Medium

**Resource type:** `AWS::FSx::FileSystem`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/fsx-windows-deployment-type-check.html](https://docs.aws.amazon.com/config/latest/developerguide/fsx-windows-deployment-type-check.html)

**Schedule type:** Periodic

**Parameters:** `deploymentTypes: MULTI_AZ_1` (not customizable)

This control checks whether an Amazon FSx for Windows File Server file system is configured to use the multiple Availability Zones (Multi-AZ) deployment type. The control fails if the file system isn't configured to use the Multi-AZ deployment type.

Amazon FSx for Windows File Server supports two deployment types for file systems: *Single-AZ* and *Multi-AZ*. The deployment types offer different levels of availability and durability. Single-AZ file systems are composed of a single Windows file server instance and a set of storage volumes within a single Availability Zone (AZ). Multi-AZ file systems are composed of a high-availability cluster of Windows file servers spread across two Availability Zones. We recommend using the Multi-AZ deployment type for most production workloads due to the high availability and durability model that it provides.

### Remediation
<a name="fsx-5-remediation"></a>

You can configure an Amazon FSx for Windows File Server file system to use the Multi-AZ deployment type when you create the file system. You can't change the deployment type for an existing FSx for Windows File Server file system.

For information about deployment types and options for FSx for Windows File Server file systems, see [Availability and durability: Single-AZ and Multi-AZ file systems](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/high-availability-multiAZ.html) and [Getting started with Amazon FSx for Windows File Server](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/getting-started.html) in the *Amazon FSx for Windows File Server User Guide*. 

# Security Hub CSPM controls for Global Accelerator
<a name="globalaccelerator-controls"></a>

These AWS Security Hub CSPM controls evaluate the AWS Global Accelerator service and resources.

These controls may not be available in all AWS Regions. For more information, see [Availability of controls by Region](securityhub-regions.md#securityhub-regions-control-support).

## [GlobalAccelerator.1] Global Accelerator accelerators should be tagged
<a name="globalaccelerator-1"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::GlobalAccelerator::Accelerator`

**AWS Config rule:** `tagged-globalaccelerator-accelerator` (custom Security Hub CSPM rule)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  |  No default value  | 

This control checks whether an AWS Global Accelerator accelerator has tags with the specific keys defined in the parameter `requiredTagKeys`. The control fails if the accelerator doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredTagKeys`. If the parameter `requiredTagKeys` isn't provided, the control only checks for the existence of a tag key and fails if the accelerator isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [What is ABAC for AWS?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Tagging your AWS resources](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *AWS General Reference*.

### Remediation
<a name="globalaccelerator-1-remediation"></a>

To add tags to an Global Accelerator global accelerator, see see [Tagging in AWS Global Accelerator](https://docs.aws.amazon.com/global-accelerator/latest/dg/tagging-in-global-accelerator.html) in the *AWS Global Accelerator Developer Guide*.

# Security Hub CSPM controls for AWS Glue
<a name="glue-controls"></a>

These AWS Security Hub CSPM controls evaluate the AWS Glue service and resources. The controls might not be available in all AWS Regions. For more information, see [Availability of controls by Region](securityhub-regions.md#securityhub-regions-control-support).

## [Glue.1] AWS Glue jobs should be tagged
<a name="glue-1"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::Glue::Job`

**AWS Config rule:** `tagged-glue-job` (custom Security Hub CSPM rule)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  | No default value  | 

This control checks whether an AWS Glue job has tags with the specific keys defined in the parameter `requiredTagKeys`. The control fails if the job doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredTagKeys`. If the parameter `requiredTagKeys` isn't provided, the control only checks for the existence of a tag key and fails if the job isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [What is ABAC for AWS?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Tagging your AWS resources](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *AWS General Reference*.

### Remediation
<a name="glue-1-remediation"></a>

To add tags to a AWS Glue job, see [AWS tags in AWS Glue](https://docs.aws.amazon.com/glue/latest/dg/monitor-tags.html) in the *AWS Glue User Guide*.

## [Glue.3] AWS Glue machine learning transforms should be encrypted at rest
<a name="glue-3"></a>

**Category:** Protect > Data Protection > Encryption of data-at-rest

**Severity:** Medium

**Resource type:** `AWS::Glue::MLTransform`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/glue-ml-transform-encrypted-at-rest.html](https://docs.aws.amazon.com/config/latest/developerguide/glue-ml-transform-encrypted-at-rest.html)

**Schedule type:** Change triggered

**Parameters:** No

This control checks whether an AWS Glue machine learning transform is encrypted at rest. The control fails if the machine learning transform isn't encrypted at rest.

Data at rest refers to data that's stored in persistent, non-volatile storage for any duration. Encrypting data at rest helps you protect its confidentiality, which reduces the risk that an unauthorized user can access it.

### Remediation
<a name="glue-3-remediation"></a>

To configure encryption for AWS Glue machine learning transforms, see [Working with machine learning transforms](https://docs.aws.amazon.com/glue/latest/dg/console-machine-learning-transforms.html) in the *AWS Glue User Guide*.

## [Glue.4] AWS Glue Spark jobs should run on supported versions of AWS Glue
<a name="glue-4"></a>

**Related requirements:** NIST.800-53.r5 CA-9(1), NIST.800-53.r5 CM-2, NIST.800-53.r5 SI-2, NIST.800-53.r5 SI-2(2), NIST.800-53.r5 SI-2(4), NIST.800-53.r5 SI-2(5)

**Category:** Identify > Vulnerability, patch, and version management

**Severity:** Medium

**Resource type:** `AWS::Glue::Job`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/glue-spark-job-supported-version.html](https://docs.aws.amazon.com/config/latest/developerguide/glue-spark-job-supported-version.html)

**Schedule type:** Change triggered

**Parameters:** `minimumSupportedGlueVersion`: `3.0` (not customizable)

This control checks whether an AWS Glue for Spark job is configured to run on a supported version of AWS Glue. The control fails if the Spark job is configured to run on a version of AWS Glue that's earlier than the minimum supported version.

**Note**  
This control also generates a `FAILED` finding for an AWS Glue for Spark job if the AWS Glue version (`GlueVersion`) property doesn’t exist or is null in the configuration item (CI) for the job. In such cases, the finding includes the following annotation: `GlueVersion is null or missing in glueetl job configuration`. To address this type of `FAILED` finding, add the `GlueVersion` property to the job’s configuration. For a list of supported versions and runtime environments, see [AWS Glue Versions](https://docs.aws.amazon.com/glue/latest/dg/release-notes.html#release-notes-versions) in the *AWS Glue User Guide*.

Running AWS Glue Spark jobs on current versions of AWS Glue can optimize performance, security, and access to the latest features of AWS Glue. It can also help safeguard against security vulnerabilities. For example, a new version might be released to provide security updates, address issues, or introduce new features.

### Remediation
<a name="glue-4-remediation"></a>

For information about migrating a Spark job to a supported version of AWS Glue, see [Migrating AWS Glue for Spark jobs](https://docs.aws.amazon.com/glue/latest/dg/migrating-version-40.html) in the *AWS Glue User Guide*.

# Security Hub CSPM controls for Amazon GuardDuty
<a name="guardduty-controls"></a>

These AWS Security Hub CSPM controls evaluate the Amazon GuardDuty service and resources. The controls might not be available in all AWS Regions. For more information, see [Availability of controls by Region](securityhub-regions.md#securityhub-regions-control-support).

## [GuardDuty.1] GuardDuty should be enabled
<a name="guardduty-1"></a>

**Related requirements:** NIST.800-53.r5 AC-2(12), NIST.800-53.r5 AU-6(1), NIST.800-53.r5 AU-6(5), NIST.800-53.r5 CA-7, NIST.800-53.r5 CM-8(3), NIST.800-53.r5 RA-3(4), NIST.800-53.r5 SA-11(1), NIST.800-53.r5 SA-11(6), NIST.800-53.r5 SA-15(2), NIST.800-53.r5 SA-15(8), NIST.800-53.r5 SA-8(19), NIST.800-53.r5 SA-8(21), NIST.800-53.r5 SA-8(25), NIST.800-53.r5 SC-5, NIST.800-53.r5 SC-5(1), NIST.800-53.r5 SC-5(3), NIST.800-53.r5 SI-20, NIST.800-53.r5 SI-3(8), NIST.800-53.r5 SI-4, NIST.800-53.r5 SI-4(1), NIST.800-53.r5 SI-4(13), NIST.800-53.r5 SI-4(2), NIST.800-53.r5 SI-4(22), NIST.800-53.r5 SI-4(25), NIST.800-53.r5 SI-4(4), NIST.800-53.r5 SI-4(5), NIST.800-171.r2 3.4.2, NIST.800-171.r2 3.14.6, NIST.800-171.r2 3.14.7, PCI DSS v3.2.1/11.4, PCI DSS v4.0.1/11.5.1

**Category:** Detect > Detection services

**Severity:** High

**Resource type:** `AWS::::Account`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/guardduty-enabled-centralized.html](https://docs.aws.amazon.com/config/latest/developerguide/guardduty-enabled-centralized.html)

**Schedule type:** Periodic

**Parameters:** None

This control checks whether Amazon GuardDuty is enabled in your GuardDuty account and Region.

It is highly recommended that you enable GuardDuty in all supported AWS Regions. Doing so allows GuardDuty to generate findings about unauthorized or unusual activity, even in Regions that you do not actively use. This also allows GuardDuty to monitor CloudTrail events for global AWS services such as IAM.

### Remediation
<a name="guardduty-1-remediation"></a>

To enable GuardDuty, see [Getting started with GuardDuty](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_settingup.html) in the *Amazon GuardDuty User Guide*.

## [GuardDuty.2] GuardDuty filters should be tagged
<a name="guardduty-2"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::GuardDuty::Filter`

**AWS Config rule:** `tagged-guardduty-filter` (custom Security Hub CSPM rule)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  |  No default value  | 

This control checks whether an Amazon GuardDuty filter has tags with the specific keys defined in the parameter `requiredTagKeys`. The control fails if the filter doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredTagKeys`. If the parameter `requiredTagKeys` isn't provided, the control only checks for the existence of a tag key and fails if the filter isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [What is ABAC for AWS?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Tagging your AWS resources](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *AWS General Reference*.

### Remediation
<a name="guardduty-2-remediation"></a>

To add tags to a GuardDuty filter, see [https://docs.aws.amazon.com/guardduty/latest/APIReference/API_TagResource.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_TagResource.html) in the *Amazon GuardDuty API Reference*.

## [GuardDuty.3] GuardDuty IPSets should be tagged
<a name="guardduty-3"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::GuardDuty::IPSet`

**AWS Config rule:** `tagged-guardduty-ipset` (custom Security Hub CSPM rule)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  |  No default value  | 

This control checks whether an Amazon GuardDuty IPSet has tags with the specific keys defined in the parameter `requiredTagKeys`. The control fails if the IPSet doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredTagKeys`. If the parameter `requiredTagKeys` isn't provided, the control only checks for the existence of a tag key and fails if the IPSet isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [What is ABAC for AWS?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Tagging your AWS resources](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *AWS General Reference*.

### Remediation
<a name="guardduty-3-remediation"></a>

To add tags to a GuardDuty IPSet, see [https://docs.aws.amazon.com/guardduty/latest/APIReference/API_TagResource.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_TagResource.html) in the *Amazon GuardDuty API Reference*.

## [GuardDuty.4] GuardDuty detectors should be tagged
<a name="guardduty-4"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::GuardDuty::Detector`

**AWS Config rule:** `tagged-guardduty-detector` (custom Security Hub CSPM rule)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  |  No default value  | 

This control checks whether an Amazon GuardDuty detector has tags with the specific keys defined in the parameter `requiredTagKeys`. The control fails if the detector doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredTagKeys`. If the parameter `requiredTagKeys` isn't provided, the control only checks for the existence of a tag key and fails if the detector isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [What is ABAC for AWS?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Tagging your AWS resources](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *AWS General Reference*.

### Remediation
<a name="guardduty-4-remediation"></a>

To add tags to a GuardDuty detector, see [https://docs.aws.amazon.com/guardduty/latest/APIReference/API_TagResource.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_TagResource.html) in the *Amazon GuardDuty API Reference*.

## [GuardDuty.5] GuardDuty EKS Audit Log Monitoring should be enabled
<a name="guardduty-5"></a>

**Category:** Detect > Detection services

**Severity:** High

**Resource type:** `AWS::GuardDuty::Detector`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/guardduty-eks-protection-audit-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/guardduty-eks-protection-audit-enabled.html)

**Schedule type:** Periodic

**Parameters:** None

This control checks whether GuardDuty EKS Audit Log Monitoring is enabled. For a standalone account, the control fails if GuardDuty EKS Audit Log Monitoring is disabled in the account. In a multi-account environment, the control fails if the delegated GuardDuty administrator account and all member accounts don't have EKS Audit Log Monitoring enabled.

In a multi-account environment, the control generates findings in only the delegated GuardDuty administrator account. Only the delegated administrator can enable or disable the EKS Audit Log Monitoring feature for the member accounts in the organization. GuardDuty member accounts can't modify this configuration from their accounts. This control generates `FAILED` findings if the delegated GuardDuty administrator has a suspended member account that doesn't have GuardDuty EKS Audit Log Monitoring enabled. To receive a `PASSED` finding, the delegated administrator must disassociate these suspended accounts in GuardDuty.

GuardDuty EKS Audit Log Monitoring helps you detect potentially suspicious activities in your Amazon Elastic Kubernetes Service (Amazon EKS) clusters. EKS Audit Log Monitoring uses Kubernetes audit logs to capture chronological activities from users, applications using the Kubernetes API, and the control plane.

### Remediation
<a name="guardduty-5-remediation"></a>

To enable GuardDuty EKS Audit Log Monitoring, see [EKS Audit Log Monitoring](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty-eks-audit-log-monitoring.html) in the *Amazon GuardDuty User Guide*.

## [GuardDuty.6] GuardDuty Lambda Protection should be enabled
<a name="guardduty-6"></a>

**Related requirements:** PCI DSS v4.0.1/11.5.1

**Category:** Detect > Detection services

**Severity:** High

**Resource type:** `AWS::GuardDuty::Detector`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/guardduty-lambda-protection-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/guardduty-lambda-protection-enabled.html)

**Schedule type:** Periodic

**Parameters:** None

This control checks whether GuardDuty Lambda Protection is enabled. For a standalone account, the control fails if GuardDuty Lambda Protection is disabled in the account. In a multi-account environment, the control fails if the delegated GuardDuty administrator account and all member accounts don't have Lambda Protection enabled.

In a multi-account environment, the control generates findings in only the delegated GuardDuty administrator account. Only the delegated administrator can enable or disable the Lambda Protection feature for the member accounts in the organization. GuardDuty member accounts can't modify this configuration from their accounts. This control generates `FAILED` findings if the delegated GuardDuty administrator has a suspended member account that doesn't have GuardDuty Lambda Protection enabled. To receive a `PASSED` finding, the delegated administrator must disassociate these suspended accounts in GuardDuty.

GuardDuty Lambda Protection helps you identify potential security threats when an AWS Lambda function gets invoked. After your enable Lambda Protection, GuardDuty starts monitoring Lambda network activity logs associated with the Lambda functions in your AWS account. When a Lambda function gets invoked and GuardDuty identifies suspicious network traffic that indicates the presence of a potentially malicious piece of code in your Lambda function, GuardDuty generates a finding. 

### Remediation
<a name="guardduty-6-remediation"></a>

To enable GuardDuty Lambda Protection, see [Configuring Lambda Protection](https://docs.aws.amazon.com/guardduty/latest/ug/configuring-lambda-protection.html) in the *Amazon GuardDuty User Guide*.

## [GuardDuty.7] GuardDuty EKS Runtime Monitoring should be enabled
<a name="guardduty-7"></a>

**Related requirements:** PCI DSS v4.0.1/11.5.1

**Category:** Detect > Detection Services

**Severity:** High

**Resource type:** `AWS::GuardDuty::Detector`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/guardduty-eks-protection-runtime-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/guardduty-eks-protection-runtime-enabled.html)

**Schedule type:** Periodic

**Parameters:** None

This control checks whether GuardDuty EKS Runtime Monitoring with automated agent management is enabled. For a standalone account, the control fails if GuardDuty EKS Runtime Monitoring with automated agent management is disabled in the account. In a multi-account environment, the control fails if the delegated GuardDuty administrator account and all member accounts don't have EKS Runtime Monitoring with automated agent management enabled.

In a multi-account environment, the control generates findings in only the delegated GuardDuty administrator account. Only the delegated administrator can enable or disable the EKS Runtime Monitoring feature with automated agent management for the member accounts in the organization. GuardDuty member accounts can't modify this configuration from their accounts. This control generates `FAILED` findings if the delegated GuardDuty administrator has a suspended member account that doesn't have GuardDuty EKS Runtime Monitoring enabled. To receive a `PASSED` finding, the delegated administrator must disassociate these suspended accounts in GuardDuty.

EKS Protection in Amazon GuardDuty provides threat detection coverage to help you protect Amazon EKS clusters within your AWS environment. EKS Runtime Monitoring uses operating system-level events to help you detect potential threats in EKS nodes and containers within your EKS clusters. 

### Remediation
<a name="guardduty-7-remediation"></a>

To enable EKS Runtime Monitoring with automated agent management, see [Enabling GuardDuty Runtime Monitoring](https://docs.aws.amazon.com/guardduty/latest/ug/runtime-monitoring-configuration.html) in the *Amazon GuardDuty User Guide*.

## [GuardDuty.8] GuardDuty Malware Protection for EC2 should be enabled
<a name="guardduty-8"></a>

**Category:** Detect > Detection services

**Severity:** High

**Resource type:** `AWS::GuardDuty::Detector`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/guardduty-malware-protection-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/guardduty-malware-protection-enabled.html)

**Schedule type:** Periodic

**Parameters:** None

This control checks whether GuardDuty Malware Protection is enabled. For a standalone account, the control fails if GuardDuty Malware Protection is disabled in the account. In a multi-account environment, the control fails if the delegated GuardDuty administrator account and all member accounts don't have Malware Protection enabled.

In a multi-account environment, the control generates findings in only the delegated GuardDuty administrator account. Only the delegated administrator can enable or disable the Malware Protection feature for the member accounts in the organization. GuardDuty member accounts can't modify this configuration from their accounts. This control generates `FAILED` findings if the delegated GuardDuty administrator has a suspended member account that doesn't have GuardDuty Malware Protection enabled. To receive a `PASSED` finding, the delegated administrator must disassociate these suspended accounts in GuardDuty.

GuardDuty Malware Protection for EC2 helps you detect the potential presence of malware by scanning the Amazon Elastic Block Store (Amazon EBS) volumes that are attached to Amazon Elastic Compute Cloud (Amazon EC2) instances and container workloads. Malware Protection provides scan options where you can decide if you want to include or exclude specific EC2 instances and container workloads at the time of scanning. It also provides an option to retain the snapshots of EBS volumes attached to the EC2 instances or container workloads, in your GuardDuty accounts. The snapshots get retained only when malware is found and Malware Protection findings are generated. 

### Remediation
<a name="guardduty-8-remediation"></a>

To enable GuardDuty Malware Protection for EC2, see [Configuring GuardDuty-initiated malware scan](https://docs.aws.amazon.com/guardduty/latest/ug/gdu-initiated-malware-scan-configuration.html) in the *Amazon GuardDuty User Guide*.

## [GuardDuty.9] GuardDuty RDS Protection should be enabled
<a name="guardduty-9"></a>

**Related requirements:** PCI DSS v4.0.1/11.5.1

**Category:** Detect > Detection services

**Severity:** High

**Resource type:** `AWS::GuardDuty::Detector`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/guardduty-rds-protection-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/guardduty-rds-protection-enabled.html)

**Schedule type:** Periodic

**Parameters:** None

This control checks whether GuardDuty RDS Protection is enabled. For a standalone account, the control fails if GuardDuty RDS Protection is disabled in the account. In a multi-account environment, the control fails if the delegated GuardDuty administrator account and all member accounts don't have RDS Protection enabled.

In a multi-account environment, the control generates findings in only the delegated GuardDuty administrator account. Only the delegated administrator can enable or disable the RDS Protection feature for the member accounts in the organization. GuardDuty member accounts can't modify this configuration from their accounts. This control generates `FAILED` findings if the delegated GuardDuty administrator has a suspended member account that doesn't have GuardDuty RDS Protection enabled. To receive a `PASSED` finding, the delegated administrator must disassociate these suspended accounts in GuardDuty.

RDS Protection in GuardDuty analyzes and profiles RDS login activity for potential access threats to your Amazon Aurora databases (Aurora MySQL-Compatible Edition and Aurora PostgreSQL-Compatible Edition). This feature allows you to identify potentially suspicious login behavior. RDS Protection doesn't require additional infrastructure; it is designed so as not to affect the performance of your database instances. When RDS Protection detects a potentially suspicious or anomalous login attempt that indicates a threat to your database, GuardDuty generates a new finding with details about the potentially compromised database. 

### Remediation
<a name="guardduty-9-remediation"></a>

To enable GuardDuty RDS Protection, see [GuardDuty RDS Protection](https://docs.aws.amazon.com/guardduty/latest/ug/rds-protection.html) in the *Amazon GuardDuty User Guide*.

## [GuardDuty.10] GuardDuty S3 Protection should be enabled
<a name="guardduty-10"></a>

**Related requirements:** PCI DSS v4.0.1/11.5.1

**Category:** Detect > Detection services

**Severity:** High

**Resource type:** `AWS::GuardDuty::Detector`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/guardduty-s3-protection-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/guardduty-s3-protection-enabled.html)

**Schedule type:** Periodic

**Parameters:** None

This control checks whether GuardDuty S3 Protection is enabled. For a standalone account, the control fails if GuardDuty S3 Protection is disabled in the account. In a multi-account environment, the control fails if the delegated GuardDuty administrator account and all member accounts don't have S3 Protection enabled.

In a multi-account environment, the control generates findings in only the delegated GuardDuty administrator account. Only the delegated administrator can enable or disable the S3 Protection feature for the member accounts in the organization. GuardDuty member accounts can't modify this configuration from their accounts. This control generates `FAILED` findings if the delegated GuardDuty administrator has a suspended member account that doesn't have GuardDuty S3 Protection enabled. To receive a `PASSED` finding, the delegated administrator must disassociate these suspended accounts in GuardDuty.

S3 Protection enables GuardDuty to monitor object-level API operations to identify potential security risks for data within your Amazon Simple Storage Service (Amazon S3) buckets. GuardDuty monitors threats against your S3 resources by analyzing AWS CloudTrail management events and CloudTrail S3 data events. 

### Remediation
<a name="guardduty-10-remediation"></a>

To enable GuardDuty S3 Protection, see [Amazon S3 Protection in Amazon GuardDuty](https://docs.aws.amazon.com/guardduty/latest/ug/s3-protection.html) in the *Amazon GuardDuty User Guide*.

## [GuardDuty.11] GuardDuty Runtime Monitoring should be enabled
<a name="guardduty-11"></a>

**Category:** Detect > Detection Services

**Severity:** High

**Resource type:** `AWS::GuardDuty::Detector`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/guardduty-runtime-monitoring-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/guardduty-runtime-monitoring-enabled.html)

**Schedule type:** Periodic

**Parameters:** None

This control checks whether Runtime Monitoring is enabled in Amazon GuardDuty. For a standalone account, the control fails if GuardDuty Runtime Monitoring is disabled for the account. In a multi-account environment, the control fails if GuardDuty Runtime Monitoring is disabled for the delegated GuardDuty administrator account and all member accounts.

In a multi-account environment, only the delegated GuardDuty administrator can enable or disable GuardDuty Runtime Monitoring for accounts in their organization. In addition, only the GuardDuty administrator can configure and manage the security agents that GuardDuty uses for runtime monitoring of AWS workloads and resources for accounts in the organization. GuardDuty member accounts can't enable, configure, or disable Runtime Monitoring for their own accounts.

GuardDuty Runtime Monitoring observes and analyzes operating system-level, networking, and file events to help you detect potential threats in specific AWS workloads in your environment. It uses GuardDuty security agents that add visibility into runtime behavior, such as file access, process execution, command line arguments, and network connections. You can enable and manage the security agent for each type of resource that you want to monitor for potential threats, such as Amazon EKS clusters and Amazon EC2 instances.

### Remediation
<a name="guardduty-11-remediation"></a>

For information about configuring and enabling GuardDuty Runtime Monitoring, see [GuardDuty Runtime Monitoring](https://docs.aws.amazon.com/guardduty/latest/ug/runtime-monitoring.html) and [Enabling GuardDuty Runtime Monitoring](https://docs.aws.amazon.com/guardduty/latest/ug/runtime-monitoring-configuration.html) in the *Amazon GuardDuty User Guide*.

## [GuardDuty.12] GuardDuty ECS Runtime Monitoring should be enabled
<a name="guardduty-12"></a>

**Category:** Detect > Detection Services

**Severity:** Medium

**Resource type:** `AWS::GuardDuty::Detector`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/guardduty-ecs-protection-runtime-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/guardduty-ecs-protection-runtime-enabled.html)

**Schedule type:** Periodic

**Parameters:** None

This control checks whether the Amazon GuardDuty automated security agent is enabled for runtime monitoring of Amazon ECS clusters on AWS Fargate. For a standalone account, the control fails if the security agent is disabled for the account. In a multi-account environment, the control fails if the security agent is disabled for the delegated GuardDuty administrator account and all member accounts.

In a multi-account environment, this control generates findings only in the delegated GuardDuty administrator account. This is because only the delegated GuardDuty administrator can enable or disable Runtime Monitoring of ECS-Fargate resources for accounts in their organization. GuardDuty member accounts can't do this for their own accounts. In addition, this control generates `FAILED` findings if GuardDuty is suspended for a member account and Runtime Monitoring of ECS-Fargate resources is disabled for the member account. To receive a `PASSED` finding, the GuardDuty administrator must disassociate the suspended member account from their administrator account by using GuardDuty.

GuardDuty Runtime Monitoring observes and analyzes operating system-level, networking, and file events to help you detect potential threats in specific AWS workloads in your environment. It uses GuardDuty security agents that add visibility into runtime behavior, such as file access, process execution, command line arguments, and network connections. You can enable and manage the security agent for each type of resource that you want to monitor for potential threats. This includes Amazon ECS clusters on AWS Fargate.

### Remediation
<a name="guardduty-12-remediation"></a>

To enable and manage the security agent for GuardDuty Runtime Monitoring of ECS-Fargate resources, you must use GuardDuty directly. You can't enable or manage it manually for ECS-Fargate resources. For information about enabling and managing the security agent, see [Prerequisites for AWS Fargate (Amazon ECS only) support](https://docs.aws.amazon.com/guardduty/latest/ug/prereq-runtime-monitoring-ecs-support.html) and [Managing the automated security agent for AWS Fargate (Amazon ECS only)](https://docs.aws.amazon.com/guardduty/latest/ug/managing-gdu-agent-ecs-automated.html) in the *Amazon GuardDuty User Guide*.

## [GuardDuty.13] GuardDuty EC2 Runtime Monitoring should be enabled
<a name="guardduty-13"></a>

**Category:** Detect > Detection Services

**Severity:** Medium

**Resource type:** `AWS::GuardDuty::Detector`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/guardduty-ec2-protection-runtime-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/guardduty-ec2-protection-runtime-enabled.html)

**Schedule type:** Periodic

**Parameters:** None

This control checks whether the Amazon GuardDuty automated security agent is enabled for runtime monitoring of Amazon EC2 instances. For a standalone account, the control fails if the security agent is disabled for the account. In a multi-account environment, the control fails if the security agent is disabled for the delegated GuardDuty administrator account and all member accounts.

In a multi-account environment, this control generates findings only in the delegated GuardDuty administrator account. This is because only the delegated GuardDuty administrator can enable or disable Runtime Monitoring of Amazon EC2 instances for accounts in their organization. GuardDuty member accounts can't do this for their own accounts. In addition, this control generates `FAILED` findings if GuardDuty is suspended for a member account and Runtime Monitoring of EC2 instances is disabled for the member account. To receive a `PASSED` finding, the GuardDuty administrator must disassociate the suspended member account from their administrator account by using GuardDuty.

GuardDuty Runtime Monitoring observes and analyzes operating system-level, networking, and file events to help you detect potential threats in specific AWS workloads in your environment. It uses GuardDuty security agents that add visibility into runtime behavior, such as file access, process execution, command line arguments, and network connections. You can enable and manage the security agent for each type of resource that you want to monitor for potential threats. This includes Amazon EC2 instances.

### Remediation
<a name="guardduty-13-remediation"></a>

For information about configuring and managing the automated security agent for GuardDuty Runtime Monitoring of EC2 instances, see [Prerequisites for Amazon EC2 instance support](https://docs.aws.amazon.com/guardduty/latest/ug/prereq-runtime-monitoring-ec2-support.html) and [Enabling the automated security agent for Amazon EC2 instances](https://docs.aws.amazon.com/guardduty/latest/ug/managing-gdu-agent-ec2-automated.html) in the *Amazon GuardDuty User Guide*.

# Security Hub CSPM controls for AWS Identity and Access Management
<a name="iam-controls"></a>

These AWS Security Hub CSPM controls evaluate the AWS Identity and Access Management (IAM) service and resources. The controls might not be available in all AWS Regions. For more information, see [Availability of controls by Region](securityhub-regions.md#securityhub-regions-control-support).

## [IAM.1] IAM policies should not allow full "\$1" administrative privileges
<a name="iam-1"></a>

**Related requirements:** CIS AWS Foundations Benchmark v1.2.0/1.22, CIS AWS Foundations Benchmark v1.4.0/1.16, NIST.800-53.r5 AC-2, NIST.800-53.r5 AC-2(1), NIST.800-53.r5 AC-3, NIST.800-53.r5 AC-3(15), NIST.800-53.r5 AC-3(7), NIST.800-53.r5 AC-5, NIST.800-53.r5 AC-6, NIST.800-53.r5 AC-6(10), NIST.800-53.r5 AC-6(2), NIST.800-53.r5 AC-6(3), NIST.800-171.r2 3.1.4, PCI DSS v3.2.1/7.2.1

**Category:** Protect > Secure access management

**Severity:** High

**Resource type:** `AWS::IAM::Policy`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/iam-policy-no-statements-with-admin-access.html](https://docs.aws.amazon.com/config/latest/developerguide/iam-policy-no-statements-with-admin-access.html)

**Schedule type:** Change triggered

**Parameters:**
+ `excludePermissionBoundaryPolicy: true` (not customizable)

This control checks whether the default version of IAM policies (also known as customer managed policies) has administrator access by including a statement with `"Effect": "Allow"` with `"Action": "*"` over `"Resource": "*"`. The control fails if you have IAM policies with such a statement.

The control only checks the customer managed policies that you create. It does not check inline and AWS managed policies.

IAM policies define a set of privileges that are granted to users, groups, or roles. Following standard security advice, AWS recommends that you grant least privilege, which means to grant only the permissions that are required to perform a task. When you provide full administrative privileges instead of the minimum set of permissions that the user needs, you expose the resources to potentially unwanted actions.

Instead of allowing full administrative privileges, determine what users need to do and then craft policies that let the users perform only those tasks. It is more secure to start with a minimum set of permissions and grant additional permissions as necessary. Do not start with permissions that are too lenient and then try to tighten them later.

You should remove IAM policies that have a statement with `"Effect": "Allow" `with `"Action": "*"` over `"Resource": "*"`.

**Note**  
AWS Config should be enabled in all Regions in which you use Security Hub CSPM. However, global resource recording can be enabled in a single Region. If you only record global resources in a single Region, then you can disable this control in all Regions except the Region where you record global resources.

### Remediation
<a name="iam-1-remediation"></a>

To modify your IAM policies so that they do not allow full "\$1" administrative privileges, see [Editing IAM policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-edit.html) in the *IAM User Guide*.

## [IAM.2] IAM users should not have IAM policies attached
<a name="iam-2"></a>

**Related requirements:** CIS AWS Foundations Benchmark v5.0.0/1.14, CIS AWS Foundations Benchmark v3.0.0/1.15, CIS AWS Foundations Benchmark v1.2.0/1.16, NIST.800-53.r5 AC-2, NIST.800-53.r5 AC-2(1), NIST.800-53.r5 AC-3, NIST.800-53.r5 AC-3(15), NIST.800-53.r5 AC-3(7), NIST.800-53.r5 AC-6, NIST.800-53.r5 AC-6(3), NIST.800-171.r2 3.1.1, NIST.800-171.r2 3.1.2, NIST.800-171.r2 3.1.7, NIST.800-171.r2 3.3.9, NIST.800-171.r2 3.13.3, PCI DSS v3.2.1/7.2.1

**Category:** Protect > Secure access management

**Severity:** Low

**Resource type:** `AWS::IAM::User`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/iam-user-no-policies-check.html](https://docs.aws.amazon.com/config/latest/developerguide/iam-user-no-policies-check.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether your IAM users have policies attached. The control fails if your IAM users have policies attached. Instead, IAM users must inherit permissions from IAM groups or assume a role.

By default, IAM users, groups, and roles have no access to AWS resources. IAM policies grant privileges to users, groups, or roles. We recommend that you apply IAM policies directly to groups and roles but not to users. Assigning privileges at the group or role level reduces the complexity of access management as the number of users grows. Reducing access management complexity might in turn reduce the opportunity for a principal to inadvertently receive or retain excessive privileges. 

**Note**  
AWS Config should be enabled in all Regions in which you use Security Hub CSPM. However, global resource recording can be enabled in a single Region. If you only record global resources in a single Region, you can disable this control in all Regions except the Region where you record global resources.

### Remediation
<a name="iam-2-remediation"></a>

To resolve this issue, [create an IAM group](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups_create.html), and attach the policy to the group. Then, [add the users to the group](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups_manage_add-remove-users.html). The policy is applied to each user in the group. To remove a policy attached directly to a user, see [Adding and removing IAM identity permissions](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html) in the *IAM User Guide*.

## [IAM.3] IAM users' access keys should be rotated every 90 days or less
<a name="iam-3"></a>

**Related requirements:** CIS AWS Foundations Benchmark v5.0.0/1.13, CIS AWS Foundations Benchmark v3.0.0/1.14, CIS AWS Foundations Benchmark v1.4.0/1.14, CIS AWS Foundations Benchmark v1.2.0/1.4, NIST.800-53.r5 AC-2(1), NIST.800-53.r5 AC-2(3), NIST.800-53.r5 AC-3(15), PCI DSS v4.0.1/8.3.9, PCI DSS v4.0.1/8.6.3

**Category:** Protect > Secure access management

**Severity:** Medium 

**Resource type:** `AWS::IAM::User`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/access-keys-rotated.html](https://docs.aws.amazon.com/config/latest/developerguide/access-keys-rotated.html)

**Schedule type:** Periodic

**Parameters:**
+ `maxAccessKeyAge`: `90` (not customizable)

This control checks whether the active access keys are rotated within 90 days.

We highly recommend that you do not generate and remove all access keys in your account. Instead, the recommended best practice is to either create one or more IAM roles or to use [federation](https://aws.amazon.com/identity/federation/) through AWS IAM Identity Center. You can use these methods to allow your users to access the AWS Management Console and AWS CLI.

Each approach has its use cases. Federation is generally better for enterprises that have an existing central directory or plan to need more than the current limit on IAM users. Applications that run outside of an AWS environment need access keys for programmatic access to AWS resources.

However, if the resources that need programmatic access run inside AWS, the best practice is to use IAM roles. Roles allow you to grant a resource access without hardcoding an access key ID and secret access key into the configuration.

To learn more about protecting your access keys and account, see [Best practices for managing AWS access keys](https://docs.aws.amazon.com/general/latest/gr/aws-access-keys-best-practices.html) in the *AWS General Reference*. Also see the blog post [Guidelines for protecting your AWS account while using programmatic access](https://aws.amazon.com/blogs/security/guidelines-for-protecting-your-aws-account-while-using-programmatic-access/).

If you already have an access key, Security Hub CSPM recommends that you rotate the access keys every 90 days. Rotating access keys reduces the chance that an access key that is associated with a compromised or terminated account is used. It also ensures that data cannot be accessed with an old key that might have been lost, cracked, or stolen. Always update your applications after you rotate access keys. 

Access keys consist of an access key ID and a secret access key. They are used to sign programmatic requests that you make to AWS. Users need their own access keys to make programmatic calls to AWS from the AWS CLI, Tools for Windows PowerShell, the AWS SDKs, or direct HTTP calls using the API operations for individual AWS services.

If your organization uses AWS IAM Identity Center (IAM Identity Center), your users can sign in to Active Directory, a built-in IAM Identity Center directory, or [another identity provider (IdP) connected to IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-idp.html). They can then be mapped to an IAM role that enables them to run AWS CLI commands or call AWS API operations without the need for access keys. To learn more, see [Configuring the AWS CLI to use AWS IAM Identity Center](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-sso.html) in the *AWS Command Line Interface User Guide*.

**Note**  
AWS Config should be enabled in all Regions in which you use Security Hub CSPM. However, global resource recording can be enabled in a single Region. If you only record global resources in a single Region, then you can disable this control in all Regions except the Region where you record global resources.

### Remediation
<a name="iam-3-remediation"></a>

To rotate access keys that are older than 90 days, see [Rotating access keys](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_RotateAccessKey) in the *IAM User Guide*. Follow the instructions for any user with an **Access key age** greater than 90 days.

## [IAM.4] IAM root user access key should not exist
<a name="iam-4"></a>

**Related requirements:** CIS AWS Foundations Benchmark v5.0.0/1.3, CIS AWS Foundations Benchmark v3.0.0/1.4, CIS AWS Foundations Benchmark v1.4.0/1.4, CIS AWS Foundations Benchmark v1.2.0/1.12, PCI DSS v3.2.1/2.1, PCI DSS v3.2.1/2.2, PCI DSS v3.2.1/7.2.1, NIST.800-53.r5 AC-2(1), NIST.800-53.r5 AC-3(15), NIST.800-53.r5 AC-3(7), NIST.800-53.r5 AC-6, NIST.800-53.r5 AC-6(10), NIST.800-53.r5 AC-6(2)

**Category:** Protect > Secure access management

**Severity:** Critical 

**Resource type:** `AWS::::Account`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/iam-root-access-key-check.html](https://docs.aws.amazon.com/config/latest/developerguide/iam-root-access-key-check.html)

**Schedule type:** Periodic

**Parameters:** None

This control checks whether the root user access key is present. 

The root user is the most privileged user in an AWS account. AWS access keys provide programmatic access to a given account.

Security Hub CSPM recommends that you remove all access keys that are associated with the root user. This limits that vectors that can be used to compromise your account. It also encourages the creation and use of role-based accounts that are least privileged. 

### Remediation
<a name="iam-4-remediation"></a>

To delete the root user access key, see [Deleting access keys for the root user](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#id_root-user_manage_delete-key) in the *IAM User Guide*. To delete the root user access keys from an AWS account in AWS GovCloud (US), see [Deleting my AWS GovCloud (US) account root user access keys](https://docs.aws.amazon.com/govcloud-us/latest/UserGuide/govcloud-account-root-user.html#delete-govcloud-root-access-key) in the *AWS GovCloud (US) User Guide*.

## [IAM.5] MFA should be enabled for all IAM users that have a console password
<a name="iam-5"></a>

**Related requirements:** CIS AWS Foundations Benchmark v5.0.0/1.9, CIS AWS Foundations Benchmark v3.0.0/1.10, CIS AWS Foundations Benchmark v1.4.0/1.10, CIS AWS Foundations Benchmark v1.2.0/1.2, NIST.800-53.r5 AC-2(1), NIST.800-53.r5 AC-3(15), NIST.800-53.r5 IA-2(1), NIST.800-53.r5 IA-2(2), NIST.800-53.r5 IA-2(6), NIST.800-53.r5 IA-2(8), PCI DSS v4.0.1/8.4.2

**Category:** Protect > Secure access management

**Severity:** Medium

**Resource type:** `AWS::IAM::User`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/mfa-enabled-for-iam-console-access.html](https://docs.aws.amazon.com/config/latest/developerguide/mfa-enabled-for-iam-console-access.html)

**Schedule type:** Periodic

**Parameters:** None

This control checks whether AWS multi-factor authentication (MFA) is enabled for all IAM users that use a console password.

Multi-factor authentication (MFA) adds an extra layer of protection on top of a user name and password. With MFA enabled, when a user signs in to an AWS website, they are prompted for their user name and password. In addition, they are prompted for an authentication code from their AWS MFA device.

We recommend that you enable MFA for all accounts that have a console password. MFA is designed to provide increased security for console access. The authenticating principal must possess a device that emits a time-sensitive key and must have knowledge of a credential.

**Note**  
AWS Config should be enabled in all Regions in which you use Security Hub CSPM. However, global resource recording can be enabled in a single Region. If you only record global resources in a single Region, then you can disable this control in all Regions except the Region where you record global resources.

### Remediation
<a name="iam-5-remediation"></a>

To add MFA for IAM users, see [Using multi-factor authentication (MFA) in AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa.html) in the *IAM User Guide*.

## [IAM.6] Hardware MFA should be enabled for the root user
<a name="iam-6"></a>

**Related requirements:** CIS AWS Foundations Benchmark v5.0.0/1.5, CIS AWS Foundations Benchmark v3.0.0/1.6, CIS AWS Foundations Benchmark v1.4.0/1.6, CIS AWS Foundations Benchmark v1.2.0/1.14, PCI DSS v3.2.1/8.3.1, NIST.800-53.r5 AC-2(1), NIST.800-53.r5 AC-3(15), NIST.800-53.r5 IA-2(1), NIST.800-53.r5 IA-2(2), NIST.800-53.r5 IA-2(6), NIST.800-53.r5 IA-2(8), PCI DSS v4.0.1/8.4.2

**Category:** Protect > Secure access management

**Severity:** Critical

**Resource type:** `AWS::::Account`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/root-account-hardware-mfa-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/root-account-hardware-mfa-enabled.html)

**Schedule type:** Periodic

**Parameters:** None

This control checks whether your AWS account is enabled to use a hardware multi-factor authentication (MFA) device to sign in with root user credentials. The control fails if hardware MFA isn't enabled or virtual MFA devices are permitted for signing in with root user credentials.

Virtual MFA might not provide the same level of security as hardware MFA devices. We recommend that you use a virtual MFA device only while you wait for hardware purchase approval or for your hardware to arrive. To learn more, see [ Assign a virtual MFA device (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_enable_virtual.html) in the *IAM User Guide*.

**Note**  
Security Hub CSPM evaluates this control based on the presence of root user credentials (login profile) in an AWS account. The control generates `PASSED` findings in the following cases:  
Root user credentials are present in the account and hardware MFA is enabled for the root user.
Root user credentials aren’t present in the account.
The control generates a `FAILED` finding if root user credentials are present in the account and hardware MFA is not enabled for the root user.

### Remediation
<a name="iam-6-remediation"></a>

For information about enabling hardware MFA for the root user, see [Multi-factor authentication for an AWS account root user](https://docs.aws.amazon.com/IAM/latest/UserGuide/enable-mfa-for-root.html) in the *IAM User Guide*.

## [IAM.7] Password policies for IAM users should have strong configurations
<a name="iam-7"></a>

**Related requirements:** NIST.800-53.r5 AC-2(1), NIST.800-53.r5 AC-2(3), NIST.800-53.r5 AC-3(15), NIST.800-53.r5 IA-5(1), NIST.800-171.r2 3.5.2, NIST.800-171.r2 3.5.7, NIST.800-171.r2 3.5.8, PCI DSS v4.0.1/8.3.6, PCI DSS v4.0.1/8.3.7, PCI DSS v4.0.1/8.3.9, PCI DSS v4.0.1/8.3.10.1, PCI DSS v4.0.1/8.6.3

**Category:** Protect > Secure access management

**Severity:** Medium

**Resource type:** `AWS::::Account`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/iam-password-policy.html](https://docs.aws.amazon.com/config/latest/developerguide/iam-password-policy.html)

**Schedule type:** Periodic

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  `RequireUppercaseCharacters`  |  Require at least one uppercase character in password  |  Boolean  |  `true` or `false`  |  `true`  | 
|  `RequireLowercaseCharacters`  |  Require at least one lowercase character in password  |  Boolean  |  `true` or `false`  |  `true`  | 
|  `RequireSymbols`  |  Require at least one symbol in password  |  Boolean  |  `true` or `false`  |  `true`  | 
|  `RequireNumbers`  |  Require at least one number in password  |  Boolean  |  `true` or `false`  |  `true`  | 
|  `MinimumPasswordLength`  |  Minimum number of characters in the password  |  Integer  |  `8` to `128`  |  `8`  | 
|  `PasswordReusePrevention`  |  Number of password rotations before an old password can be reused  |  Integer  |  `12` to `24`  |  No default value  | 
|  `MaxPasswordAge`  |  Number of days before password expiration  |  Integer  |  `1` to `90`  |  No default value  | 

This control checks whether the account password policy for IAM users uses strong configurations. The control fails if the password policy doesn't use strong configurations. Unless you provide custom parameter values, Security Hub CSPM uses the default values mentioned in the preceding table. The `PasswordReusePrevention` and `MaxPasswordAge` parameters have no default value, so if you exclude these parameters, Security Hub CSPM ignores number of password rotations and password age when evaluating this control.

To access the AWS Management Console, IAM users need passwords. As a best practice, Security Hub CSPM highly recommends that instead of creating IAM users, you use federation. Federation allows users to use their existing corporate credentials to log into the AWS Management Console. Use AWS IAM Identity Center (IAM Identity Center) to create or federate the user, and then assume an IAM role into an account.

To learn more about identity providers and federation, see [Identity providers and federation](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html) in the *IAM User Guide*. To learn more about IAM Identity Center, see the [https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html).

 If you need to use IAM users, Security Hub CSPM recommends that you enforce the creation of strong user passwords. You can set a password policy on your AWS account to specify complexity requirements and mandatory rotation periods for passwords. When you create or change a password policy, most of the password policy settings are enforced the next time users change their passwords. Some of the settings are enforced immediately.

### Remediation
<a name="iam-7-remediation"></a>

To update your password policy, see [Setting an account password policy for IAM users](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_passwords_account-policy.html) in the *IAM User Guide*.

## [IAM.8] Unused IAM user credentials should be removed
<a name="iam-8"></a>

**Related requirements:** CIS AWS Foundations Benchmark v1.2.0/1.3, NIST.800-53.r5 AC-2, NIST.800-53.r5 AC-2(1), NIST.800-53.r5 AC-2(3), NIST.800-53.r5 AC-3, NIST.800-53.r5 AC-3(15), NIST.800-53.r5 AC-3(7), NIST.800-53.r5 AC-6, NIST.800-171.r2 3.1.2, PCI DSS v3.2.1/8.1.4, PCI DSS v4.0.1/8.2.6

**Category:** Protect > Secure access management 

**Severity:** Medium 

**Resource type:** `AWS::IAM::User`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/iam-user-unused-credentials-check.html](https://docs.aws.amazon.com/config/latest/developerguide/iam-user-unused-credentials-check.html)

**Schedule type:** Periodic

**Parameters:**
+ `maxCredentialUsageAge`: `90` (not customizable)

This control checks whether your IAM users have passwords or active access keys that have not been used for 90 days.

IAM users can access AWS resources using different types of credentials, such as passwords or access keys. 

Security Hub CSPM recommends that you remove or deactivate all credentials that were unused for 90 days or more. Disabling or removing unnecessary credentials reduces the window of opportunity for credentials associated with a compromised or abandoned account to be used.

**Note**  
AWS Config should be enabled in all Regions in which you use Security Hub CSPM. However, global resource recording can be enabled in a single Region. If you only record global resources in a single Region, then you can disable this control in all Regions except the Region where you record global resources.

### Remediation
<a name="iam-8-remediation"></a>

When you view user information in the IAM console, there are columns for **Access key age**, **Password age**, and **Last activity**. If the value in any of these columns is greater than 90 days, make the credentials for those users inactive.

You can also use [credential reports](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_getting-report.html#getting-credential-reports-console) to monitor users and identify those with no activity for 90 or more days. You can download credential reports in `.csv` format from the IAM console.

After you identify the inactive accounts or unused credentials, deactivate them. For instructions, see [Creating, changing, or deleting an IAM user password (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_passwords_admin-change-user.html#id_credentials_passwords_admin-change-user_console) in the *IAM User Guide*.

## [IAM.9] MFA should be enabled for the root user
<a name="iam-9"></a>

**Related requirements:** CIS AWS Foundations Benchmark v5.0.0/1.4, PCI DSS v3.2.1/8.3.1, PCI DSS v4.0.1/8.4.2, CIS AWS Foundations Benchmark v3.0.0/1.5, CIS AWS Foundations Benchmark v1.4.0/1.5, CIS AWS Foundations Benchmark v1.2.0/1.13, NIST.800-53.r5 AC-2(1), NIST.800-53.r5 AC-3(15), NIST.800-53.r5 IA-2(1), NIST.800-53.r5 IA-2(2), NIST.800-53.r5 IA-2(6), NIST.800-53.r5 IA-2(8)

**Category:** Protect > Secure access management 

**Severity:** Critical

**Resource type:** `AWS::::Account`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/root-account-mfa-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/root-account-mfa-enabled.html)

**Schedule type:** Periodic

**Parameters:** None

This control checks whether multi-factor authentication (MFA) is enabled for the IAM root user of an AWS account to sign in to the AWS Management Console. The control fails if MFA isn't enabled for the root user of the account.

The IAM root user of an AWS account has complete access to all the services and resources in the account. If MFA is enabled, the user must enter a username, a password, and an authentication code from their AWS MFA device in order to sign in to the AWS Management Console. MFA adds an extra layer of protection on top of a username and password.

This control generates `PASSED` findings in the following cases:
+ Root user credentials are present in the account and MFA is enabled for the root user.
+ Root user credentials aren’t present in the account.

The control generates `FAILED` findings if root user credentials are present in the account and MFA isn’t enabled for the root user.

### Remediation
<a name="iam-9-remediation"></a>

For information about enabling MFA for the root user of an AWS account, see [Multi-factor authentication for the AWS account root user](https://docs.aws.amazon.com/IAM/latest/UserGuide/enable-mfa-for-root.html) in the *AWS Identity and Access Management User Guide*.

## [IAM.10] Password policies for IAM users should have strong configurations
<a name="iam-10"></a>

**Related requirements:** NIST.800-171.r2 3.5.2, NIST.800-171.r2 3.5.7, NIST.800-171.r2 3.5.8, PCI DSS v3.2.1/8.1.4, PCI DSS v3.2.1/8.2.3, PCI DSS v3.2.1/8.2.4, PCI DSS v3.2.1/8.2.5

**Category:** Protect > Secure access management 

**Severity:** Medium

**Resource type:** `AWS::::Account`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/iam-password-policy.html](https://docs.aws.amazon.com/config/latest/developerguide/iam-password-policy.html)

**Schedule type:** Periodic

**Parameters:** None

This control checks whether the account password policy for IAM users uses the following minimum PCI DSS configurations.
+ `RequireUppercaseCharacters` – Require at least one uppercase character in password. (Default = `true`)
+ `RequireLowercaseCharacters` – Require at least one lowercase character in password. (Default = `true`)
+ `RequireNumbers` – Require at least one number in password. (Default = `true`)
+ `MinimumPasswordLength` – Password minimum length. (Default = 7 or longer)
+ `PasswordReusePrevention` – Number of passwords before allowing reuse. (Default = 4)
+ `MaxPasswordAge` – Number of days before password expiration. (Default = 90)

**Note**  
On May 30, 2025, Security Hub CSPM removed this control from the PCI DSS v4.0.1 standard. PCI DSS v4.0.1 now requires passwords to have a minimum of 8 characters. This control continues to apply to the PCI DSS v3.2.1 standard, which has different password requirements.  
To evaluate account password policies against PCI DSS v4.0.1 requirements, you can use the [IAM.7 control](#iam-7). This control requires passwords to have a minimum of 8 characters. It also supports custom values for password length and other parameters. The IAM.7 control is part of the PCI DSS v4.0.1 standard in Security Hub CSPM.

### Remediation
<a name="iam-10-remediation"></a>

To update your password policy to use the recommended configuration, see [Setting an account password policy for IAM users](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_passwords_account-policy.html) in the *IAM User Guide*.

## [IAM.11] Ensure IAM password policy requires at least one uppercase letter
<a name="iam-11"></a>

**Related requirements:** CIS AWS Foundations Benchmark v1.2.0/1.5, NIST.800-171.r2 3.5.7, PCI DSS v4.0.1/8.3.6, PCI DSS v4.0.1/8.6.3

**Category:** Protect > Secure access management 

**Severity:** Medium

**Resource type:** `AWS::::Account`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/iam-password-policy.html](https://docs.aws.amazon.com/config/latest/developerguide/iam-password-policy.html)

**Schedule type:** Periodic

**Parameters:** None

Password policies, in part, enforce password complexity requirements. Use IAM password policies to ensure that passwords use different character sets.

CIS recommends that the password policy require at least one uppercase letter. Setting a password complexity policy increases account resiliency against brute force login attempts.

### Remediation
<a name="iam-11-remediation"></a>

To change your password policy, see [Setting an account password policy for IAM users](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_passwords_account-policy.html) in the *IAM User Guide*. For **Password strength**, select **Require at least one uppercase letter from the Latin alphabet (A–Z)**.

## [IAM.12] Ensure IAM password policy requires at least one lowercase letter
<a name="iam-12"></a>

**Related requirements:** CIS AWS Foundations Benchmark v1.2.0/1.6, NIST.800-171.r2 3.5.7, PCI DSS v4.0.1/8.3.6, PCI DSS v4.0.1/8.6.3

**Category:** Protect > Secure access management 

**Severity:** Medium

**Resource type:** `AWS::::Account`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/iam-password-policy.html](https://docs.aws.amazon.com/config/latest/developerguide/iam-password-policy.html)

**Schedule type:** Periodic

**Parameters:** None

Password policies, in part, enforce password complexity requirements. Use IAM password policies to ensure that passwords use different character sets. CIS recommends that the password policy require at least one lowercase letter. Setting a password complexity policy increases account resiliency against brute force login attempts.

### Remediation
<a name="iam-12-remediation"></a>

To change your password policy, see [Setting an account password policy for IAM users](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_passwords_account-policy.html) in the *IAM User Guide*. For **Password strength**, select **Require at least one lowercase letter from the Latin alphabet (A–Z)**.

## [IAM.13] Ensure IAM password policy requires at least one symbol
<a name="iam-13"></a>

**Related requirements:** CIS AWS Foundations Benchmark v1.2.0/1.7, NIST.800-171.r2 3.5.7

**Category:** Protect > Secure access management

**Severity:** Medium

**Resource type:** `AWS::::Account`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/iam-password-policy.html](https://docs.aws.amazon.com/config/latest/developerguide/iam-password-policy.html)

**Schedule type:** Periodic

**Parameters:** None

Password policies, in part, enforce password complexity requirements. Use IAM password policies to ensure that passwords use different character sets.

CIS recommends that the password policy require at least one symbol. Setting a password complexity policy increases account resiliency against brute force login attempts.

### Remediation
<a name="iam-13-remediation"></a>

To change your password policy, see [Setting an account password policy for IAM users](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_passwords_account-policy.html) in the *IAM User Guide*. For **Password strength**, select **Require at least one nonalphanumeric character**.

## [IAM.14] Ensure IAM password policy requires at least one number
<a name="iam-14"></a>

**Related requirements:** CIS AWS Foundations Benchmark v1.2.0/1.8, NIST.800-171.r2 3.5.7, PCI DSS v4.0.1/8.3.6, PCI DSS v4.0.1/8.6.3

**Category:** Protect > Secure access management

**Severity:** Medium

**Resource type:** `AWS::::Account`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/iam-password-policy.html](https://docs.aws.amazon.com/config/latest/developerguide/iam-password-policy.html)

**Schedule type:** Periodic

**Parameters:** None

Password policies, in part, enforce password complexity requirements. Use IAM password policies to ensure that passwords use different character sets.

CIS recommends that the password policy require at least one number. Setting a password complexity policy increases account resiliency against brute force login attempts.

### Remediation
<a name="iam-14-remediation"></a>

To change your password policy, see [Setting an account password policy for IAM users](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_passwords_account-policy.html) in the *IAM User Guide*. For **Password strength**, select **Require at least one number**.

## [IAM.15] Ensure IAM password policy requires minimum password length of 14 or greater
<a name="iam-15"></a>

**Related requirements:** CIS AWS Foundations Benchmark v5.0.0/1.7, CIS AWS Foundations Benchmark v3.0.0/1.8, CIS AWS Foundations Benchmark v1.4.0/1.8, CIS AWS Foundations Benchmark v1.2.0/1.9, NIST.800-171.r2 3.5.7

**Category:** Protect > Secure access management

**Severity:** Medium

**Resource type:** `AWS::::Account`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/iam-password-policy.html](https://docs.aws.amazon.com/config/latest/developerguide/iam-password-policy.html)

**Schedule type:** Periodic

**Parameters:** None

Password policies, in part, enforce password complexity requirements. Use IAM password policies to ensure that passwords are at least a given length.

CIS recommends that the password policy require a minimum password length of 14 characters. Setting a password complexity policy increases account resiliency against brute force login attempts.

### Remediation
<a name="iam-15-remediation"></a>

To change your password policy, see [Setting an account password policy for IAM users](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_passwords_account-policy.html) in the *IAM User Guide*. For **Password minimum length**, enter **14** or a larger number.

## [IAM.16] Ensure IAM password policy prevents password reuse
<a name="iam-16"></a>

**Related requirements:** CIS AWS Foundations Benchmark v5.0.0/1.8, CIS AWS Foundations Benchmark v3.0.0/1.9, CIS AWS Foundations Benchmark v1.4.0/1.9, CIS AWS Foundations Benchmark v1.2.0/1.10, NIST.800-171.r2 3.5.8, PCI DSS v4.0.1/8.3.7

**Category:** Protect > Secure access management

**Severity:** Low

**Resource type:** `AWS::::Account`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/iam-password-policy.html](https://docs.aws.amazon.com/config/latest/developerguide/iam-password-policy.html)

**Schedule type:** Periodic

**Parameters:** None

This control checks whether the number of passwords to remember is set to 24. The control fails if the value is not 24.

IAM password policies can prevent the reuse of a given password by the same user.

CIS recommends that the password policy prevent the reuse of passwords. Preventing password reuse increases account resiliency against brute force login attempts.

### Remediation
<a name="iam-16-remediation"></a>

To change your password policy, see [Setting an account password policy for IAM users](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_passwords_account-policy.html) in the *IAM User Guide*. For **Prevent password reuse**, enter **24**.

## [IAM.17] Ensure IAM password policy expires passwords within 90 days or less
<a name="iam-17"></a>

**Related requirements:** CIS AWS Foundations Benchmark v1.2.0/1.11, PCI DSS v4.0.1/8.3.9, PCI DSS v4.0.1/8.3.10.1

**Category:** Protect > Secure access management

**Severity:** Low

**Resource type:** `AWS::::Account`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/iam-password-policy.html](https://docs.aws.amazon.com/config/latest/developerguide/iam-password-policy.html)

**Schedule type:** Periodic

**Parameters:** None

IAM password policies can require passwords to be rotated or expired after a given number of days.

CIS recommends that the password policy expire passwords after 90 days or less. Reducing the password lifetime increases account resiliency against brute force login attempts. Requiring regular password changes also helps in the following scenarios:
+ Passwords can be stolen or compromised without your knowledge. This can happen via a system compromise, software vulnerability, or internal threat.
+ Certain corporate and government web filters or proxy servers can intercept and record traffic even if it's encrypted.
+ Many people use the same password for many systems such as work, email, and personal.
+ Compromised end-user workstations might have a keystroke logger.

### Remediation
<a name="iam-17-remediation"></a>

To change your password policy, see [Setting an account password policy for IAM users](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_passwords_account-policy.html) in the *IAM User Guide*. For **Turn on password expiration**, enter **90** or a smaller number.

## [IAM.18] Ensure a support role has been created to manage incidents with AWS Support
<a name="iam-18"></a>

**Related requirements:** CIS AWS Foundations Benchmark v5.0.0/1.16, CIS AWS Foundations Benchmark v3.0.0/1.17, CIS AWS Foundations Benchmark v1.4.0/1.17, CIS AWS Foundations Benchmark v1.2.0/1.20, NIST.800-171.r2 3.1.2, PCI DSS v4.0.1/12.10.3

**Category:** Protect > Secure access management

**Severity:** Low

**Resource type:** `AWS::::Account`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/iam-policy-in-use.html](https://docs.aws.amazon.com/config/latest/developerguide/iam-policy-in-use.html)

**Schedule type:** Periodic

**Parameters:**
+ `policyARN`: `arn:partition:iam::aws:policy/AWSSupportAccess` (not customizable)
+ `policyUsageType`: `ANY` (not customizable)

AWS provides a support center that can be used for incident notification and response, as well as technical support and customer services.

Create an IAM role to allow authorized users to manage incidents with AWS Support. By implementing least privilege for access control, an IAM role will require an appropriate IAM policy to allow support center access in order to manage incidents with Support.

**Note**  
AWS Config should be enabled in all Regions in which you use Security Hub CSPM. However, global resource recording can be enabled in a single Region. If you only record global resources in a single Region, then you can disable this control in all Regions except the Region where you record global resources.

### Remediation
<a name="iam-18-remediation"></a>

To remediate this issue, create a role to allow authorized users to manage Support incidents.

**To create the role to use for Support access**

1. Open the IAM console at [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).

1. In the IAM navigation pane, choose **Roles**, then choose **Create role**.

1. For **Role type**, choose the **Another AWS account**.

1. For **Account ID**, enter the AWS account ID of the AWS account to which you want to grant access to your resources.

   If the users or groups that will assume this role are in the same account, then enter the local account number.
**Note**  
The administrator of the specified account can grant permission to assume this role to any user in that account. To do this, the administrator attaches a policy to the user or a group that grants permission for the `sts:AssumeRole` action. In that policy, the resource must be the role ARN.

1. Choose **Next: Permissions**.

1. Search for the managed policy `AWSSupportAccess`.

1. Select the check box for the `AWSSupportAccess` managed policy.

1. Choose **Next: Tags**.

1. (Optional) To add metadata to the role, attach tags as key-value pairs.

   For more information about using tags in IAM, see [Tagging IAM users and roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_tags.html) in the *IAM User Guide*.

1. Choose **Next: Review**.

1. For **Role name**, enter a name for your role.

   Role names must be unique within your AWS account. They are not case sensitive.

1. (Optional) For **Role description**, enter a description for the new role.

1. Review the role, then choose **Create role**.

## [IAM.19] MFA should be enabled for all IAM users
<a name="iam-19"></a>

**Related requirements:** NIST.800-53.r5 AC-2(1), NIST.800-53.r5 AC-3(15), NIST.800-53.r5 IA-2(1), NIST.800-53.r5 IA-2(2), NIST.800-53.r5 IA-2(6), NIST.800-53.r5 IA-2(8), NIST.800-171.r2 3.3.8, NIST.800-171.r2 3.5.3, NIST.800-171.r2 3.5.4, NIST.800-171.r2 3.7.5, PCI DSS v3.2.1/8.3.1, PCI DSS v4.0.1/8.4.2, 

**Category:** Protect > Secure access management

**Severity:** Medium

**Resource type:** `AWS::IAM::User`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/iam-user-mfa-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/iam-user-mfa-enabled.html)

**Schedule type:** Periodic

**Parameters:** None

This control checks whether the IAM users have multi-factor authentication (MFA) enabled.

**Note**  
AWS Config should be enabled in all Regions in which you use Security Hub CSPM. However, global resource recording can be enabled in a single Region. If you only record global resources in a single Region, then you can disable this control in all Regions except the Region where you record global resources.

### Remediation
<a name="iam-19-remediation"></a>

To add MFA for IAM users, see [Enabling MFA devices for users in AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_enable.html) in the *IAM User Guide*.

## [IAM.20] Avoid the use of the root user
<a name="iam-20"></a>

**Important**  
Security Hub CSPM retired this control in April 2024. For more information, see [Change log for Security Hub CSPM controls](controls-change-log.md).

**Related requirements:** CIS AWS Foundations Benchmark v1.2.0/1.1

**Category:** Protect > Secure access management

**Severity:** Low

**Resource type:** `AWS::IAM::User`

**AWS Config rule:** `use-of-root-account-test` (custom Security Hub CSPM rule)

**Schedule type:** Periodic

**Parameters:** None

This control checks whether an AWS account has restrictions on the usage of the root user. The control evaluates the following resources:
+ Amazon Simple Notification Service (Amazon SNS) topics
+ AWS CloudTrail trails
+ Metric filters associated with the CloudTrail trails
+ Amazon CloudWatch alarms based on the filters

This check results in a `FAILED` finding if one or more of the following statements is true:
+ No CloudTrail trails exist in the account.
+ A CloudTrail trail is enabled, but not configured with at-least one multi-Region trail that includes read and write management events.
+ A CloudTrail trail is enabled, but not associated with a CloudWatch Logs log group.
+ The exact metric filter prescribed by the Center for Internet Security (CIS) is not used. The prescribed metric filter is `'{$.userIdentity.type="Root" && $.userIdentity.invokedBy NOT EXISTS && $.eventType !="AwsServiceEvent"}'`.
+ No CloudWatch alarms based on the metric filter exist in the account.
+ CloudWatch alarms configured to send notification to the associated SNS topic don't trigger based on the alarm condition.
+ The SNS topic doesn't comply with the [constraints for sending a message to an SNS topic](https://docs.aws.amazon.com/sns/latest/api/API_Publish.html).
+ The SNS topic doesn't have at least one subscriber.

This check results in a control status of `NO_DATA` if one or more of the following statements is true:
+ A multi-Region trail is based in a different Region. Security Hub CSPM can only generate findings in the Region where the trail is based.
+ A multi-Region trail belongs to a different account. Security Hub CSPM can only generate findings for the account that owns the trail.

This check results in a control status of `WARNING` if one or more of the following statements is true:
+ The current account doesn't own the SNS topic referenced in the CloudWatch alarm.
+ The current account doesn't have access to the SNS topic when invoking the `ListSubscriptionsByTopic` SNS API.

**Note**  
We recommend using organization trails to log events from many accounts in an organization. Organization trails are multi-Region trails by default and can only be managed by the AWS Organizations management account or the CloudTrail delegated administrator account. Using an organization trail results in a control status of NO\$1DATA for controls evaluated in organization member accounts. In member accounts, Security Hub CSPM only generates findings for member-owned resources. Findings that pertain to organization trails are generated in the resource owner's account. You can see these findings in your Security Hub CSPM delegated administrator account by using cross-Region aggregation.

As a best practice, use your root user credentials only when required to [ perform account and service management tasks](https://docs.aws.amazon.com/general/latest/gr/aws_tasks-that-require-root.html). Apply IAM policies directly to groups and roles but not to users. For instructions on setting up an administrator for daily use, see [ Creating your first IAM admin user and group](https://docs.aws.amazon.com/IAM/latest/UserGuide/getting-started_create-admin-group.html) in the *IAM User Guide*.

### Remediation
<a name="iam-20-remediation"></a>

The steps to remediate this issue include setting up an Amazon SNS topic, a CloudTrail trail, a metric filter, and an alarm for the metric filter.

**To create an Amazon SNS topic**

1. Open the Amazon SNS console at [https://console.aws.amazon.com/sns/v3/home](https://console.aws.amazon.com/sns/v3/home).

1. Create an Amazon SNS topic that receives all CIS alarms.

   Create at least one subscriber to the topic. For more information, see [Getting started with Amazon SNS](https://docs.aws.amazon.com/sns/latest/dg/sns-getting-started.html#CreateTopic) in the *Amazon Simple Notification Service Developer Guide*.

Next, set up an active CloudTrail that applies to all Regions. To do so, follow the remediation steps in [[CloudTrail.1] CloudTrail should be enabled and configured with at least one multi-Region trail that includes read and write management events](cloudtrail-controls.md#cloudtrail-1).

Make a note of the name of the CloudWatch Logs log group that you associate with the CloudTrail trail. You create the metric filter for that log group.

Finally, create the metric filter and alarm.

**To create a metric filter and alarm**

1. Open the CloudWatch console at [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).

1. In the navigation pane, choose **Log groups**.

1. Select the check box for the CloudWatch Logs log group that is associated with the CloudTrail trail that you created.

1. From **Actions**, choose **Create Metric Filter**.

1. Under **Define pattern**, do the following:

   1. Copy the following pattern and then paste it into the **Filter Pattern** field.

      ```
      {$.userIdentity.type="Root" && $.userIdentity.invokedBy NOT EXISTS && $.eventType !="AwsServiceEvent"}
      ```

   1. Choose **Next**.

1. Under **Assign Metric**, do the following:

   1. In **Filter name**, enter a name for your metric filter.

   1. For **Metric Namespace**, enter **LogMetrics**.

      If you use the same namespace for all of your CIS log metric filters, then all CIS Benchmark metrics are grouped together.

   1. For **Metric Name**, enter a name for the metric. Remember the name of the metric. You will need to select the metric when you create the alarm.

   1. For **Metric value**, enter **1**.

   1. Choose **Next**.

1. Under **Review and create**, verify the information that you provided for the new metric filter. Then, choose **Create metric filter**.

1. In the navigation pane, choose **Log groups**, and then choose the filter you created under **Metric filters**.

1. Select the check box for the filter. Choose **Create alarm**.

1. Under **Specify metric and conditions**, do the following:

   1. Under **Conditions**, for **Threshold**, choose **Static**.

   1. For **Define the alarm condition**, choose **Greater/Equal**.

   1. For **Define the threshold value**, enter **1**.

   1. Choose **Next**.

1. Under **Configure actions**, do the following:

   1. Under **Alarm state trigger**, choose **In alarm**.

   1. Under **Select an SNS topic**, choose **Select an existing SNS topic**.

   1. For **Send a notification to**, enter the name of the SNS topic that you created in the previous procedure.

   1. Choose **Next**.

1. Under **Add name and description**, enter a **Name** and **Description** for the alarm, such as **CIS-1.1-RootAccountUsage**. Then choose **Next**.

1. Under **Preview and create**, review the alarm configuration. Then choose **Create alarm**.

## [IAM.21] IAM customer managed policies that you create should not allow wildcard actions for services
<a name="iam-21"></a>

**Related requirements:** NIST.800-53.r5 AC-2, NIST.800-53.r5 AC-2(1), NIST.800-53.r5 AC-3, NIST.800-53.r5 AC-3(15), NIST.800-53.r5 AC-3(7), NIST.800-53.r5 AC-5, NIST.800-53.r5 AC-6, NIST.800-53.r5 AC-6(10), NIST.800-53.r5 AC-6(2), NIST.800-53.r5 AC-6(3), NIST.800-171.r2 3.1.1, NIST.800-171.r2 3.1.2, NIST.800-171.r2 3.1.5, NIST.800-171.r2 3.1.7, NIST.800-171.r2 3.3.8, NIST.800-171.r2 3.3.9, NIST.800-171.r2 3.13.3, NIST.800-171.r2 3.13.4

**Category:** Detect > Secure access management 

**Severity:** Low

**Resource type:** `AWS::IAM::Policy`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/iam-policy-no-statements-with-full-access.html](https://docs.aws.amazon.com/config/latest/developerguide/iam-policy-no-statements-with-full-access.html)

**Schedule type:** Change triggered

**Parameters:**
+ `excludePermissionBoundaryPolicy`: `True` (not customizable)

This control checks whether the IAM identity-based policies that you create have Allow statements that use the \$1 wildcard to grant permissions for all actions on any service. The control fails if any policy statement includes `"Effect": "Allow"` with `"Action": "Service:*"`. 

For example, the following statement in a policy results in a failed finding.

```
"Statement": [
{
  "Sid": "EC2-Wildcard",
  "Effect": "Allow",
  "Action": "ec2:*",
  "Resource": "*"
}
```

The control also fails if you use `"Effect": "Allow"` with `"NotAction": "service:*"`. In that case, the `NotAction` element provides access to all of the actions in an AWS service, except for the actions specified in `NotAction`.

This control only applies to customer managed IAM policies. It does not apply to IAM policies that are managed by AWS.

When you assign permissions to AWS services, it is important to scope the allowed IAM actions in your IAM policies. You should restrict IAM actions to only those actions that are needed. This helps you to provision least privilege permissions. Overly permissive policies might lead to privilege escalation if the policies are attached to an IAM principal that might not require the permission.

In some cases, you might want to allow IAM actions that have a similar prefix, such as `DescribeFlowLogs` and `DescribeAvailabilityZones`. In these authorized cases, you can add a suffixed wildcard to the common prefix. For example, `ec2:Describe*`.

This control passes if you use a prefixed IAM action with a suffixed wildcard. For example, the following statement in a policy results in a passed finding.

```
"Statement": [
{
  "Sid": "EC2-Wildcard",
  "Effect": "Allow",
  "Action": "ec2:Describe*",
  "Resource": "*"
}
```

When you group related IAM actions in this way, you can also avoid exceeding the IAM policy size limits.

**Note**  
AWS Config should be enabled in all Regions in which you use Security Hub CSPM. However, global resource recording can be enabled in a single Region. If you only record global resources in a single Region, then you can disable this control in all Regions except the Region where you record global resources.

### Remediation
<a name="iam-21-remediation"></a>

To remediate this issue, update your IAM policies so that they do not allow full "\$1" administrative privileges. For details about how to edit an IAM policy, see [Editing IAM policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-edit.html) in the *IAM User Guide*.

## [IAM.22] IAM user credentials unused for 45 days should be removed
<a name="iam-22"></a>

**Related requirements:** CIS AWS Foundations Benchmark v5.0.0/1.11, CIS AWS Foundations Benchmark v3.0.0/1.12, CIS AWS Foundations Benchmark v1.4.0/1.12, NIST.800-171.r2 3.1.2

**Category:** Protect > Secure access management

**Severity:** Medium

**Resource type:** `AWS::IAM::User`

**AWS Config rule: **[https://docs.aws.amazon.com/config/latest/developerguide/iam-user-unused-credentials-check.html](https://docs.aws.amazon.com/config/latest/developerguide/iam-user-unused-credentials-check.html)

**Schedule type:** Periodic

**Parameters:** None

This control checks whether your IAM users have passwords or active access keys that have not been used for 45 days or more. To do so, it checks whether the `maxCredentialUsageAge` parameter of the AWS Config rule is equal to 45 or more.

Users can access AWS resources using different types of credentials, such as passwords or access keys.

CIS recommends that you remove or deactivate all credentials that have been unused for 45 days or more. Disabling or removing unnecessary credentials reduces the window of opportunity for credentials associated with a compromised or abandoned account to be used.

The AWS Config rule for this control uses the [https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetCredentialReport.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetCredentialReport.html) and [https://docs.aws.amazon.com/IAM/latest/APIReference/API_GenerateCredentialReport.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GenerateCredentialReport.html) API operations, which are only updated every four hours. Changes to IAM users can take up to four hours to be visible to this control.

**Note**  
AWS Config should be enabled in all Regions in which you use Security Hub CSPM. However, you can enable recording of global resources in a single Region. If you only record global resources in a single Region, then you can disable this control in all Regions except the Region where you record global resources.

### Remediation
<a name="iam-22-remediation"></a>

When you view user information in the IAM console, there are columns for **Access key age**, **Password age**, and **Last activity**. If the value in any of these columns is greater than 45 days, make the credentials for those users inactive.

You can also use [credential reports](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_getting-report.html#getting-credential-reports-console) to monitor users and identify those with no activity for 45 or more days. You can download credential reports in `.csv` format from the IAM console.

After you identify the inactive accounts or unused credentials, deactivate them. For instructions, see [Creating, changing, or deleting an IAM user password (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_passwords_admin-change-user.html#id_credentials_passwords_admin-change-user_console) in the *IAM User Guide*.

## [IAM.23] IAM Access Analyzer analyzers should be tagged
<a name="iam-23"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::AccessAnalyzer::Analyzer`

**AWS Config rule: ** `tagged-accessanalyzer-analyzer` (custom Security Hub CSPM rule)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  |  No default value  | 

This control checks whether an analyzer managed by AWS Identity and Access Management Access Analyzer (IAM Access Analyzer) has tags with the specific keys defined in the parameter `requiredTagKeys`. The control fails if the analyzer doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredTagKeys`. If the parameter `requiredTagKeys` isn't provided, the control only checks for the existence of a tag key and fails if the analyzer isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [What is ABAC for AWS?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Tagging your AWS resources](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *AWS General Reference*.

### Remediation
<a name="iam-23-remediation"></a>

To add tags to an analyzer, see [https://docs.aws.amazon.com/access-analyzer/latest/APIReference/API_TagResource.html](https://docs.aws.amazon.com/access-analyzer/latest/APIReference/API_TagResource.html) in the *AWS IAM Access Analyzer API Reference*.

## [IAM.24] IAM roles should be tagged
<a name="iam-24"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::IAM::Role`

**AWS Config rule: ** `tagged-iam-role` (custom Security Hub CSPM rule)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  |  No default value  | 

This control checks whether an AWS Identity and Access Management (IAM) role has tags with the specific keys defined in the parameter `requiredTagKeys`. The control fails if the role doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredTagKeys`. If the parameter `requiredTagKeys` isn't provided, the control only checks for the existence of a tag key and fails if the role isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [What is ABAC for AWS?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Tagging your AWS resources](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *AWS General Reference*.

### Remediation
<a name="iam-24-remediation"></a>

To add tags to an IAM role, see [Tagging IAM resources](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_tags.html) in the *IAM User Guide*.

## [IAM.25] IAM users should be tagged
<a name="iam-25"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::IAM::User`

**AWS Config rule: ** `tagged-iam-user` (custom Security Hub CSPM rule)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  |  No default value  | 

This control checks whether an AWS Identity and Access Management (IAM) user has tags with the specific keys defined in the parameter `requiredTagKeys`. The control fails if the user doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredTagKeys`. If the parameter `requiredTagKeys` isn't provided, the control only checks for the existence of a tag key and fails if the user isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [What is ABAC for AWS?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Tagging your AWS resources](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *AWS General Reference*.

### Remediation
<a name="iam-25-remediation"></a>

To add tags to an IAM user, see [Tagging IAM resources](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_tags.html) in the *IAM User Guide*.

## [IAM.26] Expired SSL/TLS certificates managed in IAM should be removed
<a name="iam-26"></a>

**Related requirements:** CIS AWS Foundations Benchmark v5.0.0/1.18, CIS AWS Foundations Benchmark v3.0.0/1.19

**Category:** Identify > Compliance

**Severity:** Medium

**Resource type:** `AWS::IAM::ServerCertificate`

**AWS Config rule: **[https://docs.aws.amazon.com/config/latest/developerguide/iam-server-certificate-expiration-check.html](https://docs.aws.amazon.com/config/latest/developerguide/iam-server-certificate-expiration-check.html)

**Schedule type:** Periodic

**Parameters:** None

This controls checks whether an active SSL/TLS server certificate that is managed in IAM has expired. The control fails if the expired SSL/TLS server certificate isn't removed.

To enable HTTPS connections to your website or application in AWS, you need an SSL/TLS server certificate. You can use IAM or AWS Certificate Manager (ACM) to store and deploy server certificates. Use IAM as a certificate manager only when you must support HTTPS connections in an AWS Region that isn't supported by ACM. IAM securely encrypts your private keys and stores the encrypted version in IAM SSL certificate storage. IAM supports deploying server certificates in all Regions, but you must obtain your certificate from an external provider for use with AWS. You can't upload an ACM certificate to IAM. Additionally, you can't manage your certificates from the IAM console. Removing expired SSL/TLS certificates eliminates the risk that an invalid certificate is deployed accidentally to a resource, which can damage the credibility of the underlying application or website.

### Remediation
<a name="iam-26-remediation"></a>

To remove a server certificate from IAM, see [Managing server certificates in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_server-certs.html) in the *IAM User Guide*.

## [IAM.27] IAM identities should not have the AWSCloudShellFullAccess policy attached
<a name="iam-27"></a>

**Related requirements:** CIS AWS Foundations Benchmark v5.0.0/1.21, CIS AWS Foundations Benchmark v3.0.0/1.22

**Category:** Protect > Secure access management > Secure IAM policies

**Severity:** Medium

**Resource type:** `AWS::IAM::Role`, `AWS::IAM::User`, `AWS::IAM::Group`

**AWS Config rule: **[https://docs.aws.amazon.com/config/latest/developerguide/iam-policy-blacklisted-check.html](https://docs.aws.amazon.com/config/latest/developerguide/iam-policy-blacklisted-check.html)

**Schedule type:** Change triggered

**Parameters:**
+ "policyArns": "arn:aws:iam::aws:policy/AWSCloudShellFullAccess,arn:aws-cn:iam::aws:policy/AWSCloudShellFullAccess, arn:aws-us-gov:iam::aws:policy/AWSCloudShellFullAccess"

This control checks whether an IAM identity (user, role, or group) has the AWS managed policy `AWSCloudShellFullAccess` attached. The control fails if an IAM identity has the `AWSCloudShellFullAccess` policy attached.

AWS CloudShell provides a convenient way to run CLI commands against AWS services. The AWS managed policy `AWSCloudShellFullAccess` provides full access to CloudShell, which allows file upload and download capability between a user's local system and the CloudShell environment. Within the CloudShell environment, a user has sudo permissions, and can access the internet. As a result, atttaching this managed policy to an IAM identity gives them the ability to install file transfer software and move data from CloudShell to external internet servers. We recommend following the principle of least privilege and attaching narrower permissions to your IAM identities.

### Remediation
<a name="iam-27-remediation"></a>

To detach the `AWSCloudShellFullAccess` policy from an IAM identity, see [Adding and removing IAM identity permissions](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html) in the *IAM User Guide*.

## [IAM.28] IAM Access Analyzer external access analyzer should be enabled
<a name="iam-28"></a>

**Related requirements:** CIS AWS Foundations Benchmark v5.0.0/1.19, CIS AWS Foundations Benchmark v3.0.0/1.20

**Category:** Detect > Detection services > Privileged usage monitoring

**Severity:** High

**Resource type:** `AWS::AccessAnalyzer::Analyzer`

**AWS Config rule: **[https://docs.aws.amazon.com/config/latest/developerguide/iam-external-access-analyzer-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/iam-external-access-analyzer-enabled.html)

**Schedule type:** Periodic

**Parameters:** None

This control checks whether an AWS account has an IAM Access Analyzer external access analyzer enabled. The control fails if the account doesn't have an external access analyzer enabled in your currently selected AWS Region.

IAM Access Analyzer external access analyzers help identify resources, such as Amazon Simple Storage Service (Amazon S3) buckets or IAM roles, that are shared with an external entity. This helps you avoid unintended access to your resources and data. IAM Access Analyzer is Regional and must be enabled in each Region. To identify resources that are shared with external principals, an access analyzer uses logic-based reasoning to analyze resource-based policies in your AWS environment. When you create an external access analyzer, you can create and enable it for your entire organization or individual accounts.

**Note**  
If an account is part of an organization in AWS Organizations, this control doesn't factor external access analyzers that specify the organization as the zone of trust and are enabled for the organization in the current Region. If your organization uses this type of configuration, consider disabling this control for individual member accounts in your organization in the Region.

### Remediation
<a name="iam-28-remediation"></a>

For information about enabling an external access analyzer in a specific Region, see [Getting started with IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-getting-started.html) in the *IAM User Guide*. You must enable an analyzer in each Region in which you want to monitor access to your resources.

# Security Hub CSPM controls for Amazon Inspector
<a name="inspector-controls"></a>

These AWS Security Hub CSPM controls evaluate the Amazon Inspector service and resources.

These controls may not be available in all AWS Regions. For more information, see [Availability of controls by Region](securityhub-regions.md#securityhub-regions-control-support).

## [Inspector.1] Amazon Inspector EC2 scanning should be enabled
<a name="inspector-1"></a>

**Related requirements:** PCI DSS v4.0.1/11.3.1

**Category:** Detect > Detection services

**Severity:** High

**Resource type:** `AWS::::Account`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/inspector-ec2-scan-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/inspector-ec2-scan-enabled.html)

**Schedule type:** Periodic

**Parameters:** None

This control checks whether Amazon Inspector EC2 scanning is enabled. For a standalone account, the control fails if Amazon Inspector EC2 scanning is disabled in the account. In a multi-account environment, the control fails if the delegated Amazon Inspector administrator account and all member accounts don't have EC2 scanning enabled.

In a multi-account environment, the control generates findings in only the delegated Amazon Inspector administrator account. Only the delegated administrator can enable or disable the EC2 scanning feature for the member accounts in the organization. Amazon Inspector member accounts can't modify this configuration from their accounts. This control generates `FAILED` findings if the delegated administrator has a suspended member account that doesn't have Amazon Inspector EC2 scanning enabled. To receive a `PASSED` finding, the delegated administrator must disassociate these suspended accounts in Amazon Inspector.

Amazon Inspector EC2 scanning extracts metadata from your Amazon Elastic Compute Cloud (Amazon EC2) instance, and then compares this metadata against rules collected from security advisories to produce findings. Amazon Inspector scans instances for package vulnerabilities and network reachability issues. For information about supported operating systems, including which operating system can be scanned without an SSM agent, see [Supported operating systems: Amazon EC2 scanning](https://docs.aws.amazon.com/inspector/latest/user/supported.html#supported-os-ec2).

### Remediation
<a name="inspector-1-remediation"></a>

To enable Amazon Inspector EC2 scanning, see [Activating scans](https://docs.aws.amazon.com/inspector/latest/user/activate-scans.html#activate-scans-proc) in the *Amazon Inspector User Guide*.

## [Inspector.2] Amazon Inspector ECR scanning should be enabled
<a name="inspector-2"></a>

**Related requirements:** PCI DSS v4.0.1/11.3.1

**Category:** Detect > Detection services

**Severity:** High

**Resource type:** `AWS::::Account`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/inspector-ecr-scan-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/inspector-ecr-scan-enabled.html)

**Schedule type:** Periodic

**Parameters:** None

This control checks whether Amazon Inspector ECR scanning is enabled. For a standalone account, the control fails if Amazon Inspector ECR scanning is disabled in the account. In a multi-account environment, the control fails if the delegated Amazon Inspector administrator account and all member accounts don't have ECR scanning enabled.

In a multi-account environment, the control generates findings in only the delegated Amazon Inspector administrator account. Only the delegated administrator can enable or disable the ECR scanning feature for the member accounts in the organization. Amazon Inspector member accounts can't modify this configuration from their accounts. This control generates `FAILED` findings if the delegated administrator has a suspended member account that doesn't have Amazon Inspector ECR scanning enabled. To receive a `PASSED` finding, the delegated administrator must disassociate these suspended accounts in Amazon Inspector.

Amazon Inspector scans container images stored in Amazon Elastic Container Registry (Amazon ECR) for software vulnerabilities to generate package vulnerability findings. When you activate Amazon Inspector scans for Amazon ECR, you set Amazon Inspector as your preferred scanning service for your private registry. This replaces basic scanning, which is provided at no charge by Amazon ECR, with enhanced scanning, which is provided and billed through Amazon Inspector. Enhanced scanning gives you the benefit of vulnerability scanning for both operating system and programming language packages at the registry level. You can review findings discovered using enhanced scanning at the image level, for each layer of the image, on the Amazon ECR console. Additionally, you can review and work with these findings in other services not available for basic scanning findings, including AWS Security Hub CSPM and Amazon EventBridge.

### Remediation
<a name="inspector-2-remediation"></a>

To enable Amazon Inspector ECR scanning, see [Activating scans](https://docs.aws.amazon.com/inspector/latest/user/activate-scans.html#activate-scans-proc) in the *Amazon Inspector User Guide*.

## [Inspector.3] Amazon Inspector Lambda code scanning should be enabled
<a name="inspector-3"></a>

**Related requirements:** PCI DSS v4.0.1/6.2.4, PCI DSS v4.0.1/6.3.1

**Category:** Detect > Detection services

**Severity:** High

**Resource type:** `AWS::::Account`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/inspector-lambda-code-scan-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/inspector-lambda-code-scan-enabled.html)

**Schedule type:** Periodic

**Parameters:** None

This control checks whether Amazon Inspector Lambda code scanning is enabled. For a standalone account, the control fails if Amazon Inspector Lambda code scanning is disabled in the account. In a multi-account environment, the control fails if the delegated Amazon Inspector administrator account and all member accounts don't have Lambda code scanning enabled.

In a multi-account environment, the control generates findings in only the delegated Amazon Inspector administrator account. Only the delegated administrator can enable or disable the Lambda code scanning feature for the member accounts in the organization. Amazon Inspector member accounts can't modify this configuration from their accounts. This control generates `FAILED` findings if the delegated administrator has a suspended member account that doesn't have Amazon Inspector Lambda code scanning enabled. To receive a `PASSED` finding, the delegated administrator must disassociate these suspended accounts in Amazon Inspector.

Amazon Inspector Lambda code scanning scans the custom application code within an AWS Lambda function for code vulnerabilities based on AWS security best practices. Lambda code scanning can detect injection flaws, data leaks, weak cryptography, or missing encryption in your code. This feature is available in [specific AWS Regions only](https://docs.aws.amazon.com/inspector/latest/user/inspector_regions.html#ins-regional-feature-availability). You can activate Lambda code scanning together with Lambda standard scanning (see [[Inspector.4] Amazon Inspector Lambda standard scanning should be enabled](#inspector-4)).

### Remediation
<a name="inspector-3-remediation"></a>

To enable Amazon Inspector Lambda code scanning, see [Activating scans](https://docs.aws.amazon.com/inspector/latest/user/activate-scans.html#activate-scans-proc) in the *Amazon Inspector User Guide*.

## [Inspector.4] Amazon Inspector Lambda standard scanning should be enabled
<a name="inspector-4"></a>

**Related requirements:** PCI DSS v4.0.1/6.2.4, PCI DSS v4.0.1/6.3.1

**Category:** Detect > Detection services

**Severity:** High

**Resource type:** `AWS::::Account`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/inspector-lambda-standard-scan-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/inspector-lambda-standard-scan-enabled.html)

**Schedule type:** Periodic

**Parameters:** None

This control checks whether Amazon Inspector Lambda standard scanning is enabled. For a standalone account, the control fails if Amazon Inspector Lambda standard scanning is disabled in the account. In a multi-account environment, the control fails if the delegated Amazon Inspector administrator account and all member accounts don't have Lambda standard scanning enabled.

In a multi-account environment, the control generates findings in only the delegated Amazon Inspector administrator account. Only the delegated administrator can enable or disable the Lambda standard scanning feature for the member accounts in the organization. Amazon Inspector member accounts can't modify this configuration from their accounts. This control generates `FAILED` findings if the delegated administrator has a suspended member account that doesn't have Amazon Inspector Lambda standard scanning enabled. To receive a `PASSED` finding, the delegated administrator must disassociate these suspended accounts in Amazon Inspector.

Amazon Inspector Lambda standard scanning identifies software vulnerabilities in the application package dependencies you add to your AWS Lambda function code and layers. If Amazon Inspector detects a vulnerability in your Lambda function application package dependencies, Amazon Inspector produces a detailed `Package Vulnerability` type finding. You can activate Lambda code scanning together with Lambda standard scanning (see [[Inspector.3] Amazon Inspector Lambda code scanning should be enabled](#inspector-3)). 

### Remediation
<a name="inspector-4-remediation"></a>

To enable Amazon Inspector Lambda standard scanning, see [Activating scans](https://docs.aws.amazon.com/inspector/latest/user/activate-scans.html#activate-scans-proc) in the *Amazon Inspector User Guide*.

# Security Hub CSPM controls for AWS IoT
<a name="iot-controls"></a>

These AWS Security Hub CSPM controls evaluate the AWS IoT service and resources.

These controls may not be available in all AWS Regions. For more information, see [Availability of controls by Region](securityhub-regions.md#securityhub-regions-control-support).

## [IoT.1] AWS IoT Device Defender security profiles should be tagged
<a name="iot-1"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::IoT::SecurityProfile`

**AWS Config rule:** `tagged-iot-securityprofile` (custom Security Hub CSPM rule)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  |  No default value  | 

This control checks whether an AWS IoT Device Defender security profile has tags with the specific keys defined in the parameter `requiredTagKeys`. The control fails if the security profile doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredTagKeys`. If the parameter `requiredTagKeys` isn't provided, the control only checks for the existence of a tag key and fails if the security profile isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [What is ABAC for AWS?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Tagging your AWS resources](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *AWS General Reference*.

### Remediation
<a name="iot-1-remediation"></a>

To add tags to an AWS IoT Device Defender security profile, see [Tagging your AWS IoT resources](https://docs.aws.amazon.com/iot/latest/developerguide/tagging-iot.html) in the *AWS IoT Developer Guide*.

## [IoT.2] AWS IoT Core mitigation actions should be tagged
<a name="iot-2"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::IoT::MitigationAction`

**AWS Config rule:** `tagged-iot-mitigationaction` (custom Security Hub CSPM rule)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  |  No default value  | 

This control checks whether an AWS IoT Core mitigation action has tags with the specific keys defined in the parameter `requiredTagKeys`. The control fails if the mitigation action doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredTagKeys`. If the parameter `requiredTagKeys` isn't provided, the control only checks for the existence of a tag key and fails if the mitigation action isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [What is ABAC for AWS?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Tagging your AWS resources](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *AWS General Reference*.

### Remediation
<a name="iot-2-remediation"></a>

To add tags to an AWS IoT Core mitigation action, see [Tagging your AWS IoT resources](https://docs.aws.amazon.com/iot/latest/developerguide/tagging-iot.html) in the *AWS IoT Developer Guide*.

## [IoT.3] AWS IoT Core dimensions should be tagged
<a name="iot-3"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::IoT::Dimension`

**AWS Config rule:** `tagged-iot-dimension` (custom Security Hub CSPM rule)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  |  No default value  | 

This control checks whether an AWS IoT Core dimension has tags with the specific keys defined in the parameter `requiredTagKeys`. The control fails if the dimension doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredTagKeys`. If the parameter `requiredTagKeys` isn't provided, the control only checks for the existence of a tag key and fails if the dimension isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [What is ABAC for AWS?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Tagging your AWS resources](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *AWS General Reference*.

### Remediation
<a name="iot-3-remediation"></a>

To add tags to an AWS IoT Core dimension, see [Tagging your AWS IoT resources](https://docs.aws.amazon.com/iot/latest/developerguide/tagging-iot.html) in the *AWS IoT Developer Guide*.

## [IoT.4] AWS IoT Core authorizers should be tagged
<a name="iot-4"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::IoT::Authorizer`

**AWS Config rule:** `tagged-iot-authorizer` (custom Security Hub CSPM rule)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  |  No default value  | 

This control checks whether an AWS IoT Core authorizer has tags with the specific keys defined in the parameter `requiredTagKeys`. The control fails if the authorizer doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredTagKeys`. If the parameter `requiredTagKeys` isn't provided, the control only checks for the existence of a tag key and fails if the authorizer isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [What is ABAC for AWS?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Tagging your AWS resources](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *AWS General Reference*.

### Remediation
<a name="iot-4-remediation"></a>

To add tags to an AWS IoT Core authorizer, see [Tagging your AWS IoT resources](https://docs.aws.amazon.com/iot/latest/developerguide/tagging-iot.html) in the *AWS IoT Developer Guide*.

## [IoT.5] AWS IoT Core role aliases should be tagged
<a name="iot-5"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::IoT::RoleAlias`

**AWS Config rule:** `tagged-iot-rolealias` (custom Security Hub CSPM rule)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  |  No default value  | 

This control checks whether an AWS IoT Core role alias has tags with the specific keys defined in the parameter `requiredTagKeys`. The control fails if the role alias doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredTagKeys`. If the parameter `requiredTagKeys` isn't provided, the control only checks for the existence of a tag key and fails if the role alias isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [What is ABAC for AWS?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Tagging your AWS resources](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *AWS General Reference*.

### Remediation
<a name="iot-5-remediation"></a>

To add tags to an AWS IoT Core role alias, see [Tagging your AWS IoT resources](https://docs.aws.amazon.com/iot/latest/developerguide/tagging-iot.html) in the *AWS IoT Developer Guide*.

## [IoT.6] AWS IoT Core policies should be tagged
<a name="iot-6"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::IoT::Policy`

**AWS Config rule:** `tagged-iot-policy` (custom Security Hub CSPM rule)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  |  No default value  | 

This control checks whether an AWS IoT Core policy has tags with the specific keys defined in the parameter `requiredTagKeys`. The control fails if the policy doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredTagKeys`. If the parameter `requiredTagKeys` isn't provided, the control only checks for the existence of a tag key and fails if the policy isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [What is ABAC for AWS?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Tagging your AWS resources](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *AWS General Reference*.

### Remediation
<a name="iot-6-remediation"></a>

To add tags to an AWS IoT Core policy, see [Tagging your AWS IoT resources](https://docs.aws.amazon.com/iot/latest/developerguide/tagging-iot.html) in the *AWS IoT Developer Guide*.

# Security Hub CSPM controls for AWS IoT Events
<a name="iotevents-controls"></a>

These AWS Security Hub CSPM controls evaluate the AWS IoT Events service and resources.

These controls may not be available in all AWS Regions. For more information, see [Availability of controls by Region](securityhub-regions.md#securityhub-regions-control-support).

## [IoTEvents.1] AWS IoT Events inputs should be tagged
<a name="iotevents-1"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::IoTEvents::Input`

**AWS Config rule:** `iotevents-input-tagged`

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredKeyTags  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  |  No default value  | 

This control checks whether an AWS IoT Events input has tags with the specific keys defined in the parameter `requiredKeyTags`. The control fails if the input doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredKeyTags`. If the parameter `requiredKeyTags` isn't provided, the control only checks for the existence of a tag key and fails if the input isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [Define permissions based on attributes with ABAC authorization](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Best practices and strategies](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *Tagging AWS Resources and Tag Editor User Guide*.

### Remediation
<a name="iotevents-1-remediation"></a>

To add tags to an AWS IoT Events input, see [Tagging your AWS IoT Events resources](https://docs.aws.amazon.com/iotevents/latest/developerguide/tagging-iotevents.html) in the *AWS IoT Events Developer Guide*.

## [IoTEvents.2] AWS IoT Events detector models should be tagged
<a name="iotevents-2"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::IoTEvents::DetectorModel`

**AWS Config rule:** `iotevents-detector-model-tagged`

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredKeyTags  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  |  No default value  | 

This control checks whether an AWS IoT Events detector model has tags with the specific keys defined in the parameter `requiredKeyTags`. The control fails if the detector model doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredKeyTags`. If the parameter `requiredKeyTags` isn't provided, the control only checks for the existence of a tag key and fails if the detector model isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [Define permissions based on attributes with ABAC authorization](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Best practices and strategies](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *Tagging AWS Resources and Tag Editor User Guide*.

### Remediation
<a name="iotevents-2-remediation"></a>

To add tags to an AWS IoT Events detector model, see [Tagging your AWS IoT Events resources](https://docs.aws.amazon.com/iotevents/latest/developerguide/tagging-iotevents.html) in the *AWS IoT Events Developer Guide*.

## [IoTEvents.3] AWS IoT Events alarm models should be tagged
<a name="iotevents-3"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::IoTEvents::AlarmModel`

**AWS Config rule:** `iotevents-alarm-model-tagged`

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredKeyTags  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  |  No default value  | 

This control checks whether an AWS IoT Events alarm model has tags with the specific keys defined in the parameter `requiredKeyTags`. The control fails if the alarm model doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredKeyTags`. If the parameter `requiredKeyTags` isn't provided, the control only checks for the existence of a tag key and fails if the alarm model isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [Define permissions based on attributes with ABAC authorization](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Best practices and strategies](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *Tagging AWS Resources and Tag Editor User Guide*.

### Remediation
<a name="iotevents-3-remediation"></a>

To add tags to an AWS IoT Events alarm model, see [Tagging your AWS IoT Events resources](https://docs.aws.amazon.com/iotevents/latest/developerguide/tagging-iotevents.html) in the *AWS IoT Events Developer Guide*.

# Security Hub CSPM controls for AWS IoT SiteWise
<a name="iotsitewise-controls"></a>

These AWS Security Hub CSPM controls evaluate the AWS IoT SiteWise service and resources.

These controls may not be available in all AWS Regions. For more information, see [Availability of controls by Region](securityhub-regions.md#securityhub-regions-control-support).

## [IoTSiteWise.1] AWS IoT SiteWise asset models should be tagged
<a name="iotsitewise-1"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::IoTSiteWise::AssetModel`

**AWS Config rule:** `iotsitewise-asset-model-tagged`

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredKeyTags  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  |  No default value  | 

This control checks whether an AWS IoT SiteWise asset model has tags with the specific keys defined in the parameter `requiredKeyTags`. The control fails if the asset model doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredKeyTags`. If the parameter `requiredKeyTags` isn't provided, the control only checks for the existence of a tag key and fails if the asset model isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [Define permissions based on attributes with ABAC authorization](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Best practices and strategies](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *Tagging AWS Resources and Tag Editor User Guide*.

### Remediation
<a name="iotsitewise-1-remediation"></a>

To add tags to an AWS IoT SiteWise asset model, see [Tag your AWS IoT SiteWise resources](https://docs.aws.amazon.com/iot-sitewise/latest/userguide/tag-resources.html) in the *AWS IoT SiteWise User Guide*.

## [IoTSiteWise.2] AWS IoT SiteWise dashboards should be tagged
<a name="iotsitewise-2"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::IoTSiteWise::Dashboard`

**AWS Config rule:** `iotsitewise-dashboard-tagged`

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredKeyTags  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  |  No default value  | 

This control checks whether an AWS IoT SiteWise dashboard has tags with the specific keys defined in the parameter `requiredKeyTags`. The control fails if the dashboard doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredKeyTags`. If the parameter `requiredKeyTags` isn't provided, the control only checks for the existence of a tag key and fails if the dashboard isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [Define permissions based on attributes with ABAC authorization](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Best practices and strategies](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *Tagging AWS Resources and Tag Editor User Guide*.

### Remediation
<a name="iotsitewise-2-remediation"></a>

To add tags to an AWS IoT SiteWise dashboard, see [Tag your AWS IoT SiteWise resources](https://docs.aws.amazon.com/iot-sitewise/latest/userguide/tag-resources.html) in the *AWS IoT SiteWise User Guide*.

## [IoTSiteWise.3] AWS IoT SiteWise gateways should be tagged
<a name="iotsitewise-3"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::IoTSiteWise::Gateway`

**AWS Config rule:** `iotsitewise-gateway-tagged`

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredKeyTags  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  |  No default value  | 

This control checks whether an AWS IoT SiteWise gateway has tags with the specific keys defined in the parameter `requiredKeyTags`. The control fails if the gateway doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredKeyTags`. If the parameter `requiredKeyTags` isn't provided, the control only checks for the existence of a tag key and fails if the gateway isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [Define permissions based on attributes with ABAC authorization](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Best practices and strategies](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *Tagging AWS Resources and Tag Editor User Guide*.

### Remediation
<a name="iotsitewise-3-remediation"></a>

To add tags to an AWS IoT SiteWise gateway, see [Tag your AWS IoT SiteWise resources](https://docs.aws.amazon.com/iot-sitewise/latest/userguide/tag-resources.html) in the *AWS IoT SiteWise User Guide*.

## [IoTSiteWise.4] AWS IoT SiteWise portals should be tagged
<a name="iotsitewise-4"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::IoTSiteWise::Portal`

**AWS Config rule:** `iotsitewise-portal-tagged`

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredKeyTags  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  |  No default value  | 

This control checks whether an AWS IoT SiteWise portal has tags with the specific keys defined in the parameter `requiredKeyTags`. The control fails if the portal doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredKeyTags`. If the parameter `requiredKeyTags` isn't provided, the control only checks for the existence of a tag key and fails if the portal isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [Define permissions based on attributes with ABAC authorization](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Best practices and strategies](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *Tagging AWS Resources and Tag Editor User Guide*.

### Remediation
<a name="iotsitewise-4-remediation"></a>

To add tags to an AWS IoT SiteWise portal, see [Tag your AWS IoT SiteWise resources](https://docs.aws.amazon.com/iot-sitewise/latest/userguide/tag-resources.html) in the *AWS IoT SiteWise User Guide*.

## [IoTSiteWise.5] AWS IoT SiteWise projects should be tagged
<a name="iotsitewise-5"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::IoTSiteWise::Project`

**AWS Config rule:** `iotsitewise-project-tagged`

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredKeyTags  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  |  No default value  | 

This control checks whether an AWS IoT SiteWise project has tags with the specific keys defined in the parameter `requiredKeyTags`. The control fails if the project doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredKeyTags`. If the parameter `requiredKeyTags` isn't provided, the control only checks for the existence of a tag key and fails if the project isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [Define permissions based on attributes with ABAC authorization](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Best practices and strategies](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *Tagging AWS Resources and Tag Editor User Guide*.

### Remediation
<a name="iotsitewise-5-remediation"></a>

To add tags to an AWS IoT SiteWise project, see [Tag your AWS IoT SiteWise resources](https://docs.aws.amazon.com/iot-sitewise/latest/userguide/tag-resources.html) in the *AWS IoT SiteWise User Guide*.

# Security Hub CSPM controls for AWS IoT TwinMaker
<a name="iottwinmaker-controls"></a>

These AWS Security Hub CSPM controls evaluate the AWS IoT TwinMaker service and resources.

These controls may not be available in all AWS Regions. For more information, see [Availability of controls by Region](securityhub-regions.md#securityhub-regions-control-support).

## [IoTTwinMaker.1] AWS IoT TwinMaker sync jobs should be tagged
<a name="iottwinmaker-1"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::IoTTwinMaker::SyncJob`

**AWS Config rule:** `iottwinmaker-sync-job-tagged`

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredKeyTags  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  |  No default value  | 

This control checks whether an AWS IoT TwinMaker sync job has tags with the specific keys defined in the parameter `requiredKeyTags`. The control fails if the sync job doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredKeyTags`. If the parameter `requiredKeyTags` isn't provided, the control only checks for the existence of a tag key and fails if the sync job isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [Define permissions based on attributes with ABAC authorization](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Best practices and strategies](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *Tagging AWS Resources and Tag Editor User Guide*.

### Remediation
<a name="iottwinmaker-1-remediation"></a>

To add tags to an AWS IoT TwinMaker sync job, see [https://docs.aws.amazon.com/iot-twinmaker/latest/apireference/API_TagResource.html](https://docs.aws.amazon.com/iot-twinmaker/latest/apireference/API_TagResource.html) in the *AWS IoT TwinMaker User Guide*.

## [IoTTwinMaker.2] AWS IoT TwinMaker workspaces should be tagged
<a name="iottwinmaker-2"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::IoTTwinMaker::Workspace`

**AWS Config rule:** `iottwinmaker-workspace-tagged`

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredKeyTags  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  |  No default value  | 

This control checks whether an AWS IoT TwinMaker workspace has tags with the specific keys defined in the parameter `requiredKeyTags`. The control fails if the workspace doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredKeyTags`. If the parameter `requiredKeyTags` isn't provided, the control only checks for the existence of a tag key and fails if the workspace isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [Define permissions based on attributes with ABAC authorization](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Best practices and strategies](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *Tagging AWS Resources and Tag Editor User Guide*.

### Remediation
<a name="iottwinmaker-2-remediation"></a>

To add tags to an AWS IoT TwinMaker workspace, see [https://docs.aws.amazon.com/iot-twinmaker/latest/apireference/API_TagResource.html](https://docs.aws.amazon.com/iot-twinmaker/latest/apireference/API_TagResource.html) in the *AWS IoT TwinMaker User Guide*.

## [IoTTwinMaker.3] AWS IoT TwinMaker scenes should be tagged
<a name="iottwinmaker-3"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::IoTTwinMaker::Scene`

**AWS Config rule:** `iottwinmaker-scene-tagged`

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredKeyTags  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  |  No default value  | 

This control checks whether an AWS IoT TwinMaker scene has tags with the specific keys defined in the parameter `requiredKeyTags`. The control fails if the scene doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredKeyTags`. If the parameter `requiredKeyTags` isn't provided, the control only checks for the existence of a tag key and fails if the scene isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [Define permissions based on attributes with ABAC authorization](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Best practices and strategies](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *Tagging AWS Resources and Tag Editor User Guide*.

### Remediation
<a name="iottwinmaker-3-remediation"></a>

To add tags to an AWS IoT TwinMaker scene, see [https://docs.aws.amazon.com/iot-twinmaker/latest/apireference/API_TagResource.html](https://docs.aws.amazon.com/iot-twinmaker/latest/apireference/API_TagResource.html) in the *AWS IoT TwinMaker User Guide*.

## [IoTTwinMaker.4] AWS IoT TwinMaker entities should be tagged
<a name="iottwinmaker-4"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::IoTTwinMaker::Entity`

**AWS Config rule:** `iottwinmaker-entity-tagged`

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredKeyTags  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  |  No default value  | 

This control checks whether an AWS IoT TwinMaker entity has tags with the specific keys defined in the parameter `requiredKeyTags`. The control fails if the entity doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredKeyTags`. If the parameter `requiredKeyTags` isn't provided, the control only checks for the existence of a tag key and fails if the entity isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [Define permissions based on attributes with ABAC authorization](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Best practices and strategies](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *Tagging AWS Resources and Tag Editor User Guide*.

### Remediation
<a name="iottwinmaker-4-remediation"></a>

To add tags to an AWS IoT TwinMaker entity, see [https://docs.aws.amazon.com/iot-twinmaker/latest/apireference/API_TagResource.html](https://docs.aws.amazon.com/iot-twinmaker/latest/apireference/API_TagResource.html) in the *AWS IoT TwinMaker User Guide*.

# Security Hub CSPM controls for AWS IoT Wireless
<a name="iotwireless-controls"></a>

These AWS Security Hub CSPM controls evaluate the AWS IoT Wireless service and resources.

These controls may not be available in all AWS Regions. For more information, see [Availability of controls by Region](securityhub-regions.md#securityhub-regions-control-support).

## [IoTWireless.1] AWS IoT Wireless multicast groups should be tagged
<a name="iotwireless-1"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::IoTWireless::MulticastGroup`

**AWS Config rule:** `iotwireless-multicast-group-tagged`

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredKeyTags  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  |  No default value  | 

This control checks whether an AWS IoT Wireless multicast group has tags with the specific keys defined in the parameter `requiredKeyTags`. The control fails if the multicast group doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredKeyTags`. If the parameter `requiredKeyTags` isn't provided, the control only checks for the existence of a tag key and fails if the multicast group isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [Define permissions based on attributes with ABAC authorization](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Best practices and strategies](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *Tagging AWS Resources and Tag Editor User Guide*.

### Remediation
<a name="iotwireless-1-remediation"></a>

To add tags to an AWS IoT Wireless multicast group, see [Tagging your AWS IoT Wireless resources](https://docs.aws.amazon.com/iot-wireless/latest/developerguide/tagging-iotwireless.html) in the *AWS IoT Wireless Developer Guide*.

## [IoTWireless.2] AWS IoT Wireless service profiles should be tagged
<a name="iotwireless-2"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::IoTWireless::ServiceProfile`

**AWS Config rule:** `iotwireless-service-profile-tagged`

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredKeyTags  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  |  No default value  | 

This control checks whether an AWS IoT Wireless service profile has tags with the specific keys defined in the parameter `requiredKeyTags`. The control fails if the service profile doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredKeyTags`. If the parameter `requiredKeyTags` isn't provided, the control only checks for the existence of a tag key and fails if the service profile isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [Define permissions based on attributes with ABAC authorization](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Best practices and strategies](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *Tagging AWS Resources and Tag Editor User Guide*.

### Remediation
<a name="iotwireless-2-remediation"></a>

To add tags to an AWS IoT Wireless service profile, see [Tagging your AWS IoT Wireless resources](https://docs.aws.amazon.com/iot-wireless/latest/developerguide/tagging-iotwireless.html) in the *AWS IoT Wireless Developer Guide*.

## [IoTWireless.3] AWS IoT FUOTA tasks should be tagged
<a name="iotwireless-3"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::IoTWireless::FuotaTask`

**AWS Config rule:** `iotwireless-fuota-task-tagged`

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredKeyTags  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  |  No default value  | 

This control checks whether an AWS IoT Wireless firmware update over-the-air (FUOTA) task has tags with the specific keys defined in the parameter `requiredKeyTags`. The control fails if the FUOTA task doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredKeyTags`. If the parameter `requiredKeyTags` isn't provided, the control only checks for the existence of a tag key and fails if the FUOTA task isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [Define permissions based on attributes with ABAC authorization](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Best practices and strategies](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *Tagging AWS Resources and Tag Editor User Guide*.

### Remediation
<a name="iotwireless-3-remediation"></a>

To add tags to an AWS IoT Wireless FUOTA task, see [Tagging your AWS IoT Wireless resources](https://docs.aws.amazon.com/iot-wireless/latest/developerguide/tagging-iotwireless.html) in the *AWS IoT Wireless Developer Guide*.

# Security Hub CSPM controls for Amazon IVS
<a name="ivs-controls"></a>

These AWS Security Hub CSPM controls evaluate the Amazon Interactive Video Service (IVS) service and resources.

These controls may not be available in all AWS Regions. For more information, see [Availability of controls by Region](securityhub-regions.md#securityhub-regions-control-support).

## [IVS.1] IVS playback key pairs should be tagged
<a name="ivs-1"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::IVS::PlaybackKeyPair`

**AWS Config rule:** `ivs-playback-key-pair-tagged`

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredKeyTags  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  |  No default value  | 

This control checks whether an Amazon IVS playback key pair has tags with the specific keys defined in the parameter `requiredKeyTags`. The control fails if the playback key pair doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredKeyTags`. If the parameter `requiredKeyTags` isn't provided, the control only checks for the existence of a tag key and fails if the playback key pair isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [Define permissions based on attributes with ABAC authorization](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Best practices and strategies](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *Tagging AWS Resources and Tag Editor User Guide*.

### Remediation
<a name="ivs-1-remediation"></a>

To add tags to an IVS playback key pair, see [https://docs.aws.amazon.com/ivs/latest/RealTimeAPIReference/API_TagResource.html](https://docs.aws.amazon.com/ivs/latest/RealTimeAPIReference/API_TagResource.html) in the *Amazon IVS Real-Time Streaming API Reference*.

## [IVS.2] IVS recording configurations should be tagged
<a name="ivs-2"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::IVS::RecordingConfiguration`

**AWS Config rule:** `ivs-recording configuration-tagged`

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredKeyTags  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  |  No default value  | 

This control checks whether an Amazon IVS recording configuration has tags with the specific keys defined in the parameter `requiredKeyTags`. The control fails if the recording configuration doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredKeyTags`. If the parameter `requiredKeyTags` isn't provided, the control only checks for the existence of a tag key and fails if the recording configuration isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [Define permissions based on attributes with ABAC authorization](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Best practices and strategies](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *Tagging AWS Resources and Tag Editor User Guide*.

### Remediation
<a name="ivs-2-remediation"></a>

To add tags to an IVS recording configuration, see [https://docs.aws.amazon.com/ivs/latest/RealTimeAPIReference/API_TagResource.html](https://docs.aws.amazon.com/ivs/latest/RealTimeAPIReference/API_TagResource.html) in the *Amazon IVS Real-Time Streaming API Reference*.

## [IVS.3] IVS channels should be tagged
<a name="ivs-3"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::IVS::Channel`

**AWS Config rule:** `ivs-channel-tagged`

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredKeyTags  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  |  No default value  | 

This control checks whether an Amazon IVS channel has tags with the specific keys defined in the parameter `requiredKeyTags`. The control fails if the channel doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredKeyTags`. If the parameter `requiredKeyTags` isn't provided, the control only checks for the existence of a tag key and fails if the channel isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [Define permissions based on attributes with ABAC authorization](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Best practices and strategies](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *Tagging AWS Resources and Tag Editor User Guide*.

### Remediation
<a name="ivs-3-remediation"></a>

To add tags to an IVS channel, see [https://docs.aws.amazon.com/ivs/latest/RealTimeAPIReference/API_TagResource.html](https://docs.aws.amazon.com/ivs/latest/RealTimeAPIReference/API_TagResource.html) in the *Amazon IVS Real-Time Streaming API Reference*.

# Security Hub CSPM controls for Amazon Keyspaces
<a name="keyspaces-controls"></a>

These AWS Security Hub CSPM controls evaluate the Amazon Keyspaces service and resources.

These controls may not be available in all AWS Regions. For more information, see [Availability of controls by Region](securityhub-regions.md#securityhub-regions-control-support).

## [Keyspaces.1] Amazon Keyspaces keyspaces should be tagged
<a name="keyspaces-1"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::Cassandra::Keyspace`

**AWS Config rule:** `cassandra-keyspace-tagged`

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredKeyTags  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  |  No default value  | 

This control checks whether an Amazon Keyspaces keyspace has tags with the specific keys defined in the parameter `requiredKeyTags`. The control fails if the keyspace doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredKeyTags`. If the parameter `requiredKeyTags` isn't provided, the control only checks for the existence of a tag key and fails if the keyspace isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [Define permissions based on attributes with ABAC authorization](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Best practices and strategies](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *Tagging AWS Resources and Tag Editor User Guide*.

### Remediation
<a name="keyspaces-1-remediation"></a>

To add tags to an Amazon Keyspaces keyspace, see [Add tags to a keyspace](https://docs.aws.amazon.com/keyspaces/latest/devguide/Tagging.Operations.existing.keyspace.html) in the *Amazon Keyspaces Developer Guide*.

# Security Hub CSPM controls for Kinesis
<a name="kinesis-controls"></a>

These AWS Security Hub CSPM controls evaluate the Amazon Kinesis service and resources.

These controls may not be available in all AWS Regions. For more information, see [Availability of controls by Region](securityhub-regions.md#securityhub-regions-control-support).

## [Kinesis.1] Kinesis streams should be encrypted at rest
<a name="kinesis-1"></a>

**Related requirements:** NIST.800-53.r5 CA-9(1), NIST.800-53.r5 CM-3(6), NIST.800-53.r5 SC-13, NIST.800-53.r5 SC-28, NIST.800-53.r5 SC-28(1), NIST.800-53.r5 SC-7(10), NIST.800-53.r5 SI-7(6)

**Category:** Protect > Data Protection > Encryption of data-at-rest

**Severity:** Medium

**Resource type:** `AWS::Kinesis::Stream`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/kinesis-stream-encrypted.html](https://docs.aws.amazon.com/config/latest/developerguide/kinesis-stream-encrypted.html)

**Schedule type:** Change triggered

**Parameters:** None 

This control checks if Kinesis Data Streams are encrypted at rest with server-side encryption. This control fails if a Kinesis stream is not encrypted at rest with server-side encryption.

Server-side encryption is a feature in Amazon Kinesis Data Streams that automatically encrypts data before it's at rest by using an AWS KMS key. Data is encrypted before it's written to the Kinesis stream storage layer, and decrypted after it's retrieved from storage. As a result, your data is encrypted at rest within the Amazon Kinesis Data Streams service.

### Remediation
<a name="kinesis-1-remediation"></a>

For information about enabling server-side encryption for Kinesis streams, see [How do I get started with server-side encryption?](https://docs.aws.amazon.com/streams/latest/dev/getting-started-with-sse.html) in the *Amazon Kinesis Developer Guide*.

## [Kinesis.2] Kinesis streams should be tagged
<a name="kinesis-2"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::Kinesis::Stream`

**AWS Configrule:** `tagged-kinesis-stream` (custom Security Hub CSPM rule)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  | No default value  | 

This control checks whether an Amazon Kinesis data stream has tags with the specific keys defined in the parameter `requiredTagKeys`. The control fails if the data stream doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredTagKeys`. If the parameter `requiredTagKeys` isn't provided, the control only checks for the existence of a tag key and fails if the data stream isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [What is ABAC for AWS?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Tagging your AWS resources](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *AWS General Reference*.

### Remediation
<a name="kinesis-2-remediation"></a>

To add tags to a Kinesis data stream, see [Tagging your streams in Amazon Kinesis Data Streams](https://docs.aws.amazon.com/streams/latest/dev/tagging.html) in the *Amazon Kinesis Developer Guide*.

## [Kinesis.3] Kinesis streams should have an adequate data retention period
<a name="kinesis-3"></a>

**Severity:** Medium

**Resource type:** `AWS::Kinesis::Stream`

**AWS Configrule:** [https://docs.aws.amazon.com/config/latest/developerguide/kinesis-stream-backup-retention-check.html](https://docs.aws.amazon.com/config/latest/developerguide/kinesis-stream-backup-retention-check.html)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  minimumBackupRetentionPeriod  | Minimum number of hours that the data should be retained.  | String  | 24 to 8760  | 168  | 

This control checks whether an Amazon Kinesis data stream has a data retention period greater than or equal to the specified time frame. The control fails if the data retention period is less than the specified time frame. Unless you provide a custom parameter value for the data retention period, Security Hub CSPM uses a default value of 168 hours.

In Kinesis Data Streams, a data stream is an ordered sequence of data records meant to be written to and read from in real time. Data records are stored in shards in your stream temporarily. The time period from when a record is added to when it is no longer accessible is called the retention period. Kinesis Data Streams almost immediately makes records older than the new retention period inaccessible after decreasing the retention period. For example, changing the retention period from 24 hours to 48 hours means that records added to the stream 23 hours 55 minutes prior are still available after 24 hours. 

### Remediation
<a name="kinesis-3-remediation"></a>

To change the backup retention period for your Kinesis Data Streams, see [Change the data retention period](https://docs.aws.amazon.com/streams/latest/dev/kinesis-extended-retention.html) in the *Amazon Kinesis Data Streams Developer Guide*.

# Security Hub CSPM controls for AWS KMS
<a name="kms-controls"></a>

These AWS Security Hub CSPM controls evaluate the AWS Key Management Service (AWS KMS) service and resources. The controls might not be available in all AWS Regions. For more information, see [Availability of controls by Region](securityhub-regions.md#securityhub-regions-control-support).

## [KMS.1] IAM customer managed policies should not allow decryption actions on all KMS keys
<a name="kms-1"></a>

**Related requirements:** NIST.800-53.r5 AC-2, NIST.800-53.r5 AC-2(1), NIST.800-53.r5 AC-3, NIST.800-53.r5 AC-3(15), NIST.800-53.r5 AC-3(7), NIST.800-53.r5 AC-5, NIST.800-53.r5 AC-6, NIST.800-53.r5 AC-6(3)

**Category:** Protect > Secure access management

**Severity:** Medium

**Resource type:** `AWS::IAM::Policy`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/iam-customer-policy-blocked-kms-actions.html](https://docs.aws.amazon.com/config/latest/developerguide/iam-customer-policy-blocked-kms-actions.html)

**Schedule type:** Change triggered

**Parameters:** 
+ `blockedActionsPatterns: kms:ReEncryptFrom, kms:Decrypt` (not customizable)
+ `excludePermissionBoundaryPolicy`: `True` (not customizable)

Checks whether the default version of IAM customer managed policies allow principals to use the AWS KMS decryption actions on all resources. The control fails if the policy is open enough to allow `kms:Decrypt` or `kms:ReEncryptFrom` actions on all KMS keys.

The control only checks KMS keys in the Resource element and doesn't take into account any conditionals in the Condition element of a policy. In addition, the control evaluates both attached and unattached customer managed policies. It doesn't check inline policies or AWS managed policies.

With AWS KMS, you control who can use your KMS keys and gain access to your encrypted data. IAM policies define which actions an identity (user, group, or role) can perform on which resources. Following security best practices, AWS recommends that you allow least privilege. In other words, you should grant to identities only the `kms:Decrypt` or `kms:ReEncryptFrom` permissions and only for the keys that are required to perform a task. Otherwise, the user might use keys that are not appropriate for your data.

Instead of granting permissions for all keys, determine the minimum set of keys that users need to access encrypted data. Then design policies that allow users to use only those keys. For example, do not allow `kms:Decrypt` permission on all KMS keys. Instead, allow `kms:Decrypt` only on keys in a particular Region for your account. By adopting the principle of least privilege, you can reduce the risk of unintended disclosure of your data.

### Remediation
<a name="kms-1-remediation"></a>

To modify an IAM customer managed policy, see [Editing customer managed policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-edit.html#edit-managed-policy-console) in the *IAM User Guide*. When editing your policy, for the `Resource` field, provide the Amazon Resource Name (ARN) of the specific key or keys that you want to allow decryption actions on.

## [KMS.2] IAM principals should not have IAM inline policies that allow decryption actions on all KMS keys
<a name="kms-2"></a>

**Related requirements:** NIST.800-53.r5 AC-2, NIST.800-53.r5 AC-2(1), NIST.800-53.r5 AC-3, NIST.800-53.r5 AC-3(15), NIST.800-53.r5 AC-3(7), NIST.800-53.r5 AC-5, NIST.800-53.r5 AC-6, NIST.800-53.r5 AC-6(3)

**Category:** Protect > Secure access management

**Severity:** Medium

**Resource type:**
+ `AWS::IAM::Group`
+ `AWS::IAM::Role`
+ `AWS::IAM::User`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/iam-inline-policy-blocked-kms-actions.html](https://docs.aws.amazon.com/config/latest/developerguide/iam-inline-policy-blocked-kms-actions.html) 

**Schedule type:** Change triggered

**Parameters:**
+ `blockedActionsPatterns: kms:ReEncryptFrom, kms:Decrypt` (not customizable)

This control checks whether the inline policies that are embedded in your IAM identities (role, user, or group) allow the AWS KMS decryption and re-encryption actions on all KMS keys. The control fails if the policy is open enough to allow `kms:Decrypt` or `kms:ReEncryptFrom` actions on all KMS keys.

The control only checks KMS keys in the Resource element and doesn't take into account any conditionals in the Condition element of a policy.

With AWS KMS, you control who can use your KMS keys and gain access to your encrypted data. IAM policies define which actions an identity (user, group, or role) can perform on which resources. Following security best practices, AWS recommends that you allow least privilege. In other words, you should grant to identities only the permissions they need and only for keys that are required to perform a task. Otherwise, the user might use keys that are not appropriate for your data.

Instead of granting permission for all keys, determine the minimum set of keys that users need to access encrypted data. Then design policies that allow the users to use only those keys. For example, do not allow `kms:Decrypt` permission on all KMS keys. Instead, allow the permission only on specific keys in a specific Region for your account. By adopting the principle of least privilege, you can reduce the risk of unintended disclosure of your data.

### Remediation
<a name="kms-2-remediation"></a>

To modify an IAM inline policy, see [Editing inline policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-edit.html#edit-inline-policy-console) in the *IAM User Guide*. When editing your policy, for the `Resource` field, provide the Amazon Resource Name (ARN) of the specific key or keys that you want to allow decryption actions on.

## [KMS.3] AWS KMS keys should not be deleted unintentionally
<a name="kms-3"></a>

**Related requirements:** NIST.800-53.r5 SC-12, NIST.800-53.r5 SC-12(2)

**Category:** Protect > Data protection > Data deletion protection

**Severity:** Critical

**Resource type:** `AWS::KMS::Key`

**AWS Config rule:** `kms-cmk-not-scheduled-for-deletion-2` (custom Security Hub CSPM rule)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether KMS keys are scheduled for deletion. The control fails if a KMS key is scheduled for deletion.

KMS keys cannot be recovered once deleted. Data encrypted under a KMS key is also permanently unrecoverable if the KMS key is deleted. If meaningful data has been encrypted under a KMS key scheduled for deletion, consider decrypting the data or re-encrypting the data under a new KMS key unless you are intentionally performing a *cryptographic erasure*.

When a KMS key is scheduled for deletion, a mandatory waiting period is enforced to allow time to reverse the deletion, if it was scheduled in error. The default waiting period is 30 days, but it can be reduced to as short as 7 days when the KMS key is scheduled for deletion. During the waiting period, the scheduled deletion can be canceled and the KMS key will not be deleted.

For additional information regarding deleting KMS keys, see [Deleting KMS keys](https://docs.aws.amazon.com/kms/latest/developerguide/deleting-keys.html) in the *AWS Key Management Service Developer Guide*.

### Remediation
<a name="kms-3-remediation"></a>

To cancel a scheduled KMS key deletion, see **To cancel key deletion** under [Scheduling and canceling key deletion (console)](https://docs.aws.amazon.com/kms/latest/developerguide/deleting-keys-scheduling-key-deletion.html#deleting-keys-scheduling-key-deletion-console) in the *AWS Key Management Service Developer Guide*.

## [KMS.4] AWS KMS key rotation should be enabled
<a name="kms-4"></a>

**Related requirements:** CIS AWS Foundations Benchmark v5.0.0/3.6, CIS AWS Foundations Benchmark v3.0.0/3.6, CIS AWS Foundations Benchmark v1.4.0/3.8, CIS AWS Foundations Benchmark v1.2.0/2.8, NIST.800-53.r5 SC-12, NIST.800-53.r5 SC-12(2), NIST.800-53.r5 SC-28(3), PCI DSS v3.2.1/3.6.4, PCI DSS v4.0.1/3.7.4

**Category:** Protect > Data Protection > Encryption of data-at-rest

**Severity:** Medium

**Resource type:** `AWS::KMS::Key`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/cmk-backing-key-rotation-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/cmk-backing-key-rotation-enabled.html)

**Schedule type:** Periodic

**Parameters:** None

AWS KMS enables customers to rotate the backing key, which is key material stored in AWS KMS and is tied to the key ID of the KMS key. It's the backing key that is used to perform cryptographic operations such as encryption and decryption. Automated key rotation currently retains all previous backing keys so that decryption of encrypted data can take place transparently.

CIS recommends that you enable KMS key rotation. Rotating encryption keys helps reduce the potential impact of a compromised key because data encrypted with a new key can't be accessed with a previous key that might have been exposed.

### Remediation
<a name="kms-4-remediation"></a>

To enable KMS key rotation, see [How to enable and disable automatic key rotation](https://docs.aws.amazon.com/kms/latest/developerguide/rotate-keys.html#rotating-keys-enable-disable) in the *AWS Key Management Service Developer Guide*.

## [KMS.5] KMS keys should not be publicly accessible
<a name="kms-5"></a>

**Category:** Protect > Secure network configuration > Resources not publicly accessible

**Severity:** Critical

**Resource type:** `AWS::KMS::Key`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/kms-key-policy-no-public-access.html](https://docs.aws.amazon.com/config/latest/developerguide/kms-key-policy-no-public-access.html)

**Schedule type:** Change triggered

**Parameters:** None

This controls checks whether an AWS KMS key is publicly accessible. The control fails if the KMS key is publicly accessible.

Implementing least privilege access is fundamental to reducing security risk and the impact of errors or malicious intent. If the key policy for an AWS KMS key allows access from external accounts, third parties might be able to encrypt and decrypt data by using the key. This could result in an internal or external threat exfiltrating data from AWS services that use the key.

**Note**  
This control also returns a `FAILED` finding for an AWS KMS key if your configurations prevent AWS Config from recording the key policy in the Configuration Item (CI) for the KMS key. For AWS Config to populate the key policy in the CI for the KMS key, the [AWS Config role](https://docs.aws.amazon.com/config/latest/developerguide/gs-cli-prereq.html#gs-cli-create-iamrole) must have access to read the key policy by using the [GetKeyPolicy](https://docs.aws.amazon.com/kms/latest/APIReference/API_GetKeyPolicy.html) API call. To resolve this type of `FAILED` finding, check policies that can prevent the AWS Config role from having read access to the key policy for the KMS key. For example, check the following:  
The key policy for the KMS key.
[Service control policies (SCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) and [resource control policies (RCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html) in AWS Organizations that apply to your account.
Permissions for the AWS Config role, if you are not using the [AWS Config service-linked role](https://docs.aws.amazon.com/config/latest/developerguide/using-service-linked-roles.html).
In addition, this control doesn't evaluate policy conditions that use wildcard characters or variables. To produce a `PASSED` finding, conditions in the key policy must only use fixed values, which are values that don't contain wildcard characters or policy variables. For information about policy variables, see [Variables and tags](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_variables.html) in the *AWS Identity and Access Management User Guide*.

### Remediation
<a name="kms-5-remediation"></a>

For information about updating the key policy for an AWS KMS key, see [Key policies in AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html#key-policy-overview) in the *AWS Key Management Service Developer Guide*.

# Security Hub CSPM controls for AWS Lambda
<a name="lambda-controls"></a>

These AWS Security Hub CSPM controls evaluate the AWS Lambda service and resources. The controls might not be available in all AWS Regions. For more information, see [Availability of controls by Region](securityhub-regions.md#securityhub-regions-control-support).

## [Lambda.1] Lambda function policies should prohibit public access
<a name="lambda-1"></a>

**Related requirements:** NIST.800-53.r5 AC-21, NIST.800-53.r5 AC-3, NIST.800-53.r5 AC-3(7), NIST.800-53.r5 AC-4, NIST.800-53.r5 AC-4(21), NIST.800-53.r5 AC-6, NIST.800-53.r5 SC-7, NIST.800-53.r5 SC-7(11), NIST.800-53.r5 SC-7(16), NIST.800-53.r5 SC-7(20), NIST.800-53.r5 SC-7(21), NIST.800-53.r5 SC-7(3), NIST.800-53.r5 SC-7(4), NIST.800-53.r5 SC-7(9), PCI DSS v3.2.1/1.2.1, PCI DSS v3.2.1/1.3.1, PCI DSS v3.2.1/1.3.2, PCI DSS v3.2.1/1.3.4, PCI DSS v3.2.1/7.2.1, PCI DSS v4.0.1/7.2.1

**Category:** Protect > Secure network configuration

**Severity:** Critical

**Resource type:** `AWS::Lambda::Function`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/lambda-function-public-access-prohibited.html](https://docs.aws.amazon.com/config/latest/developerguide/lambda-function-public-access-prohibited.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether the Lambda function resource-based policy prohibits public access outside of your account. The control fails if public access is permitted. The control also fails if a Lambda function is invoked from Amazon S3, and the policy doesn't include a condition to limit public access, such as `AWS:SourceAccount`. We recommend using other S3 conditions along with `AWS:SourceAccount` in your bucket policy for more refined access.

**Note**  
This control doesn't evaluate policy conditions that use wildcard characters or variables. To produce a `PASSED` finding, conditions in the policy for the Lambda function must only use fixed values, which are values that don't contain wildcard characters or policy variables. For information about policy variables, see [Variables and tags](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_variables.html) in the *AWS Identity and Access Management User Guide*.

The Lambda function should not be publicly accessible, as this may allow unintended access to your function code.

### Remediation
<a name="lambda-1-remediation"></a>

To remediate this issue, you must update your function's resource-based policy to remove permissions or to add the `AWS:SourceAccount` condition. You can only update the resource-based policy from the Lambda API or AWS CLI.

To start, [ review the resource-based policy](https://docs.aws.amazon.com/lambda/latest/dg/access-control-resource-based.html) on the Lambda console. Identify the policy statement that has `Principal` field values that make the policy public, such as `"*"` or `{ "AWS": "*" }`.

You cannot edit the policy from the console. To remove permissions from the function, run the [https://docs.aws.amazon.com/cli/latest/reference/lambda/remove-permission.html](https://docs.aws.amazon.com/cli/latest/reference/lambda/remove-permission.html) command from the AWS CLI.

```
$ aws lambda remove-permission --function-name <function-name> --statement-id <statement-id>
```

Replace `<function-name>` with the name of the Lambda function, and `<statement-id>` with the statement ID (`Sid`) of the statement that you want to remove.

## [Lambda.2] Lambda functions should use supported runtimes
<a name="lambda-2"></a>

**Related requirements:** NIST.800-53.r5 CA-9(1), NIST.800-53.r5 CM-2, NIST.800-53.r5 SI-2, NIST.800-53.r5 SI-2(2), NIST.800-53.r5 SI-2(4), NIST.800-53.r5 SI-2(5), PCI DSS v4.0.1/12.3.4

**Category:** Protect > Secure development

**Severity:** Medium

**Resource type:** `AWS::Lambda::Function`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/lambda-function-settings-check.html](https://docs.aws.amazon.com/config/latest/developerguide/lambda-function-settings-check.html)

**Schedule type:** Change triggered

**Parameters:** 
+ `runtime`: `dotnet10, dotnet8, java25, java21, java17, java11, java8.al2, nodejs24.x, nodejs22.x, nodejs20.x, python3.14, python3.13, python3.12, python3.11, python3.10, ruby3.4, ruby3.3` (not customizable)

This control checks whether AWS Lambda function runtime settings match the expected values set for the supported runtimes in each language. The control fails if the Lambda function doesn't use a supported runtime, as noted in the Parameters section. Security Hub CSPM ignores functions that have a package type of `Image`.

Lambda runtimes are built around a combination of operating system, programming language, and software libraries that are subject to maintenance and security updates. When a runtime component is no longer supported for security updates, Lambda deprecates the runtime. Even though you can't create functions that use the deprecated runtime, the function is still available to process invocation events. We recommend ensuring that your Lambda functions are current and don't use deprecated runtime environments. For a list of supported runtimes, see [Lambda runtimes](https://docs.aws.amazon.com/lambda/latest/dg/lambda-runtimes.html) in the *AWS Lambda Developer Guide*.

### Remediation
<a name="lambda-2-remediation"></a>

For more information about supported runtimes and deprecation schedules, see [Runtime deprecation policy](https://docs.aws.amazon.com/lambda/latest/dg/runtime-support-policy.html) in the *AWS Lambda Developer Guide*. When you migrate your runtimes to the latest version, follow the syntax and guidance from the publishers of the language. We also recommend applying [runtime updates](https://docs.aws.amazon.com/lambda/latest/dg/runtimes-update.html#runtime-management-controls) to help reduce the risk of impact to your workloads in the rare event of a runtime version incompatibility.

## [Lambda.3] Lambda functions should be in a VPC
<a name="lambda-3"></a>

**Related requirements:** PCI DSS v3.2.1/1.2.1, PCI DSS v3.2.1/1.3.1, PCI DSS v3.2.1/1.3.2, PCI DSS v3.2.1/1.3.4, NIST.800-53.r5 AC-21, NIST.800-53.r5 AC-3, NIST.800-53.r5 AC-3(7), NIST.800-53.r5 AC-4, NIST.800-53.r5 AC-4(21), NIST.800-53.r5 AC-6, NIST.800-53.r5 SC-7, NIST.800-53.r5 SC-7(11), NIST.800-53.r5 SC-7(16), NIST.800-53.r5 SC-7(20), NIST.800-53.r5 SC-7(21), NIST.800-53.r5 SC-7(3), NIST.800-53.r5 SC-7(4), NIST.800-53.r5 SC-7(9)

**Category:** Protect > Secure network configuration

**Severity: ** Low

**Resource type: ** `AWS::Lambda::Function`

**AWS Config rule: ** [https://docs.aws.amazon.com/config/latest/developerguide/lambda-inside-vpc.html](https://docs.aws.amazon.com/config/latest/developerguide/lambda-inside-vpc.html) 

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether a Lambda function is deployed in a virtual private cloud (VPC). The control fails if the Lambda function isn't deployed in a VPC. Security Hub CSPM doesn't evaluate the VPC subnet routing configuration to determine public reachability. You might see failed findings for Lambda@Edge resources.

Deploying resources in a VPC strengthens security and control over network configurations. Such deployments also offer scalability and high fault tolerance across multiple Availability Zones. You can customize VPC deployments to meet diverse application requirements.

### Remediation
<a name="lambda-3-remediation"></a>

To configure an existing function to connect to private subnets in your VPC, see [Configuring VPC access](https://docs.aws.amazon.com/lambda/latest/dg/configuration-vpc.html#vpc-configuring) in the *AWS Lambda Developer Guide*. We recommend choosing at least two private subnets for high availability and at least one security group that meets the connectivity requirements of the function.

## [Lambda.5] VPC Lambda functions should operate in multiple Availability Zones
<a name="lambda-5"></a>

**Related requirements:** NIST.800-53.r5 CP-10, NIST.800-53.r5 CP-6(2), NIST.800-53.r5 SC-36, NIST.800-53.r5 SC-5(2), NIST.800-53.r5 SI-13(5)

**Category:** Recover > Resilience > High availability

**Severity:** Medium

**Resource type:** `AWS::Lambda::Function`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/lambda-vpc-multi-az-check.html](https://docs.aws.amazon.com/config/latest/developerguide/lambda-vpc-multi-az-check.html)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  `availabilityZones`  |  Minimum number of Availability Zones  |  Enum  |  `2, 3, 4, 5, 6`  |  `2`  | 

This control checks if an AWS Lambda function that connects to a virtual private cloud (VPC) operates in at least the specified number of Availability Zone (AZs). The control fails if the function doesn't operate in at least the specified number of AZs. Unless you provide a custom parameter value for the minimum number of AZs, Security Hub CSPM uses a default value of two AZs.

Deploying resources across multiple AZs is an AWS best practice to ensure high availability within your architecture. Availability is a core pillar in the confidentiality, integrity, and availability triad security model. All Lambda functions that connect to a VPC should have a multi-AZ deployment to ensure that a single zone of failure doesn't cause a total disruption of operations.

### Remediation
<a name="lambda-5-remediation"></a>

If you configure your function to connect to a VPC in your account, specify subnets in multiple AZs to ensure high availability. For instructions, see [Configuring VPC access](https://docs.aws.amazon.com/lambda/latest/dg/configuration-vpc.html#vpc-configuring) in the *AWS Lambda Developer Guide*.

Lambda automatically runs other functions in multiple AZs to ensure that it is available to process events in case of a service interruption in a single zone.

## [Lambda.6] Lambda functions should be tagged
<a name="lambda-6"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::Lambda::Function`

**AWS Config rule:** `tagged-lambda-function` (custom Security Hub CSPM rule)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  |  No default value  | 

This control checks whether an AWS Lambda function has tags with the specific keys defined in the parameter `requiredTagKeys`. The control fails if the function doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredTagKeys`. If the parameter `requiredTagKeys` isn't provided, the control only checks for the existence of a tag key and fails if the function isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [What is ABAC for AWS?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Tagging your AWS resources](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *AWS General Reference*.

### Remediation
<a name="lambda-6-remediation"></a>

To add tags to a Lambda function, see [Using tags on Lambda functions](https://docs.aws.amazon.com/lambda/latest/dg/configuration-tags.html) in the *AWS Lambda Developer Guide*.

## [Lambda.7] Lambda functions should have AWS X-Ray active tracing enabled
<a name="lambda-7"></a>

**Related requirements:** NIST.800-53.r5 CA-7

**Category:** Identify > Logging

**Severity:** Low

**Resource type:** `AWS::Lambda::Function`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/lambda-function-xray-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/lambda-function-xray-enabled.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether active tracing with AWS X-Ray is enabled for an AWS Lambda function. The control fails if active tracing with X-Ray is disabled for the Lambda function.

AWS X-Ray can provide tracing and monitoring capabilities for AWS Lambda functions, which can save time and effort debugging and operating Lambda functions. It can help you diagnose errors and identify performance bottlenecks, slowdowns, and timeouts by breaking down latency for Lambda functions. It can also help with data privacy and compliance requirements. If you enable active tracing for a Lambda function, X-Ray provides a holistic view of data flow and processing within the Lambda function, which can help you identify potential security vulnerabilities or non-compliant data handling practices. This visibility can help you maintain data integrity, confidentiality, and compliance with relevant regulations.

**Note**  
AWS X-Ray tracing is currently not supported for Lambda functions with Amazon Managed Streaming for Apache Kafka (Amazon MSK), self-managed Apache Kafka, Amazon MQ with ActiveMQ and RabbitMQ, or Amazon DocumentDB event source mappings.

### Remediation
<a name="lambda-7-remediation"></a>

For information about enabling active tracing for an AWS Lambda function, see [Visualize Lambda function invocations using AWS X-Ray](https://docs.aws.amazon.com/lambda/latest/dg/services-xray.html) in the *AWS Lambda Developer Guide*.

# Security Hub CSPM controls for Macie
<a name="macie-controls"></a>

These AWS Security Hub CSPM controls evaluate the Amazon Macie service.

These controls may not be available in all AWS Regions. For more information, see [Availability of controls by Region](securityhub-regions.md#securityhub-regions-control-support).

## [Macie.1] Amazon Macie should be enabled
<a name="macie-1"></a>

**Related requirements:** NIST.800-53.r5 CA-7, NIST.800-53.r5 CA-9(1), NIST.800-53.r5 RA-5, NIST.800-53.r5 SA-8(19), NIST.800-53.r5 SI-4

**Category:** Detect > Detection services

**Severity:** Medium

**Resource type:** `AWS::::Account`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/macie-status-check.html](https://docs.aws.amazon.com/config/latest/developerguide/macie-status-check.html)

**Schedule type:** Periodic

This control checks whether Amazon Macie is enabled for an account. The control fails if Macie isn't enabled for the account.

Amazon Macie discovers sensitive data using machine learning and pattern matching, provides visibility into data security risks, and enables automated protection against those risks. Macie automatically and continually evaluates your Amazon Simple Storage Service (Amazon S3) buckets for security and access control, and generates findings to notify you of potential issues with the security or privacy of your Amazon S3 data. Macie also automates discovery and reporting of sensitive data, such as personally identifiable information (PII), to provide you with a better understanding of the data that you store in Amazon S3. To learn more, see the [https://docs.aws.amazon.com/macie/latest/user/what-is-macie.html](https://docs.aws.amazon.com/macie/latest/user/what-is-macie.html).

### Remediation
<a name="macie-1-remediation"></a>

To enable Macie, see [Enable Macie](https://docs.aws.amazon.com/macie/latest/user/getting-started.html#enable-macie) in the *Amazon Macie User Guide*.

## [Macie.2] Macie automated sensitive data discovery should be enabled
<a name="macie-2"></a>

**Related requirements:** NIST.800-53.r5 CA-7, NIST.800-53.r5 CA-9(1), NIST.800-53.r5 RA-5, NIST.800-53.r5 SA-8(19), NIST.800-53.r5 SI-4

**Category:** Detect > Detection services

**Severity:** High

**Resource type:** `AWS::::Account`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/macie-auto-sensitive-data-discovery-check.html](https://docs.aws.amazon.com/config/latest/developerguide/macie-auto-sensitive-data-discovery-check.html)

**Schedule type:** Periodic

This control checks whether automated sensitive data discovery is enabled for an Amazon Macie administrator account. The control fails if automated sensitive data discovery isn't enabled for a Macie administrator account. This control applies only to administrator accounts.

Macie automates discovery and reporting of sensitive data, such as personally identifiable information (PII), in Amazon Simple Storage Service (Amazon S3) buckets. With automated sensitive data discovery, Macie continually evaluates your bucket inventory and uses sampling techniques to identify and select representative S3 objects from your buckets. Macie then analyzes the selected objects, inspecting them for sensitive data. As the analyses progress, Macie updates statistics, inventory data, and other information that it provides about your S3 data. Macie also generates findings to report sensitive data that it finds.

### Remediation
<a name="macie-2-remediation"></a>

To create and configure automated sensitive data discovery jobs to analyze objects in S3 buckets, see [Configuring automated sensitive data discovery for your account](https://docs.aws.amazon.com/macie/latest/user/discovery-asdd-account-manage.html) in the *Amazon Macie User Guide*.

# Security Hub CSPM controls for Amazon MSK
<a name="msk-controls"></a>

These AWS Security Hub CSPM controls evaluate the Amazon Managed Streaming for Apache Kafka (Amazon MSK) service and resources. The controls might not be available in all AWS Regions. For more information, see [Availability of controls by Region](securityhub-regions.md#securityhub-regions-control-support).

## [MSK.1] MSK clusters should be encrypted in transit among broker nodes
<a name="msk-1"></a>

**Related requirements:** NIST.800-53.r5 AC-4, NIST.800-53.r5 SC-13, NIST.800-53.r5 SC-23, NIST.800-53.r5 SC-23(3), NIST.800-53.r5 SC-7(4), NIST.800-53.r5 SC-8, NIST.800-53.r5 SC-8(1), NIST.800-53.r5 SC-8(2), PCI DSS v4.0.1/4.2.1

**Category:** Protect > Data Protection > Encryption of data-in-transit

**Severity:** Medium

**Resource type:** `AWS::MSK::Cluster`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/msk-in-cluster-node-require-tls.html](https://docs.aws.amazon.com/config/latest/developerguide/msk-in-cluster-node-require-tls.html)

**Schedule type:** Change triggered

**Parameters:** None

This controls checks whether an Amazon MSK cluster is encrypted in transit with HTTPS (TLS) among the broker nodes of the cluster. The control fails if plain text communication is enabled for a cluster broker node connection.

HTTPS offers an extra layer of security as it uses TLS to move data and can be used to help prevent potential attackers from using person-in-the-middle or similar attacks to eavesdrop on or manipulate network traffic. By default, Amazon MSK encrypts data in transit with TLS. However, you can override this default at the time that you create the cluster. We recommend using encrypted connections over HTTPS (TLS) for-broker node connections.

### Remediation
<a name="msk-1-remediation"></a>

For information about updating the encryption settings for an Amazon MSK cluster, see [Updating security settings of a cluster](https://docs.aws.amazon.com/msk/latest/developerguide/msk-update-security.html) in the *Amazon Managed Streaming for Apache Kafka Developer Guide*.

## [MSK.2] MSK clusters should have enhanced monitoring configured
<a name="msk-2"></a>

**Related requirements:** NIST.800-53.r5 CA-7, NIST.800-53.r5 SI-2

**Category:** Detect > Detection services

**Severity:** Low

**Resource type:** `AWS::MSK::Cluster`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/msk-enhanced-monitoring-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/msk-enhanced-monitoring-enabled.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether an Amazon MSK cluster has enhanced monitoring configured, specified by a monitoring level of at least `PER_TOPIC_PER_BROKER`. The control fails if the monitoring level for the cluster is set to `DEFAULT` or `PER_BROKER`.

The `PER_TOPIC_PER_BROKER` monitoring level provides more granular insights into the performance of your MSK cluster, and also provides metrics related to resource utilization, such as CPU and memory usage. This helps you identify performance bottlenecks and resource utilization patterns for individual topics and brokers. This visibility, in turn, can optimize the performance of your Kafka brokers.

### Remediation
<a name="msk-2-remediation"></a>

To configure enhanced monitoring for an MSK cluster, complete the following steps:

1. Open the Amazon MSK console at [https://console.aws.amazon.com/msk/home?region=us-east-1\$1/home/](https://console.aws.amazon.com/msk/home?region=us-east-1#/home/).

1. In the navigation pane, choose **Clusters**. Then, choose a cluster.

1. For **Action**, select **Edit monitoring**.

1. Select the option for **Enhanced topic-level monitoring**.

1. Choose **Save changes**.

For more information about monitoring levels, see [Amazon MSK metrics for monitoring Standard brokers with CloudWatch](https://docs.aws.amazon.com/msk/latest/developerguide/metrics-details.html) in the *Amazon Managed Streaming for Apache Kafka Developer Guide*.

## [MSK.3] MSK Connect connectors should be encrypted in transit
<a name="msk-3"></a>

**Related requirements:** PCI DSS v4.0.1/4.2.1

**Category:** Protect > Data Protection > Encryption of data-in-transit

**Severity:** Medium

**Resource type:** `AWS::KafkaConnect::Connector`

**AWS Config rule:** `msk-connect-connector-encrypted` (custom Security Hub CSPM rule)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether an Amazon MSK Connect connector is encrypted in transit. This control fails if the connector isn't encrypted in transit.

Data in transit refers to data that moves from one location to another, such as between nodes in your cluster or between your cluster and your application. Data may move across the internet or within a private network. Encrypting data in transit reduces the risk that an unauthorized user can eavesdrop on network traffic.

### Remediation
<a name="msk-3-remediation"></a>

You can enable encryption in transit when you create an MSK Connect connector. You can't change encryption settings after creating a connector. For more information, see [Create a connector](https://docs.aws.amazon.com/msk/latest/developerguide/mkc-create-connector-intro.html) in the *Amazon Managed Streaming for Apache Kafka Developer Guide*.

## [MSK.4] MSK clusters should have public access disabled
<a name="msk-4"></a>

**Category:** Protect > Secure access management > Resource not publicly accessible

**Severity:** Critical

**Resource type:** `AWS::MSK::Cluster`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/msk-cluster-public-access-disabled.html](https://docs.aws.amazon.com/config/latest/developerguide/msk-cluster-public-access-disabled.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether public access is disabled for an Amazon MSK cluster. The control fails if public access is enabled for the MSK cluster.

By default, clients can access an Amazon MSK cluster only if they're in the same VPC as the cluster. All communication between Kafka clients and an MSK cluster are private by default and streaming data doesn't traverse the internet. However, if an MSK cluster is configured to allow public access, anyone on the internet can establish a connection to Apache Kafka brokers that are running within the cluster. This can lead to issues such as unauthorized access, data breaches, or exploitation of vulnerabilities. If you restrict access to a cluster by requiring authentication and authorization measures, you can help protect sensitive information and maintain the integrity of your resources.

### Remediation
<a name="msk-4-remediation"></a>

For information about managing public access to an Amazon MSK cluster, see [ Turn on public access to an MSK Provisioned cluster](https://docs.aws.amazon.com/msk/latest/developerguide/public-access.html) in the *Amazon Managed Streaming for Apache Kafka Developer Guide*.

## [MSK.5] MSK connectors should have logging enabled
<a name="msk-5"></a>

**Category:** Identify > Logging

**Severity:** Medium

**Resource type:** `AWS::KafkaConnect::Connector`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/msk-connect-connector-logging-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/msk-connect-connector-logging-enabled.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether logging is enabled for an Amazon MSK connector. The control fails if logging is disabled for the MSK connector.

Amazon MSK connectors integrate external systems and Amazon services with Apache Kafka by continuously copying streaming data from a data source into an Apache Kafka cluster, or continuously copying data from a cluster into a data sink. MSK Connect can write log events that can help debug a connector. When you create a connector, you can specify zero or more of the following log destinations: Amazon CloudWatch Logs, Amazon S3, and Amazon Data Firehose.

**Note**  
Sensitive configuration values can appear in connector logs if a plugin does not define those values as secret. Kafka Connect treats undefined configuration values the same as any other plaintext value.

### Remediation
<a name="msk-5-remediation"></a>

To enable logging for an existing Amazon MSK connector, you have to re-create the connector with the appropriate logging configuration. For information about configuration options, see [Logging for MSK Connect](https://docs.aws.amazon.com/msk/latest/developerguide/msk-connect-logging.html) in the *Amazon Managed Streaming for Apache Kafka Developer Guide*.

## [MSK.6] MSK clusters should disable unauthenticated access
<a name="msk-6"></a>

**Category:** Protect > Secure access management > Passwordless authentication

**Severity:** Medium

**Resource type:** `AWS::MSK::Cluster`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/msk-unrestricted-access-check.html](https://docs.aws.amazon.com/config/latest/developerguide/msk-unrestricted-access-check.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether unauthenticated access is enabled for an Amazon MSK cluster. The control fails if unauthenticated access is enabled for the MSK cluster.

Amazon MSK supports client authentication and authorization mechanisms to control access to a cluster. These mechanisms verify the identity of clients connecting to the cluster and determine which actions clients can perform. An MSK cluster can be configured to allow unauthenticated access, which allows any client with network connectivity to publish and subscribe to Kafka topics without providing credentials. Running an MSK cluster without requiring authentication violates the principle of least privilege and can expose the cluster to unauthorized access. It can allow any client to access, modify, or delete data in Kafka topics, potentially resulting in data breaches, unauthorized data modifications, or service disruptions. We recommend enabling authentication mechanisms such as IAM authentication, SASL/SCRAM, or mutual TLS to ensure proper access control and maintain security compliance.

### Remediation
<a name="msk-6-remediation"></a>

For information about changing the authentication settings for an Amazon MSK cluster, see the following sections of the *Amazon Managed Streaming for Apache Kafka Developer Guide*: [Update security settings of an Amazon MSK cluster](https://docs.aws.amazon.com/msk/latest/developerguide/msk-update-security.html) and [Authentication and authorization for Apache Kafka APIs](https://docs.aws.amazon.com/msk/latest/developerguide/kafka_apis_iam.html).

# Security Hub CSPM controls for Amazon MQ
<a name="mq-controls"></a>

These AWS Security Hub CSPM controls evaluate the Amazon MQ service and resources. The controls might not be available in all AWS Regions. For more information, see [Availability of controls by Region](securityhub-regions.md#securityhub-regions-control-support).

## [MQ.2] ActiveMQ brokers should stream audit logs to CloudWatch
<a name="mq-2"></a>

**Related requirements:** NIST.800-53.r5 AU-2, NIST.800-53.r5 AU-3, NIST.800-53.r5 AU-12, NIST.800-53.r5 SI-4, PCI DSS v4.0.1/10.3.3

**Category:** Identify > Logging

**Severity:** Medium

**Resource type:** `AWS::AmazonMQ::Broker`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/mq-cloudwatch-audit-log-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/mq-cloudwatch-audit-log-enabled.html) 

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether an Amazon MQ ActiveMQ broker streams audit logs to Amazon CloudWatch Logs. The control fails if the broker doesn't stream audit logs to CloudWatch Logs.

By publishing ActiveMQ broker logs to CloudWatch Logs, you can create CloudWatch alarms and metrics that increase the visibility of security-related information.

### Remediation
<a name="mq-2-remediation"></a>

To stream ActiveMQ broker logs to CloudWatch Logs, see [ Configuring Amazon MQ for ActiveMQ logs](https://docs.aws.amazon.com/amazon-mq/latest/developer-guide/configure-logging-monitoring-activemq.html) in the *Amazon MQ Developer Guide*.

## [MQ.3] Amazon MQ brokers should have automatic minor version upgrade enabled
<a name="mq-3"></a>

**Important**  
Security Hub CSPM retired this control in January 2026. For more information, see [Change log for Security Hub CSPM controls](controls-change-log.md).

**Related requirements:** NIST.800-53.r5 CM-3, NIST.800-53.r5 SI-2, PCI DSS v4.0.1/6.3.3

**Category:** Identify > Vulnerability, patch, and version management

**Severity:** Medium

**Resource type:** `AWS::AmazonMQ::Broker`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/mq-auto-minor-version-upgrade-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/mq-auto-minor-version-upgrade-enabled.html) 

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether an Amazon MQ broker has automatic minor version upgrade enabled. The control fails if the broker doesn't have automatic minor version upgrade enabled.

As Amazon MQ releases and supports new broker engine versions, the changes are backward-compatible with an existing application and don't deprecate existing functionality. Automatic broker engine version updates protect you against security risks, help fix bugs, and improve functionality.

**Note**  
When the broker associated with automatic minor version upgrade is on its latest patch and becomes unsupported, you must take manual action to upgrade.

### Remediation
<a name="mq-3-remediation"></a>

To enable automatic minor version upgrade for an MQ broker, see [ Automatically upgrading the minor engine version](https://docs.aws.amazon.com/amazon-mq/latest/developer-guide/upgrading-brokers.html#upgrading-brokers-automatic-upgrades.html) in the *Amazon MQ Developer Guide*.

## [MQ.4] Amazon MQ brokers should be tagged
<a name="mq-4"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::AmazonMQ::Broker`

**AWS Config rule:** `tagged-amazonmq-broker` (custom Security Hub CSPM rule)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  |  No default value  | 

This control checks whether an Amazon MQ broker has tags with the specific keys defined in the parameter `requiredTagKeys`. The control fails if the broker doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredTagKeys`. If the parameter `requiredTagKeys` isn't provided, the control only checks for the existence of a tag key and fails if the broker isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [What is ABAC for AWS?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Tagging your AWS resources](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *AWS General Reference*.

### Remediation
<a name="mq-4-remediation"></a>

To add tags to an Amazon MQ broker, see [Tagging resources](https://docs.aws.amazon.com/amazon-mq/latest/developer-guide/amazon-mq-tagging.html) in the *Amazon MQ Developer Guide*.

## [MQ.5] ActiveMQ brokers should use active/standby deployment mode
<a name="mq-5"></a>

**Related requirements:** NIST.800-53.r5 CP-10, NIST.800-53.r5 CP-6(2), NIST.800-53.r5 SC-36, NIST.800-53.r5 SC-5(2), NIST.800-53.r5 SI-13(5)

**Category:** Recover > Resilience > High availability

**Severity:** Low

**Resource type:** `AWS::AmazonMQ::Broker`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/mq-active-deployment-mode.html](https://docs.aws.amazon.com/config/latest/developerguide/mq-active-deployment-mode.html) 

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether the deployment mode for an Amazon MQ ActiveMQ broker is set to active/standby. The control fails if a single-instance broker (enabled by default) is set as the deployment mode.

Active/standby deployment provides high availability for your Amazon MQ ActiveMQ brokers in an AWS Region. The active/standby deployment mode includes two broker instances in two different Availability Zones, configured in a redundant pair. These brokers communicate synchronously with your application, which can reduce downtime and loss of data in the event of a failure.

### Remediation
<a name="mq-5-remediation"></a>

To create a new ActiveMQ broker with active/standby deployment mode, see [ Creating and configuring an ActiveMQ broker](https://docs.aws.amazon.com/amazon-mq/latest/developer-guide/amazon-mq-creating-configuring-broker.html) in the *Amazon MQ Developer Guide*. For **Deployment mode**, choose **Active/standby broker**. You can't change the deployment mode for an existing broker. Instead, you must create a new broker and copy the settings over from the old broker.

## [MQ.6] RabbitMQ brokers should use cluster deployment mode
<a name="mq-6"></a>

**Related requirements:** NIST.800-53.r5 CP-10, NIST.800-53.r5 CP-6(2), NIST.800-53.r5 SC-36, NIST.800-53.r5 SC-5(2), NIST.800-53.r5 SI-13(5

**Category:** Recover > Resilience > High availability

**Severity:** Low

**Resource type:** `AWS::AmazonMQ::Broker`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/mq-rabbit-deployment-mode.html](https://docs.aws.amazon.com/config/latest/developerguide/mq-rabbit-deployment-mode.html) 

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether the deployment mode for an Amazon MQ RabbitMQ broker is set to cluster deployment. The control fails if a single-instance broker (enabled by default) is set as the deployment mode.

Cluster deployment provides high availability for your Amazon MQ RabbitMQ brokers in an AWS Region. The cluster deployment is a logical grouping of three RabbitMQ broker nodes, each with its own Amazon Elastic Block Store (Amazon EBS) volume and a shared state. The cluster deployment ensures that data is replicated to all nodes in the cluster, which can reduce downtime and loss of data in the event of a failure.

### Remediation
<a name="mq-6-remediation"></a>

To create a new RabbitMQ broker with cluster deployment mode, see [ Creating and connecting to a RabbitMQ broker](https://docs.aws.amazon.com/amazon-mq/latest/developer-guide/getting-started-rabbitmq.html) in the *Amazon MQ Developer Guide*. For **Deployment mode**, choose **Cluster deployment**. You can't change the deployment mode for an existing broker. Instead, you must create a new broker and copy the settings over from the old broker.

# Security Hub CSPM controls for Neptune
<a name="neptune-controls"></a>

These AWS Security Hub CSPM controls evaluate the Amazon Neptune service and resources.

These controls may not be available in all AWS Regions. For more information, see [Availability of controls by Region](securityhub-regions.md#securityhub-regions-control-support).

## [Neptune.1] Neptune DB clusters should be encrypted at rest
<a name="neptune-1"></a>

**Related requirements:** NIST.800-53.r5 CA-9(1), NIST.800-53.r5 CM-3(6), NIST.800-53.r5 SC-13, NIST.800-53.r5 SC-28, NIST.800-53.r5 SC-28(1), NIST.800-53.r5 SC-7(10), NIST.800-53.r5 SI-7(6)

**Category:** Protect > Data Protection > Encryption of data-at-rest

**Severity:** Medium

**Resource type:** `AWS::RDS::DBCluster`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/neptune-cluster-encrypted.html](https://docs.aws.amazon.com/config/latest/developerguide/neptune-cluster-encrypted.html) 

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether a Neptune DB cluster is encrypted at rest. The control fails if a Neptune DB cluster isn't encrypted at rest.

Data at rest refers to any data that's stored in persistent, non-volatile storage for any duration. Encryption helps you protect the confidentiality of such data, reducing the risk that an unauthorized user can access it. Encrypting your Neptune DB clusters protects your data and metadata against unauthorized access. It also fulfills compliance requirements for data-at-rest encryption of production file systems.

### Remediation
<a name="neptune-1-remediation"></a>

You can enable encryption at rest when you create a Neptune DB cluster. You can't change encryption settings after creating a cluster. For more information, see [ Encrypting Neptune resources at rest](https://docs.aws.amazon.com/neptune/latest/userguide/encrypt.html) in the *Neptune User Guide*.

## [Neptune.2] Neptune DB clusters should publish audit logs to CloudWatch Logs
<a name="neptune-2"></a>

**Related requirements:** NIST.800-53.r5 AC-2(4), NIST.800-53.r5 AC-4(26), NIST.800-53.r5 AC-6(9), NIST.800-53.r5 AU-10, NIST.800-53.r5 AU-12, NIST.800-53.r5 AU-2, NIST.800-53.r5 AU-3, NIST.800-53.r5 AU-6(1), NIST.800-53.r5 AU-6(3), NIST.800-53.r5 AU-6(4), NIST.800-53.r5 AU-6(5), NIST.800-53.r5 AU-7(1), NIST.800-53.r5 AU-9(7), NIST.800-53.r5 CA-7, NIST.800-53.r5 SC-7(9), NIST.800-53.r5 SI-20, NIST.800-53.r5 SI-3(8), NIST.800-53.r5 SI-4(20), NIST.800-53.r5 SI-4(5), NIST.800-53.r5 SI-7(8), PCI DSS v4.0.1/10.3.3

**Category:** Identify > Logging

**Severity:** Medium

**Resource type:** `AWS::RDS::DBCluster`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/neptune-cluster-cloudwatch-log-export-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/neptune-cluster-cloudwatch-log-export-enabled.html) 

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether a Neptune DB cluster publishes audit logs to Amazon CloudWatch Logs. The control fails if a Neptune DB cluster doesn't publish audit logs to CloudWatch Logs. `EnableCloudWatchLogsExport` should be set to `Audit`.

Amazon Neptune and Amazon CloudWatch are integrated so that you can gather and analyze performance metrics. Neptune automatically sends metrics to CloudWatch and also supports CloudWatch Alarms. Audit logs are highly customizable. When you audit a database, each operation on the data can be monitored and logged to an audit trail, including information about which database cluster is accessed and how. We recommend sending these logs to CloudWatch to help you monitor your Neptune DB clusters.

### Remediation
<a name="neptune-2-remediation"></a>

To publish Neptune audit logs to CloudWatch Logs, see [Publishing Neptune logs to Amazon CloudWatch Logs](https://docs.aws.amazon.com/neptune/latest/userguide/cloudwatch-logs.html) in the *Neptune User Guide*. In the **Log exports** section, choose **Audit**.

## [Neptune.3] Neptune DB cluster snapshots should not be public
<a name="neptune-3"></a>

**Related requirements:** NIST.800-53.r5 AC-21, NIST.800-53.r5 AC-3, NIST.800-53.r5 AC-3(7), NIST.800-53.r5 AC-4, NIST.800-53.r5 AC-4(21), NIST.800-53.r5 AC-6, NIST.800-53.r5 SC-7, NIST.800-53.r5 SC-7(11), NIST.800-53.r5 SC-7(16), NIST.800-53.r5 SC-7(20), NIST.800-53.r5 SC-7(21), NIST.800-53.r5 SC-7(3), NIST.800-53.r5 SC-7(4), NIST.800-53.r5 SC-7(9), PCI DSS v4.0.1/1.4.4

**Category:** Protect > Secure network configuration > Resources not publicly accessible

**Severity:** Critical

**Resource type:** `AWS::RDS::DBClusterSnapshot`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/neptune-cluster-snapshot-public-prohibited.html](https://docs.aws.amazon.com/config/latest/developerguide/neptune-cluster-snapshot-public-prohibited.html) 

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether a Neptune manual DB cluster snapshot is public. The control fails if a Neptune manual DB cluster snapshot is public.

A Neptune DB cluster manual snapshot should not be public unless intended. If you share an unencrypted manual snapshot as public, the snapshot is available to all AWS accounts. Public snapshots may result in unintended data exposure.

### Remediation
<a name="neptune-3-remediation"></a>

To remove public access for Neptune manual DB cluster snapshots, see [Sharing a DB cluster snapshot](https://docs.aws.amazon.com/neptune/latest/userguide/backup-restore-share-snapshot.html) in the *Neptune User Guide*.

## [Neptune.4] Neptune DB clusters should have deletion protection enabled
<a name="neptune-4"></a>

**Related requirements:** NIST.800-53.r5 CA-9(1), NIST.800-53.r5 CM-2, NIST.800-53.r5 CM-2(2), NIST.800-53.r5 CM-3, NIST.800-53.r5 SC-5(2)

**Category:** Protect > Data protection > Data deletion protection

**Severity:** Low

**Resource type:** `AWS::RDS::DBCluster`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/neptune-cluster-deletion-protection-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/neptune-cluster-deletion-protection-enabled.html) 

**Schedule type:** Change triggered

**Parameters:** None

This control checks if a Neptune DB cluster has deletion protection enabled. The control fails if a Neptune DB cluster doesn't have deletion protection enabled.

Enabling cluster deletion protection offers an additional layer of protection against accidental database deletion or deletion by an unauthorized user. A Neptune DB cluster can't be deleted while deletion protection is enabled. You must first disable deletion protection before a delete request can succeed.

### Remediation
<a name="neptune-4-remediation"></a>

To enable deletion protection for an existing Neptune DB cluster, see [ Modifying the DB cluster by using the console, CLI, and API](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.Modifying.html#Aurora.Modifying.Settings) in the *Amazon Aurora User Guide*.

## [Neptune.5] Neptune DB clusters should have automated backups enabled
<a name="neptune-5"></a>

**Related requirements:** NIST.800-53.r5 SI-12

**Category:** Recover > Resilience > Backups enabled

**Severity:** Medium

**Resource type:** `AWS::RDS::DBCluster`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/neptune-cluster-backup-retention-check.html](https://docs.aws.amazon.com/config/latest/developerguide/neptune-cluster-backup-retention-check.html) 

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  `minimumBackupRetentionPeriod`  |  Minimum backup retention period in days  |  Integer  |  `7` to `35`  |  `7`  | 

This control checks whether a Neptune DB cluster has automated backups enabled, and a backup retention period greater than or equal to the specified time frame. The control fails if backups aren't enabled for the Neptune DB cluster, or if the retention period is less than the specified time frame. Unless you provide a custom parameter value for the backup retention period, Security Hub CSPM uses a default value of 7 days.

Backups help you recover more quickly from a security incident and strengthen the resilience of your systems. By automating backups for your Neptune DB clusters, you'll be able to restore your systems to a point in time and minimize downtime and data loss. 

### Remediation
<a name="neptune-5-remediation"></a>

To enable automated backups and set a backup retention period for your Neptune DB clusters, see [ Enabling automated backups](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithAutomatedBackups.html#USER_WorkingWithAutomatedBackups.Enabling) in the *Amazon RDS User Guide*. For **Backup retention period**, choose a value greater than or equal to 7.

## [Neptune.6] Neptune DB cluster snapshots should be encrypted at rest
<a name="neptune-6"></a>

**Related requirements:** NIST.800-53.r5 CA-9(1), NIST.800-53.r5 CM-3(6), NIST.800-53.r5 SC-13, NIST.800-53.r5 SC-28, NIST.800-53.r5 SC-28(1), NIST.800-53.r5 SC-7(10), NIST.800-53.r5 SC-7(18)

**Category:** Protect > Data Protection > Encryption of data-at-rest

**Severity:** Medium

**Resource type:** `AWS::RDS::DBClusterSnapshot`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/neptune-cluster-snapshot-encrypted.html](https://docs.aws.amazon.com/config/latest/developerguide/neptune-cluster-snapshot-encrypted.html) 

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether a Neptune DB cluster snapshot is encrypted at rest. The control fails if a Neptune DB cluster isn't encrypted at rest.

Data at rest refers to any data that's stored in persistent, non-volatile storage for any duration. Encryption helps you protect the confidentiality of such data, reducing the risk that an unauthorized user gets access to it. Data in Neptune DB clusters snapshots should be encrypted at rest for an added layer of security.

### Remediation
<a name="neptune-6-remediation"></a>

You can't encrypt an existing Neptune DB cluster snapshot. Instead, you must restore the snapshot to a new DB cluster and enable encryption on the cluster. You can create an encrypted snapshot from the encrypted cluster. For instructions, see [Restoring from a DB cluster snapshot](https://docs.aws.amazon.com/neptune/latest/userguide/backup-restore-restore-snapshot.html) and [Creating a DB cluster snapshot in Neptune](https://docs.aws.amazon.com/neptune/latest/userguide/backup-restore-create-snapshot.html) in the *Neptune User Guide*.

## [Neptune.7] Neptune DB clusters should have IAM database authentication enabled
<a name="neptune-7"></a>

**Related requirements:** NIST.800-53.r5 AC-2(1), NIST.800-53.r5 AC-3, NIST.800-53.r5 AC-3(15), NIST.800-53.r5 AC-3(7), NIST.800-53.r5 AC-6

**Category:** Protect > Secure access management > Passwordless authentication

**Severity:** Medium

**Resource type:** `AWS::RDS::DBCluster`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/neptune-cluster-iam-database-authentication.html](https://docs.aws.amazon.com/config/latest/developerguide/neptune-cluster-iam-database-authentication.html) 

**Schedule type:** Change triggered

**Parameters:** None

This control checks if a Neptune DB cluster has IAM database authentication enabled. The control fails if IAM database authentication isn't enabled for a Neptune DB cluster.

IAM database authentication for Amazon Neptune database clusters removes the need to store user credentials within the database configuration because authentication is managed externally using IAM. When IAM database authentication is enabled, each request needs to be signed using AWS Signature Version 4. 

### Remediation
<a name="neptune-7-remediation"></a>

By default, IAM database authentication is disabled when you create a Neptune DB cluster. To enable it, see [ Enabling IAM database authentication in Neptune](https://docs.aws.amazon.com/neptune/latest/userguide/iam-auth-enable.html) in the *Neptune User Guide*.

## [Neptune.8] Neptune DB clusters should be configured to copy tags to snapshots
<a name="neptune-8"></a>

**Related requirements:** NIST.800-53.r5 CA-9(1), NIST.800-53.r5 CM-2, NIST.800-53.r5 CM-2(2)

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::RDS::DBCluster`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/neptune-cluster-copy-tags-to-snapshot-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/neptune-cluster-copy-tags-to-snapshot-enabled.html) 

**Schedule type:** Change triggered

**Parameters:** None

This control checks if a Neptune DB cluster is configured to copy all tags to snapshots when the snapshots are created. The control fails if a Neptune DB cluster isn't configured to copy tags to snapshots.

Identification and inventory of your IT assets is a crucial aspect of governance and security. You should tag snapshots in the same way as their parent Amazon RDS database clusters. Copying tags ensures that the metadata for the DB snapshots matches that of the parent database clusters, and that access policies for the DB snapshot also match those of the parent DB instance. 

### Remediation
<a name="neptune-8-remediation"></a>

To copy tags to snapshots for Neptune DB clusters, see [Copying tags in Neptune](https://docs.aws.amazon.com/neptune/latest/userguide/tagging.html#tagging-overview) in the *Neptune User Guide*.

## [Neptune.9] Neptune DB clusters should be deployed across multiple Availability Zones
<a name="neptune-9"></a>

**Related requirements:** NIST.800-53.r5 CP-10, NIST.800-53.r5 CP-6(2), NIST.800-53.r5 SC-36, NIST.800-53.r5 SC-5(2), NIST.800-53.r5 SI-13(5)

**Category:** Recover > Resilience > High availability

**Severity:** Medium

**Resource type:** `AWS::RDS::DBCluster`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/neptune-cluster-multi-az-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/neptune-cluster-multi-az-enabled.html) 

**Schedule type:** Change triggered

**Parameters:** None

This control checks if an Amazon Neptune DB cluster has read-replica instances in multiple Availability Zones (AZs). The control fails if the cluster is deployed in only one AZ.

If an AZ is unavailable and during regular maintenance events, read-replicas serve as failover targets for the primary instance. That is, if the primary instance fails, Neptune promotes a read-replica instance to become the primary instance. By contrast, if your DB cluster doesn't include any read-replica instances, your DB cluster remains unavailable when the primary instance fails until it has been re-created. Re-creating the primary instance takes considerably longer than promoting a read-replica. To ensure high availability, we recommend that you create one or more read-replica instances that have the same DB instance class as the primary instance and are located in different AZs than the primary instance.

### Remediation
<a name="neptune-9-remediation"></a>

To deploy a Neptune DB cluster in multiple AZs,, see [Read-replica DB instances in a Neptune DB cluster](https://docs.aws.amazon.com/neptune/latest/userguide/feature-overview-db-clusters.html#feature-overview-read-replicas) in the *Neptune User Guide*.

# Security Hub CSPM controls for AWS Network Firewall
<a name="networkfirewall-controls"></a>

These AWS Security Hub CSPM controls evaluate the AWS Network Firewall service and resources. The controls might not be available in all AWS Regions. For more information, see [Availability of controls by Region](securityhub-regions.md#securityhub-regions-control-support).

## [NetworkFirewall.1] Network Firewall firewalls should be deployed across multiple Availability Zones
<a name="networkfirewall-1"></a>

**Related requirements:** NIST.800-53.r5 CP-10, NIST.800-53.r5 CP-6(2), NIST.800-53.r5 SC-36, NIST.800-53.r5 SC-5(2), NIST.800-53.r5 SI-13(5)

**Category:** Recover > Resilience > High availability

**Severity:** Medium

**Resource type:** `AWS::NetworkFirewall::Firewall`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/netfw-multi-az-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/netfw-multi-az-enabled.html)

**Schedule type:** Change triggered

**Parameters:** None

This control evaluates whether a firewall managed through AWS Network Firewall is deployed across multiple Availability Zones (AZs). The control fails if a firewall is deployed in only one AZ.

AWS global infrastructure includes multiple AWS Regions. AZs are physically separated, isolated locations within each Region that are connected by low-latency, high-throughput, and highly redundant networking. By deploying a Network Firewall firewall across multiple AZs, you can balance and shift traffic among AZs, which helps you design highly available solutions.

### Remediation
<a name="networkfirewall-1-remediation"></a>

**Deploying a Network Firewall firewall across multiple AZs**

1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).

1. In the navigation pane, under **Network Firewall**, choose **Firewalls**.

1. On the **Firewalls** page, select the firewall that you want to edit.

1. On the firewall details page, choose the **Firewall details** tab.

1. In the **Associated policy and VPC** section, choose **Edit**

1. To add a new AZ, choose **Add New Subnet**. Select the AZ and subnet that you would like to use. Ensure that you select at least two AZs.

1. Choose **Save**.

## [NetworkFirewall.2] Network Firewall logging should be enabled
<a name="networkfirewall-2"></a>

**Related requirements:** NIST.800-53.r5 AC-2(12), NIST.800-53.r5 AC-2(4), NIST.800-53.r5 AC-4(26), NIST.800-53.r5 AC-6(9), NIST.800-53.r5 AU-10, NIST.800-53.r5 AU-12, NIST.800-53.r5 AU-2, NIST.800-53.r5 AU-3, NIST.800-53.r5 AU-6(3), NIST.800-53.r5 AU-6(4), NIST.800-53.r5 AU-9(7), NIST.800-53.r5 CA-7, NIST.800-53.r5 SC-7(9), NIST.800-53.r5 SI-3(8), NIST.800-53.r5 SI-4, NIST.800-53.r5 SI-4(20), NIST.800-53.r5 SI-7(8), NIST.800-171.r2 3.1.20, NIST.800-171.r2 3.13.1

**Category:** Identify > Logging

**Severity:** Medium

**Resource type:** `AWS::NetworkFirewall::LoggingConfiguration`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/netfw-logging-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/netfw-logging-enabled.html)

**Schedule type:** Periodic

**Parameters:** None

This control checks whether logging is enabled for an AWS Network Firewall firewall. The control fails if logging isn't enabled for at least one log type or if the logging destination doesn't exist.

Logging helps you maintain the reliability, availability, and performance of your firewalls. In Network Firewall, logging gives you detailed information about network traffic, including the time that the stateful engine received a packet flow, detailed information about the packet flow, and any stateful rule action taken against the packet flow.

### Remediation
<a name="networkfirewall-2-remediation"></a>

To enable logging for a firewall, see [Updating a firewall's logging configuration](https://docs.aws.amazon.com/network-firewall/latest/developerguide/firewall-update-logging-configuration.html) in the *AWS Network Firewall Developer Guide*.

## [NetworkFirewall.3] Network Firewall policies should have at least one rule group associated
<a name="networkfirewall-3"></a>

**Related requirements:** NIST.800-53.r5 CA-9(1), NIST.800-53.r5 CM-2, NIST.800-171.r2 3.1.3, NIST.800-171.r2 3.13.1

**Category:** Protect > Secure Network Configuration

**Severity:** Medium

**Resource type:** `AWS::NetworkFirewall::FirewallPolicy`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/netfw-policy-rule-group-associated.html](https://docs.aws.amazon.com/config/latest/developerguide/netfw-policy-rule-group-associated.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether a Network Firewall policy has any stateful or stateless rule groups associated. The control fails if stateless or stateful rule groups are not assigned.

A firewall policy defines how your firewall monitors and handles traffic in Amazon Virtual Private Cloud (Amazon VPC). Configuration of stateless and stateful rule groups helps to filter packets and traffic flows, and defines default traffic handling.

### Remediation
<a name="networkfirewall-3-remediation"></a>

To add a rule group to a Network Firewall policy, see [Updating a firewall policy](https://docs.aws.amazon.com/network-firewall/latest/developerguide/firewall-policy-updating.html) in the *AWS Network Firewall Developer Guide*. For information about creating and managing rule groups, see [Rule groups in AWS Network Firewall](https://docs.aws.amazon.com/network-firewall/latest/developerguide/rule-groups.html).

## [NetworkFirewall.4] The default stateless action for Network Firewall policies should be drop or forward for full packets
<a name="networkfirewall-4"></a>

**Related requirements:** NIST.800-53.r5 CA-9(1), NIST.800-53.r5 CM-2

**Category:** Protect > Secure Network Configuration

**Severity:** Medium

**Resource type:** `AWS::NetworkFirewall::FirewallPolicy`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/netfw-policy-default-action-full-packets.html](https://docs.aws.amazon.com/config/latest/developerguide/netfw-policy-default-action-full-packets.html)

**Schedule type:** Change triggered

**Parameters:**
+ `statelessDefaultActions: aws:drop,aws:forward_to_sfe` (not customizable)

This control checks whether the default stateless action for full packets for a Network Firewall policy is drop or forward. The control passes if `Drop` or `Forward` is selected, and fails if `Pass` is selected.

A firewall policy defines how your firewall monitors and handles traffic in Amazon VPC. You configure stateless and stateful rule groups to filter packets and traffic flows. Defaulting to `Pass` can allow unintended traffic.

### Remediation
<a name="networkfirewall-4-remediation"></a>

To change your firewall policy, see [Updating a firewall policy](https://docs.aws.amazon.com/network-firewall/latest/developerguide/firewall-policy-updating.html) in the *AWS Network Firewall Developer Guide*. For **Stateless default actions**, choose **Edit**. Then, choose **Drop** or **Forward to stateful rule groups** as the **Action**.

## [NetworkFirewall.5] The default stateless action for Network Firewall policies should be drop or forward for fragmented packets
<a name="networkfirewall-5"></a>

**Related requirements:** NIST.800-53.r5 CA-9(1), NIST.800-53.r5 CM-2, NIST.800-171.r2 3.1.3, NIST.800-171.r2 3.1.14, NIST.800-171.r2 3.13.1, NIST.800-171.r2 3.13.6

**Category:** Protect > Secure Network Configuration

**Severity:** Medium

**Resource type:** `AWS::NetworkFirewall::FirewallPolicy`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/netfw-policy-default-action-fragment-packets.html](https://docs.aws.amazon.com/config/latest/developerguide/netfw-policy-default-action-fragment-packets.html)

**Schedule type:** Change triggered

**Parameters:**
+ `statelessFragDefaultActions (Required) : aws:drop, aws:forward_to_sfe` (not customizable)

This control checks whether the default stateless action for fragmented packets for a Network Firewall policy is drop or forward. The control passes if `Drop` or `Forward` is selected, and fails if `Pass` is selected.

A firewall policy defines how your firewall monitors and handles traffic in Amazon VPC. You configure stateless and stateful rule groups to filter packets and traffic flows. Defaulting to `Pass` can allow unintended traffic.

### Remediation
<a name="networkfirewall-5-remediation"></a>

To change your firewall policy, see [Updating a firewall policy](https://docs.aws.amazon.com/network-firewall/latest/developerguide/firewall-policy-updating.html) in the *AWS Network Firewall Developer Guide*. For **Stateless default actions**, choose **Edit**. Then, choose **Drop** or **Forward to stateful rule groups** as the **Action**.

## [NetworkFirewall.6] Stateless Network Firewall rule group should not be empty
<a name="networkfirewall-6"></a>

**Related requirements:** NIST.800-53.r5 AC-4(21), NIST.800-53.r5 SC-7, NIST.800-53.r5 SC-7(11), NIST.800-53.r5 SC-7(16), NIST.800-53.r5 SC-7(21), NIST.800-53.r5 SC-7(5), NIST.800-171.r2 3.1.3, NIST.800-171.r2 3.1.14, NIST.800-171.r2 3.13.1, NIST.800-171.r2 3.13.6

**Category:** Protect > Secure Network Configuration

**Severity:** Medium

**Resource type:** `AWS::NetworkFirewall::RuleGroup`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/netfw-stateless-rule-group-not-empty.html](https://docs.aws.amazon.com/config/latest/developerguide/netfw-stateless-rule-group-not-empty.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks if a stateless rule group in AWS Network Firewall contains rules. The control fails if there are no rules in the rule group.

A rule group contains rules that define how your firewall processes traffic in your VPC. An empty stateless rule group, when present in a firewall policy, might give the impression that the rule group will process traffic. However, when the stateless rule group is empty, it does not process traffic.

### Remediation
<a name="networkfirewall-6-remediation"></a>

To add rules to your Network Firewall rule group, see [ Updating a stateful rule group](https://docs.aws.amazon.com/network-firewall/latest/developerguide/rule-group-stateful-updating.html) in the *AWS Network Firewall Developer Guide*. On the firewall details page, for **Stateless rule group**, choose **Edit** to add rules.

## [NetworkFirewall.7] Network Firewall firewalls should be tagged
<a name="networkfirewall-7"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::NetworkFirewall::Firewall`

**AWS Config rule:** `tagged-networkfirewall-firewall` (custom Security Hub CSPM rule)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  |  No default value  | 

This control checks whether an AWS Network Firewall firewall has tags with the specific keys defined in the parameter `requiredTagKeys`. The control fails if the firewall doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredTagKeys`. If the parameter `requiredTagKeys` isn't provided, the control only checks for the existence of a tag key and fails if the firewall isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [What is ABAC for AWS?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Tagging your AWS resources](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *AWS General Reference*.

### Remediation
<a name="networkfirewall-7-remediation"></a>

To add tags to an Network Firewall firewall, see [Tagging AWS Network Firewall resources](https://docs.aws.amazon.com/network-firewall/latest/developerguide/tagging.html) in the *AWS Network Firewall Developer Guide*.

## [NetworkFirewall.8] Network Firewall firewall policies should be tagged
<a name="networkfirewall-8"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::NetworkFirewall::FirewallPolicy`

**AWS Config rule:** `tagged-networkfirewall-firewallpolicy` (custom Security Hub CSPM rule)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  |  No default value  | 

This control checks whether an AWS Network Firewall firewall policy has tags with the specific keys defined in the parameter `requiredTagKeys`. The control fails if the firewall policy doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredTagKeys`. If the parameter `requiredTagKeys` isn't provided, the control only checks for the existence of a tag key and fails if the firewall policy isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [What is ABAC for AWS?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Tagging your AWS resources](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *AWS General Reference*.

### Remediation
<a name="networkfirewall-8-remediation"></a>

To add tags to an Network Firewall policy, see [Tagging AWS Network Firewall resources](https://docs.aws.amazon.com/network-firewall/latest/developerguide/tagging.html) in the *AWS Network Firewall Developer Guide*.

## [NetworkFirewall.9] Network Firewall firewalls should have deletion protection enabled
<a name="networkfirewall-9"></a>

**Related requirements:** NIST.800-53.r5 CA-9(1), NIST.800-53.r5 CM-2, NIST.800-53.r5 CM-2(2), NIST.800-53.r5 CM-3, NIST.800-53.r5 SC-5(2)

**Category:** Protect > Network Security

**Severity:** Medium

**Resource type:** `AWS::NetworkFirewall::Firewall`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/netfw-deletion-protection-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/netfw-deletion-protection-enabled.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether an AWS Network Firewall firewall has deletion protection enabled. The control fails if deletion protection isn't enabled for a firewall.

AWS Network Firewall is a stateful, managed network firewall and intrusion detection service that enables you to inspect and filter traffic to, from, or between your Virtual Private Clouds (VPCs). The deletion protection setting protects against accidental deletion of the firewall.

### Remediation
<a name="networkfirewall-9-remediation"></a>

To enable delete protection on an existing Network Firewall firewall, see [ Updating a firewall](https://docs.aws.amazon.com/network-firewall/latest/developerguide/firewall-updating.html) in the *AWS Network Firewall Developer Guide*. For **Change protections**, select **Enable**. You can also enable deletion protection by invoking the [ UpdateFirewallDeleteProtection](https://docs.aws.amazon.com/network-firewall/latest/APIReference/API_UpdateFirewallDeleteProtection.html) API and setting the `DeleteProtection` field to `true`.

## [NetworkFirewall.10] Network Firewall firewalls should have subnet change protection enabled
<a name="networkfirewall-10"></a>

**Related requirements:** NIST.800-53.r5 CA-9(1), NIST.800-53.r5 CM-2, NIST.800-53.r5 CM-2(2), NIST.800-53.r5 CM-3, NIST.800-53.r5 SC-5(2)

**Category:** Protect > Network Security

**Severity:** Medium

**Resource type:** `AWS::NetworkFirewall::Firewall`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/netfw-subnet-change-protection-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/netfw-subnet-change-protection-enabled.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether subnet change protection is enabled for an AWS Network Firewall firewall. The control fails if subnet change protection isn't enabled for the firewall.

AWS Network Firewall is a stateful, managed network firewall and intrusion detection service that you can use to inspect and filter traffic to, from, or between your Virtual Private Clouds (VPCs). If you enable subnet change protection for a Network Firewall firewall, you can protect the firewall against accidental changes to the firewall's subnet associations.

### Remediation
<a name="networkfirewall-10-remediation"></a>

For information about enabling subnet change protection for an existing Network Firewall firewall, see [Updating a firewall](https://docs.aws.amazon.com/network-firewall/latest/developerguide/firewall-updating.html) in the *AWS Network Firewall Developer Guide*.

# Security Hub CSPM controls for Amazon OpenSearch Service
<a name="opensearch-controls"></a>

These AWS Security Hub CSPM controls evaluate the Amazon OpenSearch Service (OpenSearch Service) service and resources. The controls might not be available in all AWS Regions. For more information, see [Availability of controls by Region](securityhub-regions.md#securityhub-regions-control-support).

## [Opensearch.1] OpenSearch domains should have encryption at rest enabled
<a name="opensearch-1"></a>

**Related requirements:** PCI DSS v3.2.1/1.2.1, PCI DSS v3.2.1/1.3.1, PCI DSS v3.2.1/1.3.4, PCI DSS v3.2.1/7.2.1, NIST.800-53.r5 CA-9(1), NIST.800-53.r5 CM-3(6), NIST.800-53.r5 SC-13, NIST.800-53.r5 SC-28, NIST.800-53.r5 SC-28(1), NIST.800-53.r5 SI-7(6)

**Category:** Protect > Data Protection > Encryption of data-at-rest

**Severity:** Medium

**Resource type:** `AWS::OpenSearch::Domain`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/opensearch-encrypted-at-rest.html](https://docs.aws.amazon.com/config/latest/developerguide/opensearch-encrypted-at-rest.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether OpenSearch domains have encryption-at-rest configuration enabled. The check fails if encryption at rest is not enabled.

For an added layer of security for sensitive data, you should configure your OpenSearch Service domain to be encrypted at rest. When you configure encryption of data at rest, AWS KMS stores and manages your encryption keys. To perform the encryption, AWS KMS uses the Advanced Encryption Standard algorithm with 256-bit keys (AES-256).

To learn more about OpenSearch Service encryption at rest, see [Encryption of data at rest for Amazon OpenSearch Service](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/encryption-at-rest.html) in the *Amazon OpenSearch Service* *Developer Guide*.

### Remediation
<a name="opensearch-1-remediation"></a>

To enable encryption at rest for new and existing OpenSearch domains, see [Enabling encryption of data at rest](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/encryption-at-rest.html#enabling-ear) in the *Amazon OpenSearch Service Developer Guide*.

## [Opensearch.2] OpenSearch domains should not be publicly accessible
<a name="opensearch-2"></a>

**Related requirements:** PCI DSS v3.2.1/1.2.1, PCI DSS v3.2.1/1.3.1, PCI DSS v3.2.1/1.3.2, PCI DSS v3.2.1/1.3.4, PCI DSS v3.2.1/1.3.6, NIST.800-53.r5 AC-21, NIST.800-53.r5 AC-3, NIST.800-53.r5 AC-3(7), NIST.800-53.r5 AC-4, NIST.800-53.r5 AC-4(21), NIST.800-53.r5 AC-6, NIST.800-53.r5 SC-7, NIST.800-53.r5 SC-7(11), NIST.800-53.r5 SC-7(16), NIST.800-53.r5 SC-7(20), NIST.800-53.r5 SC-7(21), NIST.800-53.r5 SC-7(3), NIST.800-53.r5 SC-7(4), NIST.800-53.r5 SC-7(9)

**Category:** Protect > Secure network configuration > Resources within VPC

**Severity:** Critical

**Resource type:** `AWS::OpenSearch::Domain`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/opensearch-in-vpc-only.html](https://docs.aws.amazon.com/config/latest/developerguide/opensearch-in-vpc-only.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether OpenSearch domains are in a VPC. It does not evaluate the VPC subnet routing configuration to determine public access.

You should ensure that OpenSearch domains are not attached to public subnets. See [Resource-based policies](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/ac.html#ac-types-resource) in the Amazon OpenSearch Service Developer Guide. You should also ensure that your VPC is configured according to the recommended best practices. See [Security best practices for your VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-best-practices.html) in the Amazon VPC User Guide.

OpenSearch domains deployed within a VPC can communicate with VPC resources over the private AWS network, without the need to traverse the public internet. This configuration increases the security posture by limiting access to the data in transit. VPCs provide a number of network controls to secure access to OpenSearch domains, including network ACL and security groups. Security Hub recommends that you migrate public OpenSearch domains to VPCs to take advantage of these controls.

### Remediation
<a name="opensearch-2-remediation"></a>

If you create a domain with a public endpoint, you cannot later place it within a VPC. Instead, you must create a new domain and migrate your data. The reverse is also true. If you create a domain within a VPC, it cannot have a public endpoint. Instead, you must either [create another domain](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/createupdatedomains.html#es-createdomains) or disable this control.

For instructions, see [Launching your Amazon OpenSearch Service domains within a VPC](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/vpc.html) in the *Amazon OpenSearch Service Developer Guide*.

## [Opensearch.3] OpenSearch domains should encrypt data sent between nodes
<a name="opensearch-3"></a>

**Related requirements:** NIST.800-53.r5 AC-4, NIST.800-53.r5 SC-13, NIST.800-53.r5 SC-23, NIST.800-53.r5 SC-23(3), NIST.800-53.r5 SC-7(4), NIST.800-53.r5 SC-8, NIST.800-53.r5 SC-8(1), NIST.800-53.r5 SC-8(2)

**Category:** Protect > Data Protection > Encryption of data-in-transit

**Severity:** Medium

**Resource type:** `AWS::OpenSearch::Domain`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/opensearch-node-to-node-encryption-check.html](https://docs.aws.amazon.com/config/latest/developerguide/opensearch-node-to-node-encryption-check.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether OpenSearch domains have node-to-node encryption enabled. This control fails if node-to-node encryption is disabled on the domain.

HTTPS (TLS) can be used to help prevent potential attackers from eavesdropping on or manipulating network traffic using person-in-the-middle or similar attacks. Only encrypted connections over HTTPS (TLS) should be allowed. Enabling node-to-node encryption for OpenSearch domains ensures that intra-cluster communications are encrypted in transit.

There can be a performance penalty associated with this configuration. You should be aware of and test the performance trade-off before enabling this option.

### Remediation
<a name="opensearch-3-remediation"></a>

To enable node-to-node encryption on an OpenSearch domain, see [Enabling node-to-node encryption](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/ntn.html#enabling-ntn) in the *Amazon OpenSearch Service Developer Guide*.

## [Opensearch.4] OpenSearch domain error logging to CloudWatch Logs should be enabled
<a name="opensearch-4"></a>

**Related requirements:** NIST.800-53.r5 AC-2(4), NIST.800-53.r5 AC-4(26), NIST.800-53.r5 AC-6(9), NIST.800-53.r5 AU-10, NIST.800-53.r5 AU-12, NIST.800-53.r5 AU-2, NIST.800-53.r5 AU-3, NIST.800-53.r5 AU-6(3), NIST.800-53.r5 AU-6(4), NIST.800-53.r5 CA-7, NIST.800-53.r5 SC-7(9), NIST.800-53.r5 SI-3(8), NIST.800-53.r5 SI-4(20), NIST.800-53.r5 SI-7(8)

**Category:** Identify > Logging

**Severity:** Medium

**Resource type:** `AWS::OpenSearch::Domain`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/opensearch-logs-to-cloudwatch.html](https://docs.aws.amazon.com/config/latest/developerguide/opensearch-logs-to-cloudwatch.html)

**Schedule type:** Change triggered

**Parameters:**
+ `logtype = 'error'` (not customizable)

This control checks whether OpenSearch domains are configured to send error logs to CloudWatch Logs. This control fails if error logging to CloudWatch is not enabled for a domain.

You should enable error logs for OpenSearch domains and send those logs to CloudWatch Logs for retention and response. Domain error logs can assist with security and access audits, and can help to diagnose availability issues.

### Remediation
<a name="opensearch-4-remediation"></a>

To enable log publishing, see [Enabling log publishing (console)](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/createdomain-configure-slow-logs.html#createdomain-configure-slow-logs-console) in the *Amazon OpenSearch Service Developer Guide*.

## [Opensearch.5] OpenSearch domains should have audit logging enabled
<a name="opensearch-5"></a>

**Related requirements:** NIST.800-53.r5 AC-2(4), NIST.800-53.r5 AC-4(26), NIST.800-53.r5 AC-6(9), NIST.800-53.r5 AU-10, NIST.800-53.r5 AU-12, NIST.800-53.r5 AU-2, NIST.800-53.r5 AU-3, NIST.800-53.r5 AU-6(3), NIST.800-53.r5 AU-6(4), NIST.800-53.r5 CA-7, NIST.800-53.r5 SC-7(9), NIST.800-53.r5 SI-3(8), NIST.800-53.r5 SI-4(20), NIST.800-53.r5 SI-7(8), PCI DSS v4.0.1/10.2.1

**Category:** Identify > Logging

**Severity:** Medium

**Resource type:** `AWS::OpenSearch::Domain`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/opensearch-audit-logging-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/opensearch-audit-logging-enabled.html)

**Schedule type:** Change triggered

**Parameters:**
+ `cloudWatchLogsLogGroupArnList` (not customizable) – Security Hub CSPM does not populate this parameter. Comma-separated list of CloudWatch Logs log groups that should be configured for audit logs.

This control checks whether OpenSearch domains have audit logging enabled. This control fails if an OpenSearch domain does not have audit logging enabled.

Audit logs are highly customizable. They allow you to track user activity on your OpenSearch clusters, including authentication successes and failures, requests to OpenSearch, index changes, and incoming search queries.

### Remediation
<a name="opensearch-5-remediation"></a>

For instructions on enabling audit logs, see [Enabling audit logs](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/audit-logs.html#audit-log-enabling) in the *Amazon OpenSearch Service Developer Guide*.

## [Opensearch.6] OpenSearch domains should have at least three data nodes
<a name="opensearch-6"></a>

**Related requirements:** NIST.800-53.r5 CP-10, NIST.800-53.r5 CP-6(2), NIST.800-53.r5 SC-36, NIST.800-53.r5 SC-5(2), NIST.800-53.r5 SI-13(5)

**Category:** Recover > Resilience > High availability

**Severity:** Medium

**Resource type:** `AWS::OpenSearch::Domain`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/opensearch-data-node-fault-tolerance.html](https://docs.aws.amazon.com/config/latest/developerguide/opensearch-data-node-fault-tolerance.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether OpenSearch domains are configured with at least three data nodes and `zoneAwarenessEnabled` is `true`. This control fails for an OpenSearch domain if `instanceCount` is less than 3 or `zoneAwarenessEnabled` is `false`.

To achieve cluster-level high availability and fault tolerance, an OpenSearch domain should have at least three data nodes. Deploying an OpenSearch domain with at least three data nodes ensures cluster operations if a node fails.

### Remediation
<a name="opensearch-6-remediation"></a>

**To modify the number of data nodes in an OpenSearch domain**

1. Sign in to the AWS console and open the Amazon OpenSearch Service console at [https://console.aws.amazon.com/aos/](https://console.aws.amazon.com/aos/).

1. Under **My domains**, choose the name of the domain to edit, and choose **Edit**.

1. Under **Data nodes** set **Number of nodes** to a number greater than `3`. If you are deploying to three Availability Zones, set the number to a multiple of three to ensure equal distribution across Availability Zones. 

1. Choose **Submit**.

## [Opensearch.7] OpenSearch domains should have fine-grained access control enabled
<a name="opensearch-7"></a>

**Related requirements:** NIST.800-53.r5 AC-2(1), NIST.800-53.r5 AC-3, NIST.800-53.r5 AC-3(15), NIST.800-53.r5 AC-3(7), NIST.800-53.r5 AC-5, NIST.800-53.r5 AC-6

**Category:** Protect > Secure Access Management > Sensitive API actions restricted

**Severity:** High

**Resource type:** `AWS::OpenSearch::Domain`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/opensearch-access-control-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/opensearch-access-control-enabled.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether OpenSearch domains have fine-grained access control enabled. The control fails if the fine-grained access control is not enabled. Fine-grained access control requires `advanced-security-options`in the OpenSearch parameter `update-domain-config` to be enabled.

Fine-grained access control offers additional ways of controlling access to your data on Amazon OpenSearch Service.

### Remediation
<a name="opensearch-7-remediation"></a>

To enable fine-grained access control, see [Fine-grained access control in Amazon OpenSearch Service](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/fgac.html) in the *Amazon OpenSearch Service Developer Guide*.

## [Opensearch.8] Connections to OpenSearch domains should be encrypted using the latest TLS security policy
<a name="opensearch-8"></a>

**Related requirements:** NIST.800-53.r5 AC-17(2), NIST.800-53.r5 AC-4, NIST.800-53.r5 IA-5(1), NIST.800-53.r5 SC-12(3), NIST.800-53.r5 SC-13, NIST.800-53.r5 SC-23, NIST.800-53.r5 SC-23(3), NIST.800-53.r5 SC-7(4), NIST.800-53.r5 SC-8, NIST.800-53.r5 SC-8(1), NIST.800-53.r5 SC-8(2), NIST.800-53.r5 SI-7(6)

**Category:** Protect > Data Protection > Encryption of data-in-transit

**Severity:** Medium

**Resource type:** `AWS::OpenSearch::Domain`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/opensearch-https-required.html](https://docs.aws.amazon.com/config/latest/developerguide/opensearch-https-required.html)

**Schedule type:** Change triggered

**Parameters:**
+ `tlsPolicies: Policy-Min-TLS-1-2-PFS-2023-10` (not customizable)

This controls checks whether an Amazon OpenSearch Service domain endpoint is configured to use the latest TLS security policy. The control fails if the OpenSearch domain endpoint isn't configured to use the latest supported policy or if HTTPs isn't enabled.

HTTPS (TLS) can be used to help prevent potential attackers from using person-in-the-middle or similar attacks to eavesdrop on or manipulate network traffic. Only encrypted connections over HTTPS (TLS) should be allowed. Encrypting data in transit can affect performance. You should test your application with this feature to understand the performance profile and the impact of TLS. TLS 1.2 provides several security enhancements over previous versions of TLS. 

### Remediation
<a name="opensearch-8-remediation"></a>

To enable TLS encryption, use the [UpdateDomainConfig](https://docs.aws.amazon.com/opensearch-service/latest/APIReference/API_UpdateDomainConfig.html) API operation. Configure the [DomainEndpointOptions](https://docs.aws.amazon.com/opensearch-service/latest/APIReference/API_DomainEndpointOptions.html) field to specify the value for `TLSSecurityPolicy`. For more information, see [Node-to-node encryption](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/ntn.html) in the *Amazon OpenSearch Service Developer Guide*.

## [Opensearch.9] OpenSearch domains should be tagged
<a name="opensearch-9"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::OpenSearch::Domain`

**AWS Config rule:** `tagged-opensearch-domain` (custom Security Hub CSPM rule)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  |  No default value  | 

This control checks whether an Amazon OpenSearch Service domain has tags with the specific keys defined in the parameter `requiredTagKeys`. The control fails if the domain doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredTagKeys`. If the parameter `requiredTagKeys` isn't provided, the control only checks for the existence of a tag key and fails if the domain isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [What is ABAC for AWS?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Tagging your AWS resources](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *AWS General Reference*.

### Remediation
<a name="opensearch-9-remediation"></a>

To add tags to an OpenSearch Service domain, see [Working with tags](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/managedomains-awsresourcetagging.html#managedomains-awsresourcetagging-console) in the *Amazon OpenSearch Service Developer Guide*.

## [Opensearch.10] OpenSearch domains should have the latest software update installed
<a name="opensearch-10"></a>

**Related requirements:** NIST.800-53.r5 SI-2, NIST.800-53.r5 SI-2(2), NIST.800-53.r5 SI-2(4), NIST.800-53.r5 SI-2(5), PCI DSS v4.0.1/6.3.3

**Category:** Identify > Vulnerability, patch, and version management

**Severity:** Medium

**Resource type:** `AWS::OpenSearch::Domain`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/opensearch-update-check.html](https://docs.aws.amazon.com/config/latest/developerguide/opensearch-update-check.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether an Amazon OpenSearch Service domain has the latest software update installed. The control fails if a software update is available but not installed for the domain.

OpenSearch Service software updates provide the latest platform fixes, updates, and features available for the environment. Keeping up-to-date with patch installation helps maintain domain security and availability. If no action is taken on required updates, the service software is updated automatically (typically after 2 weeks). We recommend scheduling updates during a time of low traffic to the domain to minimize service disruption. 

### Remediation
<a name="opensearch-10-remediation"></a>

To install software updates for an OpenSearch domain, see [Starting an update](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/service-software.html#service-software-requesting) in the *Amazon OpenSearch Service Developer Guide*.

## [Opensearch.11] OpenSearch domains should have at least three dedicated primary nodes
<a name="opensearch-11"></a>

**Related requirements:** NIST.800-53.r5 CP-10, NIST.800-53.r5 CP-2, NIST.800-53.r5 SC-5, NIST.800-53.r5 SC-36, NIST.800-53.r5 SI-13

**Category:** Recover > Resilience > High availability

**Severity:** Low

**Resource type:** `AWS::OpenSearch::Domain`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/opensearch-primary-node-fault-tolerance.html](https://docs.aws.amazon.com/config/latest/developerguide/opensearch-primary-node-fault-tolerance.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether an Amazon OpenSearch Service domain is configured with at least three dedicated primary nodes. The control fails if the domain has fewer than three dedicated primary nodes.

OpenSearch Service uses dedicated primary nodes to increase cluster stability. A dedicated primary node performs cluster management tasks, but doesn't hold data or respond to data upload requests. We recommend that you use multi-AZ with standby, which adds three dedicated primary nodes to each production OpenSearch domain. 

### Remediation
<a name="opensearch-11-remediation"></a>

To change the number of primary nodes for an OpenSearch domain, see [Creating and managing Amazon OpenSearch Service domains](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/createupdatedomains.html) in the *Amazon OpenSearch Service Developer Guide*.

# Security Hub CSPM controls for AWS Private CA
<a name="pca-controls"></a>

These AWS Security Hub CSPM controls evaluate the AWS Private Certificate Authority (AWS Private CA) service and resources.

These controls may not be available in all AWS Regions. For more information, see [Availability of controls by Region](securityhub-regions.md#securityhub-regions-control-support).

## [PCA.1] AWS Private CA root certificate authority should be disabled
<a name="pca-1"></a>

**Related requirements:** NIST.800-53.r5 CA-9(1), NIST.800-53.r5 CM-2

**Category:** Protect > Secure network configuration

**Severity:** Low

**Resource type:** `AWS::ACMPCA::CertificateAuthority`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/acm-pca-root-ca-disabled.html](https://docs.aws.amazon.com/config/latest/developerguide/acm-pca-root-ca-disabled.html)

**Schedule type:** Periodic

**Parameters:** None

This control checks if AWS Private CA has a root certificate authority (CA) that is disabled. The control fails if the root CA is enabled.

With AWS Private CA, you can create a CA hierarchy that includes a root CA and subordinate CAs. You should minimize the use of the root CA for daily tasks, especially in production environments. The root CA should only be used to issue certificates for intermediate CAs. This allows the root CA to be stored out of harm's way while the intermediate CAs perform the daily task of issuing end-entity certificates.

### Remediation
<a name="pca-1-remediation"></a>

To disable the root CA, see [Update CA status](https://docs.aws.amazon.com/privateca/latest/userguide/console-update.html#console-update-status-steps) in the *AWS Private Certificate Authority User Guide*.

## [PCA.2] AWS Private CA certificate authorities should be tagged
<a name="pca-2"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::ACMPCA::CertificateAuthority`

**AWS Config rule:** `acmpca-certificate-authority-tagged`

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredKeyTags  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  |  No default value  | 

This control checks whether an AWS Private CA certificate authority has tags with the specific keys defined in the parameter `requiredKeyTags`. The control fails if the certificate authority doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredKeyTags`. If the parameter `requiredKeyTags` isn't provided, the control only checks for the existence of a tag key and fails if the certificate authority isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [Define permissions based on attributes with ABAC authorization](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Best practices and strategies](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *Tagging AWS Resources and Tag Editor User Guide*.

### Remediation
<a name="pca-2-remediation"></a>

To add tags to an AWS Private CA authority, see [Add tags for your private CA](https://docs.aws.amazon.com/privateca/latest/userguide/PcaCaTagging.html) in the *AWS Private Certificate Authority User Guide*.

# Security Hub CSPM controls for Amazon RDS
<a name="rds-controls"></a>

These AWS Security Hub CSPM controls evaluate the Amazon Relational Database Service (Amazon RDS) and Amazon RDS resources. The controls might not be available in all AWS Regions. For more information, see [Availability of controls by Region](securityhub-regions.md#securityhub-regions-control-support).

## [RDS.1] RDS snapshot should be private
<a name="rds-1"></a>

**Related requirements:** PCI DSS v3.2.1/1.2.1, PCI DSS v3.2.1/1.3.1, PCI DSS v3.2.1/1.3.4, PCI DSS v3.2.1/1.3.6, PCI DSS v3.2.1/7.2.1, NIST.800-53.r5 AC-21, NIST.800-53.r5 AC-3, NIST.800-53.r5 AC-3(7), NIST.800-53.r5 AC-4, NIST.800-53.r5 AC-4(21), NIST.800-53.r5 AC-6, NIST.800-53.r5 SC-7, NIST.800-53.r5 SC-7(11), NIST.800-53.r5 SC-7(16), NIST.800-53.r5 SC-7(20), NIST.800-53.r5 SC-7(21), NIST.800-53.r5 SC-7(3), NIST.800-53.r5 SC-7(4), NIST.800-53.r5 SC-7(9)

**Category:** Protect > Secure network configuration

**Severity:** Critical

**Resource type:** `AWS::RDS::DBClusterSnapshot`, `AWS::RDS::DBSnapshot`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/rds-snapshots-public-prohibited.html](https://docs.aws.amazon.com/config/latest/developerguide/rds-snapshots-public-prohibited.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether Amazon RDS snapshots are public. The control fails if RDS snapshots are public. This control evaluates RDS instances, Aurora DB instances, Neptune DB instances, and Amazon DocumentDB clusters.

RDS snapshots are used to back up the data on your RDS instances at a specific point in time. They can be used to restore previous states of RDS instances.

An RDS snapshot must not be public unless intended. If you share an unencrypted manual snapshot as public, this makes the snapshot available to all AWS accounts. This may result in unintended data exposure of your RDS instance.

Note that if the configuration is changed to allow public access, the AWS Config rule may not be able to detect the change for up to 12 hours. Until the AWS Config rule detects the change, the check passes even though the configuration violates the rule.

To learn more about sharing a DB snapshot, see [Sharing a DB snapshot](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ShareSnapshot.html) in the *Amazon RDS User Guide*.

### Remediation
<a name="rds-1-remediation"></a>

To remove public access from RDS snapshots, see [Sharing a snapshot](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ShareSnapshot.html#USER_ShareSnapshot.Sharing) in the *Amazon RDS User Guide*. For **DB snapshot visibility**, we choose **Private**.

## [RDS.2] RDS DB Instances should prohibit public access, as determined by the PubliclyAccessible configuration
<a name="rds-2"></a>

**Related requirements:** CIS AWS Foundations Benchmark v5.0.0/2.2.3, CIS AWS Foundations Benchmark v3.0.0/2.3.3, NIST.800-53.r5 AC-4, NIST.800-53.r5 AC-4(21), NIST.800-53.r5 SC-7, NIST.800-53.r5 SC-7(11), NIST.800-53.r5 SC-7(16), NIST.800-53.r5 SC-7(21), NIST.800-53.r5 SC-7(4), NIST.800-53.r5 SC-7(5), PCI DSS v3.2.1/1.2.1, PCI DSS v3.2.1/1.3.1, PCI DSS v3.2.1/1.3.2, PCI DSS v3.2.1/1.3.4, PCI DSS v3.2.1/1.3.6, PCI DSS v3.2.1/7.2.1, PCI DSS v4.0.1/1.4.4

**Category:** Protect > Secure network configuration

**Severity:** Critical

**Resource type:** `AWS::RDS::DBInstance`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/rds-instance-public-access-check.html](https://docs.aws.amazon.com/config/latest/developerguide/rds-instance-public-access-check.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether Amazon RDS instances are publicly accessible by evaluating the `PubliclyAccessible` field in the instance configuration item.

Neptune DB instances and Amazon DocumentDB clusters do not have the `PubliclyAccessible` flag and cannot be evaluated. However, this control can still generate findings for these resources. You can suppress these findings.

The `PubliclyAccessible` value in the RDS instance configuration indicates whether the DB instance is publicly accessible. When the DB instance is configured with `PubliclyAccessible`, it is an Internet-facing instance with a publicly resolvable DNS name, which resolves to a public IP address. When the DB instance isn't publicly accessible, it is an internal instance with a DNS name that resolves to a private IP address.

Unless you intend for your RDS instance to be publicly accessible, the RDS instance should not be configured with `PubliclyAccessible` value. Doing so might allow unnecessary traffic to your database instance.

### Remediation
<a name="rds-2-remediation"></a>

To remove public access from RDS DB instances, see [Modifying an Amazon RDS DB instance](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.DBInstance.Modifying.html) in the *Amazon RDS User Guide*. For **Public access**, choose **No**.

## [RDS.3] RDS DB instances should have encryption at-rest enabled
<a name="rds-3"></a>

**Related requirements:** CIS AWS Foundations Benchmark v5.0.0/2.2.1, CIS AWS Foundations Benchmark v3.0.0/2.3.1, CIS AWS Foundations Benchmark v1.4.0/2.3.1, NIST.800-53.r5 CA-9(1), NIST.800-53.r5 CM-3(6), NIST.800-53.r5 SC-13, NIST.800-53.r5 SC-28, NIST.800-53.r5 SC-28(1), NIST.800-53.r5 SC-7(10), NIST.800-53.r5 SI-7(6)

**Category:** Protect > Data Protection > Encryption of data-at-rest

**Severity:** Medium

**Resource type:** `AWS::RDS::DBInstance`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/rds-storage-encrypted.html](https://docs.aws.amazon.com/config/latest/developerguide/rds-storage-encrypted.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether storage encryption is enabled for your Amazon RDS DB instances.

This control is intended for RDS DB instances. However, it can also generate findings for Aurora DB instances, Neptune DB instances, and Amazon DocumentDB clusters. If these findings are not useful, then you can suppress them.

For an added layer of security for your sensitive data in RDS DB instances, you should configure your RDS DB instances to be encrypted at rest. To encrypt your RDS DB instances and snapshots at rest, enable the encryption option for your RDS DB instances. Data that is encrypted at rest includes the underlying storage for DB instances, its automated backups, read replicas, and snapshots. 

RDS encrypted DB instances use the open standard AES-256 encryption algorithm to encrypt your data on the server that hosts your RDS DB instances. After your data is encrypted, Amazon RDS handles authentication of access and decryption of your data transparently with a minimal impact on performance. You do not need to modify your database client applications to use encryption. 

Amazon RDS encryption is currently available for all database engines and storage types. Amazon RDS encryption is available for most DB instance classes. To learn about DB instance classes that do not support Amazon RDS encryption, see [Encrypting Amazon RDS resources](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.Encryption.html) in the *Amazon RDS User Guide*.

### Remediation
<a name="rds-3-remediation"></a>

For information about encrypting DB instances in Amazon RDS, see [Encrypting Amazon RDS resources](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.Encryption.html) in the *Amazon RDS User Guide*.

## [RDS.4] RDS cluster snapshots and database snapshots should be encrypted at rest
<a name="rds-4"></a>

**Related requirements:** NIST.800-53.r5 CA-9(1), NIST.800-53.r5 CM-3(6), NIST.800-53.r5 SC-13, NIST.800-53.r5 SC-28, NIST.800-53.r5 SC-28(1), NIST.800-53.r5 SC-7(10), NIST.800-53.r5 SI-7(6)

**Category:** Protect > Data Protection > Encryption of data-at-rest

**Severity:** Medium

**Resource type:** `AWS::RDS::DBClusterSnapshot`,` AWS::RDS::DBSnapshot`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/rds-snapshot-encrypted.html](https://docs.aws.amazon.com/config/latest/developerguide/rds-snapshot-encrypted.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether an RDS DB snapshot is encrypted. The control fails if an RDS DB snapshot isn't encrypted.

This control is intended for RDS DB instances. However, it can also generate findings for snapshots of Aurora DB instances, Neptune DB instances, and Amazon DocumentDB clusters. If these findings are not useful, then you can suppress them.

Encrypting data at rest reduces the risk that an unauthenticated user gets access to data that is stored on disk. Data in RDS snapshots should be encrypted at rest for an added layer of security.

### Remediation
<a name="rds-4-remediation"></a>

To encrypt an RDS snapshot, see [Encrypting Amazon RDS resources](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.Encryption.html) in the *Amazon RDS User Guide*. When you encrypt an RDS DB instance, the encrypted data includes the underlying storage for the instance, its automated backups, read replicas, and snapshots.

You can only encrypt an RDS DB instance when you create it, not after the DB instance is created. However, because you can encrypt a copy of an unencrypted snapshot, you can effectively add encryption to an unencrypted DB instance. That is, you can create a snapshot of your DB instance, and then create an encrypted copy of that snapshot. You can then restore a DB instance from the encrypted snapshot, and thus you have an encrypted copy of your original DB instance.

## [RDS.5] RDS DB instances should be configured with multiple Availability Zones
<a name="rds-5"></a>

**Related requirements:** CIS AWS Foundations Benchmark v5.0.0/2.2.4, NIST.800-53.r5 CP-10, NIST.800-53.r5 CP-6(2), NIST.800-53.r5 SC-36, NIST.800-53.r5 SC-5(2), NIST.800-53.r5 SI-13(5)

**Category:** Recover > Resilience > High availability

**Severity:** Medium

**Resource type:** `AWS::RDS::DBInstance`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/rds-multi-az-support.html](https://docs.aws.amazon.com/config/latest/developerguide/rds-multi-az-support.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether high availability is enabled for your RDS DB instances. The control fails if an RDS DB instance isn't configured with multiple Availability Zones (AZs). This control doesn't apply to RDS DB instances that are part of a Multi-AZ DB cluster deployment.

Configuring Amazon RDS DB instances with AZs helps ensure the availability of stored data. Multi-AZ deployments allow for automated failover if there is an issue with AZ availability and during regular RDS maintenance.

### Remediation
<a name="rds-5-remediation"></a>

To deploy your DB instances in multiple AZs, [Modifying a DB instance to be a Multi-AZ DB instance deployment](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZSingleStandby.html#Concepts.MultiAZ.Migrating) in the *Amazon RDS User Guide*.

## [RDS.6] Enhanced monitoring should be configured for RDS DB instances
<a name="rds-6"></a>

**Related requirements:** NIST.800-53.r5 CA-7, NIST.800-53.r5 SI-2

**Category:** Detect > Detection services

**Severity:** Low

**Resource type:** `AWS::RDS::DBInstance`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/rds-enhanced-monitoring-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/rds-enhanced-monitoring-enabled.html)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  `monitoringInterval`  |  Number of seconds between monitoring metric collection intervals  |  Enum  |  `1`, `5`, `10`, `15`, `30`, `60`  |  No default value  | 

This control checks whether enhanced monitoring is enabled for an Amazon Relational Database Service (Amazon RDS) DB instance. The control fails if enhanced monitoring isn't enabled for the instance. If you provide a custom value for the `monitoringInterval` parameter, the control passes only if enhanced monitoring metrics are collected for the instance at the specified interval.

In Amazon RDS, Enhanced Monitoring enables a more rapid response to performance changes in underlying infrastructure. These performance changes could result in a lack of availability of the data. Enhanced Monitoring provides real-time metrics of the operating system that your RDS DB instance runs on. An agent is installed on the instance. The agent can obtain metrics more accurately than is possible from the hypervisor layer.

Enhanced Monitoring metrics are useful when you want to see how different processes or threads on a DB instance use the CPU. For more information, see [Enhanced Monitoring](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Monitoring.OS.html) in the *Amazon RDS User Guide*.

### Remediation
<a name="rds-6-remediation"></a>

For detailed instructions on enabling Enhanced Monitoring for your DB instance, see [Setting up for and enabling Enhanced Monitoring](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Monitoring.OS.Enabling) in the *Amazon RDS User Guide*.

## [RDS.7] RDS clusters should have deletion protection enabled
<a name="rds-7"></a>

**Related requirements:** NIST.800-53.r5 CM-3, NIST.800-53.r5 SC-5(2)

**Category:** Protect > Data protection > Data deletion protection

**Severity:** Medium

**Resource type:** `AWS::RDS::DBCluster`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/rds-cluster-deletion-protection-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/rds-cluster-deletion-protection-enabled.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether an RDS DB cluster has deletion protection enabled. The control fails if an RDS DB cluster doesn't have deletion protection enabled.

This control is intended for RDS DB instances. However, it can also generate findings for Aurora DB instances, Neptune DB instances, and Amazon DocumentDB clusters. If these findings are not useful, then you can suppress them.

Enabling cluster deletion protection is an additional layer of protection against accidental database deletion or deletion by an unauthorized entity.

When deletion protection is enabled, an RDS cluster cannot be deleted. Before a deletion request can succeed, deletion protection must be disabled.

### Remediation
<a name="rds-7-remediation"></a>

To enable deletion protection for an RDS DB cluster, see [Modifying the DB cluster by using the console, CLI, and API](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.Modifying.html#Aurora.Modifying.Cluster) in the *Amazon RDS User Guide*. For **Deletion protection**, choose **Enable deletion protection**. 

## [RDS.8] RDS DB instances should have deletion protection enabled
<a name="rds-8"></a>

**Related requirements:** NIST.800-53.r5 CM-3, NIST.800-53.r5 SC-5(2), NIST.800-53.r5 SI-13(5)

**Category: **Protect > Data protection > Data deletion protection

**Severity:** Low

**Resource type:** `AWS::RDS::DBInstance`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/rds-instance-deletion-protection-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/rds-instance-deletion-protection-enabled.html)

**Schedule type:** Change triggered

**Parameters:**
+ `databaseEngines`: `mariadb,mysql,custom-oracle-ee,oracle-ee-cdb,oracle-se2-cdb,oracle-ee,oracle-se2,oracle-se1,oracle-se,postgres,sqlserver-ee,sqlserver-se,sqlserver-ex,sqlserver-web` (not customizable)

This control checks whether your RDS DB instances that use one of the listed database engines have deletion protection enabled. The control fails if an RDS DB instance doesn't have deletion protection enabled.

Enabling instance deletion protection is an additional layer of protection against accidental database deletion or deletion by an unauthorized entity.

While deletion protection is enabled, an RDS DB instance cannot be deleted. Before a deletion request can succeed, deletion protection must be disabled.

### Remediation
<a name="rds-8-remediation"></a>

To enable deletion protection for an RDS DB instance, see [Modifying an Amazon RDS DB instance](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.DBInstance.Modifying.html) in the *Amazon RDS User Guide*. For **Deletion protection**, choose **Enable deletion protection**. 

## [RDS.9] RDS DB instances should publish logs to CloudWatch Logs
<a name="rds-9"></a>

**Related requirements:** NIST.800-53.r5 AC-2(4), NIST.800-53.r5 AC-4(26), NIST.800-53.r5 AC-6(9), NIST.800-53.r5 AU-10, NIST.800-53.r5 AU-12, NIST.800-53.r5 AU-2, NIST.800-53.r5 AU-3, NIST.800-53.r5 AU-6(3), NIST.800-53.r5 AU-6(4), NIST.800-53.r5 CA-7, NIST.800-53.r5 SC-7(10), NIST.800-53.r5 SC-7(9), NIST.800-53.r5 SI-3(8), NIST.800-53.r5 SI-4(20), NIST.800-53.r5 SI-7(8), PCI DSS v4.0.1/10.2.1

**Category:** Identify > Logging

**Severity:** Medium

**Resource type:** `AWS::RDS::DBInstance`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/rds-logging-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/rds-logging-enabled.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether an Amazon RDS DB instance is configured to publish the following logs to Amazon CloudWatch Logs. The control fails if the instance isn’t configured to publish the following logs to CloudWatch Logs:
+ Oracle: Alert, Audit, Trace, Listener
+ PostgreSQL: Postgresql, Upgrade
+ MySQL: Audit, Error, General, SlowQuery
+ MariaDB: Audit, Error, General, SlowQuery
+ SQL Server: Error, Agent
+ Aurora: Audit, Error, General, SlowQuery
+ Aurora-MySQL: Audit, Error, General, SlowQuery
+ Aurora-PostgreSQL: Postgresql

RDS databases should have relevant logs enabled. Database logging provides detailed records of requests made to RDS. Database logs can assist with security and access audits and can help to diagnose availability issues.

### Remediation
<a name="rds-9-remediation"></a>

For information about publishing RDS database logs to CloudWatch Logs, see [Specifying the logs to publish to CloudWatch Logs](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_LogAccess.Procedural.UploadtoCloudWatch.html#integrating_cloudwatchlogs.configure) in the *Amazon RDS User Guide*.

## [RDS.10] IAM authentication should be configured for RDS instances
<a name="rds-10"></a>

**Related requirements:** NIST.800-53.r5 AC-2(1), NIST.800-53.r5 AC-3, NIST.800-53.r5 AC-3(15), NIST.800-53.r5 AC-3(7), NIST.800-53.r5 AC-6

**Category:** Protect > Secure access management > Passwordless authentication

**Severity:** Medium

**Resource type:** `AWS::RDS::DBInstance`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/rds-instance-iam-authentication-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/rds-instance-iam-authentication-enabled.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether an RDS DB instance has IAM database authentication enabled. The control fails if IAM authentication is not configured for RDS DB instances. This control only evaluates RDS instances with the following engine types: `mysql`, `postgres`, `aurora`, `aurora-mysql`, `aurora-postgresql`, and `mariadb`. An RDS instance must also be in one of the following states for a finding to be generated: `available`, `backing-up`, `storage-optimization`, or `storage-full`.

IAM database authentication allows authentication to database instances with an authentication token instead of a password. Network traffic to and from the database is encrypted using SSL. For more information, see [IAM database authentication](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/UsingWithRDS.IAMDBAuth.html) in the *Amazon Aurora User Guide*.

### Remediation
<a name="rds-10-remediation"></a>

To activate IAM database authentication on an RDS DB instance, see [Enabling and disabling IAM database authentication](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.IAMDBAuth.Enabling.html) in the *Amazon RDS User Guide*.

## [RDS.11] RDS instances should have automatic backups enabled
<a name="rds-11"></a>

**Related requirements:** NIST.800-53.r5 CP-10, NIST.800-53.r5 CP-6, NIST.800-53.r5 CP-6(1), NIST.800-53.r5 CP-6(2), NIST.800-53.r5 CP-9, NIST.800-53.r5 SC-5(2), NIST.800-53.r5 SI-12, NIST.800-53.r5 SI-13(5)

**Category:** Recover > Resilience > Backups enabled 

**Severity:** Medium

**Resource type:** `AWS::RDS::DBInstance`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/db-instance-backup-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/db-instance-backup-enabled.html)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  `backupRetentionMinimum`  |  Minimum backup retention period in days  |  Integer  |  `7` to `35`  |  `7`  | 
|  `checkReadReplicas`  |  Checks whether RDS DB instances have backups enabled for read replicas  |  Boolean  |  Not customizable  |  `false`  | 

This control checks whether an Amazon Relational Database Service instance has automated backups enabled, and a backup retention period greater than or equal to the specified time frame. Read replicas are excluded from evaluation. The control fails if backups aren't enabled for the instance, or if the retention period is less than the specified time frame. Unless you provide a custom parameter value for the backup retention period, Security Hub CSPM uses a default value of 7 days.

Backups help you more quickly recover from a security incident and strengthens the resilience of your systems. Amazon RDS lets you configure daily full instance volume snapshots. For more information about Amazon RDS automated backups, see [Working with Backups](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithAutomatedBackups.html) in the *Amazon RDS User Guide*.

### Remediation
<a name="rds-11-remediation"></a>

To enable automated backups on an RDS DB instance, see [Enabling automated backups](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithAutomatedBackups.html#USER_WorkingWithAutomatedBackups.Enabling) in the *Amazon RDS User Guide*.

## [RDS.12] IAM authentication should be configured for RDS clusters
<a name="rds-12"></a>

**Related requirements:** NIST.800-53.r5 AC-2(1), NIST.800-53.r5 AC-3, NIST.800-53.r5 AC-3(15), NIST.800-53.r5 AC-3(7), NIST.800-53.r5 AC-6

**Category:** Protect > Secure access management > Passwordless authentication

**Severity:** Medium

**Resource type:** `AWS::RDS::DBCluster`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/rds-cluster-iam-authentication-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/rds-cluster-iam-authentication-enabled.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether an Amazon RDS DB cluster has IAM database authentication enabled.

IAM database authentication allows for password-free authentication to database instances. The authentication uses an authentication token. Network traffic to and from the database is encrypted using SSL. For more information, see [IAM database authentication](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/UsingWithRDS.IAMDBAuth.html) in the *Amazon Aurora User Guide*.

### Remediation
<a name="rds-12-remediation"></a>

To enable IAM authentication for a DB cluster, see [Enabling and disabling IAM database authentication](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/UsingWithRDS.IAMDBAuth.Enabling.html) in the *Amazon Aurora User Guide*. 

## [RDS.13] RDS automatic minor version upgrades should be enabled
<a name="rds-13"></a>

**Related requirements:** CIS AWS Foundations Benchmark v5.0.0/2.2.2, CIS AWS Foundations Benchmark v3.0.0/2.3.2, NIST.800-53.r5 SI-2, NIST.800-53.r5 SI-2(2), NIST.800-53.r5 SI-2(4), NIST.800-53.r5 SI-2(5), PCI DSS v4.0.1/6.3.3

**Category:** Identify > Vulnerability, patch, and version management

**Severity:** High

**Resource type:** `AWS::RDS::DBInstance`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/rds-automatic-minor-version-upgrade-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/rds-automatic-minor-version-upgrade-enabled.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether automatic minor version upgrades are enabled for the RDS database instance.

Automatic minor version upgrades periodically update a database to recent database engine versions. However, the upgrade might not always include the latest database engine version. If you need to keep your databases on specific versions at particular times, we recommend that you manually upgrade to the database versions that you need according to your required schedule. In cases of critical security issues or when a version reaches its end-of-support date, Amazon RDS might apply a minor version upgrade even if you haven't enabled the **Auto minor version upgrade** option. For more information, see the Amazon RDS upgrade documentation for your specific database engine:
+ [Automatic minor version upgrades for RDS for MariaDB](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_UpgradeDBInstance.MariaDB.Minor.html)
+ [Automatic minor version upgrades for RDS for MySQL](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_UpgradeDBInstance.MySQL.Minor.html)
+ [Automatic minor version upgrades for RDS for PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_UpgradeDBInstance.PostgreSQL.Minor.html)
+ [Db2 on Amazon RDS versions](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Db2.Concepts.VersionMgmt.html)
+ [Oracle minor version upgrades](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_UpgradeDBInstance.Oracle.Minor.html)
+ [Upgrades of the Microsoft SQL Server DB engine](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_UpgradeDBInstance.SQLServer.html)

### Remediation
<a name="rds-13-remediation"></a>

To enable automatic minor version upgrades for an existing DB instance, see [Modifying an Amazon RDS DB instance](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.DBInstance.Modifying.html) in the *Amazon RDS User Guide*. For **Auto minor version upgrade**, select **Yes**.

## [RDS.14] Amazon Aurora clusters should have backtracking enabled
<a name="rds-14"></a>

**Related requirements:** NIST.800-53.r5 CP-10, NIST.800-53.r5 CP-6, NIST.800-53.r5 CP-6(1), NIST.800-53.r5 CP-6(2), NIST.800-53.r5 CP-9, NIST.800-53.r5 SI-13(5)

**Category:** Recover > Resilience > Backups enabled 

**Severity:** Medium

**Resource type:** `AWS::RDS::DBCluster`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/aurora-mysql-backtracking-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/aurora-mysql-backtracking-enabled.html)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  `BacktrackWindowInHours`  |  Number of hours to backtrack an Aurora MySQL cluster  |  Double  |  `0.1` to `72`  |  No default value  | 

This control checks whether an Amazon Aurora cluster has backtracking enabled. The control fails if the cluster doesn't have backtracking enabled. If you provide a custom value for the `BacktrackWindowInHours` parameter, the control passes only if the cluster is backtracked for the specified length of time.

Backups help you to recover more quickly from a security incident. They also strengthens the resilience of your systems. Aurora backtracking reduces the time to recover a database to a point in time. It does not require a database restore to do so.

### Remediation
<a name="rds-14-remediation"></a>

To enable Aurora backtracking, see [Configuring backtracking](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Managing.Backtrack.html#AuroraMySQL.Managing.Backtrack.Configuring) in the *Amazon Aurora User Guide*.

Note that you cannot enable backtracking on an existing cluster. Instead, you can create a clone that has backtracking enabled. For more information about the limitations of Aurora backtracking, see the list of limitations in [Overview of backtracking](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Managing.Backtrack.html).

## [RDS.15] RDS DB clusters should be configured for multiple Availability Zones
<a name="rds-15"></a>

**Related requirements:** CIS AWS Foundations Benchmark v5.0.0/2.2.4, NIST.800-53.r5 CP-10, NIST.800-53.r5 CP-6(2), NIST.800-53.r5 SC-36, NIST.800-53.r5 SC-5(2), NIST.800-53.r5 SI-13(5)

**Category:** Recover > Resilience > High availability

**Severity:** Medium

**Resource type:** `AWS::RDS::DBCluster`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/rds-cluster-multi-az-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/rds-cluster-multi-az-enabled.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether high availability is enabled for your RDS DB clusters. The control fails if an RDS DB cluster isn't deployed in multiple Availability Zones (AZs).

RDS DB clusters should be configured for multiple AZs to ensure availability of stored data. Deployment to multiple AZs allows for automated failover in the event of an AZ availability issue and during regular RDS maintenance events.

### Remediation
<a name="rds-15-remediation"></a>

To deploy your DB clusters in multiple AZs, [Modifying a DB instance to be a Multi-AZ DB instance deployment](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZSingleStandby.html#Concepts.MultiAZ.Migrating) in the *Amazon RDS User Guide*.

Remediation steps differ for Aurora global databases. To configure multiple Availability Zones for an Aurora global database, select your DB cluster. Then, choose **Actions** and **Add reader**, and specify multiple AZs. For more information, see [Adding Aurora Replicas to a DB cluster](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-replicas-adding.html) in the *Amazon Aurora User Guide*.

## [RDS.16] Aurora DB clusters should be configured to copy tags to DB snapshots
<a name="rds-16"></a>

**Related requirements:** NIST.800-53.r5 CA-9(1), NIST.800-53.r5 CM-2, NIST.800-53.r5 CM-2(2)

**Category:** Identify > Inventory

**Severity:** Low

**Resource type:** `AWS::RDS::DBCluster`

**AWS Config rule:** `rds-cluster-copy-tags-to-snapshots-enabled` (custom Security Hub CSPM rule)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether an Amazon Aurora DB cluster is configured to automatically copy tags to snapshots of the DB cluster when the snapshots are created. The control fails if the Aurora DB cluster isn't configured to automatically copy tags to snapshots of the cluster when the snapshots are created.

Identification and inventory of your IT assets is a crucial aspect of governance and security. You need to have visibility of all your Amazon Aurora DB clusters so that you can assess their security posture and take action on potential areas of weakness. Aurora DB snapshots should have the same tags as their parent DB clusters. In Amazon Aurora, you can configure a DB cluster to automatically copy all the tags for the cluster to snapshots of the cluster. Enabling this setting ensures that DB snapshots inherit the same tags as their parent DB clusters.

### Remediation
<a name="rds-16-remediation"></a>

For information about configuring an Amazon Aurora DB cluster to automatically copy tags to DB snapshots, see [Modifying an Amazon Aurora DB cluster](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.Modifying.html) in the *Amazon Aurora User Guide*.

## [RDS.17] RDS DB instances should be configured to copy tags to snapshots
<a name="rds-17"></a>

**Related requirements:** NIST.800-53.r5 CA-9(1), NIST.800-53.r5 CM-2, NIST.800-53.r5 CM-2(2)

**Category:** Identify > Inventory

**Severity:** Low

**Resource type:** `AWS::RDS::DBInstance`

**AWS Config rule:** `rds-instance-copy-tags-to-snapshots-enabled` (custom Security Hub CSPM rule)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether RDS DB instances are configured to copy all tags to snapshots when the snapshots are created.

Identification and inventory of your IT assets is a crucial aspect of governance and security. You need to have visibility of all your RDS DB instances so that you can assess their security posture and take action on potential areas of weakness. Snapshots should be tagged in the same way as their parent RDS database instances. Enabling this setting ensures that snapshots inherit the tags of their parent database instances.

### Remediation
<a name="rds-17-remediation"></a>

To automatically copy tags to snapshots for an RDS DB instance, see [Modifying an Amazon RDS DB instance ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.DBInstance.Modifying.html) in the *Amazon RDS User Guide*. Select **Copy tags to snapshots**.

## [RDS.18] RDS instances should be deployed in a VPC
<a name="rds-18"></a>

**Category:** Protect > Secure network configuration > Resources within VPC 

**Severity:** High

**Resource type:** `AWS::RDS::DBInstance`

**AWS Config rule:** `rds-deployed-in-vpc` (custom Security Hub CSPM rule)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether an Amazon RDS instance is deployed on an EC2-VPC.

VPCs provide a number of network controls to secure access to RDS resources. These controls include VPC Endpoints, network ACLs, and security groups. To take advantage of these controls, we recommend that you create your RDS instances on an EC2-VPC.

### Remediation
<a name="rds-18-remediation"></a>

For instructions on moving RDS instances to a VPC, see [Updating the VPC for a DB instance](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_VPC.VPC2VPC.html) in the *Amazon RDS User Guide*.

## [RDS.19] Existing RDS event notification subscriptions should be configured for critical cluster events
<a name="rds-19"></a>

**Related requirements:** NIST.800-53.r5 CA-7, NIST.800-53.r5 SI-2

**Category:** Detect > Detection services > Application monitoring

**Severity:** Low

**Resource type:** `AWS::RDS::EventSubscription`

**AWS Config rule:** `rds-cluster-event-notifications-configured` (custom Security Hub CSPM rule)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether an existing Amazon RDS event subscription for database clusters has notifications enabled for the following source type and event category key-value pairs:

```
DBCluster: ["maintenance","failure"]
```

The control passes if there are no existing event subscriptions in your account.

RDS event notifications uses Amazon SNS to make you aware of changes in the availability or configuration of your RDS resources. These notifications allow for rapid response. For additional information about RDS event notifications, see [Using Amazon RDS event notification](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Events.html) in the *Amazon RDS User Guide*.

### Remediation
<a name="rds-19-remediation"></a>

To subscribe to RDS cluster event notifications, see [Subscribing to Amazon RDS event notification](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Events.Subscribing.html) in the *Amazon RDS User Guide*. Use the following values:


| Field | Value | 
| --- | --- | 
|  Source type  |  Clusters  | 
|  Clusters to include  |  All clusters  | 
|  Event categories to include  |  Select specific event categories or All event categories  | 

## [RDS.20] Existing RDS event notification subscriptions should be configured for critical database instance events
<a name="rds-20"></a>

**Related requirements:** NIST.800-53.r5 CA-7, NIST.800-53.r5 SI-2, PCI DSS v4.0.1/11.5.2

**Category:** Detect > Detection services > Application monitoring

**Severity:** Low

**Resource type:** `AWS::RDS::EventSubscription`

**AWS Config rule:** `rds-instance-event-notifications-configured` (custom Security Hub CSPM rule)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether an existing Amazon RDS event subscription for database instances has notifications enabled for the following source type and event category key-value pairs:

```
DBInstance: ["maintenance","configuration change","failure"]
```

The control passes if there are no existing event subscriptions in your account.

RDS event notifications use Amazon SNS to make you aware of changes in the availability or configuration of your RDS resources. These notifications allow for rapid response. For additional information about RDS event notifications, see [Using Amazon RDS event notification](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Events.html) in the *Amazon RDS User Guide*.

### Remediation
<a name="rds-20-remediation"></a>

To subscribe to RDS instance event notifications, see [Subscribing to Amazon RDS event notification](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Events.Subscribing.html) in the *Amazon RDS User Guide*. Use the following values:


| Field | Value | 
| --- | --- | 
|  Source type  |  Instances  | 
|  Instances to include  |  All instances  | 
|  Event categories to include  |  Select specific event categories or All event categories  | 

## [RDS.21] An RDS event notifications subscription should be configured for critical database parameter group events
<a name="rds-21"></a>

**Related requirements:** NIST.800-53.r5 CA-7, NIST.800-53.r5 SI-2, PCI DSS v4.0.1/11.5.2

**Category:** Detect > Detection services > Application monitoring

**Severity:** Low

**Resource type:** `AWS::RDS::EventSubscription`

**AWS Config rule:** `rds-pg-event-notifications-configured` (custom Security Hub CSPM rule)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether an Amazon RDS event subscription exists with notifications enabled for the following source type, event category key-value pairs. The control passes if there are no existing event subscriptions in your account.

```
DBParameterGroup: ["configuration change"]
```

RDS event notifications use Amazon SNS to make you aware of changes in the availability or configuration of your RDS resources. These notifications allow for rapid response. For additional information about RDS event notifications, see [Using Amazon RDS event notification](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Events.html) in the *Amazon RDS User Guide*.

### Remediation
<a name="rds-21-remediation"></a>

To subscribe to RDS database parameter group event notifications, see [Subscribing to Amazon RDS event notification](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Events.Subscribing.html) in the *Amazon RDS User Guide*. Use the following values:


| Field | Value | 
| --- | --- | 
|  Source type  |  Parameter groups  | 
|  Parameter groups to include  |  All parameter groups  | 
|  Event categories to include  |  Select specific event categories or All event categories  | 

## [RDS.22] An RDS event notifications subscription should be configured for critical database security group events
<a name="rds-22"></a>

**Related requirements:** NIST.800-53.r5 CA-7, NIST.800-53.r5 SI-2, PCI DSS v4.0.1/11.5.2

**Category:** Detect > Detection Services > Application monitoring

**Severity:** Low

**Resource type:** `AWS::RDS::EventSubscription`

**AWS Config rule:** `rds-sg-event-notifications-configured` (custom Security Hub CSPM rule)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether an Amazon RDS event subscription exists with notifications enabled for the following source type, event category key-value pairs. The control passes if there are no existing event subscriptions in your account.

```
DBSecurityGroup: ["configuration change","failure"]
```

RDS event notifications use Amazon SNS to make you aware of changes in the availability or configuration of your RDS resources. These notifications allow for a rapid response. For additional information about RDS event notifications, see [Using Amazon RDS event notification](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Events.html) in the *Amazon RDS User Guide*.

### Remediation
<a name="rds-22-remediation"></a>

To subscribe to RDS instance event notifications, see [Subscribing to Amazon RDS event notification](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Events.Subscribing.html) in the *Amazon RDS User Guide*. Use the following values:


| Field | Value | 
| --- | --- | 
|  Source type  |  Security groups  | 
|  Security groups to include  |  All security groups  | 
|  Event categories to include  |  Select specific event categories or All event categories  | 

## [RDS.23] RDS instances should not use a database engine default port
<a name="rds-23"></a>

**Related requirements:** NIST.800-53.r5 AC-4, NIST.800-53.r5 AC-4(21), NIST.800-53.r5 SC-7, NIST.800-53.r5 SC-7(11), NIST.800-53.r5 SC-7(16), NIST.800-53.r5 SC-7(21), NIST.800-53.r5 SC-7(4), NIST.800-53.r5 SC-7(5)

**Category:** Protect > Secure network configuration

**Severity:** Low

**Resource type:** `AWS::RDS::DBInstance`

**AWS Config rule:** `rds-no-default-ports` (custom Security Hub CSPM rule)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether an RDS cluster or instance uses a port other than the default port of the database engine. The control fails if the RDS cluster or instance uses the default port. This control doesn't apply to RDS instances that are part of a cluster.

If you use a known port to deploy an RDS cluster or instance, an attacker can guess information about the cluster or instance. The attacker can use this information in conjunction with other information to connect to an RDS cluster or instance or gain additional information about your application.

When you change the port, you must also update the existing connection strings that were used to connect to the old port. You should also check the security group of the DB instance to ensure that it includes an ingress rule that allows connectivity on the new port.

### Remediation
<a name="rds-23-remediation"></a>

To modify the default port of an existing RDS DB instance, see [Modifying an Amazon RDS DB instance ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.DBInstance.Modifying.html) in the *Amazon RDS User Guide*. To modify the default port of an existing RDS DB cluster, see [Modifying the DB cluster by using the console, CLI, and API ](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.Modifying.html#Aurora.Modifying.Cluster) in the *Amazon Aurora User Guide*. For **Database port**, change the port value to a non-default value.

## [RDS.24] RDS Database clusters should use a custom administrator username
<a name="rds-24"></a>

**Related requirements:** NIST.800-53.r5 CA-9(1), NIST.800-53.r5 CM-2, PCI DSS v4.0.1/2.2.2

**Category:** Identify > Resource Configuration

**Severity:** Medium

**Resource type:** `AWS::RDS::DBCluster`

**AWS Config rule:** `[rds-cluster-default-admin-check](https://docs.aws.amazon.com/config/latest/developerguide/rds-cluster-default-admin-check.html)`

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether an Amazon RDS database cluster has changed the admin username from its default value. The control does not apply to engines of the type neptune (Neptune DB) or docdb (DocumentDB). This rule will fail if the admin username is set to the default value.

When creating an Amazon RDS database, you should change the default admin username to a unique value. Default usernames are public knowledge and should be changed during RDS database creation. Changing the default usernames reduces the risk of unintended access.

### Remediation
<a name="rds-24-remediation"></a>

For changing the admin username associated with the Amazon RDS database cluster, [create a new RDS database cluster](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.CreateInstance.html) and change the default admin username while creating the database.

## [RDS.25] RDS database instances should use a custom administrator username
<a name="rds-25"></a>

**Related requirements:** NIST.800-53.r5 CA-9(1), NIST.800-53.r5 CM-2, PCI DSS v4.0.1/2.2.2

**Category:** Identify > Resource Configuration

**Severity:** Medium

**Resource type:** `AWS::RDS::DBInstance`

**AWS Config rule:** `[rds-instance-default-admin-check](https://docs.aws.amazon.com/config/latest/developerguide/rds-instance-default-admin-check.html)`

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether you've changed the administrative username for Amazon Relational Database Service (Amazon RDS) database instances from the default value. The control fails if the administrative username is set to the default value. The control doesn't apply to engines of the type neptune (Neptune DB) or docdb (DocumentDB), and to RDS instances that are part of a cluster. 

Default administrative usernames on Amazon RDS databases are public knowledge. When creating an Amazon RDS database, you should change the default administrative username to a unique value to reduce the risk of unintended access.

### Remediation
<a name="rds-25-remediation"></a>

To change the administrative username associated with an RDS database instance, first [create a new RDS database instance](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_CreateDBInstance.html). Change the default administrative username while creating the database.

## [RDS.26] RDS DB instances should be protected by a backup plan
<a name="rds-26"></a>

**Category:** Recover > Resilience > Backups enabled

**Related requirements:** NIST.800-53.r5 CP-10, NIST.800-53.r5 CP-6, NIST.800-53.r5 CP-6(1), NIST.800-53.r5 CP-6(2), NIST.800-53.r5 CP-9, NIST.800-53.r5 SC-5(2), NIST.800-53.r5 SI-12, NIST.800-53.r5 SI-13(5)

**Severity:** Medium

**Resource type:** `AWS::RDS::DBInstance`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/rds-resources-protected-by-backup-plan.html](https://docs.aws.amazon.com/config/latest/developerguide/rds-resources-protected-by-backup-plan.html) ``

**Schedule type:** Periodic

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  `backupVaultLockCheck`  |  The control produces a `PASSED` finding if the parameter is set to true and the resource uses AWS Backup Vault Lock.  |  Boolean  |  `true` or `false`  |  No default value  | 

This control evaluates if Amazon RDS DB instances are covered by a backup plan. This control fails if the RDS DB instance isn't covered by a backup plan. If you set the `backupVaultLockCheck` parameter equal to `true`, the control passes only if the instance is backed up in an AWS Backup locked vault.

**Note**  
This control doesn't evaluate Neptune and DocumentDB instances. It also doesn't evaluate RDS DB instances that are members of a cluster.

AWS Backup is a fully managed backup service that centralizes and automates the backing up of data across AWS services. With AWS Backup, you can create backup policies called backup plans. You can use these plans to define your backup requirements, such as how frequently to back up your data and how long to retain those backups. Including RDS DB instances in a backup plan helps you protect your data from unintended loss or deletion.

### Remediation
<a name="rds-26-remediation"></a>

To add an RDS DB instance to an AWS Backup backup plan, see [Assigning resources to a backup plan](https://docs.aws.amazon.com/aws-backup/latest/devguide/assigning-resources.html) in the *AWS Backup Developer Guide*.

## [RDS.27] RDS DB clusters should be encrypted at rest
<a name="rds-27"></a>

**Related requirements:** NIST.800-53.r5 CA-9(1), NIST.800-53.r5 CM-3(6), NIST.800-53.r5 SC-13, NIST.800-53.r5 SC-28, NIST.800-53.r5 SC-28(1), NIST.800-53.r5 SC-7(10), NIST.800-53.r5 SI-7(6)

**Category:** Protect > Data Protection > Encryption of data-at-rest

**Severity:** Medium

**Resource type:** `AWS::RDS::DBCluster`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/rds-cluster-encrypted-at-rest.html](https://docs.aws.amazon.com/config/latest/developerguide/rds-cluster-encrypted-at-rest.html) ``

**Schedule type:** Change triggered

**Parameters:** None

This control checks if an RDS DB cluster is encrypted at rest. The control fails if an RDS DB cluster isn't encrypted at rest.

Data at rest refers to any data that's stored in persistent, non-volatile storage for any duration. Encryption helps you protect the confidentiality of such data, reducing the risk that an unauthorized user can access it. Encrypting your RDS DB clusters protects your data and metadata against unauthorized access. It also fulfills compliance requirements for data-at-rest encryption of production file systems.

### Remediation
<a name="rds-27-remediation"></a>

You can enable encryption at rest when you create an RDS DB cluster. You can't change encryption settings after creating a cluster. For more information, see [Encrypting an Amazon Aurora DB cluster](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Overview.Encryption.html#Overview.Encryption.Enabling) in the *Amazon Aurora User Guide*.

## [RDS.28] RDS DB clusters should be tagged
<a name="rds-28"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::RDS::DBCluster`

**AWS Config rule:**`tagged-rds-dbcluster` (custom Security Hub CSPM rule)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  | No default value  | 

This control checks whether an Amazon RDS DB cluster has tags with the specific keys defined in the parameter `requiredTagKeys`. The control fails if the DB cluster doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredTagKeys`. If the parameter `requiredTagKeys` isn't provided, the control only checks for the existence of a tag key and fails if the DB cluster isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [What is ABAC for AWS?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Tagging your AWS resources](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *AWS General Reference*.

### Remediation
<a name="rds-28-remediation"></a>

To add tags to an RDS DB cluster, see [Tagging Amazon RDS resources](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Tagging.html) in the *Amazon RDS User Guide*.

## [RDS.29] RDS DB cluster snapshots should be tagged
<a name="rds-29"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::RDS::DBClusterSnapshot`

**AWS Config rule:**`tagged-rds-dbclustersnapshot` (custom Security Hub CSPM rule)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  | No default value  | 

This control checks whether an Amazon RDS DB cluster snapshot has tags with the specific keys defined in the parameter `requiredTagKeys`. The control fails if the DB cluster snapshot doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredTagKeys`. If the parameter `requiredTagKeys` isn't provided, the control only checks for the existence of a tag key and fails if the DB cluster snapshot isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [What is ABAC for AWS?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Tagging your AWS resources](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *AWS General Reference*.

### Remediation
<a name="rds-29-remediation"></a>

To add tags to an RDS DB cluster snapshot, see [Tagging Amazon RDS resources](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Tagging.html) in the *Amazon RDS User Guide*.

## [RDS.30] RDS DB instances should be tagged
<a name="rds-30"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::RDS::DBInstance`

**AWS Config rule:**`tagged-rds-dbinstance` (custom Security Hub CSPM rule)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  | No default value  | 

This control checks whether an Amazon RDS DB instance has tags with the specific keys defined in the parameter `requiredTagKeys`. The control fails if the DB instance doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredTagKeys`. If the parameter `requiredTagKeys` isn't provided, the control only checks for the existence of a tag key and fails if the DB instance isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [What is ABAC for AWS?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Tagging your AWS resources](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *AWS General Reference*.

### Remediation
<a name="rds-30-remediation"></a>

To add tags to an RDS DB instance, see [Tagging Amazon RDS resources](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Tagging.html) in the *Amazon RDS User Guide*.

## [RDS.31] RDS DB security groups should be tagged
<a name="rds-31"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::RDS::DBSecurityGroup`

**AWS Config rule:**`tagged-rds-dbsecuritygroup` (custom Security Hub CSPM rule)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  | No default value  | 

This control checks whether an Amazon RDS DB security group has tags with the specific keys defined in the parameter `requiredTagKeys`. The control fails if the DB security group doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredTagKeys`. If the parameter `requiredTagKeys` isn't provided, the control only checks for the existence of a tag key and fails if the DB security group isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [What is ABAC for AWS?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Tagging your AWS resources](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *AWS General Reference*.

### Remediation
<a name="rds-31-remediation"></a>

To add tags to an RDS DB security group, see [Tagging Amazon RDS resources](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Tagging.html) in the *Amazon RDS User Guide*.

## [RDS.32] RDS DB snapshots should be tagged
<a name="rds-32"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::RDS::DBSnapshot`

**AWS Config rule:**`tagged-rds-dbsnapshot` (custom Security Hub CSPM rule)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  | No default value  | 

This control checks whether an Amazon RDS DB snapshot has tags with the specific keys defined in the parameter `requiredTagKeys`. The control fails if the DB snapshot doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredTagKeys`. If the parameter `requiredTagKeys` isn't provided, the control only checks for the existence of a tag key and fails if the DB snapshot isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [What is ABAC for AWS?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Tagging your AWS resources](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *AWS General Reference*.

### Remediation
<a name="rds-32-remediation"></a>

To add tags to an RDS DB snapshot, see [Tagging Amazon RDS resources](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Tagging.html) in the *Amazon RDS User Guide*.

## [RDS.33] RDS DB subnet groups should be tagged
<a name="rds-33"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::RDS::DBSubnetGroup`

**AWS Config rule:**`tagged-rds-dbsubnetgroups` (custom Security Hub CSPM rule)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  | No default value  | 

This control checks whether an Amazon RDS DB subnet group has tags with the specific keys defined in the parameter `requiredTagKeys`. The control fails if the DB subnet group doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredTagKeys`. If the parameter `requiredTagKeys` isn't provided, the control only checks for the existence of a tag key and fails if the DB subnet group isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [What is ABAC for AWS?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Tagging your AWS resources](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *AWS General Reference*.

### Remediation
<a name="rds-33-remediation"></a>

To add tags to an RDS DB subnet group, see [Tagging Amazon RDS resources](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Tagging.html) in the *Amazon RDS User Guide*.

## [RDS.34] Aurora MySQL DB clusters should publish audit logs to CloudWatch Logs
<a name="rds-34"></a>

**Related requirements:** NIST.800-53.r5 AC-2(4), NIST.800-53.r5 AC-4(26), NIST.800-53.r5 AC-6(9), NIST.800-53.r5 AU-10, NIST.800-53.r5 AU-12, NIST.800-53.r5 AU-2, NIST.800-53.r5 AU-3, NIST.800-53.r5 AU-6(3), NIST.800-53.r5 AU-6(4), NIST.800-53.r5 CA-7, NIST.800-53.r5 SC-7(9), NIST.800-53.r5 SI-3(8), NIST.800-53.r5 SI-4(20), NIST.800-53.r5 SI-7(8), PCI DSS v4.0.1/10.2.1

**Category:** Identify > Logging

**Severity:** Medium

**Resource type:** `AWS::RDS::DBCluster`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/rds-aurora-mysql-audit-logging-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/rds-aurora-mysql-audit-logging-enabled.html) ``

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether an Amazon Aurora MySQL DB cluster is configured to publish audit logs to Amazon CloudWatch Logs. The control fails if the cluster isn't configured to publish audit logs to CloudWatch Logs. The control doesn't generate findings for Aurora Serverless v1 DB clusters.

Audit logs capture a record of database activity, including login attempts, data modifications, schema changes, and other events that can be audited for security and compliance purposes. When you configure an Aurora MySQL DB cluster to publish audit logs to a log group in Amazon CloudWatch Logs, you can perform real-time analysis of the log data. CloudWatch Logs retains logs in highly durable storage. You can also create alarms and view metrics in CloudWatch.

**Note**  
An alternative way to publish audit logs to CloudWatch Logs is by enabling advanced auditing and setting the cluster-level DB parameter `server_audit_logs_upload` to `1`. The default for the `server_audit_logs_upload parameter` is `0`. However, we recommend you use the following remediation instructions instead to pass this control.

### Remediation
<a name="rds-34-remediation"></a>

To publish Aurora MySQL DB cluster audit logs to CloudWatch Logs, see [Publishing Amazon Aurora MySQL logs to Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Integrating.CloudWatch.html) in the *Amazon Aurora User Guide*.

## [RDS.35] RDS DB clusters should have automatic minor version upgrade enabled
<a name="rds-35"></a>

**Related requirements:** NIST.800-53.r5 SI-2, NIST.800-53.r5 SI-2(2), NIST.800-53.r5 SI-2(4), NIST.800-53.r5 SI-2(5), PCI DSS v4.0.1/6.3.3

**Category:** Identify > Vulnerability, patch, and version management

**Severity:** Medium

**Resource type:** `AWS::RDS::DBCluster`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/rds-cluster-auto-minor-version-upgrade-enable.html](https://docs.aws.amazon.com/config/latest/developerguide/rds-cluster-auto-minor-version-upgrade-enable.html) ``

**Schedule type:** Change triggered

**Parameters:** None

This control checks if automatic minor version upgrade is enabled for an Amazon RDS Multi-AZ DB cluster. The control fails if automatic minor version upgrade isn't enabled for the Multi-AZ DB cluster.

RDS provides automatic minor version upgrade so that you can keep your Multi-AZ DB cluster up to date. Minor versions can introduce new software features, bug fixes, security patches, and performance improvements. By enabling automatic minor version upgrade on RDS database clusters, the cluster, along with the instances in the cluster, will receive automatic updates to the minor version when new versions are available. The updates are applied automatically during the maintenance window.

### Remediation
<a name="rds-35-remediation"></a>

To enable automatic minor version upgrade on Multi-AZ DB clusters, see [Modifying a Multi-AZ DB cluster](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/modify-multi-az-db-cluster.html) in the *Amazon RDS User Guide*.

## [RDS.36] RDS for PostgreSQL DB instances should publish logs to CloudWatch Logs
<a name="rds-36"></a>

**Related requirements:** PCI DSS v4.0.1/10.4.2

**Category:** Identify > Logging

**Severity:** Medium

**Resource type:** `AWS::RDS::DBInstance`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/rds-postgresql-logs-to-cloudwatch.html](https://docs.aws.amazon.com/config/latest/developerguide/rds-postgresql-logs-to-cloudwatch.html)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  `logTypes`  |  Comma-separated list of log types to be published to CloudWatch Logs  |  StringList  |  Not customizable  |  `postgresql`  | 

This control checks whether an Amazon RDS for PostgreSQL DB instance is configured to publish logs to Amazon CloudWatch Logs. The control fails if the PostgreSQL DB instance isn't configured to publish the log types mentioned in the `logTypes` parameter to CloudWatch Logs.

Database logging provides detailed records of requests made to an RDS instance. PostgreSQL generates event logs that contain useful information for administrators. Publishing these logs to CloudWatch Logs centralizes log management and helps you perform real-time analysis of the log data. CloudWatch Logs retains logs in highly durable storage. You can also create alarms and view metrics in CloudWatch.

### Remediation
<a name="rds-36-remediation"></a>

To publish PostgreSQL DB instance logs to CloudWatch Logs, see [Publishing PostgreSQL logs to Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_LogAccess.Concepts.PostgreSQL.html#USER_LogAccess.Concepts.PostgreSQL.PublishtoCloudWatchLogs) in the *Amazon RDS User Guide*.

## [RDS.37] Aurora PostgreSQL DB clusters should publish logs to CloudWatch Logs
<a name="rds-37"></a>

**Related requirements:** PCI DSS v4.0.1/10.4.2

**Category:** Identify > Logging

**Severity:** Medium

**Resource type:** `AWS::RDS::DBCluster`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/rds-aurora-postgresql-logs-to-cloudwatch.html](https://docs.aws.amazon.com/config/latest/developerguide/rds-aurora-postgresql-logs-to-cloudwatch.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether an Amazon Aurora PostgreSQL DB cluster is configured to publish logs to Amazon CloudWatch Logs. The control fails if the Aurora PostgreSQL DB cluster isn't configured to publish PostgreSQL logs to CloudWatch Logs.

Database logging provides detailed records of requests made to an RDS cluster. Aurora PostgreSQL generates event logs that contain useful information for administrators. Publishing these logs to CloudWatch Logs centralizes log management and helps you perform real-time analysis of the log data. CloudWatch Logs retains logs in highly durable storage. You can also create alarms and view metrics in CloudWatch.

### Remediation
<a name="rds-37-remediation"></a>

To publish Aurora PostgreSQL DB cluster logs to CloudWatch Logs, see [Publishing Aurora PostgreSQL logs to Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.CloudWatch.html) in the *Amazon RDS User Guide*.

## [RDS.38] RDS for PostgreSQL DB instances should be encrypted in transit
<a name="rds-38"></a>

**Category:** Protect > Data Protection > Encryption of data-in-transit

**Severity:** Medium

**Resource type:** `AWS::RDS::DBInstance`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/rds-postgres-instance-encrypted-in-transit.html](https://docs.aws.amazon.com/config/latest/developerguide/rds-postgres-instance-encrypted-in-transit.html)

**Schedule type:** Periodic

**Parameters:** None

This control checks whether a connection to an Amazon RDS for PostgreSQL database (DB) instance is encrypted in transit. The control fails if the `rds.force_ssl` parameter for the parameter group associated with the instance is set to `0` (off). This control doesn't evaluate RDS DB instances that are part of a DB cluster.

Data in transit refers to data that moves from one location to another, such as between nodes in your cluster or between your cluster and your application. Data may move across the internet or within a private network. Encrypting data in transit reduces the risk that an unauthorized user can eavesdrop on network traffic.

### Remediation
<a name="rds-38-remediation"></a>

To require all connections to your RDS for PostgreSQL DB instance to use SSL, see [Using SSL with a PostgreSQL DB instance](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/PostgreSQL.Concepts.General.SSL.html) in the *Amazon RDS User Guide*.

## [RDS.39] RDS for MySQL DB instances should be encrypted in transit
<a name="rds-39"></a>

**Category:** Protect > Data Protection > Encryption of data-in-transit

**Severity:** Medium

**Resource type:** `AWS::RDS::DBInstance`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/rds-mysql-instance-encrypted-in-transit.html](https://docs.aws.amazon.com/config/latest/developerguide/rds-mysql-instance-encrypted-in-transit.html)

**Schedule type:** Periodic

**Parameters:** None

This control checks whether a connection to an Amazon RDS for MySQL database (DB) instance is encrypted in transit. The control fails if the `rds.require_secure_transport` parameter for the parameter group associated with the instance is set to `0` (off). This control doesn't evaluate RDS DB instances that are part of a DB cluster.

Data in transit refers to data that moves from one location to another, such as between nodes in your cluster or between your cluster and your application. Data may move across the internet or within a private network. Encrypting data in transit reduces the risk that an unauthorized user can eavesdrop on network traffic.

### Remediation
<a name="rds-39-remediation"></a>

To require all connections to your RDS for MySQL DB instance to use SSL, see [SSL/TLS support for MySQL DB instances on Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/MySQL.Concepts.SSLSupport.html) in the *Amazon RDS User Guide*.

## [RDS.40] RDS for SQL Server DB instances should publish logs to CloudWatch Logs
<a name="rds-40"></a>

**Related requirements:** NIST.800-53.r5 AC-2(4), NIST.800-53.r5 AC-4(26), NIST.800-53.r5 AC-6(9), NIST.800-53.r5 AU-10, NIST.800-53.r5 AU-12, NIST.800-53.r5 AU-2, NIST.800-53.r5 AU-3, NIST.800-53.r5 AU-6(3), NIST.800-53.r5 AU-6(4), NIST.800-53.r5 CA-7, NIST.800-53.r5 SC-7(10), NIST.800-53.r5 SC-7(9), NIST.800-53.r5 SI-3(8), NIST.800-53.r5 SI-4(20), NIST.800-53.r5 SI-7(8)

**Category:** Identify > Logging

**Severity:** Medium

**Resource type:** `AWS::RDS::DBInstance`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/rds-sql-server-logs-to-cloudwatch.html](https://docs.aws.amazon.com/config/latest/developerguide/rds-sql-server-logs-to-cloudwatch.html)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  `logTypes`  |  A list of the types of logs that an RDS for SQL Server DB instance should be configured to publish to CloudWatch Logs. This control fails if a DB instance isn't configured to publish a type of log specified in the list.  |  EnumList (maximum of 2 items)  |  `agent`, `error`  |  `agent`, `error`  | 

This control checks whether an Amazon RDS for Microsoft SQL Server DB instance is configured to publish logs to Amazon CloudWatch Logs. The control fails if the RDS for SQL Server DB instance isn't configured to publish logs to CloudWatch Logs. You can optionally specify the types of logs that a DB instance should be configured to publish.

Database logging provides detailed records of requests made to an Amazon RDS DB instance. Publishing logs to CloudWatch Logs centralizes log management and helps you perform real-time analysis of log data. CloudWatch Logs retains logs in highly durable storage. In addition, you can use it to create alarms for specific errors that can occur, such as frequent restarts that are recorded in an error log. Similarly, you can create alarms for errors or warnings that are recorded in SQL Server agent logs related to SQL agent jobs.

### Remediation
<a name="rds-40-remediation"></a>

For information about publishing logs to CloudWatch Logs for an RDS for SQL Server DB instance, see [Amazon RDS for Microsoft SQL Server database log files](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_LogAccess.Concepts.SQLServer.html) in the *Amazon Relational Database Service User Guide*.

## [RDS.41] RDS for SQL Server DB instances should be encrypted in transit
<a name="rds-41"></a>

**Category:** Protect > Data Protection > Encryption of data-in-transit

**Severity:** Medium

**Resource type:** `AWS::RDS::DBInstance`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/rds-sqlserver-encrypted-in-transit.html](https://docs.aws.amazon.com/config/latest/developerguide/rds-sqlserver-encrypted-in-transit.html)

**Schedule type:** Periodic

**Parameters:** None

This control checks whether a connection to an Amazon RDS for Microsoft SQL Server DB instance is encrypted in transit. The control fails if the `rds.force_ssl` parameter of the parameter group associated with the DB instance is set to `0 (off)`.

Data in transit refers to data that moves from one location to another, such as between nodes in a DB cluster or between a DB cluster and a client application. Data can move across the internet or within a private network. Encrypting data in transit reduces the risk of unauthorized users eavesdropping on network traffic.

### Remediation
<a name="rds-41-remediation"></a>

For information about enabling SSL/TLS for connections to Amazon RDS DB instances running Microsoft SQL Server, see [Using SSL with a Microsoft SQL Server DB Instance](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/SQLServer.Concepts.General.SSL.Using.html) in the *Amazon Relational Database Service User Guide*.

## [RDS.42] RDS for MariaDB DB instances should publish logs to CloudWatch Logs
<a name="rds-42"></a>

**Related requirements:** NIST.800-53.r5 AC-2(4), NIST.800-53.r5 AC-4(26), NIST.800-53.r5 AC-6(9), NIST.800-53.r5 AU-2, NIST.800-53.r5 AU-3, NIST.800-53.r5 AU-6(3), NIST.800-53.r5 AU-6(4), NIST.800-53.r5 AU-10, NIST.800-53.r5 AU-12, NIST.800-53.r5 CA-7, NIST.800-53.r5 SC-7(9), NIST.800-53.r5 SC-7(10), NIST.800-53.r5 SI-3(8), NIST.800-53.r5 SI-4(20), NIST.800-53.r5 SI-7(8)

**Category:** Identify > Logging

**Severity:** Medium

**Resource type:** `AWS::RDS::DBInstance`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/mariadb-publish-logs-to-cloudwatch-logs.html](https://docs.aws.amazon.com/config/latest/developerguide/mariadb-publish-logs-to-cloudwatch-logs.html)

**Schedule type:** Periodic

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  `logTypes`  |  A list of the types of logs that a MariaDB DB instance should be configured to publish to CloudWatch Logs. The control generates a `FAILED` finding if a DB instance isn't configured to publish a log type specified in the list.  |  EnumList (maximum of 4 items)  |  `audit`, `error`, `general`, `slowquery`  |  `audit, error`  | 

This control checks whether an Amazon RDS for MariaDB DB instance is configured to publish certain types of logs to Amazon CloudWatch Logs. The control fails if the MariaDB DB instance isn't configured to publish the logs to CloudWatch Logs. You can optionally specify which types of logs a MariaDB DB instance should be configured to publish.

Database logging provides detailed records of requests made to an Amazon RDS for MariaDB DB instance. Publishing logs to Amazon CloudWatch Logs centralizes log management and helps you perform real-time analysis of the log data. In addition, CloudWatch Logs retains the logs in durable storage, which can support security, access, and availability reviews and audits. With CloudWatch Logs, you can also create alarms and review metrics.

### Remediation
<a name="rds-42-remediation"></a>

For information about configuring an Amazon RDS for MariaDB DB instance to publish logs to Amazon CloudWatch Logs, see [Publishing MariaDB logs to Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_LogAccess.MariaDB.PublishtoCloudWatchLogs.html) in the *Amazon Relational Database Service User Guide*.

## [RDS.43] RDS DB proxies should require TLS encryption for connections
<a name="rds-43"></a>

**Category:** Protect > Data Protection > Encryption of data-in-transit

**Severity:** Medium

**Resource type:** `AWS::RDS::DBProxy`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/rds-proxy-tls-encryption.html](https://docs.aws.amazon.com/config/latest/developerguide/rds-proxy-tls-encryption.html)

**Schedule type:** Periodic

**Parameters:** None

This control checks whether an Amazon RDS DB proxy requires TLS for all connections between the proxy and the underlying RDS DB instance. The control fails if the proxy doesn't require TLS for all connections between the proxy and the RDS DB instance.

Amazon RDS Proxy can act as an additional layer of security between client applications and underlying RDS DB instances. For example, you can connect to an RDS proxy using TLS 1.3, even if the underlying DB instance supports an older version of TLS. By using RDS Proxy, you can enforce strong authentication requirements for database applications.

### Remediation
<a name="rds-43-remediation"></a>

For information about changing the settings for an Amazon RDS proxy to require TLS, see [Modifying an RDS proxy](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-proxy-modifying-proxy.html) in the *Amazon Relational Database Service User Guide*.

## [RDS.44] RDS for MariaDB DB instances should be encrypted in transit
<a name="rds-44"></a>

**Category:** Protect > Data Protection > Encryption of data-in-transit

**Severity:** Medium

**Resource type:** `AWS::RDS::DBInstance`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/rds-mariadb-instance-encrypted-in-transit.html](https://docs.aws.amazon.com/config/latest/developerguide/rds-mariadb-instance-encrypted-in-transit.html)

**Schedule type:** Periodic

**Parameters:** None

This control checks whether connections to an Amazon RDS for MariaDB DB instance are encrypted in transit. The control fails if the DB parameter group associated with the DB instance is not in sync, or the `require_secure_transport` parameter of the parameter group is not set to `ON`.

**Note**  
This control doesn't evaluate Amazon RDS DB instances that use MariaDB versions earlier than version 10.5. The `require_secure_transport` parameter is supported only for MariaDB versions 10.5 and later.

Data in transit refers to data that moves from one location to another, such as between nodes in a DB cluster or between a DB cluster and a client application. Data can move across the internet or within a private network. Encrypting data in transit reduces the risk of unauthorized users eavesdropping on network traffic.

### Remediation
<a name="rds-44-remediation"></a>

For information about enabling SSL/TLS for connections to an Amazon RDS for MariaDB DB instance, see [Requiring SSL/TLS for all connections to a MariaDB DB instance](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/mariadb-ssl-connections.require-ssl.html) in the *Amazon Relational Database Service User Guide*.

## [RDS.45] Aurora MySQL DB clusters should have audit logging enabled
<a name="rds-45"></a>

**Related requirements:** NIST.800-53.r5 AC-2(4), NIST.800-53.r5 AC-4(26), NIST.800-53.r5 AC-6(9), NIST.800-53.r5 AU-2, NIST.800-53.r5 AU-3, NIST.800-53.r5 AU-6(3), NIST.800-53.r5 AU-6(4), NIST.800-53.r5 AU-10, NIST.800-53.r5 AU-12, NIST.800-53.r5 CA-7, NIST.800-53.r5 SC-7(9), NIST.800-53.r5 SI-3(8), NIST.800-53.r5 SI-4(20), NIST.800-53.r5 SI-7(8)

**Category:** Identify > Logging

**Severity:** Medium

**Resource type:** `AWS::RDS::DBCluster`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/aurora-mysql-cluster-audit-logging.html](https://docs.aws.amazon.com/config/latest/developerguide/aurora-mysql-cluster-audit-logging.html)

**Schedule type:** Periodic

**Parameters:** None

This control checks whether an Amazon Aurora MySQL DB cluster has audit logging enabled. The control fails if the DB parameter group associated with the DB cluster is not in sync, the `server_audit_logging` parameter is not set to `1`, or the `server_audit_events` parameter is set to an empty value.

Database logs can assist with security and access audits and help diagnose availability issues. Audit logs capture a record of database activity, including login attempts, data modifications, schema changes, and other events that can be audited for security and compliance purposes.

### Remediation
<a name="rds-45-remediation"></a>

For information about enabling logging for an Amazon Aurora MySQL DB cluster, see [Publishing Amazon Aurora MySQL logs to Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Integrating.CloudWatch.html) in the *Amazon Aurora User Guide*.

## [RDS.46] RDS DB instances should not be deployed in public subnets with routes to internet gateways
<a name="rds-46"></a>

**Category:** Protect > Secure network configuration > Resources not publicly accessible

**Severity:** High

**Resource type:** `AWS::RDS::DBInstance`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/rds-instance-subnet-igw-check.html](https://docs.aws.amazon.com/config/latest/developerguide/rds-instance-subnet-igw-check.html)

**Schedule type:** Periodic

**Parameters:** None

This control checks whether an Amazon RDS DB instance is deployed in a public subnet that has a route to an internet gateway. The control fails if the RDS DB instance is deployed in a subnet that has a route to an internet gateway and the destination is set to `0.0.0.0/0` or `::/0`.

By provisioning your Amazon RDS resources in private subnets, you can prevent your RDS resources from receiving inbound traffic from the public internet, which can prevent unintended access to your RDS DB instances. If RDS resources are provisioned in a public subnet that is open to the internet, they might be vulnerable to risks such as data exfiltration.

### Remediation
<a name="rds-46-remediation"></a>

For information about provisioning a private subnet for an Amazon RDS DB instance, see [Working with a DB instance in a VPC](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_VPC.WorkingWithRDSInstanceinaVPC.html) in the *Amazon Relational Database Service User Guide*.

## [RDS.47] RDS for PostgreSQL DB clusters should be configured to copy tags to DB snapshots
<a name="rds-47"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::RDS::DBCluster`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/rds-pgsql-cluster-copy-tags-to-snapshot-check.html](https://docs.aws.amazon.com/config/latest/developerguide/rds-pgsql-cluster-copy-tags-to-snapshot-check.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether an Amazon RDS for PostgreSQL DB cluster is configured to automatically copy tags to snapshots of the DB cluster when the snapshots are created. The control fails if the `CopyTagsToSnapshot` parameter is set to `false` for the RDS for PostgreSQL DB cluster.

Copying tags to DB snapshots helps maintain proper resource tracking, governance, and cost allocation across backup resources. This enables consistent resource identification, access control, and compliance monitoring across both active databases and their snapshots. Properly tagged snapshots improve security operations by ensuring backup resources inherit the same metadata as their source databases.

### Remediation
<a name="rds-47-remediation"></a>

For information about configuring an Amazon RDS for PostgreSQL DB cluster to automatically copy tags to DB snapshots, see [Tagging Amazon RDS resources](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Tagging.html) in the *Amazon Relational Database Service User Guide*.

## [RDS.48] RDS for MySQL DB clusters should be configured to copy tags to DB snapshots
<a name="rds-48"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::RDS::DBCluster`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/rds-mysql-cluster-copy-tags-to-snapshot-check.html](https://docs.aws.amazon.com/config/latest/developerguide/rds-mysql-cluster-copy-tags-to-snapshot-check.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether an Amazon RDS for MySQL DB cluster is configured to automatically copy tags to snapshots of the DB cluster when the snapshots are created. The control fails if the `CopyTagsToSnapshot` parameter is set to `false` for the RDS for MySQL DB cluster.

Copying tags to DB snapshots helps maintain proper resource tracking, governance, and cost allocation across backup resources. This enables consistent resource identification, access control, and compliance monitoring across both active databases and their snapshots. Properly tagged snapshots improve security operations by ensuring backup resources inherit the same metadata as their source databases.

### Remediation
<a name="rds-48-remediation"></a>

For information about configuring an Amazon RDS for MySQL DB cluster to automatically copy tags to DB snapshots, see [Tagging Amazon RDS resources](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Tagging.html) in the *Amazon Relational Database Service User Guide*.

## [RDS.50] RDS DB clusters should have enough backup retention period set
<a name="rds-50"></a>

**Category:** Recover > Resilience > Backups enabled 

**Severity:** Medium

**Resource type:** `AWS::RDS::DBCluster`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/rds-cluster-backup-retention-check.html](https://docs.aws.amazon.com/config/latest/developerguide/rds-cluster-backup-retention-check.html)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  `minimumBackupRetentionPeriod`  |  The minimum backup retention period in days for the control to check  |  Integer  |  `7` to `35`  |  `7`  | 

This control checks whether an RDS DB cluster has a minimum backup retention period. The control fails if the backup retention period is less than the specified parameter value. Unless you provide a custom parameter value, Security Hub uses a default value of 7 days.

This control checks whether an RDS DB cluster has a minimum backup retention period. The control fails if the backup retention period is less than the specified parameter value. Unless you provide a customer parameter value, Security Hub uses a default value of 7 days. This control applies to all types of RDS DB clusters including Aurora DB cluster, DocumentDB clusters, NeptuneDB clusters, etc.

### Remediation
<a name="rds-50-remediation"></a>

To configure the backup retention period for an RDS DB cluster, modify the cluster settings and set the backup retention period to at least 7 days (or the value specified in the control parameter). For detailed instructions, see [Backup retention period](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithAutomatedBackups.BackupRetention.html) in the *Amazon Relational Database Service User Guide*. For Aurora DB clusters, see [Overview of backing up and restoring an Aurora DB cluster](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.Managing.Backups.html) in the *Amazon Aurora User Guide for Aurora*. For other type of DB clusters (e.g. DocumentDB clusters), see the corresponding service user guide for how to update the backup retention period for the cluster. 

# Security Hub CSPM controls for Amazon Redshift
<a name="redshift-controls"></a>

These AWS Security Hub CSPM controls evaluate the Amazon Redshift service and resources. The controls might not be available in all AWS Regions. For more information, see [Availability of controls by Region](securityhub-regions.md#securityhub-regions-control-support).

## [Redshift.1] Amazon Redshift clusters should prohibit public access
<a name="redshift-1"></a>

**Related requirements:** NIST.800-53.r5 AC-21, NIST.800-53.r5 AC-3, NIST.800-53.r5 AC-3(7), NIST.800-53.r5 AC-4, NIST.800-53.r5 AC-4(21), NIST.800-53.r5 AC-6, NIST.800-53.r5 SC-7, NIST.800-53.r5 SC-7(11), NIST.800-53.r5 SC-7(16), NIST.800-53.r5 SC-7(20), NIST.800-53.r5 SC-7(21), NIST.800-53.r5 SC-7(3), NIST.800-53.r5 SC-7(4), NIST.800-53.r5 SC-7(9), PCI DSS v3.2.1/1.2.1, PCI DSS v3.2.1/1.3.1, PCI DSS v3.2.1/1.3.2, PCI DSS v3.2.1/1.3.4, PCI DSS v3.2.1/1.3.6, PCI DSS v4.0.1/1.4.4

**Category:** Protect > Secure network configuration > Resources not publicly accessible

**Severity:** Critical

**Resource type:** `AWS::Redshift::Cluster`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/redshift-cluster-public-access-check.html](https://docs.aws.amazon.com/config/latest/developerguide/redshift-cluster-public-access-check.html)

**Schedule type:** Change triggered

**Parameters:** None 

This control checks whether Amazon Redshift clusters are publicly accessible. It evaluates the `PubliclyAccessible` field in the cluster configuration item. 

The `PubliclyAccessible` attribute of the Amazon Redshift cluster configuration indicates whether the cluster is publicly accessible. When the cluster is configured with `PubliclyAccessible` set to `true`, it is an Internet-facing instance that has a publicly resolvable DNS name, which resolves to a public IP address.

When the cluster is not publicly accessible, it is an internal instance with a DNS name that resolves to a private IP address. Unless you intend for your cluster to be publicly accessible, the cluster should not be configured with `PubliclyAccessible` set to `true`.

### Remediation
<a name="redshift-1-remediation"></a>

To update an Amazon Redshift cluster to disable public access, see [Modifying a cluster](https://docs.aws.amazon.com/redshift/latest/mgmt/managing-clusters-console.html#modify-cluster) in the *Amazon Redshift Management Guide*. Set **Publicly accessible** to **No**.

## [Redshift.2] Connections to Amazon Redshift clusters should be encrypted in transit
<a name="redshift-2"></a>

**Related requirements:** NIST.800-53.r5 AC-4, NIST.800-53.r5 SC-13, NIST.800-53.r5 SC-23, NIST.800-53.r5 SC-23(3), NIST.800-53.r5 SC-7(4), NIST.800-53.r5 SC-8, NIST.800-53.r5 SC-8(1), NIST.800-53.r5 SC-8(2), PCI DSS v4.0.1/4.2.1

**Category:** Protect > Data Protection > Encryption of data-in-transit

**Severity:** Medium

**Resource type:** `AWS::Redshift::Cluster` `AWS::Redshift::ClusterParameterGroup`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/redshift-require-tls-ssl.html](https://docs.aws.amazon.com/config/latest/developerguide/redshift-require-tls-ssl.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether connections to Amazon Redshift clusters are required to use encryption in transit. The check fails if the Amazon Redshift cluster parameter `require_SSL` isn't set to `True`.

TLS can be used to help prevent potential attackers from using person-in-the-middle or similar attacks to eavesdrop on or manipulate network traffic. Only encrypted connections over TLS should be allowed. Encrypting data in transit can affect performance. You should test your application with this feature to understand the performance profile and the impact of TLS. 

### Remediation
<a name="redshift-2-remediation"></a>

To update an Amazon Redshift parameter group to require encryption, see [Modifying a parameter group](https://docs.aws.amazon.com/redshift/latest/mgmt/managing-parameter-groups-console.html#parameter-group-modify) in the *Amazon Redshift Management Guide*. Set `require_ssl` to **True**.

## [Redshift.3] Amazon Redshift clusters should have automatic snapshots enabled
<a name="redshift-3"></a>

**Related requirements:** NIST.800-53.r5 CP-10, NIST.800-53.r5 CP-6, NIST.800-53.r5 CP-6(1), NIST.800-53.r5 CP-6(2), NIST.800-53.r5 CP-9, NIST.800-53.r5 SC-5(2), NIST.800-53.r5 SC-7(10), NIST.800-53.r5 SI-13(5)

**Category:** Recover > Resilience > Backups enabled 

**Severity:** Medium

**Resource type:** `AWS::Redshift::Cluster`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/redshift-backup-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/redshift-backup-enabled.html)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  `​MinRetentionPeriod`  |  Minimum snapshot retention period in days  |  Integer  |  `7` to `35`  |  `7`  | 

This control checks whether an Amazon Redshift cluster has automated snapshots enabled, and a retention period greater than or equal to the specified time frame. The control fails if automated snapshots aren't enabled for the cluster, or if the retention period is less than the specified time frame. Unless you provide a custom parameter value for the snapshot retention period, Security Hub CSPM uses a default value of 7 days.

Backups help you to recover more quickly from a security incident. They strengthen the resilience of your systems. Amazon Redshift takes periodic snapshots by default. This control checks whether automatic snapshots are enabled and retained for at least seven days. For more details on Amazon Redshift automated snapshots, see [Automated snapshots](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-snapshots.html#about-automated-snapshots) in the *Amazon Redshift Management Guide*.

### Remediation
<a name="redshift-3-remediation"></a>

To update the snapshot retention period for an Amazon Redshift cluster, see [Modifying a cluster](https://docs.aws.amazon.com/redshift/latest/mgmt/managing-clusters-console.html#modify-cluster) in the *Amazon Redshift Management Guide*. For **Backup**, set **Snapshot retention** to a value of 7 or greater.

## [Redshift.4] Amazon Redshift clusters should have audit logging enabled
<a name="redshift-4"></a>

**Related requirements:** NIST.800-53.r5 AC-2(4), NIST.800-53.r5 AC-4(26), NIST.800-53.r5 AC-6(9), NIST.800-53.r5 AU-10, NIST.800-53.r5 AU-12, NIST.800-53.r5 AU-2, NIST.800-53.r5 AU-3, NIST.800-53.r5 AU-6(3), NIST.800-53.r5 AU-6(4), NIST.800-53.r5 CA-7, NIST.800-53.r5 SC-7(9), NIST.800-53.r5 SI-3(8), NIST.800-53.r5 SI-4(20), NIST.800-53.r5 SI-7(8), PCI DSS v4.0.1/10.2.1

**Category:** Identify > Logging

**Severity:** Medium

**Resource type:** `AWS::Redshift::Cluster`

**AWS Config rule:** `redshift-cluster-audit-logging-enabled` (custom Security Hub CSPM rule)

**Schedule type:** Change triggered

**Parameters:** None 

This control checks whether an Amazon Redshift cluster has audit logging enabled.

Amazon Redshift audit logging provides additional information about connections and user activities in your cluster. This data can be stored and secured in Amazon S3 and can be helpful in security audits and investigations. For more information, see [Database audit logging](https://docs.aws.amazon.com/redshift/latest/mgmt/db-auditing.html) in the *Amazon Redshift Management Guide*.

### Remediation
<a name="redshift-4-remediation"></a>

To configure audit logging for an Amazon Redshift cluster, see [Configuring auditing using the console](https://docs.aws.amazon.com/redshift/latest/mgmt/db-auditing-console.html) in the *Amazon Redshift Management Guide*.

## [Redshift.6] Amazon Redshift should have automatic upgrades to major versions enabled
<a name="redshift-6"></a>

**Related requirements:** NIST.800-53.r5 CA-9(1), NIST.800-53.r5 CM-2, NIST.800-53.r5 CP-9, NIST.800-53.r5 SC-5(2), NIST.800-53.r5 SI-2, NIST.800-53.r5 SI-2(2), NIST.800-53.r5 SI-2(4), NIST.800-53.r5 SI-2(5)

**Category:** Identify > Vulnerability, patch, and version management

**Severity:** Medium

**Resource type:** `AWS::Redshift::Cluster`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/redshift-cluster-maintenancesettings-check.html](https://docs.aws.amazon.com/config/latest/developerguide/redshift-cluster-maintenancesettings-check.html)

**Schedule type:** Change triggered

**Parameters:**
+ `allowVersionUpgrade = true` (not customizable)

This control checks whether automatic major version upgrades are enabled for the Amazon Redshift cluster.

Enabling automatic major version upgrades ensures that the latest major version updates to Amazon Redshift clusters are installed during the maintenance window. These updates might include security patches and bug fixes. Keeping up to date with patch installation is an important step in securing systems.

### Remediation
<a name="redshift-6-remediation"></a>

To remediate this issue from the AWS CLI, use the Amazon Redshift `modify-cluster` command, and set the `--allow-version-upgrade` attribute. `clustername` is the name of your Amazon Redshift cluster.

```
aws redshift modify-cluster --cluster-identifier clustername --allow-version-upgrade
```

## [Redshift.7] Redshift clusters should use enhanced VPC routing
<a name="redshift-7"></a>

**Related requirements:** NIST.800-53.r5 AC-4, NIST.800-53.r5 AC-4(21), NIST.800-53.r5 SC-7, NIST.800-53.r5 SC-7(11), NIST.800-53.r5 SC-7(20), NIST.800-53.r5 SC-7(21), NIST.800-53.r5 SC-7(4), NIST.800-53.r5 SC-7(9)

**Category:** Protect > Secure network configuration > API private access

**Severity:** Medium

**Resource type:** `AWS::Redshift::Cluster`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/redshift-enhanced-vpc-routing-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/redshift-enhanced-vpc-routing-enabled.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether an Amazon Redshift cluster has `EnhancedVpcRouting` enabled.

Enhanced VPC routing forces all `COPY` and `UNLOAD` traffic between the cluster and data repositories to go through your VPC. You can then use VPC features such as security groups and network access control lists to secure network traffic. You can also use VPC Flow Logs to monitor network traffic.

### Remediation
<a name="redshift-7-remediation"></a>

For detailed remediation instructions, see [Enabling enhanced VPC routing](https://docs.aws.amazon.com/redshift/latest/mgmt/enhanced-vpc-enabling-cluster.html) in the *Amazon Redshift Management Guide*.

## [Redshift.8] Amazon Redshift clusters should not use the default Admin username
<a name="redshift-8"></a>

**Related requirements:** NIST.800-53.r5 CA-9(1), NIST.800-53.r5 CM-2

**Category:** Identify > Resource Configuration

**Severity:** Medium

**Resource type:** `AWS::Redshift::Cluster`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/redshift-default-admin-check.html](https://docs.aws.amazon.com/config/latest/developerguide/redshift-default-admin-check.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether an Amazon Redshift cluster has changed the admin username from its default value. This control will fail if the admin username for a Redshift cluster is set to `awsuser`.

When creating a Redshift cluster, you should change the default admin username to a unique value. Default usernames are public knowledge and should be changed upon configuration. Changing the default usernames reduces the risk of unintended access.

### Remediation
<a name="redshift-8-remediation"></a>

You can't change the admin username for your Amazon Redshift cluster after creating it. To create a new cluster with a non-default username, see [Step 1: Create a sample Amazon Redshift cluster](https://docs.aws.amazon.com/redshift/latest/gsg/rs-gsg-prereq.html) in the *Amazon Redshift Getting Started Guide*.

## [Redshift.10] Redshift clusters should be encrypted at rest
<a name="redshift-10"></a>

**Related requirements:** NIST.800-53.r5 CA-9(1), NIST.800-53.r5 CM-3(6), NIST.800-53.r5 SC-13, NIST.800-53.r5 SC-28, NIST.800-53.r5 SC-28(1), NIST.800-53.r5 SI-7(6)

**Category:** Protect > Data Protection > Encryption of data-at-rest

**Severity:** Medium

**Resource type:** `AWS::Redshift::Cluster`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/redshift-cluster-kms-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/redshift-cluster-kms-enabled.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks if Amazon Redshift clusters are encrypted at rest. The control fails if a Redshift cluster isn't encrypted at rest or if the encryption key is different from the provided key in the rule parameter.

In Amazon Redshift, you can turn on database encryption for your clusters to help protect data at rest. When you turn on encryption for a cluster, the data blocks and system metadata are encrypted for the cluster and its snapshots. Encryption of data at rest is a recommended best practice because it adds a layer of access management to your data. Encrypting Redshift clusters at rest reduces the risk that an unauthorized user can access the data stored on disk.

### Remediation
<a name="redshift-10-remediation"></a>

To modify a Redshift cluster to use KMS encryption, see [Changing cluster encryption](https://docs.aws.amazon.com/redshift/latest/mgmt/changing-cluster-encryption.html) in the *Amazon Redshift Management Guide*.

## [Redshift.11] Redshift clusters should be tagged
<a name="redshift-11"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::Redshift::Cluster`

**AWS Config rule:** `tagged-redshift-cluster` (custom Security Hub CSPM rule)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  |  No default value  | 

This control checks whether an Amazon Redshift cluster has tags with the specific keys defined in the parameter `requiredTagKeys`. The control fails if the cluster doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredTagKeys`. If the parameter `requiredTagKeys` isn't provided, the control only checks for the existence of a tag key and fails if the cluster isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [What is ABAC for AWS?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Tagging your AWS resources](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *AWS General Reference*.

### Remediation
<a name="redshift-11-remediation"></a>

To add tags to a Redshift cluster, see [Tagging resources in Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/mgmt/amazon-redshift-tagging.html) in the *Amazon Redshift Management Guide*.

## [Redshift.12] Redshift event notification subscriptions should be tagged
<a name="redshift-12"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::Redshift::EventSubscription`

**AWS Config rule:** `tagged-redshift-eventsubscription` (custom Security Hub CSPM rule)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  |  No default value  | 

This control checks whether an Amazon Redshift cluster snapshot has tags with the specific keys defined in the parameter `requiredTagKeys`. The control fails if the cluster snapshot doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredTagKeys`. If the parameter `requiredTagKeys` isn't provided, the control only checks for the existence of a tag key and fails if the cluster snapshot isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [What is ABAC for AWS?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Tagging your AWS resources](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *AWS General Reference*.

### Remediation
<a name="redshift-12-remediation"></a>

To add tags to a Redshift event notification subscription, see [Tagging resources in Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/mgmt/amazon-redshift-tagging.html) in the *Amazon Redshift Management Guide*.

## [Redshift.13] Redshift cluster snapshots should be tagged
<a name="redshift-13"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::Redshift::ClusterSnapshot`

**AWS Config rule:** `tagged-redshift-clustersnapshot` (custom Security Hub CSPM rule)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  |  No default value  | 

This control checks whether an Amazon Redshift cluster snapshot has tags with the specific keys defined in the parameter `requiredTagKeys`. The control fails if the cluster snapshot doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredTagKeys`. If the parameter `requiredTagKeys` isn't provided, the control only checks for the existence of a tag key and fails if the cluster snapshot isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [What is ABAC for AWS?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Tagging your AWS resources](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *AWS General Reference*.

### Remediation
<a name="redshift-13-remediation"></a>

To add tags to a Redshift cluster snapshot, see [Tagging resources in Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/mgmt/amazon-redshift-tagging.html) in the *Amazon Redshift Management Guide*.

## [Redshift.14] Redshift cluster subnet groups should be tagged
<a name="redshift-14"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::Redshift::ClusterSubnetGroup`

**AWS Config rule:** `tagged-redshift-clustersubnetgroup` (custom Security Hub CSPM rule)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  |  No default value  | 

This control checks whether an Amazon Redshift cluster subnet group has tags with the specific keys defined in the parameter `requiredTagKeys`. The control fails if the cluster subnet group doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredTagKeys`. If the parameter `requiredTagKeys` isn't provided, the control only checks for the existence of a tag key and fails if the cluster subnet group isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [What is ABAC for AWS?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Tagging your AWS resources](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *AWS General Reference*.

### Remediation
<a name="redshift-14-remediation"></a>

To add tags to a Redshift cluster subnet group, see [Tagging resources in Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/mgmt/amazon-redshift-tagging.html) in the *Amazon Redshift Management Guide*.

## [Redshift.15] Redshift security groups should allow ingress on the cluster port only from restricted origins
<a name="redshift-15"></a>

**Related requirements:** PCI DSS v4.0.1/1.3.1

**Category:** Protect > Secure network configuration > Security group configuration

**Severity:** High

**Resource type:** `AWS::Redshift::Cluster`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/redshift-unrestricted-port-access.html](https://docs.aws.amazon.com/config/latest/developerguide/redshift-unrestricted-port-access.html)

**Schedule type:** Periodic

**Parameters:** None

This control checks whether a security group associated with an Amazon Redshift cluster has ingress rules that permit access to the cluster port from the internet (0.0.0.0/0 or ::/0). The control fails if the security group ingress rules permit access to the cluster port from the internet.

Permitting unrestricted inbound access to the Redshift cluster port (IP address with a /0 suffix) can result in unauthorized access or security incidents. We recommend applying the principal of least privilege access when creating security groups and configuring inbound rules.

### Remediation
<a name="redshift-15-remediation"></a>

To restrict ingress on the Redshift cluster port to restricted origins, see [Work with security group rules](https://docs.aws.amazon.com/vpc/latest/userguide/security-group-rules.html#working-with-security-group-rules) in the *Amazon VPC User Guide*. Update rules where the port range matches the Redshift cluster port and the IP port range is 0.0.0.0/0.

## [Redshift.16] Redshift cluster subnet groups should have subnets from multiple Availability Zones
<a name="redshift-16"></a>

**Category:** Recover > Resilience > High availability

**Severity:** Medium

**Resource type:** `AWS::Redshift::ClusterSubnetGroup`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/redshift-cluster-subnet-group-multi-az.html](https://docs.aws.amazon.com/config/latest/developerguide/redshift-cluster-subnet-group-multi-az.html)

**Schedule type:** Change triggered

**Parameters:** None

The control checks whether an Amazon Redshift cluster subnet group has subnets from more than one Availability Zone (AZ). The control fails if the cluster subnet group doesn't have subnets from at least two different AZs.

Configuring subnets across multiple AZs help ensure that your Redshift data warehouse can continue operating even when failure events occur.

### Remediation
<a name="redshift-16-remediation"></a>

To modify a Redshift cluster subnet group to span multiple AZs, see [Modifying a cluster subnet group](https://docs.aws.amazon.com/redshift/latest/mgmt/modify-cluster-subnet-group.html) in the *Amazon Redshift Management Guide*.

## [Redshift.17] Redshift cluster parameter groups should be tagged
<a name="redshift-17"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::Redshift::ClusterParameterGroup`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/redshift-cluster-parameter-group-tagged.html](https://docs.aws.amazon.com/config/latest/developerguide/redshift-cluster-parameter-group-tagged.html)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
| requiredKeyTags | A list of non-system tag keys that must be assigned to an evaluated resource. Tag keys are case sensitive. | StringList (maximum of 6 items) | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions). | No default value | 

This control checks whether an Amazon Redshift cluster parameter group has the tag keys specified by the `requiredKeyTags` parameter. The control fails if the parameter group doesn't have any tag keys, or it doesn't have all the keys specified by the `requiredKeyTags` parameter. If you don't specify any values for the `requiredKeyTags` parameter, the control checks only for the existence of a tag key and fails if the parameter group doesn't have any tag keys. The control ignores system tags, which are applied automatically and have the `aws:` prefix.

A tag is a label that you create and assign to an AWS resource. Each tag consists of a required tag key and an optional tag value. You can use tags to categorize resources by purpose, owner, environment, or other criteria. They can help you identify, organize, search for, and filter resources. They can also help you track resource owners for actions and notifications. You can also use tags to implement attribute-based access control (ABAC) as an authorization strategy. For more information about ABAC strategies, see [Define permissions based on attributes with ABAC authorization](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*. For more information about tags, see the [Tagging AWS Resources and Tag Editor User Guide](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html).

**Note**  
Do not store personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible from many AWS services. They aren't intended to be used for private or sensitive data.

### Remediation
<a name="redshift-17-remediation"></a>

For information about adding tags to an Amazon Redshift cluster parameter group, see [Tag resources in Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/mgmt/amazon-redshift-tagging.html) in the *Amazon Redshift Management Guide*.

## [Redshift.18] Redshift clusters should have Multi-AZ deployments enabled
<a name="redshift-18"></a>

**Category:** Recover > Resilience > High availability

**Severity:** Medium

**Resource type:** `AWS::Redshift::Cluster`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/redshift-cluster-multi-az-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/redshift-cluster-multi-az-enabled.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether multiple Availability Zones (Multi-AZ) deployments are enabled for an Amazon Redshift cluster. The control fails if Multi-AZ deployments aren't enabled for the Amazon Redshift cluster.

Amazon Redshift supports multiple Availability Zones (Multi-AZ) deployments for provisioned clusters. If Multi-AZ deployments are enabled for a cluster, an Amazon Redshift data warehouse can continue operating in failure scenarios when an unexpected event happens in an Availability Zone (AZ). A Multi-AZ deployment deploys compute resources in more than one AZ and these compute resources can be accessed through a single endpoint. In the event of an entire AZ failure, the remaining compute resources in another AZ are available to continue processing workloads. You can convert an existing Single-AZ data warehouse to a Multi-AZ data warehouse. Additional compute resources are then provisioned in a second AZ.

### Remediation
<a name="redshift-18-remediation"></a>

For information about configuring Multi-AZ deployments for an Amazon Redshift cluster, see [Converting a Single-AZ data warehouse to a Multi-AZ data warehouse](https://docs.aws.amazon.com/redshift/latest/mgmt/convert-saz-to-maz.html) in the *Amazon Redshift Management Guide*.

# Security Hub CSPM controls for Amazon Redshift Serverless
<a name="redshiftserverless-controls"></a>

These AWS Security Hub CSPM controls evaluate the Amazon Redshift Serverless service and resources. The controls might not be available in all AWS Regions. For more information, see [Availability of controls by Region](securityhub-regions.md#securityhub-regions-control-support).

## [RedshiftServerless.1] Amazon Redshift Serverless workgroups should use enhanced VPC routing
<a name="redshiftserverless-1"></a>

**Category:** Protect > Secure network configuration > Resources within VPC

**Severity:** High

**Resource type:** `AWS::RedshiftServerless::Workgroup`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/redshift-serverless-workgroup-routes-within-vpc.html](https://docs.aws.amazon.com/config/latest/developerguide/redshift-serverless-workgroup-routes-within-vpc.html)

**Schedule type:** Periodic

**Parameters:** None

This control checks whether enhanced VPC routing is enabled for an Amazon Redshift Serverless workgroup. The control fails if enhanced VPC routing is disabled for the workgroup.

If enhanced VPC routing is disabled for an Amazon Redshift Serverless workgroup, Amazon Redshift routes traffic through the internet, including traffic to other services within the AWS network. If you enable enhanced VPC routing for a workgroup, Amazon Redshift forces all `COPY` and `UNLOAD` traffic between your cluster and your data repositories through your virtual private cloud (VPC) based on the Amazon VPC service. With enhanced VPC routing, you can use standard VPC features to control the flow of data between your Amazon Redshift cluster and other resources. This includes features such as VPC security groups and endpoint policies, network access control lists (ACLs), and Domain Name System (DNS) servers. You can also use VPC flow logs to monitor `COPY` and `UNLOAD` traffic.

### Remediation
<a name="redshiftserverless-1-remediation"></a>

For more information about enhanced VPC routing and how to enable it for a workgroup, see [Controlling network traffic with Redshift enhanced VPC routing](https://docs.aws.amazon.com/redshift/latest/mgmt/enhanced-vpc-routing.html) in the *Amazon Redshift Management Guide*.

## [RedshiftServerless.2] Connections to Redshift Serverless workgroups should be required to use SSL
<a name="redshiftserverless-2"></a>

**Category:** Protect > Data Protection > Encryption of data-in-transit

**Severity:** Medium

**Resource type:** `AWS::RedshiftServerless::Workgroup`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/redshift-serverless-workgroup-encrypted-in-transit.html](https://docs.aws.amazon.com/config/latest/developerguide/redshift-serverless-workgroup-encrypted-in-transit.html)

**Schedule type:** Periodic

**Parameters:** None

This control checks whether connections to an Amazon Redshift Serverless workgroup are required to encrypt data in transit. The control fails if the `require_ssl` configuration parameter for the workgroup is set to `false`.

An Amazon Redshift Serverless workgroup is a collection of compute resources that groups together compute resources like RPUs, VPC subnet groups, and security groups. Properties of a workgroup include network and security settings. These settings specify whether connections to a workgroup should be required to use SSL to encrypt data in transit.

### Remediation
<a name="redshiftserverless-2-remediation"></a>

For information about updating the settings for an Amazon Redshift Serverless workgroup to require SSL connections, see [Connecting to Amazon Redshift Serverless](https://docs.aws.amazon.com/redshift/latest/mgmt/serverless-connecting.html) in the *Amazon Redshift Management Guide*.

## [RedshiftServerless.3] Redshift Serverless workgroups should prohibit public access
<a name="redshiftserverless-3"></a>

**Category:** Protect > Secure network configuration > Resources not publicly accessible

**Severity:** High

**Resource type:** `AWS::RedshiftServerless::Workgroup`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/redshift-serverless-workgroup-no-public-access.html](https://docs.aws.amazon.com/config/latest/developerguide/redshift-serverless-workgroup-no-public-access.html)

**Schedule type:** Periodic

**Parameters:** None

This control checks whether public access is disabled for an Amazon Redshift Serverless workgroup. It evaluates the `publiclyAccessible` property of a Redshift Serverless workgroup. The control fails if public access is enabled (`true`) for the workgroup.

The public access (`publiclyAccessible`) setting for an Amazon Redshift Serverless workgroup specifies whether the workgroup can be accessed from a public network. If public access is enabled (`true`) for a workgroup, Amazon Redshift creates an Elastic IP address that makes the workgroup publicly accessible from outside the VPC. If you don't want a workgroup to be publicly accessible, disable public access for it.

### Remediation
<a name="redshiftserverless-3-remediation"></a>

For information about changing the public access setting for an Amazon Redshift Serverless workgroup, see [Viewing the properties for a workgroup](https://docs.aws.amazon.com/redshift/latest/mgmt/serverless-console-workgroups.html) in the *Amazon Redshift Management Guide*.

## [RedshiftServerless.4] Redshift Serverless namespaces should be encrypted with customer managed AWS KMS keys
<a name="redshiftserverless-4"></a>

**Related requirements:** NIST.800-53.r5 AU-9, NIST.800-53.r5 CA-9(1), NIST.800-53.r5 CM-3(6), NIST.800-53.r5 SC-7(10), NIST.800-53.r5 SC-12(2), NIST.800-53.r5 SC-13, NIST.800-53.r5 SC-28, NIST.800-53.r5 SC-28(1), NIST.800-53.r5 SI-7(6)

**Category:** Protect > Data Protection > Encryption of data-at-rest

**Severity:** Medium

**Resource type:** `AWS::RedshiftServerless::Namespace`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/redshift-serverless-namespace-cmk-encryption.html](https://docs.aws.amazon.com/config/latest/developerguide/redshift-serverless-namespace-cmk-encryption.html)

**Schedule type:** Periodic

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  `kmsKeyArns`  |  A list of Amazon Resource Names (ARNs) of AWS KMS keys to include in the evaluation. The control generates a `FAILED` finding if a Redshift Serverless namespace isn't encrypted with a KMS key in the list.  |  StringList (maximum of 3 items)  |  1–3 ARNs of existing KMS keys. For example: `arn:aws:kms:us-west-2:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab`.  |  No default value  | 

This control checks whether an Amazon Redshift Serverless namespace is encrypted at rest with a customer managed AWS KMS key. The control fails if the Redshift Serverless namespace isn't encrypted with a customer managed KMS key. You can optionally specify a list of KMS keys for the control to include in the evaluation.

In Amazon Redshift Serverless, a namespace defines a logical container for database objects. This control periodically checks whether the encryption settings for a namespace specify a customer managed AWS KMS key, instead of an AWS managed KMS key, for encryption of data in the namespace. With a customer managed KMS key, you have full control of the key. This includes defining and maintaining the key policy, managing grants, rotating cryptographic material, assigning tags, creating aliases, and enabling and disabling the key.

### Remediation
<a name="redshiftserverless-4-remediation"></a>

For information about updating the encryption settings for an Amazon Redshift Serverless namespace and specifying a customer managed AWS KMS key, see [Changing the AWS KMS key for a namespace](https://docs.aws.amazon.com/redshift/latest/mgmt/serverless-workgroups-and-namespaces-rotate-kms-key.html) in the *Amazon Redshift Management Guide*.

## [RedshiftServerless.5] Redshift Serverless namespaces should not use the default admin username
<a name="redshiftserverless-5"></a>

**Category:** Identify > Resource configuration

**Severity:** Medium

**Resource type:** `AWS::RedshiftServerless::Namespace`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/redshift-serverless-default-admin-check.html](https://docs.aws.amazon.com/config/latest/developerguide/redshift-serverless-default-admin-check.html)

**Schedule type:** Periodic

**Parameters:** None

This control checks whether the admin username for an Amazon Redshift Serverless namespace is the default admin username, `admin`. The control fails if the admin username for the Redshift Serverless namespace is `admin`. 

When creating an Amazon Redshift Serverless namespace, you should specify a custom admin username for the namespace. The default admin username is public knowledge. By specifying a custom admin username, you can, for example, help mitigate the risk or effectiveness of brute force attacks against the namespace.

### Remediation
<a name="redshiftserverless-5-remediation"></a>

You can change the admin username for an Amazon Redshift Serverless namespace by using the Amazon Redshift Serverless console or API. To change it by using the console, choose the namespace configuration, and then choose **Edit admin credentials** on the **Actions** menu. To change it programmatically, use the [UpdateNamespace](https://docs.aws.amazon.com/redshift-serverless/latest/APIReference/API_UpdateNamespace.html) operation or, if you’re using the AWS CLI, run the [update-namespace](https://docs.aws.amazon.com/cli/latest/reference/redshift-serverless/update-namespace.html) command. If you change the admin username, you must also change the admin password at the same time.

## [RedshiftServerless.6] Redshift Serverless namespaces should export logs to CloudWatch Logs
<a name="redshiftserverless-6"></a>

**Category:** Identify > Logging

**Severity:** Medium

**Resource type:** `AWS::RedshiftServerless::Namespace`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/redshift-serverless-publish-logs-to-cloudwatch.html](https://docs.aws.amazon.com/config/latest/developerguide/redshift-serverless-publish-logs-to-cloudwatch.html)

**Schedule type:** Periodic

**Parameters:** None

This control checks whether an Amazon Redshift Serverless namespace is configured to export connection and user logs to Amazon CloudWatch Logs. The control fails if the Redshift Serverless namespace isn't configured to export the logs to CloudWatch Logs.

If you configure Amazon Redshift Serverless to export connection log (`connectionlog`) and user log (`userlog`) data to a log group in Amazon CloudWatch Logs, you can collect and store your log records in durable storage, which can support security, access, and availability reviews and audits. With CloudWatch Logs, you can also perform real-time analysis of log data and use CloudWatch to create alarms and review metrics.

### Remediation
<a name="redshiftserverless-6-remediation"></a>

To export log data for an Amazon Redshift Serverless namespace to Amazon CloudWatch Logs, the respective logs must be selected for export in the audit logging configuration settings for the namespace. For information about updating these settings, see [Editing security and encryption](https://docs.aws.amazon.com/redshift/latest/mgmt/serverless-console-configuration-edit-network-settings.html) in the *Amazon Redshift Management Guide*.

# Security Hub CSPM controls for Route 53
<a name="route53-controls"></a>

These AWS Security Hub CSPM controls evaluate the Amazon Route 53 service and resources.

These controls may not be available in all AWS Regions. For more information, see [Availability of controls by Region](securityhub-regions.md#securityhub-regions-control-support).

## [Route53.1] Route 53 health checks should be tagged
<a name="route53-1"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::Route53::HealthCheck`

**AWS Config rule:**`tagged-route53-healthcheck` (custom Security Hub CSPM rule)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  | No default value  | 

This control checks whether an Amazon Route 53 health check has tags with the specific keys defined in the parameter `requiredTagKeys`. The control fails if the health check doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredTagKeys`. If the parameter `requiredTagKeys` isn't provided, the control only checks for the existence of a tag key and fails if the health check isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [What is ABAC for AWS?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Tagging your AWS resources](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *AWS General Reference*.

### Remediation
<a name="route53-1-remediation"></a>

To add tags to a Route 53 health check, see [ Naming and tagging health checks](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/health-checks-tagging.html) in the *Amazon Route 53 Developer Guide*.

## [Route53.2] Route 53 public hosted zones should log DNS queries
<a name="route53-2"></a>

**Related requirements:** NIST.800-53.r5 AC-2(4), NIST.800-53.r5 AC-4(26), NIST.800-53.r5 AC-6(9), NIST.800-53.r5 AU-10, NIST.800-53.r5 AU-12, NIST.800-53.r5 AU-2, NIST.800-53.r5 AU-3, NIST.800-53.r5 AU-6(3), NIST.800-53.r5 AU-6(4), NIST.800-53.r5 CA-7, NIST.800-53.r5 SC-7(9), NIST.800-53.r5 SI-3(8), NIST.800-53.r5 SI-4(20), NIST.800-53.r5 SI-7(8), PCI DSS v4.0.1/10.4.2

**Category:** Identify > Logging

**Severity:** Medium

**Resource type:** `AWS::Route53::HostedZone`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/route53-query-logging-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/route53-query-logging-enabled.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks if DNS query logging is enabled for an Amazon Route 53 public hosted zone. The control fails if DNS query logging isn't enabled for a Route 53 public hosted zone.

Logging DNS queries for a Route 53 hosted zone addresses DNS security and compliance requirements and grants visibility. The logs include information such as the domain or subdomain that was queried, the date and time of the query, the DNS record type (for example, A or AAAA), and the DNS response code (for example, `NoError` or `ServFail`). When DNS query logging is enabled, Route 53 publishes the log files to Amazon CloudWatch Logs.

### Remediation
<a name="route53-2-remediation"></a>

To log DNS queries for Route 53 public hosted zones, see [ Configuring logging for DNS queries](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/query-logs.html#query-logs-configuring) in the *Amazon Route 53 Developer Guide*.

# Security Hub CSPM controls for Amazon S3
<a name="s3-controls"></a>

These AWS Security Hub CSPM controls evaluate the Amazon Simple Storage Service (Amazon S3) service and resources. The controls might not be available in all AWS Regions. For more information, see [Availability of controls by Region](securityhub-regions.md#securityhub-regions-control-support).

## [S3.1] S3 general purpose buckets should have block public access settings enabled
<a name="s3-1"></a>

**Related requirements:** CIS AWS Foundations Benchmark v5.0.0/2.1.4, CIS AWS Foundations Benchmark v3.0.0/2.1.4, CIS AWS Foundations Benchmark v1.4.0/2.1.5, NIST.800-53.r5 AC-21, NIST.800-53.r5 AC-3, NIST.800-53.r5 AC-3(7), NIST.800-53.r5 AC-4, NIST.800-53.r5 AC-4(21), NIST.800-53.r5 AC-6, NIST.800-53.r5 SC-7, NIST.800-53.r5 SC-7(11), NIST.800-53.r5 SC-7(16), NIST.800-53.r5 SC-7(20), NIST.800-53.r5 SC-7(21), NIST.800-53.r5 SC-7(3), NIST.800-53.r5 SC-7(4), NIST.800-53.r5 SC-7(9), PCI DSS v3.2.1/1.2.1, PCI DSS v3.2.1/1.3.1, PCI DSS v3.2.1/1.3.2, PCI DSS v3.2.1/1.3.4, PCI DSS v3.2.1/1.3.6, PCI DSS v4.0.1/1.4.4

**Category:** Protect > Secure network configuration

**Severity:** Medium

**Resource type:** `AWS::::Account`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/s3-account-level-public-access-blocks-periodic.html](https://docs.aws.amazon.com/config/latest/developerguide/s3-account-level-public-access-blocks-periodic.html) 

**Schedule type:** Periodic

**Parameters:** 
+ `ignorePublicAcls`: `true` (not customizable)
+ `blockPublicPolicy`: `true` (not customizable)
+ `blockPublicAcls`: `true` (not customizable)
+ `restrictPublicBuckets`: `true` (not customizable)

This control checks whether the preceding Amazon S3 block public access settings are configured at the account level for an S3 general purpose bucket. The control fails if one or more of the block public access settings are set to `false`.

The control fails if any of the settings are set to `false`, or if any of the settings are not configured.

Amazon S3 public access block is designed to provide controls across an entire AWS account or at the individual S3 bucket level to ensure that objects never have public access. Public access is granted to buckets and objects through access control lists (ACLs), bucket policies, or both.

Unless you intend to have your S3 buckets be publicly accessible, you should configure the account level Amazon S3 Block Public Access feature.

To learn more, see [Using Amazon S3 Block Public Access](https://docs.aws.amazon.com/AmazonS3/latest/dev/access-control-block-public-access.html) in the *Amazon Simple Storage Service User Guide*.

### Remediation
<a name="s3-1-remediation"></a>

To enable Amazon S3 Block Public Access for your AWS account, see [Configuring block public access settings for your account](https://docs.aws.amazon.com/AmazonS3/latest/userguide/configuring-block-public-access-account.html) in the *Amazon Simple Storage Service User Guide*.

## [S3.2] S3 general purpose buckets should block public read access
<a name="s3-2"></a>

**Related requirements:** PCI DSS v3.2.1/1.2.1, PCI DSS v3.2.1/1.3.1, PCI DSS v3.2.1/1.3.2, PCI DSS v3.2.1/1.3.6, PCI DSS v3.2.1/7.2.1, NIST.800-53.r5 AC-21, NIST.800-53.r5 AC-3, NIST.800-53.r5 AC-3(7), NIST.800-53.r5 AC-4, NIST.800-53.r5 AC-4(21), NIST.800-53.r5 AC-6, NIST.800-53.r5 SC-7, NIST.800-53.r5 SC-7(11), NIST.800-53.r5 SC-7(16), NIST.800-53.r5 SC-7(20), NIST.800-53.r5 SC-7(21), NIST.800-53.r5 SC-7(3), NIST.800-53.r5 SC-7(4), NIST.800-53.r5 SC-7(9)

**Category:** Protect > Secure network configuration

**Severity:** Critical

**Resource type:** `AWS::S3::Bucket`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/s3-bucket-public-read-prohibited](https://docs.aws.amazon.com/config/latest/developerguide/s3-bucket-public-read-prohibited)

**Schedule type:** Periodic and change triggered

**Parameters:** None

This control checks whether an Amazon S3 general purpose bucket permits public read access. It evaluates the block public access settings, the bucket policy, and the bucket access control list (ACL). The control fails if the bucket permits public read access.

**Note**  
If an S3 bucket has a bucket policy, this control doesn't evaluate policy conditions that use wildcard characters or variables. To produce a `PASSED` finding, conditions in the bucket policy must only use fixed values, which are values that don't contain wildcard characters or policy variables. For information about policy variables, see [Variables and tags](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_variables.html) in the *AWS Identity and Access Management User Guide*.

Some use cases may require that everyone on the internet be able to read from your S3 bucket. However, those situations are rare. To ensure the integrity and security of your data, your S3 bucket should not be publicly readable.

### Remediation
<a name="s3-2-remediation"></a>

To block public read access on your Amazon S3 buckets, see [Configuring block public access settings for your S3 buckets](https://docs.aws.amazon.com/AmazonS3/latest/userguide/configuring-block-public-access-bucket.html) in the *Amazon Simple Storage Service User Guide*.

## [S3.3] S3 general purpose buckets should block public write access
<a name="s3-3"></a>

**Related requirements:** PCI DSS v3.2.1/1.2.1, PCI DSS v3.2.1/1.3.1, PCI DSS v3.2.1/1.3.2, PCI DSS v3.2.1/1.3.4, PCI DSS v3.2.1/1.3.6, PCI DSS v3.2.1/7.2.1, NIST.800-53.r5 AC-21, NIST.800-53.r5 AC-3, NIST.800-53.r5 AC-3(7), NIST.800-53.r5 AC-4, NIST.800-53.r5 AC-4(21), NIST.800-53.r5 AC-6, NIST.800-53.r5 SC-7, NIST.800-53.r5 SC-7(11), NIST.800-53.r5 SC-7(16), NIST.800-53.r5 SC-7(20), NIST.800-53.r5 SC-7(21), NIST.800-53.r5 SC-7(3), NIST.800-53.r5 SC-7(4), NIST.800-53.r5 SC-7(9)

**Category:** Protect > Secure network configuration

**Severity:** Critical

**Resource type:** `AWS::S3::Bucket`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/s3-bucket-public-write-prohibited.html](https://docs.aws.amazon.com/config/latest/developerguide/s3-bucket-public-write-prohibited.html) 

**Schedule type:** Periodic and change triggered

**Parameters:** None

This control checks whether an Amazon S3 general purpose bucket permits public write access. It evaluates the block public access settings, the bucket policy, and the bucket access control list (ACL). The control fails if the bucket permits public write access.

**Note**  
If an S3 bucket has a bucket policy, this control doesn't evaluate policy conditions that use wildcard characters or variables. To produce a `PASSED` finding, conditions in the bucket policy must only use fixed values, which are values that don't contain wildcard characters or policy variables. For information about policy variables, see [Variables and tags](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_variables.html) in the *AWS Identity and Access Management User Guide*.

Some use cases require that everyone on the internet be able to write to your S3 bucket. However, those situations are rare. To ensure the integrity and security of your data, your S3 bucket should not be publicly writable.

### Remediation
<a name="s3-3-remediation"></a>

To block public write access on your Amazon S3 buckets, see [Configuring block public access settings for your S3 buckets](https://docs.aws.amazon.com/AmazonS3/latest/userguide/configuring-block-public-access-bucket.html) in the *Amazon Simple Storage Service User Guide*.

## [S3.5] S3 general purpose buckets should require requests to use SSL
<a name="s3-5"></a>

**Related requirements:** CIS AWS Foundations Benchmark v5.0.0/2.1.1, CIS AWS Foundations Benchmark v3.0.0/2.1.1, CIS AWS Foundations Benchmark v1.4.0/2.1.2, NIST.800-53.r5 AC-17(2), NIST.800-53.r5 AC-4, NIST.800-53.r5 IA-5(1), NIST.800-53.r5 SC-12(3), NIST.800-53.r5 SC-13, NIST.800-53.r5 SC-23, NIST.800-53.r5 SC-23(3), NIST.800-53.r5 SC-7(4), NIST.800-53.r5 SC-8, NIST.800-53.r5 SC-8(1), NIST.800-53.r5 SC-8(2), NIST.800-53.r5 SI-7(6), NIST.800-171.r2 3.13.8, NIST.800-171.r2 3.13.15, PCI DSS v3.2.1/4.1, PCI DSS v4.0.1/4.2.1

**Category:** Protect > Secure access management

**Severity:** Medium

**Resource type:** `AWS::S3::Bucket`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/s3-bucket-ssl-requests-only.html](https://docs.aws.amazon.com/config/latest/developerguide/s3-bucket-ssl-requests-only.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether an Amazon S3 general purpose bucket has a policy that requires requests to use SSL. The control fails if the bucket policy doesn't require requests to use SSL.

S3 buckets should have policies that require all requests (`Action: S3:*`) to only accept transmission of data over HTTPS in the S3 resource policy, indicated by the condition key `aws:SecureTransport`.

### Remediation
<a name="s3-5-remediation"></a>

To update an Amazon S3 bucket policy to deny nonsecure transport, see [Adding a bucket policy by using the Amazon S3 console](https://docs.aws.amazon.com/AmazonS3/latest/userguide/add-bucket-policy.html) in the *Amazon Simple Storage Service User Guide*.

Add a policy statement similar to the one in the following policy. Replace `amzn-s3-demo-bucket` with the name of the bucket you're modifying.

------
#### [ JSON ]

****  

```
{
    "Id": "ExamplePolicy",
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "AllowSSLRequestsOnly",
            "Action": "s3:*",
            "Effect": "Deny",
            "Resource": [
                "arn:aws:s3:::amzn-s3-demo-bucket",
                "arn:aws:s3:::amzn-s3-demo-bucket/*"
            ],
            "Condition": {
                "Bool": {
                     "aws:SecureTransport": "false"
                }
            },
           "Principal": "*"
        }
    ]
}
```

------

For more information, see [What S3 bucket policy should I use to comply with the AWS Config rule s3-bucket-ssl-requests-only?](https://aws.amazon.com/premiumsupport/knowledge-center/s3-bucket-policy-for-config-rule/) in the *AWS Official Knowledge Center*.

## [S3.6] S3 general purpose bucket policies should restrict access to other AWS accounts
<a name="s3-6"></a>

**Related requirements:** NIST.800-53.r5 CA-9(1), NIST.800-53.r5 CM-2, NIST.800-171.r2 3.13.4

**Category:** Protect > Secure access management > Sensitive API operations actions restricted 

**Severity:** High

**Resource type:** `AWS::S3::Bucket`

**AWS Config** rule: [https://docs.aws.amazon.com/config/latest/developerguide/s3-bucket-blacklisted-actions-prohibited.html](https://docs.aws.amazon.com/config/latest/developerguide/s3-bucket-blacklisted-actions-prohibited.html)

**Schedule type:** Change triggered

**Parameters:**
+ `blacklistedactionpatterns`: `s3:DeleteBucketPolicy, s3:PutBucketAcl, s3:PutBucketPolicy, s3:PutEncryptionConfiguration, s3:PutObjectAcl` (not customizable)

This control checks whether an Amazon S3 general purpose bucket policy prevents principals from other AWS accounts from performing denied actions on resources in the S3 bucket. The control fails if the bucket policy allows one or more of the preceding actions for a principal in another AWS account.

Implementing least privilege access is fundamental to reducing security risk and the impact of errors or malicious intent. If an S3 bucket policy allows access from external accounts, it could result in data exfiltration by an insider threat or an attacker.

The `blacklistedactionpatterns` parameter allows for successful evaluation of the rule for S3 buckets. The parameter grants access to external accounts for action patterns that are not included in the `blacklistedactionpatterns` list.

### Remediation
<a name="s3-6-remediation"></a>

To update an Amazon S3 bucket policy to remove permissions, see.[Adding a bucket policy by using the Amazon S3 console](https://docs.aws.amazon.com/AmazonS3/latest/userguide/add-bucket-policy.html) in the *Amazon Simple Storage Service User Guide*.

On the **Edit bucket policy** page, in the policy editing text box, take one of the following actions:
+ Remove the statements that grant other AWS accounts access to denied actions.
+ Remove the permitted denied actions from the statements.

## [S3.7] S3 general purpose buckets should use cross-Region replication
<a name="s3-7"></a>

**Related requirements:** PCI DSS v3.2.1/2.2, NIST.800-53.r5 AU-9(2), NIST.800-53.r5 CP-10, NIST.800-53.r5 CP-6, NIST.800-53.r5 CP-6(1), NIST.800-53.r5 CP-6(2), NIST.800-53.r5 CP-9, NIST.800-53.r5 SC-36(2), NIST.800-53.r5 SC-5(2), NIST.800-53.r5 SI-13(5)

**Category:** Protect > Secure access management

**Severity: ** Low

**Resource type:** `AWS::S3::Bucket`

**AWS Config rule: ** [https://docs.aws.amazon.com/config/latest/developerguide/s3-bucket-cross-region-replication-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/s3-bucket-cross-region-replication-enabled.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether an Amazon S3 general purpose bucket has cross-Region replication enabled. The control fails if the bucket doesn't have cross-Region replication enabled.

Replication is the automatic, asynchronous copying of objects across buckets in the same or different AWS Regions. Replication copies newly created objects and object updates from a source bucket to a destination bucket or buckets. AWS best practices recommend replication for source and destination buckets that are owned by the same AWS account. In addition to availability, you should consider other systems hardening settings.

This control produces a `FAILED` finding for a replication destination bucket if it doesn't have cross-region replication enabled. If there's a legitimate reason that the destination bucket doesn't need cross-region replication to be enabled, you can suppress findings for this bucket.

### Remediation
<a name="s3-7-remediation"></a>

To enable Cross-Region Replication on an S3 bucket, see [Configuring replication for source and destination buckets owned by the same account](https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication-walkthrough1.html) in the *Amazon Simple Storage Service User Guide*. For **Source bucket**, choose **Apply to all objects in the bucket**.

## [S3.8] S3 general purpose buckets should block public access
<a name="s3-8"></a>

**Related requirements:** CIS AWS Foundations Benchmark v5.0.0/2.1.4, CIS AWS Foundations Benchmark v3.0.02.1.4, CIS AWS Foundations Benchmark v1.4.0/2.1.5, NIST.800-53.r5 AC-21, NIST.800-53.r5 AC-3, NIST.800-53.r5 AC-3(7), NIST.800-53.r5 AC-4, NIST.800-53.r5 AC-4(21), NIST.800-53.r5 AC-6, NIST.800-53.r5 SC-7, NIST.800-53.r5 SC-7(11), NIST.800-53.r5 SC-7(16), NIST.800-53.r5 SC-7(20), NIST.800-53.r5 SC-7(21), NIST.800-53.r5 SC-7(3), NIST.800-53.r5 SC-7(4), NIST.800-53.r5 SC-7(9), PCI DSS v4.0.1/1.4.4

**Category:** Protect > Secure access management > Access control

**Severity:** High

**Resource type:** `AWS::S3::Bucket`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/s3-bucket-level-public-access-prohibited.html](https://docs.aws.amazon.com/config/latest/developerguide/s3-bucket-level-public-access-prohibited.html)

**Schedule type:** Change triggered

**Parameters:**
+ `excludedPublicBuckets` (not customizable) – A comma-separated list of known allowed public S3 bucket names

This control checks whether an Amazon S3 general purpose bucket blocks public access at the bucket level. The control fails if any of the following settings are set to `false`:
+ `ignorePublicAcls`
+ `blockPublicPolicy`
+ `blockPublicAcls`
+ `restrictPublicBuckets`

Block Public Access at the S3 bucket level provides controls to ensure that objects never have public access. Public access is granted to buckets and objects through access control lists (ACLs), bucket policies, or both.

Unless you intend to have your S3 buckets publicly accessible, you should configure the bucket level Amazon S3 Block Public Access feature.

### Remediation
<a name="s3-8-remediation"></a>

For information on how to remove public access at a bucket level, see [Blocking public access to your Amazon S3 storage](https://docs.aws.amazon.com/AmazonS3/latest/dev/access-control-block-public-access.html) in the *Amazon S3 User Guide*.

## [S3.9] S3 general purpose buckets should have server access logging enabled
<a name="s3-9"></a>

**Related requirements:** NIST.800-53.r5 AC-2(4), NIST.800-53.r5 AC-4(26), NIST.800-53.r5 AC-6(9), NIST.800-53.r5 AU-10, NIST.800-53.r5 AU-12, NIST.800-53.r5 AU-2, NIST.800-53.r5 AU-3, NIST.800-53.r5 AU-6(3), NIST.800-53.r5 AU-6(4), NIST.800-53.r5 CA-7, NIST.800-53.r5 SC-7(9), NIST.800-53.r5 SI-3(8), NIST.800-53.r5 SI-4(20), NIST.800-53.r5 SI-7(8), NIST.800-171.r2 3.3.8, PCI DSS v4.0.1/10.2.1

**Category:** Identify > Logging

**Severity:** Medium

**Resource type:** `AWS::S3::Bucket`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/s3-bucket-logging-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/s3-bucket-logging-enabled.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether server access logging is enabled for an Amazon S3 general purpose bucket. The control fails if server access logging isn't enabled. When logging is enabled, Amazon S3 delivers access logs for a source bucket to a chosen target bucket. The target bucket must be in the same AWS Region as the source bucket and must not have a default retention period configured. The target logging bucket does not need to have server access logging enabled, and you should suppress findings for this bucket. 

Server access logging provides detailed records of requests made to a bucket. Server access logs can assist in security and access audits. For more information, see [Security Best Practices for Amazon S3: Enable Amazon S3 server access logging](https://docs.aws.amazon.com/AmazonS3/latest/dev/security-best-practices.html).

### Remediation
<a name="s3-9-remediation"></a>

To enable Amazon S3 server access logging, see [Enabling Amazon S3 server access logging](https://docs.aws.amazon.com/AmazonS3/latest/userguide/enable-server-access-logging.html) in the *Amazon S3 User Guide*.

## [S3.10] S3 general purpose buckets with versioning enabled should have Lifecycle configurations
<a name="s3-10"></a>

**Related requirements:** NIST.800-53.r5 CP-10, NIST.800-53.r5 CP-6(2), NIST.800-53.r5 CP-9, NIST.800-53.r5 SC-5(2), NIST.800-53.r5 SI-13(5)

**Category:** Identify > Logging

**Severity:** Medium

**Resource type:** `AWS::S3::Bucket`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/s3-version-lifecycle-policy-check.html](https://docs.aws.amazon.com/config/latest/developerguide/s3-version-lifecycle-policy-check.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether an Amazon S3 general purpose versioned bucket has a Lifecycle configuration. The control fails if the bucket doesn't have a Lifecycle configuration.

We recommended creating a Lifecycle configuration for your S3 bucket to help you define actions that you want Amazon S3 to take during an object's lifetime. 

### Remediation
<a name="s3-10-remediation"></a>

For more information on configuring lifecycle on an Amazon S3 bucket, see [Setting lifecycle configuration on a bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/how-to-set-lifecycle-configuration-intro.html) and [Managing your storage lifecycle](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lifecycle-mgmt.html).

## [S3.11] S3 general purpose buckets should have event notifications enabled
<a name="s3-11"></a>

**Related requirements:** NIST.800-53.r5 CA-7, NIST.800-53.r5 SI-3(8), NIST.800-53.r5 SI-4, NIST.800-53.r5 SI-4(4), NIST.800-171.r2 3.3.8

**Category:** Identify > Logging

**Severity:** Medium

**Resource type:** `AWS::S3::Bucket`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/s3-event-notifications-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/s3-event-notifications-enabled.html)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  `eventTypes`  |  List of preferred S3 event types  |  EnumList (maximum of 28 items)  |  `s3:IntelligentTiering, s3:LifecycleExpiration:*, s3:LifecycleExpiration:Delete, s3:LifecycleExpiration:DeleteMarkerCreated, s3:LifecycleTransition, s3:ObjectAcl:Put, s3:ObjectCreated:*, s3:ObjectCreated:CompleteMultipartUpload, s3:ObjectCreated:Copy, s3:ObjectCreated:Post, s3:ObjectCreated:Put, s3:ObjectRemoved:*, s3:ObjectRemoved:Delete, s3:ObjectRemoved:DeleteMarkerCreated, s3:ObjectRestore:*, s3:ObjectRestore:Completed, s3:ObjectRestore:Delete, s3:ObjectRestore:Post, s3:ObjectTagging:*, s3:ObjectTagging:Delete, s3:ObjectTagging:Put, s3:ReducedRedundancyLostObject, s3:Replication:*, s3:Replication:OperationFailedReplication, s3:Replication:OperationMissedThreshold, s3:Replication:OperationNotTracked, s3:Replication:OperationReplicatedAfterThreshold, s3:TestEvent`  |  No default value  | 

This control checks whether S3 Event Notifications are enabled on an Amazon S3 general purpose bucket. The control fails if S3 Event Notifications are not enabled on the bucket. If you provide custom values for the `eventTypes` parameter, the control passes only if event notifications are enabled for the specified types of events.

When you enable S3 Event Notifications, you receive alerts when specific events occur that impact your S3 buckets. For example, you can be notified of object creation, object removal, and object restoration. These notifications can alert relevant teams to accidental or intentional modifications that may lead to unauthorized data access.

### Remediation
<a name="s3-11-remediation"></a>

For information about detecting changes to S3 buckets and objects, see [Amazon S3 Event Notifications](https://docs.aws.amazon.com/AmazonS3/latest/userguide/NotificationHowTo.html) in the *Amazon S3 User Guide*.

## [S3.12] ACLs should not be used to manage user access to S3 general purpose buckets
<a name="s3-12"></a>

**Related requirements:** NIST.800-53.r5 AC-2(1), NIST.800-53.r5 AC-3, NIST.800-53.r5 AC-3(15), NIST.800-53.r5 AC-3(7), NIST.800-53.r5 AC-6

**Category:** Protect > Secure access management > Access control

**Severity:** Medium

**Resource type:** `AWS::S3::Bucket`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/s3-bucket-acl-prohibited.html](https://docs.aws.amazon.com/config/latest/developerguide/s3-bucket-acl-prohibited.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether an Amazon S3 general purpose bucket provides user permissions with an access control list (ACL). The control fails if an ACL is configured for managing user access on the bucket.

ACLs are legacy access control mechanisms that predate IAM. Instead of ACLs, we recommend using S3 bucket policies or AWS Identity and Access Management (IAM) policies to manage access to your S3 buckets.

### Remediation
<a name="s3-12-remediation"></a>

To pass this control, you should disable ACLs for your S3 buckets. For instructions, see [Controlling ownership of objects and disabling ACLs for your bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/about-object-ownership.html) in the *Amazon Simple Storage Service User Guide*.

To create an S3 bucket policy, see [Adding a bucket policy by using the Amazon S3 console](https://docs.aws.amazon.com/AmazonS3/latest/userguide/add-bucket-policy.html). To create an IAM user policy on an S3 bucket, see [Controlling access to a bucket with user policies](https://docs.aws.amazon.com/AmazonS3/latest/userguide/walkthrough1.html#walkthrough-grant-user1-permissions).

## [S3.13] S3 general purpose buckets should have Lifecycle configurations
<a name="s3-13"></a>

**Related requirements:** NIST.800-53.r5 CP-10, NIST.800-53.r5 CP-6(2), NIST.800-53.r5 CP-9, NIST.800-53.r5 SC-5(2), NIST.800-53.r5 SI-13(5)

**Category:** Protect > Data protection 

**Severity:** Low

**Resource type:** `AWS::S3::Bucket`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/s3-lifecycle-policy-check.html](https://docs.aws.amazon.com/config/latest/developerguide/s3-lifecycle-policy-check.html)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  `targetTransitionDays`  |  Number of days after object creation when objects are transitioned to a specified storage class  |  Integer  |  `1` to `36500`  |  No default value  | 
|  `targetExpirationDays`  |  Number of days after object creation when objects are deleted  |  Integer  |  `1` to `36500`  |  No default value  | 
|  `targetTransitionStorageClass`  |  Destination S3 storage class type  |  Enum  |  `STANDARD_IA, INTELLIGENT_TIERING, ONEZONE_IA, GLACIER, GLACIER_IR, DEEP_ARCHIVE`  |  No default value  | 

This control checks whether an Amazon S3 general purpose bucket has a Lifecycle configuration. The control fails if the bucket doesn't have a Lifecycle configuration. If you provide custom values for one or more of the preceding parameters, the control passes only if the policy includes the specified storage class, deletion time, or transition time. 

Creating a Lifecycle configuration for your S3 bucket defines actions that you want Amazon S3 to take during an object's lifetime. For example, you can transition objects to another storage class, archive them, or delete them after a specified period of time.

### Remediation
<a name="s3-13-remediation"></a>

For information about configuring lifecycle policies on an Amazon S3 bucket, see [Setting lifecycle configuration on a bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/how-to-set-lifecycle-configuration-intro.html) and see [Managing your storage lifecycle](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lifecycle-mgmt.html) in the *Amazon S3 User Guide*.

## [S3.14] S3 general purpose buckets should have versioning enabled
<a name="s3-14"></a>

**Category:** Protect > Data protection > Data deletion protection

**Related requirements:** NIST.800-53.r5 AU-9(2), NIST.800-53.r5 CP-10, NIST.800-53.r5 CP-6, NIST.800-53.r5 CP-6(1), NIST.800-53.r5 CP-6(2), NIST.800-53.r5 CP-9, NIST.800-53.r5 SC-5(2), NIST.800-53.r5 SI-12, NIST.800-53.r5 SI-13(5), NIST.800-171.r2 3.3.8

**Severity:** Low

**Resource type:** `AWS::S3::Bucket`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/s3-bucket-versioning-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/s3-bucket-versioning-enabled.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether an Amazon S3 general purpose bucket has versioning enabled. The control fails if versioning is suspended for the bucket.

Versioning keeps multiple variants of an object in the same S3 bucket. You can use versioning to preserve, retrieve, and restore earlier versions of an object stored in your S3 bucket. Versioning helps you recover from both unintended user actions and application failures.

**Tip**  
As the number of objects increases in a bucket because of versioning, you can set up a Lifecycle configuration to automatically archive or delete versioned objects based on rules. For more information, see [Amazon S3 Lifecycle Management for Versioned Objects](https://aws.amazon.com/blogs/aws/amazon-s3-lifecycle-management-update/).

### Remediation
<a name="s3-14-remediation"></a>

To use versioning on an S3 bucket, see [Enabling versioning on buckets](https://docs.aws.amazon.com/AmazonS3/latest/userguide/manage-versioning-examples.html) in the *Amazon S3 User Guide*.

## [S3.15] S3 general purpose buckets should have Object Lock enabled
<a name="s3-15"></a>

**Category:** Protect > Data protection > Data deletion protection

**Related requirements:** NIST.800-53.r5 CP-6(2), PCI DSS v4.0.1/10.5.1

**Severity:** Medium

**Resource type:** `AWS::S3::Bucket`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/s3-bucket-default-lock-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/s3-bucket-default-lock-enabled.html)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  `mode`  |  S3 Object Lock retention mode  |  Enum  |  `GOVERNANCE`, `COMPLIANCE`  |  No default value  | 

This control checks whether an Amazon S3 general purpose bucket has Object Lock enabled. The control fails if Object Lock isn't enabled for the bucket. If you provide a custom value for the `mode` parameter, the control passes only if S3 Object Lock uses the specified retention mode.

You can use S3 Object Lock to store objects using a write-once-read-many (WORM) model. Object Lock can help prevent objects in S3 buckets from being deleted or overwritten for a fixed amount of time or indefinitely. You can use S3 Object Lock to meet regulatory requirements that require WORM storage, or add an extra layer of protection against object changes and deletion.

### Remediation
<a name="s3-15-remediation"></a>

To configure Object Lock for new and existing S3 buckets, see [Configuring S3 Object Lock](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock-configure.html) in the *Amazon S3 User Guide*. 

## [S3.17] S3 general purpose buckets should be encrypted at rest with AWS KMS keys
<a name="s3-17"></a>

**Category:** Protect > Data Protection > Encryption of data-at-rest

**Related requirements:** NIST.800-53.r5 SC-12(2), NIST.800-53.r5 CM-3(6), NIST.800-53.r5 SC-13, NIST.800-53.r5 SC-28, NIST.800-53.r5 SC-28(1), NIST.800-53.r5 SC-7(10), NIST.800-53.r5 CA-9(1), NIST.800-53.r5 SI-7(6), NIST.800-53.r5 AU-9, NIST.800-171.r2 3.8.9, NIST.800-171.r2 3.13.11, NIST.800-171.r2 3.13.16, PCI DSS v4.0.1/3.5.1

**Severity:** Medium

**Resource type:** `AWS::S3::Bucket`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/s3-default-encryption-kms.html](https://docs.aws.amazon.com/config/latest/developerguide/s3-default-encryption-kms.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether an Amazon S3 general purpose bucket is encrypted with an AWS KMS key (SSE-KMS or DSSE-KMS). The control fails if the bucket is encrypted with default encryption (SSE-S3).

Server-side encryption (SSE) is the encryption of data at its destination by the application or service that receives it. Unless you specify otherwise, S3 buckets use Amazon S3 managed keys (SSE-S3) by default for server-side encryption. However, for added control, you can choose to configure buckets to use server-side encryption with AWS KMS keys (SSE-KMS or DSSE-KMS) instead. Amazon S3 encrypts your data at the object level as it writes it to disks in AWS data centers and decrypts it for you when you access it.

### Remediation
<a name="s3-17-remediation"></a>

To encrypt an S3 bucket using SSE-KMS, see [Specifying server-side encryption with AWS KMS (SSE-KMS)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/specifying-kms-encryption.html) in the *Amazon S3 User Guide*. To encrypt an S3 bucket using DSSE-KMS, see [Specifying dual-layer server-side encryption with AWS KMS keys (DSSE-KMS)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/specifying-dsse-encryption.html) in the *Amazon S3 User Guide*.

## [S3.19] S3 access points should have block public access settings enabled
<a name="s3-19"></a>

**Related requirements:** NIST.800-53.r5 AC-21, NIST.800-53.r5 AC-3, NIST.800-53.r5 AC-3(7), NIST.800-53.r5 AC-4, NIST.800-53.r5 AC-4(21), NIST.800-53.r5 AC-6, NIST.800-53.r5 SC-7, NIST.800-53.r5 SC-7(11), NIST.800-53.r5 SC-7(16), NIST.800-53.r5 SC-7(20), NIST.800-53.r5 SC-7(21), NIST.800-53.r5 SC-7(3), NIST.800-53.r5 SC-7(4), NIST.800-53.r5 SC-7(9), PCI DSS v4.0.1/1.4.4

**Category:** Protect > Secure access management > Resource not publicly accessible

**Severity:** Critical

**Resource type:** `AWS::S3::AccessPoint`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/s3-access-point-public-access-blocks.html](https://docs.aws.amazon.com/config/latest/developerguide/s3-access-point-public-access-blocks.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether an Amazon S3 access point has block public access settings enabled. The control fails if block public access settings aren't enabled for the access point.

The Amazon S3 Block Public Access feature helps you manage access to your S3 resources at three levels: the account, bucket, and access point levels. The settings at each level can be configured independently, allowing you to have different levels of public access restrictions for your data. The access point settings can't individually override the more restrictive settings at higher levels (account level or bucket assigned to the access point). Instead, the settings at the access point level are additive, meaning they complement and work alongside the settings at the other levels. Unless you intend an S3 access point to be publicly accessible, you should enable block public access settings.

### Remediation
<a name="s3-19-remediation"></a>

Amazon S3 currently doesn't support changing an access point's block public access settings after the access point has been created. All block public access settings are enabled by default when you create a new access point. We recommend that you keep all settings enabled unless you know that you have a specific need to disable any of them. For more information, see [Managing public access to access points](https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-points-bpa-settings.html) in the *Amazon Simple Storage Service User Guide*.

## [S3.20] S3 general purpose buckets should have MFA delete enabled
<a name="s3-20"></a>

**Related requirements:** CIS AWS Foundations Benchmark v5.0.0/2.1.2, CIS AWS Foundations Benchmark v3.0.0/2.1.2, CIS AWS Foundations Benchmark v1.4.0/2.1.3, NIST.800-53.r5 CA-9(1), NIST.800-53.r5 CM-2, NIST.800-53.r5 CM-2(2), NIST.800-53.r5 CM-3, NIST.800-53.r5 SC-5(2)

**Category:** Protect > Data protection > Data deletion protection

**Severity:** Low

**Resource type:** `AWS::S3::Bucket`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/s3-bucket-mfa-delete-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/s3-bucket-mfa-delete-enabled.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether multi-factor authentication (MFA) delete is enabled for an Amazon S3 general purpose bucket. The control fails if MFA delete is not enabled for the bucket. The control doesn't produce findings for buckets that have a lifecycle configuration.

If you enable versioning for an S3 general purpose bucket, you can optionally add another layer of security by configuring MFA delete for the bucket. If you do this, the bucket owner must include two forms of authentication in any request to delete a version of an object in the bucket or change the versioning state of the bucket. MFA delete provides added security if, for example, the bucket owner’s security credentials are compromised. MFA delete can also help prevent accidental bucket deletions by requiring the user who initiates the delete action to prove physical possession of an MFA device with an MFA code, which adds an extra layer of friction and security to the delete action.

**Note**  
This control produces a `PASSED` finding only if MFA delete is enabled for the S3 general purpose bucket. To enable MFA delete for a bucket, versioning must also be enabled for the bucket. Bucket versioning is a method of storing multiple variations of an S3 object in the same bucket. In addition, only the bucket owner who is logged in as a root user can enable MFA delete and perform delete actions on the bucket. You cannot use MFA delete with a bucket that has a lifecycle configuration.

### Remediation
<a name="s3-20-remediation"></a>

For information about enabling versioning and configuring MFA delete for an S3 bucket, see [Configuring MFA delete](https://docs.aws.amazon.com/AmazonS3/latest/userguide/MultiFactorAuthenticationDelete.html) in the *Amazon Simple Storage Service User Guide*.

## [S3.22] S3 general purpose buckets should log object-level write events
<a name="s3-22"></a>

**Related requirements:** CIS AWS Foundations Benchmark v5.0.0/3.8, CIS AWS Foundations Benchmark v3.0.0/3.8, PCI DSS v4.0.1/10.2.1

**Category:** Identify > Logging

**Severity:** Medium

**Resource type:** `AWS::::Account`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/cloudtrail-all-write-s3-data-event-check.html](https://docs.aws.amazon.com/config/latest/developerguide/cloudtrail-all-write-s3-data-event-check.html)

**Schedule type:** Periodic

**Parameters:** None

This control checks whether an AWS account has at least one AWS CloudTrail multi-Region trail that logs all write data events for Amazon S3 buckets. The control fails if the account doesn't have a multi-Region trail that logs write data events for S3 buckets.

S3 object-level operations, such as `GetObject`, `DeleteObject`, and `PutObject`, are called data events. By default, CloudTrail doesn't log data events, but you can configure trails to log data events for S3 buckets. When you enable object-level logging for write data events, you can log each individual object (file) access within an S3 bucket. Enabling object-level logging can help you meet data compliance requirements, perform comprehensive security analysis, monitor specific patterns of user behavior in your AWS account, and take action on object-level API activity within your S3 buckets by using Amazon CloudWatch Events. This control produces a `PASSED` finding if you configure a multi-Region trail that logs write-only or all types of data events for all S3 buckets.

### Remediation
<a name="s3-22-remediation"></a>

To enable object-level logging for S3 buckets, see [Enabling CloudTrail event logging for S3 buckets and objects](https://docs.aws.amazon.com/AmazonS3/latest/userguide/enable-cloudtrail-logging-for-s3.html) in the *Amazon Simple Storage Service User Guide*.

## [S3.23] S3 general purpose buckets should log object-level read events
<a name="s3-23"></a>

**Related requirements:** CIS AWS Foundations Benchmark v5.0.0/3.9, CIS AWS Foundations Benchmark v3.0.0/3.9, PCI DSS v4.0.1/10.2.1

**Category:** Identify > Logging

**Severity:** Medium

**Resource type:** `AWS::::Account`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/cloudtrail-all-read-s3-data-event-check.html](https://docs.aws.amazon.com/config/latest/developerguide/cloudtrail-all-read-s3-data-event-check.html)

**Schedule type:** Periodic

**Parameters:** None

This control checks whether an AWS account has at least one AWS CloudTrail multi-Region trail that logs all read data events for Amazon S3 buckets. The control fails if the account doesn't have a multi-Region trail that logs read data events for S3 buckets.

S3 object-level operations, such as `GetObject`, `DeleteObject`, and `PutObject`, are called data events. By default, CloudTrail doesn't log data events, but you can configure trails to log data events for S3 buckets. When you enable object-level logging for read data events, you can log each individual object (file) access within an S3 bucket. Enabling object-level logging can help you meet data compliance requirements, perform comprehensive security analysis, monitor specific patterns of user behavior in your AWS account, and take action on object-level API activity within your S3 buckets by using Amazon CloudWatch Events. This control produces a `PASSED` finding if you configure a multi-Region trail that logs read-only or all types of data events for all S3 buckets.

### Remediation
<a name="s3-23-remediation"></a>

To enable object-level logging for S3 buckets, see [Enabling CloudTrail event logging for S3 buckets and objects](https://docs.aws.amazon.com/AmazonS3/latest/userguide/enable-cloudtrail-logging-for-s3.html) in the *Amazon Simple Storage Service User Guide*.

## [S3.24] S3 Multi-Region Access Points should have block public access settings enabled
<a name="s3-24"></a>

**Related requirements:** PCI DSS v4.0.1/1.4.4

**Category:** Protect > Secure network configuration > Resources not publicly accessible

**Severity:** High

**Resource type:** `AWS::S3::MultiRegionAccessPoint`

**AWS Config rule:** `s3-mrap-public-access-blocked` (custom Security Hub CSPM rule)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether an Amazon S3 Multi-Region Access Point has block public access settings enabled. The control fails when the Multi-Region Access Point doesn't have block public access settings enabled.

Publicly accessible resources can be lead to unauthorized access, data breaches, or exploitation of vulnerabilities. Restricting access through authentication and authorization measures helps to safeguard sensitive information and maintain the integrity of your resources.

### Remediation
<a name="s3-24-remediation"></a>

By default, all Block Public Access settings are enabled for an S3 Multi-Region Access Point. For more information , see [Blocking public access with Amazon S3 Multi-Region Access Points](https://docs.aws.amazon.com/AmazonS3/latest/userguide/multi-region-access-point-block-public-access.html) in the *Amazon Simple Storage Service User Guide*. You can't change the Block Public Access settings for a Multi-Region Access Point after it has been created.

## [S3.25] S3 directory buckets should have lifecycle configurations
<a name="s3-25"></a>

**Category:** Protect > Data Protection

**Severity:** Low

**Resource type:** `AWS::S3Express::DirectoryBucket`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/s3express-dir-bucket-lifecycle-rules-check.html](https://docs.aws.amazon.com/config/latest/developerguide/s3express-dir-bucket-lifecycle-rules-check.html)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  `targetExpirationDays`  |  The number of days, after object creation, when objects should expire.  |  Integer  |  `1` to `2147483647`  |  No default value  | 

This control checks whether lifecycle rules are configured for an S3 directory bucket. The control fails if lifecycle rules aren't configured for the directory bucket, or a lifecycle rule for the bucket specifies expiration settings that don't match the parameter value that you optionally specify.

In Amazon S3, a lifecycle configuration is a set of rules that define actions for Amazon S3 to apply to a group of objects in a bucket. For an S3 directory bucket, you can create a lifecycle rule that specifies when objects expire based on age (in days). You can also create a lifecycle rule that deletes incomplete multipart uploads. Unlike other types of S3 buckets, such as general purpose buckets, directory buckets do not support other types of actions for lifecycle rules, such as transitioning objects between storage classes.

### Remediation
<a name="s3-25-remediation"></a>

To define a lifecycle configuration for an S3 directory bucket, create a lifecycle rule for the bucket. For more information, see [Creating and managing a lifecycle configuration for your directory bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/directory-bucket-create-lc.html) in the *Amazon Simple Storage Service User Guide*.

# Security Hub CSPM controls for SageMaker AI
<a name="sagemaker-controls"></a>

These AWS Security Hub CSPM controls evaluate the Amazon SageMaker AI service and resources. The controls might not be available in all AWS Regions. For more information, see [Availability of controls by Region](securityhub-regions.md#securityhub-regions-control-support).

## [SageMaker.1] Amazon SageMaker notebook instances should not have direct internet access
<a name="sagemaker-1"></a>

**Related requirements:** NIST.800-53.r5 AC-21, NIST.800-53.r5 AC-3, NIST.800-53.r5 AC-3(7), NIST.800-53.r5 AC-4, NIST.800-53.r5 AC-4(21), NIST.800-53.r5 AC-6, NIST.800-53.r5 SC-7, NIST.800-53.r5 SC-7(11), NIST.800-53.r5 SC-7(16), NIST.800-53.r5 SC-7(20), NIST.800-53.r5 SC-7(21), NIST.800-53.r5 SC-7(3), NIST.800-53.r5 SC-7(4), NIST.800-53.r5 SC-7(9), PCI DSS v3.2.1/1.2.1, PCI DSS v3.2.1/1.3.1, PCI DSS v3.2.1/1.3.2, PCI DSS v3.2.1/1.3.4, PCI DSS v3.2.1/1.3.6, PCI DSS v4.0.1/1.4.4

**Category:** Protect > Secure network configuration

**Severity:** High

**Resource type:** `AWS::SageMaker::NotebookInstance`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/sagemaker-notebook-no-direct-internet-access.html](https://docs.aws.amazon.com/config/latest/developerguide/sagemaker-notebook-no-direct-internet-access.html)

**Schedule type:** Periodic

**Parameters:** None

This control checks whether direct internet access is disabled for an SageMaker AI notebook instance. The control fails if the `DirectInternetAccess` field is enabled for the notebook instance. 

If you configure your SageMaker AI instance without a VPC, then by default direct internet access is enabled on your instance. You should configure your instance with a VPC and change the default setting to **Disable—Access the internet through a VPC**. To train or host models from a notebook, you need internet access. To enable internet access, your VPC must have either an interface endpoint (AWS PrivateLink) or a NAT gateway and a security group that allows outbound connections. To learn more about how to connect a notebook instance to resources in a VPC, see [Connect a notebook instance to resources in a VPC](https://docs.aws.amazon.com/sagemaker/latest/dg/appendix-notebook-and-internet-access.html) in the *Amazon SageMaker AI Developer Guide*. You should also ensure that access to your SageMaker AI configuration is limited to only authorized users. Restrict IAM permissions that permit users to change SageMaker AI settings and resources.

### Remediation
<a name="sagemaker-1-remediation"></a>

You can't change the internet access setting after creating a notebook instance. Instead, you can stop, delete, and recreate the instance with blocked internet access. To delete a notebook instance that permits direct internet access, see [Use notebook instances to build models: Clean up](https://docs.aws.amazon.com/sagemaker/latest/dg/ex1-cleanup.html) in the *Amazon SageMaker AI Developer Guide*. To recreate a notebook instance that denies internet access, see [Create a notebook instance](https://docs.aws.amazon.com/sagemaker/latest/dg/howitworks-create-ws.html). For **Network, Direct internet access**, choose **Disable—Access the internet through a VPC**.

## [SageMaker.2] SageMaker notebook instances should be launched in a custom VPC
<a name="sagemaker-2"></a>

**Related requirements:** NIST.800-53.r5 AC-21, NIST.800-53.r5 AC-3, NIST.800-53.r5 AC-3(7), NIST.800-53.r5 AC-4, NIST.800-53.r5 AC-4(21), NIST.800-53.r5 AC-6, NIST.800-53.r5 SC-7, NIST.800-53.r5 SC-7(11), NIST.800-53.r5 SC-7(16), NIST.800-53.r5 SC-7(20), NIST.800-53.r5 SC-7(21), NIST.800-53.r5 SC-7(3), NIST.800-53.r5 SC-7(4), NIST.800-53.r5 SC-7(9)

**Category:** Protect > Secure network configuration > Resources within VPC

**Severity:** High

**Resource type:** `AWS::SageMaker::NotebookInstance`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/sagemaker-notebook-instance-inside-vpc.html](https://docs.aws.amazon.com/config/latest/developerguide/sagemaker-notebook-instance-inside-vpc.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks if an Amazon SageMaker AI notebook instance is launched within a custom virtual private cloud (VPC). This control fails if a SageMaker AI notebook instance is not launched within a custom VPC or if it is launched in the SageMaker AI service VPC.

Subnets are a range of IP addresses within a VPC. We recommend keeping your resources inside a custom VPC whenever possible to ensure secure network protection of your infrastructure. An Amazon VPC is a virtual network dedicated to your AWS account. With an Amazon VPC, you can control the network access and internet connectivity of your SageMaker AI Studio and notebook instances.

### Remediation
<a name="sagemaker-2-remediation"></a>

You can't change the VPC setting after creating a notebook instance. Instead, you can stop, delete, and recreate the instance. For instructions, see [Use notebook instances to build models: Clean up](https://docs.aws.amazon.com/sagemaker/latest/dg/ex1-cleanup.html) in the *Amazon SageMaker AI Developer Guide*.

## [SageMaker.3] Users should not have root access to SageMaker notebook instances
<a name="sagemaker-3"></a>

**Related requirements:** NIST.800-53.r5 AC-2(1), NIST.800-53.r5 AC-3(15), NIST.800-53.r5 AC-3(7), NIST.800-53.r5 AC-6, NIST.800-53.r5 AC-6(10), NIST.800-53.r5 AC-6(2)

**Category:** Protect > Secure access management > Root user access restrictions

**Severity:** High

**Resource type:** `AWS::SageMaker::NotebookInstance`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/sagemaker-notebook-instance-root-access-check.html](https://docs.aws.amazon.com/config/latest/developerguide/sagemaker-notebook-instance-root-access-check.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether root access is turned on for an Amazon SageMaker AI notebook instance. The control fails if root access is turned on for a SageMaker AI notebook instance.

In adherence to the principal of least privilege, it is a recommended security best practice to restrict root access to instance resources to avoid unintentionally over provisioning permissions.

### Remediation
<a name="sagemaker-3-remediation"></a>

To restrict root access to SageMaker AI notebook instances, see [Control root access to a SageMaker AI notebook instance](https://docs.aws.amazon.com/sagemaker/latest/dg/nbi-root-access.html) in the *Amazon SageMaker AI Developer Guide*.

## [SageMaker.4] SageMaker endpoint production variants should have an initial instance count greater than 1
<a name="sagemaker-4"></a>

**Related requirements:** NIST.800-53.r5 CP-10, NIST.800-53.r5 SC-5, NIST.800-53.r5 SC-36, NIST.800-53.r5 SA-13

**Category:** Recover > Resilience > High availability

**Severity:** Medium

**Resource type:** `AWS::SageMaker::EndpointConfig`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/sagemaker-endpoint-config-prod-instance-count.html](https://docs.aws.amazon.com/config/latest/developerguide/sagemaker-endpoint-config-prod-instance-count.html)

**Schedule type:** Periodic

**Parameters:** None

This control checks whether production variants of an Amazon SageMaker AI endpoint have an initial instance count greater than 1. The control fails if the endpoint's production variants have only 1 initial instance.

Production variants running with an instance count greater than 1 permit multi-AZ instance redundancy managed by SageMaker AI. Deploying resources across multiple Availability Zones is an AWS best practice to provide high availability within your architecture. High availability helps you to recover from security incidents.

**Note**  
This control applies only to instance-based endpoint configuration.

### Remediation
<a name="sagemaker-4-remediation"></a>

For more information about the parameters of endpoint configuration, see [Create an endpoint configuration](https://docs.aws.amazon.com/sagemaker/latest/dg/serverless-endpoints-create.html#serverless-endpoints-create-config) in the *Amazon SageMaker AI Developer Guide*.

## [SageMaker.5] SageMaker models should have network isolation enabled
<a name="sagemaker-5"></a>

**Category:** Protect > Secure network configuration > Resources not publicly accessible

**Severity:** Medium

**Resource type:** `AWS::SageMaker::Model`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/sagemaker-model-isolation-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/sagemaker-model-isolation-enabled.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether an Amazon SageMaker AI hosted model has network isolation enabled. The control fails if the `EnableNetworkIsolation` parameter for the hosted model is set to `False`.

SageMaker AI training and deployed inference containers are internet-enabled by default. If you don't want SageMaker AI to provide external network access to your training or inference containers, you can enable network isolation. If you enable network isolation, no inbound or outbound network calls can be made to or from the model container, including calls to or from other AWS services. Additionally, no AWS credentials are made available to the container runtime environment. Enabling network isolation helps prevent unintended access to your SageMaker AI resources from the internet.

**Note**  
On August 13, 2025, Security Hub CSPM changed the title and description of this control. The new title and description more accurately reflect that the control checks the setting for the `EnableNetworkIsolation` parameter of Amazon SageMaker AI hosted models. Previously, the title of this control was: *SageMaker models should block inbound traffic*.

### Remediation
<a name="sagemaker-5-remediation"></a>

For more information about network isolation for SageMaker AI models, see [Run training and inference containers in internet-free mode](https://docs.aws.amazon.com/sagemaker/latest/dg/mkt-algo-model-internet-free.html) in the *Amazon SageMaker AI Developer Guide*. When you create a model, you can enable network isolation by setting the value for the `EnableNetworkIsolation` parameter to `True`.

## [SageMaker.6] SageMaker app image configurations should be tagged
<a name="sagemaker-6"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::SageMaker::AppImageConfig`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/sagemaker-app-image-config-tagged.html](https://docs.aws.amazon.com/config/latest/developerguide/sagemaker-app-image-config-tagged.html)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
| requiredKeyTags | A list of non-system tag keys that must be assigned to an evaluated resource. Tag keys are case sensitive. | StringList (maximum of 6 items) | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions). | No default value | 

This control checks whether an Amazon SageMaker AI app image configuration (`AppImageConfig`) has the tag keys specified by the `requiredKeyTags` parameter. The control fails if the app image configuration doesn't have any tag keys, or it doesn't have all the keys specified by the `requiredKeyTags` parameter. If you don't specify any values for the `requiredKeyTags` parameter, the control checks only for the existence of a tag key and fails if the app image configuration doesn't have any tag keys. The control ignores system tags, which are applied automatically and have the `aws:` prefix.

A tag is a label that you create and assign to an AWS resource. Each tag consists of a required tag key and an optional tag value. You can use tags to categorize resources by purpose, owner, environment, or other criteria. They can help you identify, organize, search for, and filter resources. They can also help you track resource owners for actions and notifications. You can also use tags to implement attribute-based access control (ABAC) as an authorization strategy. For more information about ABAC strategies, see [Define permissions based on attributes with ABAC authorization](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*. For more information about tags, see the [Tagging AWS Resources and Tag Editor User Guide](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html).

**Note**  
Do not store personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible from many AWS services. They aren't intended to be used for private or sensitive data.

### Remediation
<a name="sagemaker-6-remediation"></a>

To add tags to an Amazon SageMaker AI app image configuration (`AppImageConfig`), you can use the [AddTags](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_AddTags.html) operation of the SageMaker AI API or, if you're using the AWS CLI, run the [add-tags](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/add-tags.html) command.

## [SageMaker.7] SageMaker images should be tagged
<a name="sagemaker-7"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::SageMaker::Image`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/sagemaker-image-tagged.html](https://docs.aws.amazon.com/config/latest/developerguide/sagemaker-image-tagged.html)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
| requiredKeyTags | A list of non-system tag keys that must be assigned to an evaluated resource. Tag keys are case sensitive. | StringList (maximum of 6 items) | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions). | No default value | 

This control checks whether an Amazon SageMaker AI image has the tag keys specified by the `requiredKeyTags` parameter. The control fails if the image doesn't have any tag keys, or it doesn't have all the keys specified by the `requiredKeyTags` parameter. If you don't specify any values for the `requiredKeyTags` parameter, the control checks only for the existence of a tag key and fails if the image doesn't have any tag keys. The control ignores system tags, which are applied automatically and have the `aws:` prefix.

A tag is a label that you create and assign to an AWS resource. Each tag consists of a required tag key and an optional tag value. You can use tags to categorize resources by purpose, owner, environment, or other criteria. They can help you identify, organize, search for, and filter resources. They can also help you track resource owners for actions and notifications. You can also use tags to implement attribute-based access control (ABAC) as an authorization strategy. For more information about ABAC strategies, see [Define permissions based on attributes with ABAC authorization](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*. For more information about tags, see the [Tagging AWS Resources and Tag Editor User Guide](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html).

**Note**  
Do not store personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible from many AWS services. They aren't intended to be used for private or sensitive data.

### Remediation
<a name="sagemaker-7-remediation"></a>

To add tags to an Amazon SageMaker AI image, you can use the [AddTags](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_AddTags.html) operation of the SageMaker AI API or, if you're using the AWS CLI, run the [add-tags](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/add-tags.html) command.

## [SageMaker.8] SageMaker notebook instances should run on supported platforms
<a name="sagemaker-8"></a>

**Category:** Detect > Vulnerability, patch, and version management

**Severity:** Medium

**Resource type:** `AWS::SageMaker::NotebookInstance`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/sagemaker-notebook-instance-platform-version.html](https://docs.aws.amazon.com/config/latest/developerguide/sagemaker-notebook-instance-platform-version.html)

**Schedule type:** Periodic

**Parameters:**
+ `supportedPlatformIdentifierVersions`: `notebook-al2-v3` (not customizable)

This control checks whether an Amazon SageMaker AI notebook instance is configured to run on a supported platform, based on the platform identifier specified for the notebook instance. The control fails if the notebook instance is configured to run on a platform that's no longer supported.

If the platform for an Amazon SageMaker AI notebook instance is no longer supported, it might not receive security patches, bug fixes, or other types of updates. Notebook instances might continue to function, but they won't receive SageMaker AI security updates or critical bug fixes. You assume the risks associated with using an unsupported platform. For more information, see [JupyterLab versioning](https://docs.aws.amazon.com/sagemaker/latest/dg/nbi-jl.html) in the *Amazon SageMaker AI Developer Guide*.

### Remediation
<a name="sagemaker-8-remediation"></a>

For information about the platforms that Amazon SageMaker AI currently supports and how to migrate to them, see [Amazon Linux 2 notebook instances](https://docs.aws.amazon.com/sagemaker/latest/dg/nbi-al2.html) in the *Amazon SageMaker AI Developer Guide*.

## [SageMaker.9] SageMaker data quality job definitions should have inter-container traffic encryption enabled
<a name="sagemaker-9"></a>

**Category:** Protect > Data Protection > Encryption of data-in-transit

**Severity:** Medium

**Resource type:** `AWS::SageMaker::DataQualityJobDefinition`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/sagemaker-data-quality-job-encrypt-in-transit.html](https://docs.aws.amazon.com/config/latest/developerguide/sagemaker-data-quality-job-encrypt-in-transit.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether an Amazon SageMaker AI data quality job definition has encryption enabled for inter-container traffic. The control fails if the definition for a job that monitors data quality and drift does not have encryption enabled for inter-container traffic.

Enabling inter-container traffic encryption protects sensitive ML data during distributed processing for data quality analysis. 

### Remediation
<a name="sagemaker-9-remediation"></a>

For more information about inter-container traffic encryption for Amazon SageMaker AI, see [Protect Communications Between ML Compute Instances in a Distributed Training Job](https://docs.aws.amazon.com/sagemaker/latest/dg/train-encrypt.html) in the *Amazon SageMaker AI Developer Guide*. When you create a data quality job definition, you can enable inter-container traffic encryption by setting the value for the `EnableInterContainerTrafficEncryption` parameter to `True`.

## [SageMaker.10] SageMaker model explainability job definitions should have inter-container traffic encryption enabled
<a name="sagemaker-10"></a>

**Category:** Protect > Data Protection > Encryption of data-in-transit

**Severity:** Medium

**Resource type:** `AWS::SageMaker::ModelExplainabilityJobDefinition`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/sagemaker-model-explainability-job-encrypt-in-transit.html](https://docs.aws.amazon.com/config/latest/developerguide/sagemaker-model-explainability-job-encrypt-in-transit.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether an Amazon SageMaker model explainability job definition has inter-container traffic encryption enabled. The control fails if the model explainability job definition does not have inter-container traffic encryption enabled.

Enabling inter-container traffic encryption protects sensitive ML data such as model data, training datasets, intermediate processing results, parameters and model weights during distributed processing for explainability analysis. 

### Remediation
<a name="sagemaker-10-remediation"></a>

For an existing SageMaker model explainability job definition, inter-container traffic encryption cannot be updated in place. To create a new SageMaker model explainability job definition with inter-container traffic encryption enabled, use [API](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_CreateModelExplainabilityJobDefinition.html) or [CLI](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/create-model-explainability-job-definition.html) or [ CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/aws-resource-sagemaker-modelexplainabilityjobdefinition.html) and set [https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_MonitoringNetworkConfig.html#API_MonitoringNetworkConfig_Contents](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_MonitoringNetworkConfig.html#API_MonitoringNetworkConfig_Contents) to `True`.

## [SageMaker.11] SageMaker data quality job definitions should have network isolation enabled
<a name="sagemaker-11"></a>

**Category:** Protect > Secure network configuration

**Severity:** Medium

**Resource type:** `AWS::SageMaker::DataQualityJobDefinition`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/sagemaker-data-quality-job-isolation.html](https://docs.aws.amazon.com/config/latest/developerguide/sagemaker-data-quality-job-isolation.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether an Amazon SageMaker AI data quality monitoring job definition has network isolation enabled. The control fails if the definition for a job that monitors data quality and drift has network isolation disabled.

Network isolation reduces the attack. surface and prevents external access thereby protecting against unauthorized external access, accidental data exposure and potential data exfiltration. 

### Remediation
<a name="sagemaker-11-remediation"></a>

For more information about network isolation for SageMaker AI, see [Run training and inference containers in internet-free mode](https://docs.aws.amazon.com/sagemaker/latest/dg/mkt-algo-model-internet-free.html) in the *Amazon SageMaker AI Developer Guide*. When you create a data quality job definition, you can enable network isolation by setting the value for the `EnableNetworkIsolation` parameter to `True`.

## [SageMaker.12] SageMaker model bias job definitions should have network isolation enabled
<a name="sagemaker-12"></a>

**Category:** Protect > Secure network configuration > Resources policy configuration

**Severity:** Medium

**Resource type:** `AWS::SageMaker::ModelBiasJobDefinition`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/sagemaker-model-bias-job-isolation.html](https://docs.aws.amazon.com/config/latest/developerguide/sagemaker-model-bias-job-isolation.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether a SageMaker model bias job definition has network isolation enabled. The control fails if model bias job definition does not have network isolation enabled.

Network isolation prevents SageMaker model bias jobs from communicating with external resources over the internet. By enabling network isolation, you ensure that the job's containers cannot make outbound connections, reducing the attack surface and protecting sensitive data from exfiltration. This is particularly important for jobs processing regulated or sensitive data.

### Remediation
<a name="sagemaker-12-remediation"></a>

To enable network isolation, you must create a new model bias job definition with `EnableNetworkIsolation` parameter set to `True`. Network isolation cannot be modified after job definition creation. To create a new model bias job definition, see [ CreateModelBiasJobDefinition](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_CreateModelBiasJobDefinition.html) in the *Amazon SageMaker AI Developer Guide*. 

## [SageMaker.13] SageMaker model quality job definitions should have inter-container traffic encryption enabled
<a name="sagemaker-13"></a>

**Category:** Protect > Data Protection > Encryption of data-in-transit

**Severity:** Medium

**Resource type:** `AWS::SageMaker::ModelQualityJobDefinition`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/sagemaker-model-quality-job-encrypt-in-transit.html](https://docs.aws.amazon.com/config/latest/developerguide/sagemaker-model-quality-job-encrypt-in-transit.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether Amazon SageMaker model quality job definitions have encryption in transit enabled for inter-container traffic. The control fails if a model quality job definition does not have inter-container traffic encryption enabled.

Inter-container traffic encryption protects data transmitted between containers during distributed model quality monitoring jobs. By default, inter-container traffic is unencrypted. Enabling encryption helps maintain data confidentiality during processing and supports compliance with regulatory requirements for data in transit protection.

### Remediation
<a name="sagemaker-13-remediation"></a>

To enable inter-container traffic encryption for your Amazon SageMaker model quality job definition, you must re-create the job definition with the appropriate in-transit encryption configuration. To create a model quality job definition, see [ CreateModelQualityJobDefinition](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_CreateModelQualityJobDefinition.html) in the *Amazon SageMaker AI Developer Guide*. 

## [SageMaker.14] SageMaker monitoring schedules should have network isolation enabled
<a name="sagemaker-14"></a>

**Category:** Protect > Secure network configuration

**Severity:** Medium

**Resource type:** `AWS::SageMaker::MonitoringSchedule`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/sagemaker-monitoring-schedule-isolation.html](https://docs.aws.amazon.com/config/latest/developerguide/sagemaker-monitoring-schedule-isolation.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether Amazon SageMaker monitoring schedules have network isolation enabled. The control fails if a monitoring schedule has EnableNetworkIsolation set to false or not configured

Network isolation prevents monitoring jobs from making outbound network calls, reducing the attack surface by eliminating internet access from containers.

### Remediation
<a name="sagemaker-14-remediation"></a>

For information about configuring network isolation in the NetworkConfig parameter when creating or updating a monitoring schedule, see [CreateMonitoringSchedule](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_CreateMonitoringSchedule.html) or [ UpdateMonitoringSchedule](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_UpdateMonitoringSchedule.html) in the *Amazon SageMaker AI Developer Guide*.

## [SageMaker.15] SageMaker model bias job definitions should have inter-container traffic encryption enabled
<a name="sagemaker-15"></a>

**Category:** Protect > Data Protection > Encryption of data-in-transit

**Severity:** Medium

**Resource type:** `AWS::SageMaker::ModelBiasJobDefinition`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/sagemaker-model-bias-job-encrypt-in-transit.html](https://docs.aws.amazon.com/config/latest/developerguide/sagemaker-model-bias-job-encrypt-in-transit.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether Amazon SageMaker model bias job definitions have inter-container traffic encryption enabled when using multiple compute instances. The control fails if `EnableInterContainerTrafficEncryption` is set to false or is not configured for job definitions with an instance count of 2 or greater.

EInter-container traffic encryption protects data transmitted between compute instances during distributed model bias monitoring jobs. Encryption prevents unauthorized access to model-related information such as weights that are transmitted between instances.

### Remediation
<a name="sagemaker-15-remediation"></a>

To enable inter-container traffic encryption for SageMaker model bias job definitions, set the `EnableInterContainerTrafficEncryption` parameter to `True` when the job definition uses multiple compute instances. For information about protecting communications between ML compute instances, see [Protect Communications Between ML Compute Instances in a Distributed Training Job](https://docs.aws.amazon.com/sagemaker/latest/dg/train-encrypt.html) in the *Amazon SageMaker AI Developer Guide*. 

## [SageMaker.16] SageMaker models should use private registry in VPC for primary containers
<a name="sagemaker-16"></a>

**Category:** Protect > Secure network configuration > Resources within VPC

**Severity:** Medium

**Resource type:** `AWS::SageMaker::Model`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/sagemaker-model-private-registry-required.html](https://docs.aws.amazon.com/config/latest/developerguide/sagemaker-model-private-registry-required.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether an Amazon SageMaker AI model pulls container image from a private registry in a VPC for the primary container. The control fails if the image is not configured or repository access mode is `Platform`.

Using a private Docker registry in a VPC for SageMaker model containers ensures container images are pulled from trusted, controlled sources within your VPC. Also, it ensures container images are accessed through VPC endpoints, without traversing the public internet.

### Remediation
<a name="sagemaker-16-remediation"></a>

To configure private docker registries for SageMaker AI real-time inference containers, see [Use a Private Docker Registry for Real-Time Inference Containers](https://docs.aws.amazon.com/sagemaker/latest/dg/your-algorithms-containers-inference-private.html) in the *Amazon SageMaker AI Developer Guide*.

## [SageMaker.17] SageMaker feature group offline stores should be encrypted with AWS KMS keys
<a name="sagemaker-17"></a>

**Category:** Protect > Data Protection > Encryption of data-at-rest

**Severity:** Medium

**Resource type:** `AWS::SageMaker::FeatureGroup`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/sagemaker-featuregroup-encryption-at-rest.html](https://docs.aws.amazon.com/config/latest/developerguide/sagemaker-featuregroup-encryption-at-rest.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether an Amazon SageMaker offline store for a feature group is encrypted at rest with an AWS KMS key. The control fails if the offline store S3 storage for a feature group is not encrypted with a KMS key.

Using customer-managed AWS KMS keys for encryption at rest of SageMaker feature group offline stores provide enhanced security. Customer-managed KMS keys provide you full control over encryption key lifecycle and key policies. Additionally, all encryption key usage can be logged and monitored through AWS CloudTrail for auditability.

### Remediation
<a name="sagemaker-17-remediation"></a>

For information on enabling encryption at rest for SageMaker Feature Store offline stores using AWS KMS customer-managed keys, see [Security and access control](https://docs.aws.amazon.com/sagemaker/latest/dg/feature-store-security.html#feature-store-authorizing-use-cmk-offline-store) in the *Amazon SageMaker AI Developer Guide*.

# Security Hub CSPM controls for Secrets Manager
<a name="secretsmanager-controls"></a>

These AWS Security Hub CSPM controls evaluate the AWS Secrets Manager service and resources.

These controls may not be available in all AWS Regions. For more information, see [Availability of controls by Region](securityhub-regions.md#securityhub-regions-control-support).

## [SecretsManager.1] Secrets Manager secrets should have automatic rotation enabled
<a name="secretsmanager-1"></a>

**Related requirements:** NIST.800-53.r5 AC-2(1), NIST.800-53.r5 AC-3(15), PCI DSS v4.0.1/8.6.3, PCI DSS v4.0.1/8.3.9

**Category:** Protect > Secure development

**Severity:** Medium

**Resource type:** `AWS::SecretsManager::Secret`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/secretsmanager-rotation-enabled-check.html](https://docs.aws.amazon.com/config/latest/developerguide/secretsmanager-rotation-enabled-check.html)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  `maximumAllowedRotationFrequency`  |  Maximum number of days allowed for secret rotation frequency  |  Integer  |  `1` to `365`  |  No default value  | 

This control checks whether a secret stored in AWS Secrets Manager is configured with automatic rotation. The control fails if the secret isn't configured with automatic rotation. If you provide a custom value for the `maximumAllowedRotationFrequency` parameter, the control passes only if the secret is automatically rotated within the specified window of time.

Secrets Manager helps you improve the security posture of your organization. Secrets include database credentials, passwords, and third-party API keys. You can use Secrets Manager to store secrets centrally, encrypt secrets automatically, control access to secrets, and rotate secrets safely and automatically.

Secrets Manager can rotate secrets. You can use rotation to replace long-term secrets with short-term ones. Rotating your secrets limits how long an unauthorized user can use a compromised secret. For this reason, you should rotate your secrets frequently. To learn more about rotation, see [Rotating your AWS Secrets Manager secrets](https://docs.aws.amazon.com/secretsmanager/latest/userguide/rotating-secrets.html) in the *AWS Secrets Manager User Guide*.

### Remediation
<a name="secretsmanager-1-remediation"></a>

To turn on automatic rotation for Secrets Manager secrets, see [Set up automatic rotation for AWS Secrets Manager secrets using the console](https://docs.aws.amazon.com/secretsmanager/latest/userguide/rotate-secrets_turn-on-for-other.html) in the *AWS Secrets Manager User Guide*. You must choose and configure an AWS Lambda function for rotation.

## [SecretsManager.2] Secrets Manager secrets configured with automatic rotation should rotate successfully
<a name="secretsmanager-2"></a>

**Related requirements:** NIST.800-53.r5 AC-2(1), NIST.800-53.r5 AC-3(15), PCI DSS v4.0.1/8.6.3, PCI DSS v4.0.1/8.3.9

**Category:** Protect > Secure development

**Severity:** Medium

**Resource type:** `AWS::SecretsManager::Secret`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/secretsmanager-scheduled-rotation-success-check.html](https://docs.aws.amazon.com/config/latest/developerguide/secretsmanager-scheduled-rotation-success-check.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether an AWS Secrets Manager secret rotated successfully based on the rotation schedule. The control fails if `RotationOccurringAsScheduled` is `false`. The control only evaluates secrets that have rotation turned on.

Secrets Manager helps you improve the security posture of your organization. Secrets include database credentials, passwords, and third-party API keys. You can use Secrets Manager to store secrets centrally, encrypt secrets automatically, control access to secrets, and rotate secrets safely and automatically.

Secrets Manager can rotate secrets. You can use rotation to replace long-term secrets with short-term ones. Rotating your secrets limits how long an unauthorized user can use a compromised secret. For this reason, you should rotate your secrets frequently.

In addition to configuring secrets to rotate automatically, you should ensure that those secrets rotate successfully based on the rotation schedule.

To learn more about rotation, see [Rotating your AWS Secrets Manager secrets](https://docs.aws.amazon.com/secretsmanager/latest/userguide/rotating-secrets.html) in the *AWS Secrets Manager User Guide*.

### Remediation
<a name="secretsmanager-2-remediation"></a>

If the automatic rotation fails, then Secrets Manager might have encountered errors with the configuration. To rotate secrets in Secrets Manager, you use a Lambda function that defines how to interact with the database or service that owns the secret.

For help diagnosing and fixing common errors related to secrets rotation, see [Troubleshooting AWS Secrets Manager rotation of secrets](https://docs.aws.amazon.com/secretsmanager/latest/userguide/troubleshoot_rotation.html) in the *AWS Secrets Manager User Guide*.

## [SecretsManager.3] Remove unused Secrets Manager secrets
<a name="secretsmanager-3"></a>

**Related requirements:** NIST.800-53.r5 AC-2(1), NIST.800-53.r5 AC-3(15)

**Category:** Protect > Secure access management

**Severity:** Medium

**Resource type:** `AWS::SecretsManager::Secret`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/secretsmanager-secret-unused.html](https://docs.aws.amazon.com/config/latest/developerguide/secretsmanager-secret-unused.html)

**Schedule type:** Periodic

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  `unusedForDays`  |  Maximum number of days that a secret can remain unused  |  Integer  |  `1` to `365`  |  `90`  | 

This control checks whether an AWS Secrets Manager secret has been accessed within the specified time frame. The control fails if a secret is unused beyond the specified time frame. Unless you provide a custom parameter value for the access period, Security Hub CSPM uses a default value of 90 days.

Deleting unused secrets is as important as rotating secrets. Unused secrets can be abused by their former users, who no longer need access to these secrets. Also, as more users get access to a secret, someone might have mishandled and leaked it to an unauthorized entity, which increases the risk of abuse. Deleting unused secrets helps revoke secret access from users who no longer need it. It also helps to reduce the cost of using Secrets Manager. Therefore, it is essential to routinely delete unused secrets.

### Remediation
<a name="secretsmanager-3-remediation"></a>

To delete inactive Secrets Manager secrets, see [Delete an AWS Secrets Manager secret](https://docs.aws.amazon.com/secretsmanager/latest/userguide/manage_delete-secret.html) in the *AWS Secrets Manager User Guide*.

## [SecretsManager.4] Secrets Manager secrets should be rotated within a specified number of days
<a name="secretsmanager-4"></a>

**Related requirements:** NIST.800-53.r5 AC-2(1), NIST.800-53.r5 AC-3(15), PCI DSS v4.0.1/8.6.3, PCI DSS v4.0.1/8.3.9

**Category:** Protect > Secure access management

**Severity:** Medium

**Resource type:** `AWS::SecretsManager::Secret`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/secretsmanager-secret-periodic-rotation.html](https://docs.aws.amazon.com/config/latest/developerguide/secretsmanager-secret-periodic-rotation.html)

**Schedule type:** Periodic

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  `maxDaysSinceRotation`  |  Maximum number of days that a secret can remain unchanged  |  Integer  |  `1` to `180`  |  `90`  | 

This control checks whether an AWS Secrets Manager secret is rotated at least once within the specified time frame. The control fails if a secret isn't rotated at least this frequently. Unless you provide a custom parameter value for the rotation period, Security Hub CSPM uses a default value of 90 days.

Rotating secrets can help you to reduce the risk of an unauthorized use of your secrets in your AWS account. Examples include database credentials, passwords, third-party API keys, and even arbitrary text. If you do not change your secrets for a long period of time, the secrets are more likely to be compromised.

As more users get access to a secret, it can become more likely that someone mishandled and leaked it to an unauthorized entity. Secrets can be leaked through logs and cache data. They can be shared for debugging purposes and not changed or revoked once the debugging completes. For all these reasons, secrets should be rotated frequently.

You can configure automatic rotation for secrets in AWS Secrets Manager. With automatic rotation, you can replace long-term secrets with short-term ones, significantly reducing the risk of compromise. We recommend that you configure automatic rotation for your Secrets Manager secrets. For more information, see [Rotating your AWS Secrets Manager secrets](https://docs.aws.amazon.com/secretsmanager/latest/userguide/rotating-secrets.html) in the *AWS Secrets Manager User Guide*. 

### Remediation
<a name="secretsmanager-4-remediation"></a>

To turn on automatic rotation for Secrets Manager secrets, see [Set up automatic rotation for AWS Secrets Manager secrets using the console](https://docs.aws.amazon.com/secretsmanager/latest/userguide/rotate-secrets_turn-on-for-other.html) in the *AWS Secrets Manager User Guide*. You must choose and configure an AWS Lambda function for rotation.

## [SecretsManager.5] Secrets Manager secrets should be tagged
<a name="secretsmanager-5"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::SecretsManager::Secret`

**AWS Config rule:** `tagged-secretsmanager-secret` (custom Security Hub CSPM rule)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  |  No default value  | 

This control checks whether an AWS Secrets Manager secret has tags with the specific keys defined in the parameter `requiredTagKeys`. The control fails if the secret doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredTagKeys`. If the parameter `requiredTagKeys` isn't provided, the control only checks for the existence of a tag key and fails if the secret isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [What is ABAC for AWS?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Tagging your AWS resources](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *AWS General Reference*.

### Remediation
<a name="secretsmanager-5-remediation"></a>

To add tags to a Secrets Manager secret, see [Tag AWS Secrets Manager secrets](https://docs.aws.amazon.com/secretsmanager/latest/userguide/managing-secrets_tagging.html) in the *AWS Secrets Manager User Guide*.

# Security Hub CSPM controls for AWS Service Catalog
<a name="servicecatalog-controls"></a>

This AWS Security Hub CSPM control evaluates the AWS Service Catalog service and resources. The control might not be available in all AWS Regions. For more information, see [Availability of controls by Region](securityhub-regions.md#securityhub-regions-control-support).

## [ServiceCatalog.1] Service Catalog portfolios should be shared within an AWS organization only
<a name="servicecatalog-1"></a>

**Related requirements:** NIST.800-53.r5 AC-3, NIST.800-53.r5 AC-4, NIST.800-53.r5 AC-6, NIST.800-53.r5 CM-8, NIST.800-53.r5 SC-7

**Category:** Protect > Secure access management

**Severity:** Medium

**Resource type:** `AWS::ServiceCatalog::Portfolio`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/service-catalog-shared-within-organization.html](https://docs.aws.amazon.com/config/latest/developerguide/service-catalog-shared-within-organization.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether AWS Service Catalog shares portfolios within an organization when the integration with AWS Organizations is enabled. The control fails if portfolios aren't shared within an organization.

Portfolio sharing only within Organizations helps ensure that a portfolio isn't shared with incorrect AWS accounts. To share a Service Catalog portfolio with an account in an organization, Security Hub CSPM recommends using `ORGANIZATION_MEMBER_ACCOUNT` instead of `ACCOUNT`. This simplifies administration by governing the access granted to the account across the organization. If you have a business need to share Service Catalog portfolios with an external account, you can [automatically suppress the findings](automation-rules.md) from this control or [disable it](disable-controls-overview.md).

### Remediation
<a name="servicecatalog-1-remediation"></a>

To enable portfolio sharing with AWS Organizations, see [Sharing with AWS Organizations](https://docs.aws.amazon.com/servicecatalog/latest/adminguide/catalogs_portfolios_sharing_how-to-share.html#portfolio-sharing-organizations) in the *AWS Service Catalog Administrator Guide*.

# Security Hub CSPM controls for Amazon SES
<a name="ses-controls"></a>

These AWS Security Hub CSPM controls evaluate the Amazon Simple Email Service (Amazon SES) service and resources.

These controls may not be available in all AWS Regions. For more information, see [Availability of controls by Region](securityhub-regions.md#securityhub-regions-control-support).

## [SES.1] SES contact lists should be tagged
<a name="ses-1"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::SES::ContactList`

**AWS Configrule:** `tagged-ses-contactlist` (custom Security Hub CSPM rule)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  | No default value  | 

This control checks whether an Amazon SES contact list has tags with the specific keys defined in the parameter `requiredTagKeys`. The control fails if the contact list doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredTagKeys`. If the parameter `requiredTagKeys` isn't provided, the control only checks for the existence of a tag key and fails if the contact list isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [What is ABAC for AWS?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Tagging your AWS resources](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *AWS General Reference*.

### Remediation
<a name="ses-1-remediation"></a>

To add tags to an Amazon SES contact list, see [TagResource](https://docs.aws.amazon.com/ses/latest/APIReference-V2/API_TagResource.html) in the *Amazon SES API v2 Reference*.

## [SES.2] SES configuration sets should be tagged
<a name="ses-2"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::SES::ConfigurationSet`

**AWS Configrule:** `tagged-ses-configurationset` (custom Security Hub CSPM rule)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  | No default value  | 

This control checks whether an Amazon SES configuration set has tags with the specific keys defined in the parameter `requiredTagKeys`. The control fails if the configuration set doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredTagKeys`. If the parameter `requiredTagKeys` isn't provided, the control only checks for the existence of a tag key and fails if the configuration set isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [What is ABAC for AWS?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Tagging your AWS resources](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *AWS General Reference*.

### Remediation
<a name="ses-2-remediation"></a>

To add tags to an Amazon SES configuration set, see [TagResource](https://docs.aws.amazon.com/ses/latest/APIReference-V2/API_TagResource.html) in the *Amazon SES API v2 Reference*.

## [SES.3] SES configuration sets should have TLS enabled for sending emails
<a name="ses-3"></a>

**Category:** Protect > Data Protection > Encryption of data-in-transit 

**Severity:** Medium

**Resource type:** `AWS::SES::ConfigurationSet`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/ses-sending-tls-required.html](https://docs.aws.amazon.com/config/latest/developerguide/ses-sending-tls-required.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether an Amazon SES configuration set requires TLS connections. The control fails if the TLS Policy is not set to `'REQUIRE'` for a configuration set.

By default, Amazon SES uses opportunistic TLS, which means emails can be sent unencrypted if a TLS connection cannot be established with the receiving mail server. Enforcing TLS for email sending ensures that messages are only delivered when a secure encrypted connection can be established. This helps protect the confidentiality and integrity of email content during transmission between Amazon SES and the recipient's mail server. If a secure TLS connection cannot be established, the message will not be delivered, preventing potential exposure of sensitive information.

**Note**  
While TLS 1.3 is the default delivery method for Amazon SES, without enforcing TLS requirement through configuration sets, messages could potentially be delivered in plaintext if a TLS connection fails. To pass this control, you must configure the TLS Policy to `'REQUIRE'` in your SES configuration set's delivery options. When TLS is required, messages are only delivered if a TLS connection can be established with the receiving mail server.

### Remediation
<a name="ses-3-remediation"></a>

To configure Amazon SES to require TLS connections for a configuration set, see [Amazon SES and security protocols](https://docs.aws.amazon.com/ses/latest/dg/security-protocols.html#security-ses-to-receiver) in the *Amazon SES Developer Guide*.

# Security Hub CSPM controls for Amazon SNS
<a name="sns-controls"></a>

These AWS Security Hub CSPM controls evaluate the Amazon Simple Notification Service (Amazon SNS) service and resources. The controls might not be available in all AWS Regions. For more information, see [Availability of controls by Region](securityhub-regions.md#securityhub-regions-control-support).

## [SNS.1] SNS topics should be encrypted at-rest using AWS KMS
<a name="sns-1"></a>

**Related requirements:** NIST.800-53.r5 CA-9(1), NIST.800-53.r5 CM-3(6), NIST.800-53.r5 SC-13, NIST.800-53.r5 SC-28, NIST.800-53.r5 SC-28(1), NIST.800-53.r5 SC-7(10), NIST.800-53.r5 SI-7(6), NIST.800-171.r2 3.13.11, NIST.800-171.r2 3.13.16

**Category:** Protect > Data Protection > Encryption of data-at-rest

**Severity:** Medium

**Resource type:** `AWS::SNS::Topic`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/sns-encrypted-kms.html](https://docs.aws.amazon.com/config/latest/developerguide/sns-encrypted-kms.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether an Amazon SNS topic is encrypted at rest using keys managed in AWS Key Management Service (AWS KMS). The controls fails if the SNS topic doesn't use a KMS key for server-side encryption (SSE). By default, SNS stores messages and files using disk encryption. To pass this control, you must choose to use a KMS key for encryption instead. This adds an additional layer of security and provides more access control flexibility.

Encrypting data at rest reduces the risk of data stored on disk being accessed by a user not authenticated to AWS. API permissions are required to decrypt the data before it can be read. We recommend encrypting SNS topics with KMS keys for an added layer of security.

### Remediation
<a name="sns-1-remediation"></a>

To enable SSE for an SNS topic, see [Enabling server-side encryption (SSE) for an Amazon SNS topic](https://docs.aws.amazon.com/sns/latest/dg/sns-enable-encryption-for-topic.html) in the *Amazon Simple Notification Service Developer Guide*. Before you can use SSE, you must also configure AWS KMS key policies to allow encryption of topics and encryption and decryption of messages. For more information, see [Configuring AWS KMS permissions](https://docs.aws.amazon.com/sns/latest/dg/sns-key-management.html#sns-what-permissions-for-sse) in the *Amazon Simple Notification Service Developer Guide*.

## [SNS.2] Logging of delivery status should be enabled for notification messages sent to a topic
<a name="sns-2"></a>

**Important**  
Security Hub CSPM retired this control in April 2024. For more information, see [Change log for Security Hub CSPM controls](controls-change-log.md).

**Related requirements:** NIST.800-53.r5 AU-12, NIST.800-53.r5 AU-2

**Category:** Identify > Logging

**Severity:** Medium

**Resource type:** `AWS::SNS::Topic`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/sns-topic-message-delivery-notification-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/sns-topic-message-delivery-notification-enabled.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether logging is enabled for the delivery status of notification messages sent to an Amazon SNS topic for the endpoints. This control fails if the delivery status notification for messages is not enabled.

Logging is an important part of maintaining the reliability, availability, and performance of services. Logging message delivery status helps provide operational insights, such as the following:
+ Knowing whether a message was delivered to the Amazon SNS endpoint.
+ Identifying the response sent from the Amazon SNS endpoint to Amazon SNS.
+ Determining the message dwell time (the time between the publish timestamp and the hand off to an Amazon SNS endpoint).

### Remediation
<a name="sns-2-remediation"></a>

To configure delivery status logging for a topic, see [Amazon SNS message delivery status](https://docs.aws.amazon.com/sns/latest/dg/sns-topic-attributes.html) in the *Amazon Simple Notification Service Developer Guide*.

## [SNS.3] SNS topics should be tagged
<a name="sns-3"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::SNS::Topic`

**AWS Config rule:** `tagged-sns-topic` (custom Security Hub CSPM rule)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  |  No default value  | 

This control checks whether an Amazon SNS topic has tags with the specific keys defined in the parameter `requiredTagKeys`. The control fails if the topic doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredTagKeys`. If the parameter `requiredTagKeys` isn't provided, the control only checks for the existence of a tag key and fails if the topic isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [What is ABAC for AWS?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Tagging your AWS resources](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *AWS General Reference*.

### Remediation
<a name="sns-3-remediation"></a>

To add tags to an SNS topic, see [Configuring Amazon SNS topic tags](https://docs.aws.amazon.com/sns/latest/dg/sns-tags-configuring.html) in the *Amazon Simple Notification Service Developer Guide*.

## [SNS.4] SNS topic access policies should not allow public access
<a name="sns-4"></a>

**Category:** Protect > Secure network configuration > Resources not publicly accessible

**Severity:** Critical

**Resource type:** `AWS::SNS::Topic`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/sns-topic-no-public-access.html](https://docs.aws.amazon.com/config/latest/developerguide/sns-topic-no-public-access.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks if the Amazon SNS topic access policy allows public access. This control fails if the SNS topic access policy allows public access.

You use an Amazon SNS access policy with a particular topic to restrict who can work with that topic (for example, who can publish messages to it or who can subscribe to it). SNS policies can grant access to other AWS accounts, or to users within your own AWS account. Providing a wildcard (\$1) in the `Principal` field of the topic policy and a lack of conditions to limit the topic policy can result in data exfiltration, denial of service, or undesired injection of messages into your service by an attacker.

**Note**  
This control doesn't evaluate policy conditions that use wildcard characters or variables. To produce a `PASSED` finding, conditions in the Amazon SNS access policy for a topic must only use fixed values, which are values that don't contain wildcard characters or policy variables. For information about policy variables, see [Variables and tags](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_variables.html) in the *AWS Identity and Access Management User Guide*.

### Remediation
<a name="sns-4-remediation"></a>

To update access policies for an SNS topic, see [Overview of managing access in Amazon SNS](https://docs.aws.amazon.com/sns/latest/dg/sns-overview-of-managing-access.html) in the *Amazon Simple Notification Service Developer Guide*.

# Security Hub CSPM controls for Amazon SQS
<a name="sqs-controls"></a>

These AWS Security Hub CSPM controls evaluate the Amazon Simple Queue Service (Amazon SQS) service and resources. The controls might not be available in all AWS Regions. For more information, see [Availability of controls by Region](securityhub-regions.md#securityhub-regions-control-support).

## [SQS.1] Amazon SQS queues should be encrypted at rest
<a name="sqs-1"></a>

**Related requirements:** NIST.800-53.r5 CA-9(1), NIST.800-53.r5 CM-3(6), NIST.800-53.r5 SC-13, NIST.800-53.r5 SC-28, NIST.800-53.r5 SC-28(1), NIST.800-53.r5 SC-7(10), NIST.800-53.r5 SI-7(6)

**Category:** Protect > Data Protection > Encryption of data-at-rest

**Severity:** Medium

**Resource type:** `AWS::SQS::Queue`

**AWS Config rule:** `sqs-queue-encrypted` (custom Security Hub CSPM rule)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether an Amazon SQS queue is encrypted at rest. The control fails if the queue isn't encrypted with an SQS-managed key (SSE-SQS) or an AWS Key Management Service (AWS KMS) key (SSE-KMS).

Encrypting data at rest reduces the risk of an unauthorized user accessing data stored on disk. Server-side encryption (SSE) protects the contents of messages in SQS queues using SQS-managed encryption keys (SSE-SQS) or AWS KMS keys (SSE-KMS).

### Remediation
<a name="sqs-1-remediation"></a>

To configure SSE for an SQS queue, see [ Configuring server-side encryption (SSE) for a queue (console)](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-configure-sse-existing-queue.html) in the *Amazon Simple Queue Service Developer Guide*.

## [SQS.2] SQS queues should be tagged
<a name="sqs-2"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::SQS::Queue`

**AWS Config rule:** `tagged-sqs-queue` (custom Security Hub CSPM rule)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  |  No default value  | 

This control checks whether an Amazon SQS queue has tags with the specific keys defined in the parameter `requiredTagKeys`. The control fails if the queue doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredTagKeys`. If the parameter `requiredTagKeys` isn't provided, the control only checks for the existence of a tag key and fails if the queue isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [What is ABAC for AWS?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Tagging your AWS resources](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *AWS General Reference*.

### Remediation
<a name="sqs-2-remediation"></a>

To add tags to an existing queue using the Amazon SQS console, see [ Configuring cost allocation tags for an Amazon SQS queue (console)](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-configure-tag-queue.html) in the *Amazon Simple Queue Service Developer Guide*.

## [SQS.3] SQS queue access policies should not allow public access
<a name="sqs-3"></a>

**Category:** Protect > Secure access management > Resource not publicly accessible

**Severity:** Critical

**Resource type:** `AWS::SQS::Queue`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/sqs-queue-no-public-access.html](https://docs.aws.amazon.com/config/latest/developerguide/sqs-queue-no-public-access.html)

**Schedule type:** Change triggered

**Parameters:** None

This controls checks whether an Amazon SQS access policy allows public access to an SQS queue. The control fails if an SQS access policy allows public access to the queue.

An Amazon SQS access policy can allow public access to an SQS queue, which might allow an anonymous user or any authenticated AWS IAM identity to access the queue. SQS access policies typically provide this access by specifying the wildcard character (`*`) in the `Principal` element of the policy, not using proper conditions to restrict access to the queue, or both. If an SQS access policy allows public access, third parties might be able to perform tasks such as receive messages from the queue, send messages to the queue, or modify the access policy for the queue. This could result in events such as data exfiltration, a denial of service, or injection of messages into the queue by a threat actor.

**Note**  
This control doesn't evaluate policy conditions that use wildcard characters or variables. To produce a `PASSED` finding, conditions in the Amazon SQS access policy for a queue must only use fixed values, which are values that don't contain wildcard characters or policy variables. For information about policy variables, see [Variables and tags](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_variables.html) in the *AWS Identity and Access Management User Guide*.

### Remediation
<a name="sqs-3-remediation"></a>

For information about configuring the SQS access policy for an SQS queue, see [Using custom policies with the Amazon SQS Access Policy Language](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-creating-custom-policies.html) in the *Amazon Simple Queue Service Developer Guide*.

# Security Hub CSPM controls for Step Functions
<a name="stepfunctions-controls"></a>

These AWS Security Hub CSPM controls evaluate the AWS Step Functions service and resources.

These controls may not be available in all AWS Regions. For more information, see [Availability of controls by Region](securityhub-regions.md#securityhub-regions-control-support).

## [StepFunctions.1] Step Functions state machines should have logging turned on
<a name="stepfunctions-1"></a>

**Related requirements:** PCI DSS v4.0.1/10.4.2

**Category:** Identify > Logging

**Severity:** Medium

**Resource type:** `AWS::StepFunctions::StateMachine`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/step-functions-state-machine-logging-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/step-functions-state-machine-logging-enabled.html)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  `logLevel`  |  Minimum logging level  |  Enum  |  `ALL, ERROR, FATAL`  |  No default value  | 

This controls checks whether an AWS Step Functions state machine has logging turned on. The control fails if a state machine doesn't have logging turned on. If you provide a custom value for the `logLevel` parameter, the control passes only if the state machine has the specified logging level turned on.

Monitoring helps you maintain the reliability, availability, and performance of Step Functions. You should collect as much monitoring data from the AWS services that you use so you can more easily debug multi-point failures. Having a logging configuration defined for your Step Functions state machines allows for you to track execution history and results in Amazon CloudWatch Logs. Optionally, you can track only errors or fatal events.

### Remediation
<a name="stepfunctions-1-remediation"></a>

To turn on logging for a Step Functions state machine, see [Configure logging](https://docs.aws.amazon.com/step-functions/latest/dg/cw-logs.html#monitoring-logging-configure) in the *AWS Step Functions Developer Guide*.

## [StepFunctions.2] Step Functions activities should be tagged
<a name="stepfunctions-2"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::StepFunctions::Activity`

**AWS Config rule:**`tagged-stepfunctions-activity` (custom Security Hub CSPM rule)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  | No default value  | 

This control checks whether an AWS Step Functions activity has tags with the specific keys defined in the parameter `requiredTagKeys`. The control fails if the activity doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredTagKeys`. If the parameter `requiredTagKeys` isn't provided, the control only checks for the existence of a tag key and fails if the activity isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [What is ABAC for AWS?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Tagging your AWS resources](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *AWS General Reference*.

### Remediation
<a name="stepfunctions-2-remediation"></a>

To add tags to an Step Functions activity, see [Tagging in Step Functions](https://docs.aws.amazon.com/step-functions/latest/dg/concepts-tagging.html) in the *AWS Step Functions Developer Guide*.

# Security Hub CSPM controls for Systems Manager
<a name="ssm-controls"></a>

These AWS Security Hub CSPM controls evaluate the AWS Systems Manager (SSM) service and resources. The controls might not be available in all AWS Regions. For more information, see [Availability of controls by Region](securityhub-regions.md#securityhub-regions-control-support).

## [SSM.1] Amazon EC2 instances should be managed by AWS Systems Manager
<a name="ssm-1"></a>

**Related requirements:** PCI DSS v3.2.1/2.4, NIST.800-53.r5 CA-9(1), NIST.800-53.r5 CM-2, NIST.800-53.r5 CM-2(2), NIST.800-53.r5 CM-8, NIST.800-53.r5 CM-8(1), NIST.800-53.r5 CM-8(2), NIST.800-53.r5 CM-8(3), NIST.800-53.r5 SA-15(2), NIST.800-53.r5 SA-15(8), NIST.800-53.r5 SA-3, NIST.800-53.r5 SI-2(3)

**Category:** Identify > Inventory

**Severity:** Medium

**Evaluated resource:** `AWS::EC2::Instance`

**Required AWS Config recording resources:** `AWS::EC2::Instance`, `AWS::SSM::ManagedInstanceInventory`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/ec2-instance-managed-by-systems-manager.html](https://docs.aws.amazon.com/config/latest/developerguide/ec2-instance-managed-by-systems-manager.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether the stopped and running EC2 instances in your account are managed by AWS Systems Manager. Systems Manager is an AWS service that you can use to view and control your AWS infrastructure.

To help you maintain security and compliance, Systems Manager scans your stopped and running managed instances. A managed instance is a machine that's configured for use with Systems Manager. Systems Manager then reports or takes corrective action on any policy violations that it detects. Systems Manager also helps you configure and maintain your managed instances. To learn more, see the [AWS Systems Manager User Guide](https://docs.aws.amazon.com/systems-manager/latest/userguide/what-is-systems-manager.html).

**Note**  
This control generates `FAILED` findings for EC2 instances that are AWS Elastic Disaster Recovery Replication Server instances managed by AWS. A Replication Server instance is an EC2 Instance that’s automatically launched by AWS Elastic Disaster Recovery to support continuous data replication from source servers. AWS intentionally removes the Systems Manager (SSM) Agent from these instances to maintain isolation and help prevent potential unintended access paths.

### Remediation
<a name="ssm-1-remediation"></a>

For information about managing EC2 instances with AWS Systems Manager, see [Amazon EC2 host management](https://docs.aws.amazon.com/systems-manager/latest/userguide/quick-setup-host-management.html) in the *AWS Systems Manager User Guide*. In the **Configuration options** section on the AWS Systems Manager console, you can keep the default settings or change them as necessary for your preferred configuration.

## [SSM.2] Amazon EC2 instances managed by Systems Manager should have a patch compliance status of COMPLIANT after a patch installation
<a name="ssm-2"></a>

**Related requirements:** NIST.800-53.r5 CM-8(3), NIST.800-53.r5 SI-2, NIST.800-53.r5 SI-2(2), NIST.800-53.r5 SI-2(3), NIST.800-53.r5 SI-2(4), NIST.800-53.r5 SI-2(5), NIST.800-171.r2 3.7.1, PCI DSS v3.2.1/6.2, PCI DSS v4.0.1/2.2.1, PCI DSS v4.0.1/6.3.3

**Category:** Detect > Detection services 

**Severity:** High

**Resource type:** `AWS::SSM::PatchCompliance`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/ec2-managedinstance-patch-compliance-status-check.html](https://docs.aws.amazon.com/config/latest/developerguide/ec2-managedinstance-patch-compliance-status-check.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether the compliance status of Systems Manager patch compliance is `COMPLIANT` or `NON_COMPLIANT` after the patch installation on the instance. The control fails if the compliance status is `NON_COMPLIANT`. The control only checks instances that are managed by Systems Manager Patch Manager.

Patching your EC2 instances as required by your organization reduces the attack surface of your AWS accounts.

### Remediation
<a name="ssm-2-remediation"></a>

Systems Manager recommends using [patch policies](https://docs.aws.amazon.com/systems-manager/latest/userguide/patch-manager-policies.html) to configure patching for your managed instances. You can also use [Systems Manager documents](https://docs.aws.amazon.com/systems-manager/latest/userguide/patch-manager-ssm-documents.html), as described in the following procedure, to patch an instance.

**To remediate noncompliant patches**

1. Open the AWS Systems Manager console at [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).

1. For **Node Management**, choose **Run Command**, and then choose **Run command**.

1. Choose the option for **AWS-RunPatchBaseline**.

1. Change the **Operation** to **Install**.

1. Choose **Choose instances manually**, and then choose the noncompliant instances.

1. Choose **Run**.

1. After the command is complete, to monitor the new compliance status of your patched instances, choose **Compliance** in the navigation pane.

## [SSM.3] Amazon EC2 instances managed by Systems Manager should have an association compliance status of COMPLIANT
<a name="ssm-3"></a>

**Related requirements:** NIST.800-53.r5 CA-9(1), NIST.800-53.r5 CM-2, NIST.800-53.r5 CM-2(2), NIST.800-53.r5 CM-8, NIST.800-53.r5 CM-8(1), NIST.800-53.r5 CM-8(3), NIST.800-53.r5 SI-2(3), PCI DSS v3.2.1/2.4, PCI DSS v4.0.1/2.2.1, PCI DSS v4.0.1/6.3.3

**Category:** Detect > Detection services

**Severity:** Low

**Resource type:** `AWS::SSM::AssociationCompliance`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/ec2-managedinstance-association-compliance-status-check.html](https://docs.aws.amazon.com/config/latest/developerguide/ec2-managedinstance-association-compliance-status-check.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether the status of the AWS Systems Manager association compliance is `COMPLIANT` or `NON_COMPLIANT` after the association is run on an instance. The control fails if the association compliance status is `NON_COMPLIANT`.

A State Manager association is a configuration that is assigned to your managed instances. The configuration defines the state that you want to maintain on your instances. For example, an association can specify that antivirus software must be installed and running on your instances or that certain ports must be closed. 

After you create one or more State Manager associations, compliance status information is immediately available to you. You can view the compliance status in the console or in response to AWS CLI commands or corresponding Systems Manager API actions. For associations, Configuration Compliance shows the compliance status (`Compliant` or `Non-compliant`). It also shows the severity level assigned to the association, such as `Critical` or `Medium`.

To learn more about State Manager association compliance, see [About State Manager association compliance](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-compliance-about.html#sysman-compliance-about-association) in the *AWS Systems Manager User Guide*.

### Remediation
<a name="ssm-3-remediation"></a>

A failed association can be related to different things, including targets and Systems Manager document names. To remediate this issue, you must first identify and investigate the association by viewing association history. For instructions on viewing association history, see [Viewing association histories](https://docs.aws.amazon.com/systems-manager/latest/userguide/state-manager-associations-history.html) in the *AWS Systems Manager User Guide*.

After investigating, you can edit the association to correct the identified issue. You can edit an association to specify a new name, schedule, severity level, or targets. After you edit an association, AWS Systems Manager creates a new version. For instructions on editing an association, see [Editing and creating a new version of an association](https://docs.aws.amazon.com/systems-manager/latest/userguide/state-manager-associations-edit.html) in the *AWS Systems Manager User Guide*.

## [SSM.4] SSM documents should not be public
<a name="ssm-4"></a>

**Related requirements:** NIST.800-53.r5 AC-21, NIST.800-53.r5 AC-3, NIST.800-53.r5 AC-3(7), NIST.800-53.r5 AC-4, NIST.800-53.r5 AC-4(21), NIST.800-53.r5 AC-6, NIST.800-53.r5 SC-7, NIST.800-53.r5 SC-7(11), NIST.800-53.r5 SC-7(16), NIST.800-53.r5 SC-7(20), NIST.800-53.r5 SC-7(21), NIST.800-53.r5 SC-7(3), NIST.800-53.r5 SC-7(4), NIST.800-53.r5 SC-7(9)

**Category:** Protect > Secure network configuration > Resources not publicly accessible

**Severity:** Critical

**Resource type:** `AWS::SSM::Document`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/ssm-document-not-public.html](https://docs.aws.amazon.com/config/latest/developerguide/ssm-document-not-public.html)

**Schedule type:** Periodic

**Parameters:** None

This control checks whether AWS Systems Manager documents that are owned by an account are public. The control fails if Systems Manager documents that have `Self` as the owner are public.

Systems Manager documents that are public might allow unintended access to your documents. A public Systems Manager document can expose valuable information about your account, resources, and internal processes.

Unless your use case requires public sharing, we recommend that you block public sharing for Systems Manager documents that have `Self` as the owner.

### Remediation
<a name="ssm-4-remediation"></a>

For information about configuring sharing for Systems Manager documents, see [Share an SSM document](https://docs.aws.amazon.com/systems-manager/latest/userguide/documents-ssm-sharing.html#ssm-how-to-share) in the *AWS Systems Manager User Guide*.

## [SSM.5] SSM documents should be tagged
<a name="ssm-5"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::SSM::Document`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/ssm-document-tagged.html](https://docs.aws.amazon.com/config/latest/developerguide/ssm-document-tagged.html)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
| requiredKeyTags | A list of non-system tag keys that must be assigned to an evaluated resource. Tag keys are case sensitive. | StringList (maximum of 6 items) | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions). | No default value | 

This control checks whether an AWS Systems Manager document has the tag keys specified by the `requiredKeyTags` parameter. The control fails if the document doesn't have any tag keys, or it doesn't have all the keys specified by the `requiredKeyTags` parameter. If you don't specify any values for the `requiredKeyTags` parameter, the control checks only for the existence of a tag key and fails if the document doesn't have any tag keys. The control ignores system tags, which are applied automatically and have the `aws:` prefix. The control doesn't evaluate Systems Manager documents that are owned by Amazon.

A tag is a label that you create and assign to an AWS resource. Each tag consists of a required tag key and an optional tag value. You can use tags to categorize resources by purpose, owner, environment, or other criteria. They can help you identify, organize, search for, and filter resources. They can also help you track resource owners for actions and notifications. You can also use tags to implement attribute-based access control (ABAC) as an authorization strategy. For more information about ABAC strategies, see [Define permissions based on attributes with ABAC authorization](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*. For more information about tags, see the [Tagging AWS Resources and Tag Editor User Guide](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html).

**Note**  
Do not store personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible from many AWS services. They aren't intended to be used for private or sensitive data.

### Remediation
<a name="ssm-5-remediation"></a>

To add tags to an AWS Systems Manager document, you can use the [AddTagsToResource](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_AddTagsToResource.html) operation of the AWS Systems Manager API or, if you're using the AWS CLI, run the [add-tags-to-resource](https://docs.aws.amazon.com/cli/latest/reference/ssm/add-tags-to-resource.html) command. You can also use the AWS Systems Manager console.

## [SSM.6] SSM Automation should have CloudWatch logging enabled
<a name="ssm-6"></a>

**Category:** Identify > Logging

**Severity:** Medium

**Resource type:** `AWS::::Account`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/ssm-automation-logging-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/ssm-automation-logging-enabled.html)

**Schedule type:** Periodic

**Parameters:** None

This control checks whether Amazon CloudWatch logging is enabled for AWS Systems Manager (SSM) Automation. The control fails if CloudWatch logging isn't enabled for SSM Automation.

SSM Automation is an AWS Systems Manager tool that helps you build automated solutions to deploy, configure, and manage AWS resources at scale using predefined or custom runbooks. To meet operational or security requirements for your organization, you might need to provide a record of the scripts that it runs. You can configure SSM Automation to send the output from `aws:executeScript` actions in your runbooks to an Amazon CloudWatch Logs log group that you specify. With CloudWatch Logs, you can monitor, store, and access log files from various AWS services.

### Remediation
<a name="ssm-6-remediation"></a>

For information about enabling CloudWatch logging for SSM Automation, see [Logging Automation action output with CloudWatch Logs](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-action-logging.html) in the *AWS Systems Manager User Guide*.

## [SSM.7] SSM documents should have the block public sharing setting enabled
<a name="ssm-7"></a>

**Category:** Protect > Secure access management > Resource not publicly accessible

**Severity:** Critical

**Resource type:** `AWS::::Account`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/ssm-automation-block-public-sharing.html](https://docs.aws.amazon.com/config/latest/developerguide/ssm-automation-block-public-sharing.html)

**Schedule type:** Periodic

**Parameters:** None

This control checks whether the block public sharing setting is enabled for AWS Systems Manager documents. The control fails if the block public sharing setting is disabled for Systems Manager documents.

The block public sharing setting for AWS Systems Manager (SSM) documents is an account-level setting. Enabling this setting can prevent unwanted access to your SSM documents. If you enable this setting, your change doesn't affect any SSM documents that you're currently sharing with the public. Unless your use case requires you to share SSM documents with the public, we recommend that you enable the block public sharing setting. The setting can differ for each AWS Region.

### Remediation
<a name="ssm-7-remediation"></a>

For information about enabling the block public sharing setting for AWS Systems Manager (SSM) documents, see [Block public sharing for SSM documents](https://docs.aws.amazon.com/systems-manager/latest/userguide/documents-ssm-sharing.html#block-public-access) in the *AWS Systems Manager User Guide*.

# Security Hub CSPM controls for AWS Transfer Family
<a name="transfer-controls"></a>

These AWS Security Hub CSPM controls evaluate the AWS Transfer Family service and resources. The controls might not be available in all AWS Regions. For more information, see [Availability of controls by Region](securityhub-regions.md#securityhub-regions-control-support).

## [Transfer.1] AWS Transfer Family workflows should be tagged
<a name="transfer-1"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::Transfer::Workflow`

**AWS Config rule:** `tagged-transfer-workflow` (custom Security Hub CSPM rule)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
|  requiredTagKeys  | List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive.  | StringList (maximum of 6 items)  | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions).  |  No default value  | 

This control checks whether an AWS Transfer Family workflow has tags with the specific keys defined in the parameter `requiredTagKeys`. The control fails if the workflow doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter `requiredTagKeys`. If the parameter `requiredTagKeys` isn't provided, the control only checks for the existence of a tag key and fails if the workflow isn't tagged with any key. System tags, which are automatically applied and begin with `aws:`, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see [What is ABAC for AWS?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*.

**Note**  
Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see [Tagging your AWS resources](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-best-practices) in the *AWS General Reference*.

### Remediation
<a name="transfer-1-remediation"></a>

**To add tags to a Transfer Family workflow (console)**

1. Open the AWS Transfer Family console.

1. In the navigation pane, choose **Workflows**. Then, select the workflow that you want to tag.

1. Choose **Manage tags**, and then add the tags.

## [Transfer.2] Transfer Family servers should not use FTP protocol for endpoint connection
<a name="transfer-2"></a>

**Related requirements:** NIST.800-53.r5 CM-7, NIST.800-53.r5 IA-5, NIST.800-53.r5 SC-8, PCI DSS v4.0.1/4.2.1

**Category:** Protect > Data Protection > Encryption of data-in-transit

**Severity:** Medium

**Resource type:** `AWS::Transfer::Server`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/transfer-family-server-no-ftp.html](https://docs.aws.amazon.com/config/latest/developerguide/transfer-family-server-no-ftp.html)

**Schedule type:** Periodic

**Parameters:** None

This control checks whether an AWS Transfer Family server uses a protocol other than FTP for endpoint connection. The control fails if the server uses FTP protocol for a client to connect to the server's endpoint.

FTP (File Transfer Protocol) establishes the endpoint connection through unencrypted channels, leaving data sent over these channels vulnerable to interception. Using SFTP (SSH File Transfer Protocol), FTPS (File Transfer Protocol Secure), or AS2 (Applicability Statement 2) offers an extra layer of security by encrypting your data in transit and can be used to help prevent potential attackers from using person-in-the-middle or similar attacks to eavesdrop on or manipulate network traffic.

### Remediation
<a name="transfer-2-remediation"></a>

To modify the protocol for a Transfer Family server, see [Edit the file transfer protocols](https://docs.aws.amazon.com/transfer/latest/userguide/edit-server-config.html#edit-protocols) in the *AWS Transfer Family User Guide*.

## [Transfer.3] Transfer Family connectors should have logging enabled
<a name="transfer-3"></a>

**Related requirements:** NIST.800-53.r5 AC-2(12), NIST.800-53.r5 AC-2(4), NIST.800-53.r5 AC-4(26), NIST.800-53.r5 AC-6(9), NIST.800-53.r5 AU-10, NIST.800-53.r5 AU-12, NIST.800-53.r5 AU-2, NIST.800-53.r5 AU-3, NIST.800-53.r5 AU-6(3), NIST.800-53.r5 AU-6(4), NIST.800-53.r5 AU-9(7), NIST.800-53.r5 CA-7, NIST.800-53.r5 SC-7(9), NIST.800-53.r5 SI-3(8), NIST.800-53.r5 SI-4, NIST.800-53.r5 SI-4(20), NIST.800-53.r5 SI-7(8)

**Category:** Identify > Logging

**Severity:** Medium

**Resource type:** `AWS::Transfer::Connector`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/transfer-connector-logging-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/transfer-connector-logging-enabled.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether Amazon CloudWatch logging is enabled for an AWS Transfer Family connector. The control fails if CloudWatch logging isn't enabled for the connector.

Amazon CloudWatch is a monitoring and observability service that provides visibility into your AWS resources, including AWS Transfer Family resources. For Transfer Family, CloudWatch provides consolidated auditing and logging for workflow progress and results. This includes several metrics that Transfer Family defines for workflows. You can configure Transfer Family to automatically log connector events in CloudWatch. To do this, you specify a logging role for the connector. For the logging role, you create an IAM role and a resource-based IAM policy that defines the permissions for the role.

### Remediation
<a name="transfer-3-remediation"></a>

For information about enabling CloudWatch logging for a Transfer Family connector, see [Amazon CloudWatch logging for AWS Transfer Family servers](https://docs.aws.amazon.com/transfer/latest/userguide/structured-logging.html) in the *AWS Transfer Family User Guide*.

## [Transfer.4] Transfer Family agreements should be tagged
<a name="transfer-4"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::Transfer::Agreement`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/transfer-agreement-tagged.html](https://docs.aws.amazon.com/config/latest/developerguide/transfer-agreement-tagged.html)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
| requiredKeyTags | A list of non-system tag keys that must be assigned to an evaluated resource. Tag keys are case sensitive. | StringList (maximum of 6 items) | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions). | No default value | 

This control checks whether an AWS Transfer Family agreement has the tag keys specified by the `requiredKeyTags` parameter. The control fails if the agreement doesn't have any tag keys, or it doesn't have all the keys specified by the `requiredKeyTags` parameter. If you don't specify any values for the `requiredKeyTags` parameter, the control checks only for the existence of a tag key and fails if the agreement doesn't have any tag keys. The control ignores system tags, which are applied automatically and have the `aws:` prefix.

A tag is a label that you create and assign to an AWS resource. Each tag consists of a required tag key and an optional tag value. You can use tags to categorize resources by purpose, owner, environment, or other criteria. They can help you identify, organize, search for, and filter resources. They can also help you track resource owners for actions and notifications. You can also use tags to implement attribute-based access control (ABAC) as an authorization strategy. For more information about ABAC strategies, see [Define permissions based on attributes with ABAC authorization](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*. For more information about tags, see the [Tagging AWS Resources and Tag Editor User Guide](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html).

**Note**  
Do not store personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible from many AWS services. They aren't intended to be used for private or sensitive data.

### Remediation
<a name="transfer-4-remediation"></a>

For information about adding tags to an AWS Transfer Family agreement, see [Resource tagging methods](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#intro-tag-methods) in the *Tagging AWS Resources and Tag Editor User Guide*.

## [Transfer.5] Transfer Family certificates should be tagged
<a name="transfer-5"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::Transfer::Certificate`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/transfer-certificate-tagged.html](https://docs.aws.amazon.com/config/latest/developerguide/transfer-certificate-tagged.html)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
| requiredKeyTags | A list of non-system tag keys that must be assigned to an evaluated resource. Tag keys are case sensitive. | StringList (maximum of 6 items) | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions). | No default value | 

This control checks whether an AWS Transfer Family certificate has the tag keys specified by the `requiredKeyTags` parameter. The control fails if the certificate doesn't have any tag keys, or it doesn't have all the keys specified by the `requiredKeyTags` parameter. If you don't specify any values for the `requiredKeyTags` parameter, the control checks only for the existence of a tag key and fails if the certificate doesn't have any tag keys. The control ignores system tags, which are applied automatically and have the `aws:` prefix.

A tag is a label that you create and assign to an AWS resource. Each tag consists of a required tag key and an optional tag value. You can use tags to categorize resources by purpose, owner, environment, or other criteria. They can help you identify, organize, search for, and filter resources. They can also help you track resource owners for actions and notifications. You can also use tags to implement attribute-based access control (ABAC) as an authorization strategy. For more information about ABAC strategies, see [Define permissions based on attributes with ABAC authorization](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*. For more information about tags, see the [Tagging AWS Resources and Tag Editor User Guide](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html).

**Note**  
Do not store personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible from many AWS services. They aren't intended to be used for private or sensitive data.

### Remediation
<a name="transfer-5-remediation"></a>

For information about adding tags to an AWS Transfer Family certificate, see [Resource tagging methods](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#intro-tag-methods) in the *Tagging AWS Resources and Tag Editor User Guide*.

## [Transfer.6] Transfer Family connectors should be tagged
<a name="transfer-6"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::Transfer::Connector`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/transfer-connector-tagged.html](https://docs.aws.amazon.com/config/latest/developerguide/transfer-connector-tagged.html)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
| requiredKeyTags | A list of non-system tag keys that must be assigned to an evaluated resource. Tag keys are case sensitive. | StringList (maximum of 6 items) | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions). | No default value | 

This control checks whether an AWS Transfer Family connector has the tag keys specified by the `requiredKeyTags` parameter. The control fails if the connector doesn't have any tag keys, or it doesn't have all the keys specified by the `requiredKeyTags` parameter. If you don't specify any values for the `requiredKeyTags` parameter, the control checks only for the existence of a tag key and fails if the connector doesn't have any tag keys. The control ignores system tags, which are applied automatically and have the `aws:` prefix.

A tag is a label that you create and assign to an AWS resource. Each tag consists of a required tag key and an optional tag value. You can use tags to categorize resources by purpose, owner, environment, or other criteria. They can help you identify, organize, search for, and filter resources. They can also help you track resource owners for actions and notifications. You can also use tags to implement attribute-based access control (ABAC) as an authorization strategy. For more information about ABAC strategies, see [Define permissions based on attributes with ABAC authorization](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*. For more information about tags, see the [Tagging AWS Resources and Tag Editor User Guide](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html).

**Note**  
Do not store personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible from many AWS services. They aren't intended to be used for private or sensitive data.

### Remediation
<a name="transfer-6-remediation"></a>

For information about adding tags to an AWS Transfer Family connector, see [Resource tagging methods](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#intro-tag-methods) in the *Tagging AWS Resources and Tag Editor User Guide*.

## [Transfer.7] Transfer Family profiles should be tagged
<a name="transfer-7"></a>

**Category:** Identify > Inventory > Tagging

**Severity:** Low

**Resource type:** `AWS::Transfer::Profile`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/transfer-profile-tagged.html](https://docs.aws.amazon.com/config/latest/developerguide/transfer-profile-tagged.html)

**Schedule type:** Change triggered

**Parameters:**


| Parameter | Description | Type | Allowed custom values | Security Hub CSPM default value | 
| --- | --- | --- | --- | --- | 
| requiredKeyTags | A list of non-system tag keys that must be assigned to an evaluated resource. Tag keys are case sensitive. | StringList (maximum of 6 items) | 1–6 tag keys that meet [AWS requirements](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#tag-conventions). | No default value | 

This control checks whether an AWS Transfer Family profile has the tag keys specified by the `requiredKeyTags` parameter. The control fails if the profile doesn't have any tag keys, or it doesn't have all the keys specified by the `requiredKeyTags` parameter. If you don't specify any values for the `requiredKeyTags` parameter, the control checks only for the existence of a tag key and fails if the profile doesn't have any tag keys. The control ignores system tags, which are applied automatically and have the `aws:` prefix. The control evaluates local profiles and partner profiles.

A tag is a label that you create and assign to an AWS resource. Each tag consists of a required tag key and an optional tag value. You can use tags to categorize resources by purpose, owner, environment, or other criteria. They can help you identify, organize, search for, and filter resources. They can also help you track resource owners for actions and notifications. You can also use tags to implement attribute-based access control (ABAC) as an authorization strategy. For more information about ABAC strategies, see [Define permissions based on attributes with ABAC authorization](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*. For more information about tags, see the [Tagging AWS Resources and Tag Editor User Guide](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html).

**Note**  
Do not store personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible from many AWS services. They aren't intended to be used for private or sensitive data.

### Remediation
<a name="transfer-7-remediation"></a>

For information about adding tags to an AWS Transfer Family profile, see [Resource tagging methods](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html#intro-tag-methods) in the *Tagging AWS Resources and Tag Editor User Guide*.

# Security Hub CSPM controls for AWS WAF
<a name="waf-controls"></a>

These AWS Security Hub CSPM controls evaluate the AWS WAF service and resources. The controls might not be available in all AWS Regions. For more information, see [Availability of controls by Region](securityhub-regions.md#securityhub-regions-control-support).

## [WAF.1] AWS WAF Classic Global Web ACL logging should be enabled
<a name="waf-1"></a>

**Related requirements:** NIST.800-53.r5 AC-4(26), NIST.800-53.r5 AU-10, NIST.800-53.r5 AU-12, NIST.800-53.r5 AU-2, NIST.800-53.r5 AU-3, NIST.800-53.r5 AU-6(3), NIST.800-53.r5 AU-6(4), NIST.800-53.r5 CA-7, NIST.800-53.r5 SC-7(9), NIST.800-53.r5 SI-7(8), PCI DSS v4.0.1/10.4.2

**Category:** Identify > Logging

**Severity:** Medium

**Resource type:** `AWS::WAF::WebACL`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/waf-classic-logging-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/waf-classic-logging-enabled.html)

**Schedule type:** Periodic

**Parameters:** None

This control checks whether logging is enabled for an AWS WAF global web ACL. This control fails if logging is not enabled for the web ACL.

Logging is an important part of maintaining the reliability, availability, and performance of AWS WAF globally. It is a business and compliance requirement in many organizations, and allows you to troubleshoot application behavior. It also provides detailed information about the traffic that is analyzed by the web ACL that is attached to AWS WAF.

### Remediation
<a name="waf-1-remediation"></a>

To enable logging for an AWS WAF web ACL, see [ Logging web ACL traffic information](https://docs.aws.amazon.com/waf/latest/developerguide/classic-logging.html) in the *AWS WAF Developer Guide*.

## [WAF.2] AWS WAF Classic Regional rules should have at least one condition
<a name="waf-2"></a>

**Related requirements:** NIST.800-53.r5 AC-4(21), NIST.800-53.r5 SC-7, NIST.800-53.r5 SC-7(11), NIST.800-53.r5 SC-7(16), NIST.800-53.r5 SC-7(21)

**Category:** Protect > Secure network configuration

**Severity:** Medium

**Resource type:** `AWS::WAFRegional::Rule`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/waf-regional-rule-not-empty.html](https://docs.aws.amazon.com/config/latest/developerguide/waf-regional-rule-not-empty.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether an AWS WAF Regional rule has at least one condition. The control fails if no conditions are present within a rule.

A WAF Regional rule can contain multiple conditions. The rule's conditions allow for traffic inspection and take a defined action (allow, block, or count). Without any conditions, the traffic passes without inspection. A WAF Regional rule with no conditions, but with a name or tag suggesting allow, block, or count, could lead to the wrong assumption that one of those actions is occurring.

### Remediation
<a name="waf-2-remediation"></a>

To add a condition to an empty rule, see [Adding and removing conditions in a rule](https://docs.aws.amazon.com/waf/latest/developerguide/classic-web-acl-rules-editing.html) in the *AWS WAF Developer Guide*.

## [WAF.3] AWS WAF Classic Regional rule groups should have at least one rule
<a name="waf-3"></a>

**Related requirements:** NIST.800-53.r5 AC-4(21), NIST.800-53.r5 SC-7, NIST.800-53.r5 SC-7(11), NIST.800-53.r5 SC-7(16), NIST.800-53.r5 SC-7(21)

**Category:** Protect > Secure network configuration

**Severity:** Medium

**Resource type:** `AWS::WAFRegional::RuleGroup`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/waf-regional-rulegroup-not-empty.html](https://docs.aws.amazon.com/config/latest/developerguide/waf-regional-rulegroup-not-empty.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether an AWS WAF Regional rule group has at least one rule. The control fails if no rules are present within a rule group.

A WAF Regional rule group can contain multiple rules. The rule's conditions allow for traffic inspection and take a defined action (allow, block, or count). Without any rules, the traffic passes without inspection. A WAF Regional rule group with no rules, but with a name or tag suggesting allow, block, or count, could lead to the wrong assumption that one of those actions is occurring.

### Remediation
<a name="waf-3-remediation"></a>

To add rules and rule conditions to an empty rule group, see [Adding and deleting rules from an AWS WAF Classic rule group](https://docs.aws.amazon.com/waf/latest/developerguide/classic-rule-group-editing.html) and [Adding and removing conditions in a rule](https://docs.aws.amazon.com/waf/latest/developerguide/classic-web-acl-rules-editing.html) in the *AWS WAF Developer Guide*.

## [WAF.4] AWS WAF Classic Regional web ACLs should have at least one rule or rule group
<a name="waf-4"></a>

**Related requirements:** NIST.800-53.r5 CA-9(1), NIST.800-53.r5 CM-2

**Category:** Protect > Secure network configuration

**Severity:** Medium

**Resource type:** `AWS::WAFRegional::WebACL`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/waf-regional-webacl-not-empty](https://docs.aws.amazon.com/config/latest/developerguide/waf-regional-webacl-not-empty)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether an AWS WAF Classic Regional web ACL contains any WAF rules or WAF rule groups. This control fails if a web ACL does not contain any WAF rules or rule groups.

A WAF Regional web ACL can contain a collection of rules and rule groups that inspect and control web requests. If a web ACL is empty, the web traffic can pass without being detected or acted upon by WAF depending on the default action.

### Remediation
<a name="waf-4-remediation"></a>

To add rules or rule groups to an empty AWS WAF Classic Regional web ACL, see [Editing a Web ACL](https://docs.aws.amazon.com/waf/latest/developerguide/classic-web-acl-editing.html) in the *AWS WAF Developer Guide*.

## [WAF.6] AWS WAF Classic global rules should have at least one condition
<a name="waf-6"></a>

**Related requirements:** NIST.800-53.r5 CA-9(1), NIST.800-53.r5 CM-2

**Category:** Protect > Secure network configuration

**Severity:** Medium

**Resource type:** `AWS::WAF::Rule`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/waf-global-rule-not-empty.html](https://docs.aws.amazon.com/config/latest/developerguide/waf-global-rule-not-empty.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether an AWS WAF global rule contains any conditions. The control fails if no conditions are present within a rule.

A WAF global rule can contain multiple conditions. A rule's conditions allow for traffic inspection and take a defined action (allow, block, or count). Without any conditions, the traffic passes without inspection. A WAF global rule with no conditions, but with a name or tag suggesting allow, block, or count, could lead to the wrong assumption that one of those actions is occurring.

### Remediation
<a name="waf-6-remediation"></a>

For instructions on creating a rule and adding conditions, see [Creating a rule and adding conditions](https://docs.aws.amazon.com/waf/latest/developerguide/classic-web-acl-rules-creating.html) in the *AWS WAF Developer Guide*.

## [WAF.7] AWS WAF Classic global rule groups should have at least one rule
<a name="waf-7"></a>

**Related requirements:** NIST.800-53.r5 CA-9(1), NIST.800-53.r5 CM-2

**Category:** Protect > Secure network configuration

**Severity:** Medium

**Resource type:** `AWS::WAF::RuleGroup`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/waf-global-rulegroup-not-empty.html](https://docs.aws.amazon.com/config/latest/developerguide/waf-global-rulegroup-not-empty.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether an AWS WAF global rule group has at least one rule. The control fails if no rules are present within a rule group.

A WAF global rule group can contain multiple rules. The rule's conditions allow for traffic inspection and take a defined action (allow, block, or count). Without any rules, the traffic passes without inspection. A WAF global rule group with no rules, but with a name or tag suggesting allow, block, or count, could lead to the wrong assumption that one of those actions is occurring.

### Remediation
<a name="waf-7-remediation"></a>

For instructions on adding a rule to a rule group, see [Creating an AWS WAF Classic rule group](https://docs.aws.amazon.com/waf/latest/developerguide/classic-create-rule-group.html) in the *AWS WAF Developer Guide*.

## [WAF.8] AWS WAF Classic global web ACLs should have at least one rule or rule group
<a name="waf-8"></a>

**Related requirements:** NIST.800-53.r5 AC-4(21), NIST.800-53.r5 SC-7, NIST.800-53.r5 SC-7(11), NIST.800-53.r5 SC-7(16), NIST.800-53.r5 SC-7(21)

**Category:** Protect > Secure network configuration

**Severity:** Medium

**Resource type:** `AWS::WAF::WebACL`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/waf-global-webacl-not-empty](https://docs.aws.amazon.com/config/latest/developerguide/waf-global-webacl-not-empty)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether an AWS WAF global web ACL contains at least one WAF rule or WAF rule group. The control fails if a web ACL does not contain any WAF rules or rule groups.

A WAF global web ACL can contain a collection of rules and rule groups that inspect and control web requests. If a web ACL is empty, the web traffic can pass without being detected or acted upon by WAF depending on the default action.

### Remediation
<a name="waf-8-remediation"></a>

To add rules or rule groups to an empty AWS WAF global web ACL, see [Editing a web ACL](https://docs.aws.amazon.com/waf/latest/developerguide/classic-web-acl-editing.html) in the *AWS WAF Developer Guide*. For **Filter**, choose **Global (CloudFront)**.

## [WAF.10] AWS WAF web ACLs should have at least one rule or rule group
<a name="waf-10"></a>

**Related requirements:** NIST.800-53.r5 CA-9(1), NIST.800-53.r5 CM-2

**Category:** Protect > Secure network configuration

**Severity:** Medium

**Resource type:** `AWS::WAFv2::WebACL`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/wafv2-webacl-not-empty.html](https://docs.aws.amazon.com/config/latest/developerguide/wafv2-webacl-not-empty.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether an AWS WAFV2 web access control list (web ACL) contains at least one rule or rule group. The control fails if a web ACL does not contain any rules or rule groups.

A web ACL gives you fine-grained control over all of the HTTP(S) web requests that your protected resource responds to. A web ACL should contain a collection of rules and rule groups that inspect and control web requests. If a web ACL is empty, the web traffic can pass without being detected or acted upon by AWS WAF depending on the default action.

### Remediation
<a name="waf-10-remediation"></a>

To add rules or rule groups to an empty WAFV2 web ACL, see [Editing a Web ACL](https://docs.aws.amazon.com/waf/latest/developerguide/web-acl-editing.html) in the *AWS WAF Developer Guide*.

## [WAF.11] AWS WAF web ACL logging should be enabled
<a name="waf-11"></a>

**Related requirements:** NIST.800-53.r5 AC-4(26), NIST.800-53.r5 AU-10, NIST.800-53.r5 AU-12, NIST.800-53.r5 AU-2, NIST.800-53.r5 AU-3, NIST.800-53.r5 AU-6(3), NIST.800-53.r5 AU-6(4), NIST.800-53.r5 CA-7, NIST.800-53.r5 SC-7(10), NIST.800-53.r5 SC-7(9), NIST.800-53.r5 SI-7(8), PCI DSS v4.0.1/10.4.2

**Category:** Identify > Logging

**Severity:** Low

**Resource type:** `AWS::WAFv2::WebACL`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/wafv2-logging-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/wafv2-logging-enabled.html) ``

**Schedule type:** Periodic

**Parameters:** None

This control checks whether logging is activated for an AWS WAFV2 web access control list (web ACL). This control fails if logging is deactivated for the web ACL.

**Note**  
This control doesn't check whether AWS WAF web ACL logging is enabled for an account through Amazon Security Lake.

Logging maintains the reliability, availability, and performance of AWS WAF. In addition, logging is a business and compliance requirement in many organizations. By logging traffic that's analyzed by your web ACL, you can troubleshoot application behavior.

### Remediation
<a name="waf-11-remediation"></a>

To activate logging for an AWS WAF web ACL, see [Managing logging for a web ACL](https://docs.aws.amazon.com/waf/latest/developerguide/logging-management.html) in the *AWS WAF Developer Guide*.

## [WAF.12] AWS WAF rules should have CloudWatch metrics enabled
<a name="waf-12"></a>

**Related requirements:** NIST.800-53.r5 AC-4(26), NIST.800-53.r5 AU-10, NIST.800-53.r5 AU-12, NIST.800-53.r5 AU-2, NIST.800-53.r5 AU-3, NIST.800-53.r5 AU-6(3), NIST.800-53.r5 AU-6(4), NIST.800-53.r5 CA-7, NIST.800-53.r5 SC-7(10), NIST.800-53.r5 SC-7(9), NIST.800-53.r5 SI-7(8), NIST.800-171.r2 3.14.6, NIST.800-171.r2 3.14.7

**Category:** Identify > Logging

**Severity:** Medium

**Resource type:** `AWS::WAFv2::RuleGroup`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/wafv2-rulegroup-logging-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/wafv2-rulegroup-logging-enabled.html) ``

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether an AWS WAF rule or rule group has Amazon CloudWatch metrics enabled. The control fails if the rule or rule group doesn't have CloudWatch metrics enabled.

Configuring CloudWatch metrics on AWS WAF rules and rule groups provides visibility into traffic flow. You can see which ACL rules are triggered and which requests are accepted and blocked. This visibility can help you identify malicious activity on your associated resources.

### Remediation
<a name="waf-12-remediation"></a>

To enable CloudWatch metrics on an AWS WAF rule group, invoke the [ UpdateRuleGroup](https://docs.aws.amazon.com/waf/latest/APIReference/API_UpdateRuleGroup.html) API. To enable CloudWatch metrics on an AWS WAF rule, invoke the [ UpdateWebACL](https://docs.aws.amazon.com/waf/latest/APIReference/API_UpdateWebACL.html) API. Set the `CloudWatchMetricsEnabled` field to `true`. When you use the AWS WAF console to create rules or rule groups, CloudWatch metrics are automatically enabled.

# Security Hub CSPM controls for WorkSpaces
<a name="workspaces-controls"></a>

These AWS Security Hub CSPM controls evaluate the Amazon WorkSpaces service and resources.

These controls may not be available in all AWS Regions. For more information, see [Availability of controls by Region](securityhub-regions.md#securityhub-regions-control-support).

## [WorkSpaces.1] WorkSpaces user volumes should be encrypted at rest
<a name="workspaces-1"></a>

**Category:** Protect > Data Protection > Encryption of data-at-rest

**Severity:** Medium

**Resource type:** `AWS::WorkSpaces::Workspace`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/workspaces-user-volume-encryption-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/workspaces-user-volume-encryption-enabled.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether a user volume in an Amazon WorkSpaces WorkSpace is encrypted at rest. The control fails if the WorkSpace user volume isn't encrypted at rest.

Data at rest refers to data that's stored in persistent, non-volatile storage for any duration. Encrypting data at rest helps you protect its confidentiality, which reduces the risk that an unauthorized user can access it.

### Remediation
<a name="workspaces-1-remediation"></a>

To encrypt a WorkSpaces user volume, see [ Encrypt a WorkSpace](https://docs.aws.amazon.com/workspaces/latest/adminguide/encrypt-workspaces.html#encrypt_workspace) in the *Amazon WorkSpaces Administration Guide*.

## [WorkSpaces.2] WorkSpaces root volumes should be encrypted at rest
<a name="workspaces-2"></a>

**Category:** Protect > Data Protection > Encryption of data-at-rest

**Severity:** Medium

**Resource type:** `AWS::WorkSpaces::Workspace`

**AWS Config rule:** [https://docs.aws.amazon.com/config/latest/developerguide/workspaces-root-volume-encryption-enabled.html](https://docs.aws.amazon.com/config/latest/developerguide/workspaces-root-volume-encryption-enabled.html)

**Schedule type:** Change triggered

**Parameters:** None

This control checks whether a root volume in an Amazon WorkSpaces WorkSpace is encrypted at rest. The control fails if the WorkSpace root volume isn't encrypted at rest.

Data at rest refers to data that's stored in persistent, non-volatile storage for any duration. Encrypting data at rest helps you protect its confidentiality, which reduces the risk that an unauthorized user can access it.

### Remediation
<a name="workspaces-2-remediation"></a>

To encrypt a WorkSpaces root volume, see [ Encrypt a WorkSpace](https://docs.aws.amazon.com/workspaces/latest/adminguide/encrypt-workspaces.html#encrypt_workspace) in the *Amazon WorkSpaces Administration Guide*.