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

Amazon S3 buckets do not save access logs by default. The logs, however, contain value data used to identify security incidents, monitor policy violations, and assist with non-repudiation controls.

The template does not forward audit logs to Amazon CloudWatch for monitoring. This can allow malicious behavior to go undetected and lead to delayed incident response.

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

A Kubernetes API server writes audit events to standard output by default. The audit events should be logged to persistent storage. The audit events contain valuable data used to identify security incidents, monitor policy violations, and assist with non-repudiation controls.

Example 1: The following configuration starts a Kubernetes API server without the --audit-log-path flag.

...
spec:
  containers:
  - command:
    - kube-apiserver
    - --authorization-mode=RBAC
  image: example.domain/kube-apiserver-amd64:v1.6.0
...

A Kubernetes API server does not log events if there is no audit policy file specified. The event logs contain valuable data used to identify security incidents, monitor policy violations, and assist with non-repudiation controls.

Example 1: The following configuration starts a Kubernetes API server without the --audit-policy-file flag.

...
spec:
  containers:
  - command:
    - kube-apiserver
    - --audit-log-path=<the log file path>
  image: example.domain/kube-apiserver-amd64:v1.6.0
  ...

By default, Amazon Redshift clusters do not capture audit logs. This can allow malicious behavior to go undetected and inhibit forensic analysis in the event of a breach.

Example 1: The following example template defines an Amazon Redshift cluster without audit logging.

  "Resources": {
    "RedshiftClusterTest": {
      "Properties": {
        "NodeType": "dc1.large",
        "Port": 5439,
        "VpcSecurityGroupIds": [
          "${RedshiftSecurityGroup}"
        ],
        "ClusterSubnetGroupName": "RedshiftClusterSubnetGroup",
        "ClusterType": "single-node"
        "MasterUserPassword": "MasterUserPassword",
        "MasterUsername": "MasterUsername",
        "DBName": "${DatabaseName}",
        "IamRoles": ["RawDataBucketAccessRole.Arn"],
        "PubliclyAccessible": true
      },
      "Type": "AWS::Redshift::Cluster"
    }

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

A lack of audit records limits the ability to detect and respond to security related incidents and prevents forensic investigation.

This permission has a "dangerous" protection level. Permissions designated as dangerous imply an increased risk to user data privacy or device operation. In this case, access to the call log can pose a danger to user privacy and personal safety. Applications that require access to the call log must manage it with the utmost caution.

Example 1: The <uses-permission .../> element of AndroidManifest.xml declares usage of the READ_CALL_LOG permission, which enables an application to read the user's call log.

 <uses-permission android:name="android.permission.READ_CALL_LOG"/> 

Example 2: The <uses-permission .../> element of AndroidManifest.xml declares usage of the WRITE_CALL_LOG permission, which enables an application to write to the user's call log.

 <uses-permission android:name="android.permission.WRITE_CALL_LOG"/> 

Avoid logging SQL queries in production systems. SQL queries often contain sensitive information, such as credit card details or social security numbers, and logging this information in plain text can compromise its confidentiality.

Example 1: The following entries from log4j.properties file causes all queries to be logged at the info level.

...
log4j.logger.net.sf.hibernate.type=info
log4j.logger.net.sf.hibernate.tool.hbm2ddl=info
...

ASP.NET W3Clogger.loggingFields can be configured to allow logging sensitive data such as private and system information.
This data can contain sensitive information related to HTTP requests and HTTP responses such as clients/server IP, server ports, header cookies and authenticated usernames that accessed the server.

In case of data breach, adversary can use this information to:

- Steal sensitive information or impersonate a user with higher privileges.
- Discover internal servers, gain unauthorized access to restricted resources.
- Devise attacks focused on exploiting known vulnerabilities reported against the detected server


Example 1: The following code shows an action method in a controller where validation has been disabled:

  builder.Services.AddW3CLogging(logging =>
    logging.LoggingFields = W3CLoggingFields.All;

    ... )

Example 1 shows how W3Clogging can be configure, using Flag All, to log all possible fields in Http request, including sensitive data such as ClientIpAddress, ServerName, ServerIpAddress, ServerPort, UserName, and Cookie.

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

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

Log files should be kept long enough to facilitate post-incident analysis and threat detection, as well as to meet compliance requirements. The --audit-log-maxage flag defines the maximum number of days to retain old audit log files. Either the flag is not present in the command to start a Kubernetes API server or the retention period is set to less than 30 days.

Example 1: The following command starts a Kubernetes API server and sets --audit-log-maxage flag to 2 (2 days), which is too short.

...
kind: Pod
...
spec:
  containers:
  - command:
    - kube-apiserver
    ...
    - --audit-log-maxage=2
    ...

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.

ASP.NET MVC controller actions that modify data by writing, updating, or deleting could benefit from being restricted to accept one of the following HTTP verbs: Post, Put, Patch, or Delete. This increases the difficulty of cross-site request forgery because accidental clicking of links will not cause the action to execute.

The following controller action by default accepts any verb and may be susceptible to cross-site request forgery:

public ActionResult UpdateWidget(Model model)
{
  // ... controller logic
}

ASP.NET MVC provides a convenient way to better protect an application against cross-site request forgery by adding an antiforgery token at the form side and validating that antiforgery token at the controller. If used, this token is usually included as a hidden form field and validated when the form is submitted, which increases the chances that a request is from your application and not forged.

The following controller code does not include the built-in defense against cross-site request forgery:

public ActionResult ActionName(Model model, string returnurl)
{
  // ... controller logic
}