Unencrypted communication channels are prone to eavesdropping and tampering. Servicing client requests over an insecure communications channel allows attackers to perform man-in-the-middle attacks, and gives them access to read or modify the data in transit.

Unencrypted communication channels are prone to eavesdropping and tampering. Servicing client requests over an insecure communications channel allows attackers to perform man-in-the-middle attacks, and gives them access to read or modify the data in transit.

Unencrypted communication channels are prone to eavesdropping and tampering. Servicing client requests over an insecure communications channel allows attackers to perform man-in-the-middle attacks, and gives them access to read or modify the data in transit.

Unencrypted communication channels are prone to eavesdropping and tampering. Servicing client requests over an insecure communications channel allows attackers to perform man-in-the-middle attacks, and gives them access to read or modify the data in transit.

Unencrypted communication channels are prone to eavesdropping and tampering. Servicing client requests over an insecure communications channel allows attackers to perform man-in-the-middle attacks, and gives them access to read or modify the data in transit.

Unencrypted communication channels are prone to eavesdropping and tampering. Servicing client requests over an insecure communications channel allows attackers to perform man-in-the-middle attacks, and gives them access to read or modify the data in transit.

Mismanagement of permissions increases the risk of unauthorized access to or modification of restricted data.

To define user permission for access to buckets and objects in buckets, Google Cloud Storage offers two systems: Access Control Lists (ACLs) and Identity and Access Management (IAM). IAM can be used throughout Google Cloud, while only Cloud Storage supports ACLs. Enabling Uniform Bucket-level Access prevents ACLs from granting permission. This ensures IAM is the only system to manage all access control of Google Cloud resources.

Example 1: The following Terraform configuration permits using ACLs alongside IAM to grant access to the storage bucket by setting uniform_bucket_level_access to false.

resource "google_storage_bucket" "bucket-demo" {
...
  uniform_bucket_level_access = false
...
}

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
    }
}

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 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 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 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 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 rest is not enabled. This exposes data to unauthorized access and potential theft.

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.