OWASP Top Ten 2017: Insufficient Logging & Monitoring

Overview

This JSON response provides information and recommendations on the OWASP Top Ten 2017 vulnerability category A10: Insufficient Logging & Monitoring. It explains the threat agents and attack vectors, security weaknesses, and impacts of this vulnerability. The response also includes recommendations on how to prevent insufficient logging and monitoring, as well as example attack scenarios. References to relevant OWASP resources and external sources are provided as well.

Description

Insufficient logging and monitoring is a critical vulnerability that can lead to major security incidents. Attackers often exploit the lack of monitoring and timely response to achieve their goals without being detected. This JSON response provides detailed information on the vulnerability and offers preventive measures to mitigate the risk. It is based on the OWASP Top Ten 2017 list and provides valuable insights for developers and security professionals.

How to Prevent ?

To prevent insufficient logging and monitoring, it is crucial to ensure that all auditable events, such as logins, failed logins, and high-value transactions, are properly logged. Warnings and errors should generate clear and adequate log messages. Additionally, application and API logs should be monitored for suspicious activity. Logs should be securely stored, and effective alerting thresholds and response escalation processes should be established. Penetration testing and scans should trigger alerts, and real-time or near-real-time detection of active attacks should be implemented. It is also recommended to have an incident response and recovery plan in place.

Example Attack Scenarios:

• Scenario 1: Open Source Project Forum Breach:  In this scenario, an open source project forum software was hacked due to a flaw in its software. The attackers wiped out the internal source code repository and all forum contents. The lack of monitoring, logging, and alerting exacerbated the breach and caused significant damage. As a result, the forum software project is no longer active.

• Scenario 2: Password Scans and Account Takeover:  In this scenario, an attacker performs scans for users with a common password. They are able to take over all accounts that use this password. For other users, the scan leaves behind one false login. This attack can be repeated with different passwords over time.

• Scenario 3: Internal Malware Analysis Sandbox Breach:  In this scenario, a major US retailer had an internal malware analysis sandbox. The sandbox software detected potentially unwanted software, but no action was taken to address the detection. The sandbox produced warnings over time until the breach was eventually detected due to fraudulent card transactions by an external bank.