OWASP Top 10: Security Logging and Monitoring Failures

Security logging and monitoring failures can be classified into two main groups. The first is a failure to implement proper security logging within a web application. For example, a web application may not log failed login attempts, which can be a potential indicator of account takeover attacks. Alternatively, the application may implement logging, but these logs could lack the detail required to diagnose and respond to a potential threat.

If an application does implement logging, these logs may not be monitored regularly for potential suspicious activity. This may be due to inadequate security processes, local log storage, or a failure to implement proper alert escalation and notification processes. As a result, the organization doesn’t respond to detected threats, increasing the potential impact of an attack.

What is the Risk?

Security logs are intended to provide visibility into potential attacks against a web application. For example, a web app may log failed login attempts, and a sudden surge in these could indicate a credential stuffing or password guessing attack against the application.

If a web application fails to log security events or these logs aren’t monitored, the security team may be unaware that the application is under attack. This could result in data breaches, application downtime, or other effects if the attacker successfully gains access to a user account, exploits a vulnerability, or causes the application to crash.

Examples of Attack Scenarios

Security logging and monitoring failures can be exploited any time that a cybercriminal attacks a web application. If the organization doesn’t implement proper logging and monitoring, the attack will take longer to detect, increasing the probability that the attacker will be successful.

For example, a credential stuffing attack is a simple but noisy type of cyberattack. The cybercriminal has a list of usernames and breached passwords from other websites or applications. They try each of these sets of breached credentials in turn, looking for a match. If someone used the same credentials on multiple sites, there is a chance that the attacker will successfully gain access.

In this attack, each incorrect set of credentials results in a failed login attempt, which should be logged and generate a security alert if a particular threshold is exceeded. However, if the web application lacks proper logging and alerting or the security team isn’t monitoring, then the attack may go undetected for some time. This increases the probability that an attacker will find a valid set of credentials and gain unauthorized access to a user account.

Case Study: Equifax

The 2017 Equifax breach is one of the largest in history. The attackers maintained access to the systems of the credit reporting agency for three months (May to July 2017) and stole the personal data of about 148 million Americans, 15.2 million British citizens, and 19,000 Canadians. Stolen data included highly sensitive information, such as Social Security Numbers (SSNs), driver’s license numbers, and credit card numbers.

A failure to implement proper security logging and monitoring was central to the Equifax breach. The company had failed to renew a crucial SSL certificate nine months earlier, limiting visibility into network traffic, and it failed to implement proper application logging. For example, the attackers ran about 9,000 queries against Equifax systems and extracted data from 51 databases over the course of several months without detection.

How to Remediate Security Logging and Monitoring Failures

Logging and monitoring failures are a combination of software and process issues. Some best practices for remediating them include:

• Log Significant Security Events: A web application should generate logs for certain security events, such as successful and failed logins or attempted access to sensitive resources.
• Include Necessary Context: Logs and alerts should include the context required to identify and respond to potential threats. For example, a log of a failed login attempt should include the account identifier to allow correlation of multiple failed attempts for a user account and detection of likely compromised user accounts.
• Store Logs Securely: Log files should be stored in a way that means they will likely be available for analysis in the wake of a cybersecurity incident. This means that an organization should establish log retention timelines and store logs on a secure system to prevent deletion by an attacker.
• Protect Against Injection: Log files may include user-provided data. This data should be encoded in a way that protects against injection attacks targeting log monitoring and alerting solutions.
• Implement Monitoring Processes: Logs only provide value if they are reviewed for signs of a potential attack. The organization should have processes in place to ensure that they can quickly identify and address potential intrusions.
• Create an Incident Response Strategy: In the event of a successful cyberattack, the security team needs to act swiftly to minimize the impacts of the attack. The organization should have an incident response plan in place and train responders to ensure a quick, correct response.

How IONIX Can Help

The OWASP Top Ten list details the most significant current and emerging vulnerabilities to web applications. This provides valuable information both to developers looking to improve the security of their applications and attackers attempting to exploit them.

The IONIX platform helps organizations defend against these risks by performing proactive simulations of every OWASP Top Ten vulnerability as part of an initial risk assessment. To learn more about enhancing your threat visibility with IONIX, sign up for a free demo.