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

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

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

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 Kubernetes API server automatically rotates log files. To facilitate post-incident analysis and threat detection, as well as to meet compliance requirements, you must retain a sufficient amount of log data. The --audit-log-maxbackup flag defines the maximum number of log files to retain. Either this flag is not present in the command to start a Kubernetes API server or the maximum number of log files to retain is less than 10.

Example 1: The following command starts a Kubernetes API server and sets the --audit-log-maxbackup flag to 2, which insufficiently retains only two log files.

...
kind: Pod
...
spec:
  containers:
  - command:
    - kube-apiserver
    ...
    - --audit-log-maxbackup=2
    ...

The Kubernetes API server automatically rotates log files. To facilitate post-incident analysis and threat detection, as well as to meet compliance requirements, you must retain a sufficient amount of log data. The --audit-log-maxsize flag sets the maximum size in megabytes (MB) of the audit log file before it's automatically rotated. Either this flag is not present in the command to start a Kubernetes API server or the maximum size of the audit log file is set to less than 100 MB.

Example 1: The following command starts a Kubernetes API server and sets the --audit-log-maxsize flag to 2 (megabytes), which is insufficient.

...
kind: Pod
...
spec:
  containers:
  - command:
    - kube-apiserver
    ...
    - ----audit-log-maxsize=2
    ...

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.

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.

By default, a trail logs events only in the AWS Region where it was created.

This allows unaudited and unmonitored activities to take place on the organization's AWS infrastructure.

For example, an authorized AWS user might make configurational changes that cause harm to the organization and avoid detection.

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.

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

This enables an attacker with the necessary privileges to perform harmful configuration changes and hide them by modifying the CloudTrail logs.

Example 1: The following Ansible task sets up a CloudTrail configuration without log file integrity validation because the enable_log_file_validation parameter is missing.

- name: create a single region cloudtrail
  community.aws.cloudtrail:
    s3_bucket_name: mylogbucket
    s3_key_prefix: cloudtrail
    region: us-west-2

By default, CloudTrail records events and delivers log files but logging is deliberately disabled. This can allow malicious behavior to go undetected and inhibit forensic analysis in the event of a breach.

Example 1: The following Ansible task sets up a CloudTrail with logging disabled because enable_logging is set to false.

- name: create a single region cloudtrail
  community.aws.cloudtrail:
    s3_bucket_name: mylogbucket
    s3_key_prefix: cloudtrail
    region: us-west-2
    enable_logging: false

A Kubernetes API server writes audit events to standard output by default. The audit events should be logged to persistent storage. The audit events contain valuable data used to identify security incidents, monitor policy violations, and assist with non-repudiation controls.

Example 1: The following configuration starts a Kubernetes API server without the --audit-log-path flag.

...
spec:
  containers:
  - command:
    - kube-apiserver
    - --authorization-mode=RBAC
  image: example.domain/kube-apiserver-amd64:v1.6.0
...

A Kubernetes API server does not log events if there is no audit policy file specified. The event logs contain valuable data used to identify security incidents, monitor policy violations, and assist with non-repudiation controls.

Example 1: The following configuration starts a Kubernetes API server without the --audit-policy-file flag.

...
spec:
  containers:
  - command:
    - kube-apiserver
    - --audit-log-path=<the log file path>
  image: example.domain/kube-apiserver-amd64:v1.6.0
  ...

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 short retention period reduces the amount of log information that the organization can consult in the event of an investigation. Industry standards recommend different retention periods depending on the type of data and the legal obligations required for the organization.

A short retention period reduces the amount of log information that the organization can consult in the event of an investigation. Industry standards recommend different retention periods depending on the type of data and the legal obligations required for the organization.