Insufficient Logging and Monitoring, a TOP 10 Security Risk

In an awareness document aimed at application security specialists, the Open Web Application Security Project (OWASP) identified "insufficient logging and monitoring" as among the top 10 most critical web application security risks.

OWASP Top 10 2017: Insufficient Logging and Monitoring

The Open Web Application Security Project (OWASP) is an open community that provides various resources related to application security. Based on research including an industry survey, OWASP recognized in their Top Ten 2017 Project that insufficient logging and monitoring has allowed malicious actors to attack without detection or without sufficient alerting for security teams.

The report states that most successful attacks begin with vulnerability probing. Often, a breach can be prevented if the initial probing is detected promptly. In contrast, the report links to a data breach study in which it took, on average, 191 days to identify a breach—even after a breach has already occurred. This slow response to an attack can be greatly improved with adequate event monitoring.

OWASP published a list of specific ways in which the logging and monitoring infrastructure may not be sufficient to respond to an attack, including:

  • Auditable events are not recorded

  • Log messages are not clear

  • Log data is not monitored during normal operation

  • Log data is only stored locally, allowing logs to be modified during an attack or lost before a breach is identified

  • Alerts are not generated in a way that initiates a response from the security team

  • Event data is exposed to users or attackers

Security Incidents Detectable by Adequate Log Collection

A lot of security incidents can be prevented or mitigated with good log collection and monitoring in place. Some examples are listed below:

NotPetya and BadRabbit ransomware

NotPetya and BadRabbit both utilize Mimikatz, which can extract plaintext passwords, hashes, PIN codes, and Kerberos tickets from memory. The execution of this tool provides a sequence of traces in the form of event codes through Sysmon events as well as Windows EventLog. These traces would have been captured by sufficient logging of Sysmon events and EventLog events.

DNS attacks and malware traffic

DNS hijacking attacks and other DNS anomalies can be allowed to continue without sufficient logging and monitoring of DNS queries and responses. Adequate logging of DNS traffic can also lead to discovery of compromised clients communicating with command-and-control servers.

Attacks by botnets

Botnet attacks, such as one based on the Broadcom UPnP Remote Preauth Code Execution vulnerability, often have a chain of infection which runs through a series of stages. The logging of network activity is crucial for later analysis of the attack. Many network devices support activity logging via Syslog.

Logging hosts for threats

WinNTI, a trojan by an advanced persistent threat (APT) group, executes a series of steps on the host machine such as hiding the payload in the Registry, modifying Registry permissions, reconnaissance, and other dubious activities. Detection and forensic analysis are possible with sufficient logging on the host, including logging of Windows EventLog and PowerShell activity.

Implementing OWASP Logging Guidelines

The OWASP report provides several recommendations for improving logging and monitoring. Unfortunately, there are many real-world challenges which make it difficult to set up an effective logging infrastructure. The NXLog Enterprise Edition has a flexible design and features that can handle event data effectively and help security teams overcome these challenges.

With regard to a logging infrastructure, the report’s recommendations fall into these general categories:


Auditable events should be logged with sufficient context.

In NXLog, each event is a set of fields. NXLog can be configured to add fields during processing based on the event source, lookup, or other rules. It was designed to work with structured data.


Events should be retained for long enough that delayed forensic analysis can be performed when necessary.

NXLog can be used to implement different kinds of rotation and retention policies.


Log data should be generated in a format suitable for centralized log management.

NXLog can collect, parse, convert, and generate log data in various formats, such as XML, JSON, KVP, Syslog and others, whether configured as a local agent to forward logs or when used as a collector to ingest agent-less data.


High-value transactions should have an audit trail with controls to prevent tampering.

Standard SSL/TLS is supported by various NXLog modules for sending and receiving encrypted log data. There are other safeguards available as well, such as HMAC checksumming and duplication prevention. Events can be written to append-only database tables via ODBC or other database modules.


Suspicious activities should be detected and responded to promptly.

Event data collected by NXLog can be forwarded to a third-party dashboard for monitoring, such as ELK or Graylog and it supports all major SIEM products. NXLog can be configured to send alerts when events match specified conditions.

While logging is a basic security requirement, there may be further opportunities to improve your log collection system. Armed with the tools and expert knowledge from NXLog, let’s aim for sufficient logging, with no excuses!

Download a fully functional trial of the Enterprise Edition for free