In awareness documents aimed at application and web 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 and top 10 API security risks for 2017 and 2019 respectively.
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.
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
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 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.
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.
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.