"The OWASP Top 10 is a standard awareness document for developers and web application security. It represents a broad consensus about the most critical security risks to web applications."
In this article these top security risks discussed in the context of log collection.
OWASP API security top 10 most critical API security risks
APIs are a critical part of modern technologies - from SaaS and web consumer applications to enterprise deployments. The API Security Top 10 2019 has included Insufficient Logging and Monitoring as a risk to secure APIs.
OWASP top 10 most critical web application security risks
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 10 Web Application Security Risks 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
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 Event Log. These traces would have been captured by sufficient logging of Sysmon and Windows Event Log 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 Event Log and Windows 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:
| Context |
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. |
| Retention |
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. |
| Format |
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. |
| Integrity |
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. |
| Monitoring |
Suspicious activities should be detected and responded to promptly. |
