By default, Amazon RDS instances are not encrypted. This exposes the data to potential theft and unauthorized access.

Insufficiently protected data communication channels can put critical organizational data at risk of theft, tampering, or disclosure.

By default, Amazon Redshift clusters are not encrypted. This exposes the data to unauthorized access and potential theft.

An Amazon S3 bucket is created without server-side encryption. Encryption mitigates data breaches by making data unreadable to anyone without the proper credentials. Encryption at rest can help satisfy some industrial and government compliance requirements such as GDPR, HIPAA, and PCI.

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

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

By default, CloudWatch Log Groups retain logs indefinitely. An unset retention value indicates that organizational data handling policies have not been consulted in order to set appropriate configurations. This might result in unnecessary expenses for the organization to store and manage logging events.

An attacker can launch a Denial of Wallet (DoW) attack by persistently prompting spurious event-logging over an extended period of time, which can impact the organization financially.

Example 1: The following example shows an Ansible task that fails to define a retention policy.

- name: create a log_group in CloudWatchLogs
  community.aws.cloudwatchlogs_log_group:
    log_group_name: test-log-group
    tags: { "Name": "test-log-group", "Env" : "QA" }

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

Backups are critical to protect against data loss or corruption. Settings that undermine backups include but are not limited to:
- Disabling data backup
- Failure to back up data regularly
- Failure to check the integrity of backups regularly
- Insufficient backup retention period

Backups are critical to protect against data loss or corruption. Settings that undermine backups include but are not limited to:
- Disabling data backup
- Failure to back up data regularly
- Failure to check the integrity of backups regularly
- Insufficient backup retention period

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

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, 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, 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.

Automatic software upgrades, which ensure timely patching of known software vulnerabilities, are disabled.

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.

A publicly accessible Amazon RDS instance unnecessarily broadens an organization's attack surface. Services open to interaction with the public are subjected to almost continuous scanning and probing by attackers.

Example 1: The following Ansible task sets up an RDS instance with public access because publicly_accessible is set to true.

- name: createdb
  community.aws.rds_instance:
    db_instance_identifier: test-db
    engine: aurora
    instance_type: db.t2.small
    username: "{{ username }}"
    password: "{{ password }}"
    cluster_id: test-cluster
    publicly_accessible: true

Cloud services typically use techniques like caching, replication, and load balancing to facilitate service scalability, deliver content faster, and mitigate the impacts of volumetric attacks. Disabled or misconfigured availability features degrade service performance, but immediate effects are often not apparent until extreme events such as traffic spikes and hardware failures occur.