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 misconfiguration of public access to an S3 bucket is a leading cause of data breaches.

Although S3 buckets block public access by default, any authorized user can update bucket policies or access control lists (ACLs) to allow public access.

A Terraform configuration creates a Cloud Storage Bucket without enabling usage and storage logs. These logs contain valuable data for network monitoring, forensics, real-time security analysis, and expense optimization.

Example 1: The following example shows a Terraform configuration that creates a Cloud Storage Bucket without enabling usage and storage logging because the log_bucket argument is missing.

resource "google_storage_bucket" "bucket-demo" {
    name     = "name-demo"
    location = "US"
}

By default, a Google Kubernetes Engine (GKE) cluster writes logs to the Stackdriver Kubernetes Engine Logging Service. The Terraform configuration sets up a GKE cluster and explicitly disables the logging service. Logs contain valuable data used to identify security incidents, monitor policy violations, and assist with non-repudiation controls.

Example 1: The following example shows a Terraform configuration that disables the logging service of a GKE cluster by setting logging_service to none.

resource "google_container_cluster" "cluster-demo" {
    name            = "name-demo"
    location        = "us-central1-a"
    logging_service = "none"
    ...
}

By default, a Google Kubernetes Engine (GKE) cluster sends metrics from Pods to the Stackdriver Kubernetes Engine Monitoring Service. The Terraform script sets up a GKE cluster and explicitly disables the monitoring service. The absence of metrics undermines proper detection of and prompt response to security events.

Example 1: The following example shows a Terraform configuration that disables the monitoring service of a GKE cluster by setting monitoring_service to none.

resource "google_container_cluster" "cluster-demo" {
    name               = "name-demo"
    location           = "us-central1-a"
    monitoring_service = "none"
    ...
}

There are numerous risks associated with presence of files with easy-to-guess names and locations. Through enumeration, attackers can fingerprint platforms and applications that are known to use specific file names. These files can also lead to exposure of sensitive information and privileged functionality. Predictable file names could expose admin interfaces, sensitive system information, configuration details, business logic and allow an attacker to add, remove or modify application functionality. Reconnaissance is a fundamental step of a successful attack strategy. Predictable file names can make it very easy to map their target and obtain information essential for compromising it.

All SSL/TLS certificates issued before December 1, 2017 from the Symantec infrastructure are deprecated and are no longer trusted by major browsers including Chrome, Firefox, Safari, Internet Explorer, and Edge. This includes all certificates issued by Symantec and its affiliated subsidiary CA's: Thawte, GeoTrust, Equifax, Verisign, and RapidSSL.
Symantec CA public key infrastructure was acquired by DigiCert in October 2017. Starting December 1, 2017, DigiCert took over the validation and issuance of all Symantec SSL/TLS certificates. These new and reissued certificates that use DigiCert as the root CA are trusted by all browsers.
Deprecated certificates imply that the certificate fails to protect the privacy and integrity of user data on the SSL/TLS communication channel. Customers who access websites that use deprecated certificates receive a "Your connection is not private" warning to deter them from continuing to the website.

Weak authentication mechanisms expose organizations to unauthorized access.

Authentication mechanisms can fail for various reasons, such as:
- Weak passwords
- Improper validation
- Weak credential management

Weak authentication mechanisms expose organizations to unauthorized access.

Authentication mechanisms can fail for various reasons, such as:
- Weak passwords
- Improper validation
- Weak credential management

Weak authentication mechanisms expose organizations to unauthorized access.

Authentication mechanisms can fail for various reasons, such as:
- Weak passwords
- Improper validation
- Weak credential management

Weak authentication mechanisms expose organizations to unauthorized access.

Authentication mechanisms can fail for various reasons, such as:
- Weak passwords
- Improper validation
- Weak credential management

Weak authentication mechanisms expose organizations to unauthorized access.

Authentication mechanisms can fail for various reasons, such as:
- Weak passwords
- Improper validation
- Weak credential management

Weak authentication mechanisms expose organizations to unauthorized access.

Authentication mechanisms can fail for various reasons, such as:
- Weak passwords
- Improper validation
- Weak credential management

Weak authentication mechanisms expose organizations to unauthorized access.

Authentication mechanisms can fail for various reasons, such as:
- Weak passwords
- Improper validation
- Weak credential management

Public access of an S3 bucket due to misconfigurations is a leading cause of data breaches.
Although S3 buckets block public access by default, any authorized user can update bucket policies or access control lists (ACLs) to allow public access. Forbid this type of update by enabling the setting of BlockPublicPolicy and BlockPublicAcls respectively under an S3 property of PublicAccessBlockConfiguration.
To also guard against any pre-existing overly-permissive bucket policies and ACLs respectively, enable the settings of RestrictPublicBuckets and IgnorePublicAcls.

Programmers can leverage several different approaches to implementing authentication systems. Web form and network authentication are two commonly used forms of authentication. The effectiveness of network authentication is partly determined by the server configuration. HTTP headers are commonly used for network authentication. Incorrect configuration of these headers or application of the headers to resources that do not need to protected can either allow an attacker to bypass header-based authentication or disrupt availability of system resources.

Failure to disable unnecessary services such as WebDAV of Microsoft IIS or processing insufficiently validated HTTP requests could open up access to restricted information or allow an attacker to gain administrative privileges.

An AWS IAM Principal defines access to a resource for a user, service, or other entity. In an IAM Statement, there is a definition of an IAM Principal that allows everyone to access an S3 action.

Secrets with long validity periods are prone to theft and consequently place the organization at risk of breach.

Example 1: The following example shows a template that defines a key without an expiration date.

@secure()
param secretValue string

resource example 'Microsoft.KeyVault/vaults/secrets@2019-09-01' = {
    ...
    properties: {
        ...
        value: secretValue
    }
}