Insufficient Logging

When a security-critical event occurs, the product either does not record the event or omits important details about the event when logging it.


Description

When security-critical events are not logged properly, such as a failed login attempt, this can make malicious behavior more difficult to detect and may hinder forensic analysis after an attack succeeds.

As organizations adopt cloud storage resources, these technologies often require configuration changes to enable detailed logging information, since detailed logging can incur additional costs. This could lead to telemetry gaps in critical audit logs. For example, in Azure, the default value for logging is disabled.

Demonstrations

The following examples help to illustrate the nature of this weakness and describe methods or techniques which can be used to mitigate the risk.

Note that the examples here are by no means exhaustive and any given weakness may have many subtle varieties, each of which may require different detection methods or runtime controls.

Example One

The example below shows a configuration for the service security audit feature in the Windows Communication Foundation (WCF).

<system.serviceModel>
  <behaviors>
    <serviceBehaviors>
      <behavior name="NewBehavior">
        <serviceSecurityAudit auditLogLocation="Default"
        suppressAuditFailure="false"
        serviceAuthorizationAuditLevel="None"
        messageAuthenticationAuditLevel="None" />

      ...


</system.serviceModel>

The previous configuration file has effectively disabled the recording of security-critical events, which would force the administrator to look to other sources during debug or recovery efforts.

Logging failed authentication attempts can warn administrators of potential brute force attacks. Similarly, logging successful authentication events can provide a useful audit trail when a legitimate account is compromised. The following configuration shows appropriate settings, assuming that the site does not have excessive traffic, which could fill the logs if there are a large number of success or failure events (CWE-779).

<system.serviceModel>
  <behaviors>
    <serviceBehaviors>
      <behavior name="NewBehavior">
        <serviceSecurityAudit auditLogLocation="Default"
        suppressAuditFailure="false"
        serviceAuthorizationAuditLevel="SuccessAndFailure"
        messageAuthenticationAuditLevel="SuccessAndFailure" />

      ...


</system.serviceModel>

Example Two

In the following Java example the code attempts to authenticate the user. If the login fails a retry is made. Proper restrictions on the number of login attempts are of course part of the retry functionality. Unfortunately, the failed login is not recorded and there would be no record of an adversary attempting to brute force the program.

if LoginUser(){
  // Login successful
  RunProgram();
} else {
  // Login unsuccessful
  LoginRetry();
}

It is recommended to log the failed login action. Note that unneutralized usernames should not be part of the log message, and passwords should never be part of the log message.

if LoginUser(){
  // Login successful
  log.warn("Login by user successful.");
  RunProgram();
} else {
  // Login unsuccessful
  log.warn("Login attempt by user failed, trying again.");
  LoginRetry();
}

Example Three

Consider this command for updating Azure's Storage Logging for Blob service, adapted from [REF-1307]:

az storage logging update --account-name --account-key --services b --log d --retention 90

The "--log d" portion of the command says to log deletes. However, the argument does not include the logging of writes and reads. Adding the "rw" arguments to the -log parameter will fix the issue:

az storage logging update --account-name --account-key --services b --log rwd --retention 90

To enable Azure's storage analytic logs programmatically using PowerShell:

Set-AzStorageServiceLoggingProperty -ServiceType Queue -LoggingOperations read,write,delete -RetentionDays 5 -Context $MyContextObject

Notice that here, the retention has been limited to 5 days.

See Also

Comprehensive Categorization: Protection Mechanism Failure

Weaknesses in this category are related to protection mechanism failure.

OWASP Top Ten 2021 Category A09:2021 - Security Logging and Monitoring Failures

Weaknesses in this category are related to the A09 category "Security Logging and Monitoring Failures" in the OWASP Top Ten 2021.

CISQ Quality Measures - Security

Weaknesses in this category are related to the CISQ Quality Measures for Security. Presence of these weaknesses could reduce the security of the software.

Comprehensive CWE Dictionary

This view (slice) covers all the elements in CWE.

Weakness Base Elements

This view (slice) displays only weakness base elements.


Common Weakness Enumeration content on this website is copyright of The MITRE Corporation unless otherwise specified. Use of the Common Weakness Enumeration and the associated references on this website are subject to the Terms of Use as specified by The MITRE Corporation.