Encryption at the SOAP message level ensures true end-to-end confidentiality. SOAP messages can be sent over a number transport protocols such as HTTPS, HTTP, TCP, SMTP, UDP, etc. Message-level encryption ensures the confidentiality of the message regardless of the transport protocol. A common scenario among web services is to relay SOAP messages between services, so message-level encryption means message senders and receivers do not need to worry about all transport security between relay points.

Encryption at the SOAP message level ensures true end-to-end confidentiality. SOAP messages can be sent over a number transport protocols such as HTTPS, HTTP, TCP, SMTP, UDP, etc. Message-level encryption ensures the confidentiality of the message regardless of the transport protocol. A common scenario among web services is to relay SOAP messages between services, so message-level encryption means message senders and receivers do not need to worry about all transport security between any relay points.

By default, EBS volumes are not encrypted.
Example 1: The following example template exposes the data to potential theft and unauthorized access.

	Resources:
  	  EBSVOLExample:
    	Type: AWS::EC2::Volume
    	Properties:
      	  Encrypted: false
	

An Amazon EC2 AMI that maps an unencrypted block device exposes the data to unauthorized access and potential theft.

Example 1: The following Ansible task creates an Amazon EC2 AMI and attaches a block device without data at rest encryption to the AMI because the encrypted parameter is set to false.

- name: Basic AMI Creation
  amazon.aws.ec2_ami:
    state: present
    instance_id: i-xxxxxx
    name: test_ami
    device_mapping:
      device_name: /dev/sda
      encrypted: false

An unencrypted Amazon Kinesis stream storage layer exposes the data to unauthorized access and potential theft.

Example 1: The following Ansible task sets up a Kinesis stream without data at rest encryption because the encryption_state parameter is set to disabled.

- name: Set up Kinesis Stream with 10 shards and wait for the stream to become active
  community.aws.kinesis_stream:
    name: test-stream
    shards: 10
    wait: yes
    wait_timeout: 600
    encryption_state: disabled
  register: test_stream

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

Every cloud service security feature is designed to prevent or mitigate a known threat. When disabled by intent or negligence, it offers no protection.

By default, if a GKE node repeatedly reports an unhealthy status over a given period, GKE initiates a repair process for that node. Disabling node auto-repair prevents timely and automated replacements of unhealthy nodes on which mission-critical workloads might run.

Example 1: The following Terraform configuration disables node auto-repair of a node pool by setting auto_repair to false in the management block.

resource "google_container_node_pool" "node-pool-demo" {
...
  management {
    auto_repair = false
    ...
  }
...
}

By default, GKE nodes run with Container-Optimized OS (COS). COS is an operating system image that is optimized to run GKE nodes on Google Compute Engine instances. Opting out of the default forgoes the benefits of enhanced security and efficiency.

Example 1: The following example Terraform configuration sets up a pool of GKE nodes that do not run COS because image_type is set to a non-COS image in the node_config block.

resource "google_container_node_pool" "node_pool_demo" {
  ...
  node_config {
    image_type = "UBUNTU"
    ...
  }
  ...
}

Data backups are often over-looked as assets that require just as much protection as the original data.

Unencrypted backups leave the backup data accessible to potential attackers.

By default, Azure SQL Virtual Machines Automated Backup settings do not enforce encryption of data backups.

Example 1: The following example shows a Terraform configuration that defines Azure SQL Virtual Machine Automated Backup settings that do not enforce encryption of backup data.

resource "azurerm_mssql_virtual_machine" "aztf009-tn-03" {
  virtual_machine_id               = data.azurerm_virtual_machine.example.id
  ...
  auto_backup {
    retention_period_in_days = 1
    storage_blob_endpoint = ""
    storage_account_access_key = azurerm_storage_account.example.primary_access_key
  }
}

By default, GKE automatically upgrades Kubernetes nodes to newer stable versions. Automatic upgrades, which ensure timely patching of known software vulnerabilities, are disabled.

Example 1: The following example Terraform configuration disables automatic upgrades of Kubernetes nodes by setting auto_upgrade to false in the management block.

resource "google_container_node_pool" "node_pool_demo" {
...
  management {
    auto_upgrade = false
    ...
  }
...
}

Unencrypted communication channels are prone to eavesdropping and tampering.

Disabling transport security exposes the data to unauthorized access, potential theft, and tampering.

Unencrypted communication channels are prone to eavesdropping and tampering.

Disabling transport security exposes the data to unauthorized access, potential theft, and tampering.

Loose access configurations can expose systems and broaden an organization's attack surface. Services open to interaction with the public are typically subjected to near-continuous scanning and probing by malicious entities.

This is especially problematic when a zero-day exploit for an exposed service is discovered and published, such as Heartbleed. Attackers can actively pursue and search for unpatched and exposed systems to exploit.

Loose access configurations can expose systems and broaden an organization's attack surface. Services open to interaction with the public are typically subjected to near-continuous scanning and probing by malicious entities.

This is especially problematic when a zero-day exploit for an exposed service is discovered and published, such as Heartbleed. Attackers can actively pursue and search for unpatched and exposed systems to exploit.

Loose access configurations can expose systems and broaden an organization's attack surface. Services open to interaction with the public are typically subjected to near-continuous scanning and probing by malicious entities.

This is especially problematic when a zero-day exploit for an exposed service is discovered and published, such as Heartbleed. Attackers can actively pursue and search for unpatched and exposed systems to exploit.

Loose access configurations can expose systems and broaden an organization's attack surface. Services open to interaction with the public are typically subjected to near-continuous scanning and probing by malicious entities.

This is especially problematic when a zero-day exploit for an exposed service is discovered and published, such as Heartbleed. Attackers can actively pursue and search for unpatched and exposed systems to exploit.

Loose access configurations can expose systems and broaden an organization's attack surface. Services open to interaction with the public are typically subjected to near-continuous scanning and probing by malicious entities.

This is especially problematic when a zero-day exploit for an exposed service is discovered and published, such as Heartbleed. Attackers can actively pursue and search for unpatched and exposed systems to exploit.

Loose access configurations can expose systems and broaden an organization's attack surface. Services open to interaction with the public are typically subjected to near-continuous scanning and probing by malicious entities.

This is especially problematic when a zero-day exploit for an exposed service is discovered and published, such as Heartbleed. Attackers can actively pursue and search for unpatched and exposed systems to exploit.

Loose access configurations can expose systems and broaden an organization's attack surface. Services open to interaction with the public are typically subjected to near-continuous scanning and probing by malicious entities.

This is especially problematic when a zero-day exploit for an exposed service is discovered and published, such as Heartbleed. Attackers can actively pursue and search for unpatched and exposed systems to exploit.

Loose access configurations can expose systems and broaden an organization's attack surface. Services open to interaction with the public are typically subjected to near-continuous scanning and probing by malicious entities.

This is especially problematic when a zero-day exploit for an exposed service is discovered and published, such as Heartbleed. Attackers can actively pursue and search for unpatched and exposed systems to exploit.