A Security timestamp indicates a message's freshness. If an attacker intercepts a message retransmits it at a later time, the receiver can reject the replay attack because the timestamp will indicate that the message is stale. Optionally, timestamps can include an expiration attribute which places a hard limit on how long security semantics are valid.

To prevent attackers from tampering with timestamps, timestamps should be signed. Without a signed timestamp, it might be possible to intercept a SOAP message, modify the timestamp, and send the message on without the receiver's knowledge. Under these circumstances, an attacker may potentially trick a recipient into accepting a malicious message.

A Security timestamp indicates a message's freshness. If an attacker intercepts a message retransmits it at a later time, the receiver can reject the replay attack because the timestamp will indicate that the message is stale. Optionally, timestamps can include an expiration attribute which places a hard limit on how long security semantics are valid.

To prevent attackers from tampering with timestamps, timestamps should be signed. Without a signed timestamp, it might be possible to intercept a SOAP message, modify the timestamp, and send the message on without the receiver's knowledge. Under these circumstances, an attacker may potentially trick a recipient into accepting a malicious message.

A Security timestamp indicates a message's freshness. If an attacker intercepts a message retransmits it at a later time, the receiver can reject the replay attack because the timestamp will indicate that the message is stale. Optionally, timestamps can include an expiration attribute which places a hard limit on how long security semantics are valid.

To prevent attackers from tampering with timestamps, timestamps should be signed. Without a signed timestamp, it might be possible to intercept a SOAP message, modify the timestamp, and send the message on without the receiver's knowledge. Under these circumstances, an attacker may potentially trick a recipient into accepting a malicious message.

Service Providers that use the UsernameToken might accept passwords sent in plain text. Sending plain text passwords over an unencrypted channel can expose the credential to attackers who can sniff the SOAP message.

Example 1: The following WebSphere service provider configuration uses the UsernameToken:

<com.ibm.etools.webservice.wsext:WsExtension xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:com.ibm.etools.webservice.wsext="http://www.ibm.com/websphere/appserver/schemas/5.0.2/wsext.xmi" xmi:id="WsExtension_1152150731239">
...
        <securityRequestConsumerServiceConfig xmi:id="SecurityRequestConsumerServiceConfig_1211399165585">
          <requiredSecurityToken xmi:id="RequiredSecurityToken_1211399165605" name="Token_34865684" uri="" localName="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#UsernameToken" usage="Required"/>
...
</com.ibm.etools.webservice.wsext:WsExtension>

Encryption at rest is not enabled. This exposes data to unauthorized access and potential theft.

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

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

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

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

By default, an HTTP trigger enables a Cloud Function to run in response to HTTPS requests only. Allowing insecure HTTP requests exposes data to unauthorized access, potential theft, and tampering.

Example 1: The following example shows a Terraform configuration that defines an HTTP trigger that fails to enforce HTTPS endpoints by setting https_trigger_security_level to SECURE_OPTIONAL.

resource "google_cloudfunctions_function" "demo_function" {
...
  trigger_http = true
  https_trigger_security_level = "SECURE_OPTIONAL"
...
}

Sending plain text passwords over an unencrypted channel can expose the credential to attackers who can sniff the SOAP message.

Example 1: The following WebSphere client configuration uses the UsernameToken:

<com.ibm.etools.webservice.wscext:WsClientExtension xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:com.ibm.etools.webservice.wscext="http://www.ibm.com/websphere/appserver/schemas/5.0.2/wscext.xmi" xmi:id="WsClientExtension_1151349988084">
...
        <securityRequestGeneratorServiceConfig xmi:id="SecurityRequestGeneratorServiceConfig_1154318832968">
          <securityToken xmi:id="SecurityToken_1211395747219" name="basicauth" uri="" localName="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#UsernameToken"/>
...
</com.ibm.etools.webservice.wscext:WsClientExtension>

Implementation flaws, misconfigurations, and compromised keys are some of the problems that prevent single-layer encryption from fully protecting highly-sensitive data. Organizations should adopt a defense-in-depth approach to protect highly-sensitive data and avoid having a single-point-of-failure in their security design.

Amazon CloudFront Distribution can be misconfigured to allow unauthenticated or unencrypted communication, or use an outdated protocol. Such misconfigurations can cause compromise and allow an attacker, residing on a shared network, to snoop and tamper with data in transit.

By default, an EFS file system is not encrypted. This exposes the data to unauthorized access and potential theft.

Example 1: The following Ansible task sets up an EFS file system without data at rest encryption because the encrypt parameter is set to no.

- name: EFS provisioning
  community.aws.efs:
    state: present
    name: myTestEFS
    encrypt: no
    targets:
      - subnet_id: subnet-12345678
        security_groups: [ "sg-87654321" ]

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

Physical media theft is a common means for attackers to gain access to confidential information.

By default, Azure SQL Databases use Transparent Data Encryption (TDE) to encrypt and protect data at rest.

Disabling TDE for an Azure SQL Database exposes the data to potential theft.

Example 1: The following example shows a Terraform configuration that defines an Azure SQL Database that does not encrypt its data.

resource "azurerm_mssql_database" "aztf008-tp-01" {
  name           = "aztf008-db-d"
  ... 
  sku_name       = "DW100c"
  ...
  transparent_data_encryption_enabled = false
}

Encryption at rest is not enabled. This exposes data to unauthorized access and potential theft.

Encryption at rest is not enabled. This exposes data to unauthorized access and potential theft.

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.

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.