A lack of audit records limits the ability to detect and respond to security-related incidents and prevents forensic investigation.

Configuration settings that undermine logging capabilities include but are not limited to:
- deliberately disabling audit logging
- exempting actions of specific users, groups, or processes from being logged
- inadequately protecting log integrity
- not enabling optional audit logging
- reducing the log sampling rate

A lack of audit records limits the ability to detect and respond to security-related incidents and prevents forensic investigation.

Configuration settings that undermine logging capabilities include but are not limited to:
- deliberately disabling audit logging
- exempting actions of specific users, groups, or processes from being logged
- inadequately protecting log integrity
- not enabling optional audit logging
- reducing the log sampling rate

The template does not forward audit logs to Amazon CloudWatch for monitoring. This can allow malicious behavior to go undetected and lead to delayed incident response.

A lack of audit records limits the ability to detect and respond to security-related incidents and prevents forensic investigation.

Configuration settings that undermine logging capabilities include but are not limited to:
- deliberately disabling audit logging
- exempting actions of specific users, groups, or processes from being logged
- inadequately protecting log integrity
- not enabling optional audit logging
- reducing the log sampling rate

Any delayed response to breaches undermines an organization's ability to limit the impact of a breach.

Configuration settings that undermine monitoring capabilities include but are not limited to:
- deliberately disabling monitoring
- not enabling optional monitoring
- not specifying relevant events to export to monitoring services
- exempting actions of specific users, groups, processes, and geographical regions from monitoring

By default, Amazon Redshift clusters do not capture audit logs. This can allow malicious behavior to go undetected and inhibit forensic analysis in the event of a breach.

Example 1: The following example template defines an Amazon Redshift cluster without audit logging.

  "Resources": {
    "RedshiftClusterTest": {
      "Properties": {
        "NodeType": "dc1.large",
        "Port": 5439,
        "VpcSecurityGroupIds": [
          "${RedshiftSecurityGroup}"
        ],
        "ClusterSubnetGroupName": "RedshiftClusterSubnetGroup",
        "ClusterType": "single-node"
        "MasterUserPassword": "MasterUserPassword",
        "MasterUsername": "MasterUsername",
        "DBName": "${DatabaseName}",
        "IamRoles": ["RawDataBucketAccessRole.Arn"],
        "PubliclyAccessible": true
      },
      "Type": "AWS::Redshift::Cluster"
    }

A lack of audit records limits the ability to detect and respond to security-related incidents and prevents forensic investigation.

Configuration settings that undermine logging capabilities include but are not limited to:
- deliberately disabling audit logging
- exempting actions of specific users, groups, or processes from being logged
- inadequately protecting log integrity
- not enabling optional audit logging
- reducing the log sampling rate

Amazon S3 buckets do not save access logs by default. The logs, however, contain value data used to identify security incidents, monitor policy violations, and assist with non-repudiation controls.

A lack of audit records limits the ability to detect and respond to security-related incidents and prevents forensic investigation.

Configuration settings that undermine logging capabilities include but are not limited to:
- deliberately disabling audit logging
- exempting actions of specific users, groups, or processes from being logged
- inadequately protecting log integrity
- not enabling optional audit logging
- reducing the log sampling rate

Any delayed response to breaches undermines an organization's ability to limit the impact of a breach.

Configuration settings that undermine monitoring capabilities include but are not limited to:
- deliberately disabling monitoring
- not enabling optional monitoring
- not specifying relevant events to export to monitoring services
- exempting actions of specific users, groups, processes, and geographical regions from monitoring

Customer-managed keys are not used to encrypt data at rest.

By default, AWS uses AWS-managed keys to encrypt data at rest if encryption is enabled. Customer-managed keys enable organizations to use cryptographic keys of their choice to encrypt data. This gives organizations better control over and logging of encryption processes.

As such, customer-managed keys are often part of the solution to address requirements that include but are not limited to:
- Audit logs for sensitive data access
- Data residency
- Replacing, disabling, or destroying keys

Note that keys with the format aws/service-name are reserved for AWS-managed keys.

Denying access to resources through overuse is a common attack pattern used to exhaust system resources and drive up billing costs.

Customer-managed keys are not used to encrypt data at rest.

By default, AWS uses AWS-managed keys to encrypt data at rest if encryption is enabled. Customer-managed keys enable organizations to use cryptographic keys of their choice to encrypt data. This gives organizations better control over and logging of encryption processes.

As such, customer-managed keys are often part of the solution to address requirements that include but are not limited to:
- Audit logs for sensitive data access
- Data residency
- Replacing, disabling, or destroying keys

Note that keys with the format aws/service-name are reserved for AWS-managed keys.

Customer-managed keys are not used to encrypt data at rest.

By default, AWS uses AWS-managed keys to encrypt data at rest if encryption is enabled. Customer-managed keys enable organizations to use cryptographic keys of their choice to encrypt data. This gives organizations better control over and logging of encryption processes.

As such, customer-managed keys are often part of the solution to address requirements that include but are not limited to:
- Audit logs for sensitive data access
- Data residency
- Replacing, disabling, or destroying keys

Note that keys with the format aws/service-name are reserved for AWS-managed keys.

Customer-managed keys are not used to encrypt data at rest.

By default, AWS uses AWS-managed keys to encrypt data at rest if encryption is enabled. Customer-managed keys enable organizations to use cryptographic keys of their choice to encrypt data. This gives organizations better control over and logging of encryption processes.

As such, customer-managed keys are often part of the solution to address requirements that include but are not limited to:
- Audit logs for sensitive data access
- Data residency
- Replacing, disabling, or destroying keys

Note that keys with the format aws/service-name are reserved for AWS-managed keys.

Customer-managed keys are not used to encrypt data at rest.

By default, AWS uses AWS-managed keys to encrypt data at rest if encryption is enabled. Customer-managed keys enable organizations to use cryptographic keys of their choice to encrypt data. This gives organizations better control over and logging of encryption processes.

As such, customer-managed keys are often part of the solution to address requirements that include but are not limited to:
- Audit logs for sensitive data access
- Data residency
- Replacing, disabling, or destroying keys

Note that keys with the format aws/service-name are reserved for AWS-managed keys.

By default, CloudTrail log file validation is disabled, which prevents investigators from asserting that there has been no external tampering with CloudTrail log files.

A direct result of this is that an attacker with the necessary privileges can perform harmful configuration changes and cover their tracks by modifying CloudTrail logs.

Example 1: The following is an example of a trail with log file validation disabled by setting EnableLogFileValidation to false. Omitting the property results in the default value set to false as well.

"myTrail": {
    "DependsOn": [
        "BucketPolicy"
    ],
    "Type": "AWS::CloudTrail::Trail",
    "Properties": {
        "S3BucketName": {
            "Ref": "S3Bucket"
        },
        "IsLogging": true,
        "EnableLogFileValidation": false
    }
}

Customer-managed keys are not used to encrypt data at rest.

By default, AWS uses AWS-managed keys to encrypt data at rest if encryption is enabled. Customer-managed keys enable organizations to use cryptographic keys of their choice to encrypt data. This gives organizations better control over and logging of encryption processes.

As such, customer-managed keys are often part of the solution to address requirements that include but are not limited to:
- Audit logs for sensitive data access
- Data residency
- Replacing, disabling, or destroying keys

Note that keys with the format aws/service-name are reserved for AWS-managed keys.

By default, a container cannot execute most system and network administration operations. The privileged mode removes such restrictions. This dramatically expands the attack surface of malicious jobs.

Customer-managed keys are not used to encrypt data at rest.

By default, AWS uses AWS-managed keys to encrypt data at rest if encryption is enabled. Customer-managed keys enable organizations to use cryptographic keys of their choice to encrypt data. This gives organizations better control over and logging of encryption processes.

As such, customer-managed keys are often part of the solution to address requirements that include but are not limited to:
- Audit logs for sensitive data access
- Data residency
- Replacing, disabling, or destroying keys

Note that keys with the format aws/service-name are reserved for AWS-managed keys.