Scenarios of Insufficient Logging & Monitoring — An OWASP Perspective

One of the critical pillars of robust cybersecurity defense lies in ensuring that log collection meets or surpasses the EPS (Events Per Second) values outlined in the SANS EPS calculation table.
This factor plays a pivotal role in safeguarding your organization against threats.
However, inadequate logging due to constraints within SIEM system requirements or resource limitations stands out as a prominent risk identified by OWASP.
This limitation significantly impacts incident response capabilities and
forensic investigations, leaving organizations vulnerable to potential
threats and extensive recovery periods.

Below are the example scenarios from OWASP:

Scenario #1
Access keys of an administrative API were leaked on a public repository. The repository owner was notified by email about the potential leak, but took more than 48 hours to act upon the incident, and access keys exposure may have allowed access to sensitive data. Due to insufficient logging, the company is not able to assess what data was accessed by malicious actors.

Scenario #2
A video-sharing platform was hit by a “large-scale” credential stuffing attack. Despite failed logins being logged, no alerts were triggered during the timespan of the attack. As a reaction to user complaints, API logs were analyzed and the attack was detected. The company had to make a public announcement asking users to reset their passwords, and report the incident to regulatory authorities.

Scenario #3:
A children’s health plan provider’s website operator couldn’t detect a breach due to a lack of monitoring and logging. An external party informed the health plan provider that an attacker had accessed and modified thousands of sensitive health records of more than 3.5 million children. A post-incident review found that the website developers had not addressed significant vulnerabilities. As there was no logging or monitoring of the system, the data breach could have been in progress since 2013, a period of more than seven years.

Scenario #4:
A major Indian airline had a data breach involving more than ten years’ worth of personal data of millions of passengers, including passport and credit card data. The data breach occurred at a third-party cloud hosting provider, who notified the airline of the breach after some time.

Scenario #5:
A major European airline suffered a GDPR reportable breach. The breach was reportedly caused by payment application security vulnerabilities exploited by attackers, who harvested more than 400,000 customer payment records. The airline was fined 20 million pounds as a result by the privacy regulator.

Scenario #6:
An open source project forum software run by a small team was hacked using a flaw in its software. The attackers managed to wipe out the internal source code repository containing the next version, and all of the forum contents. Although source could be recovered, the lack of monitoring, logging or alerting led to a far worse breach. The forum software project is no longer active as a result of this issue.

Scenario #7:
An attacker uses scans for users using a common password. They can take over all accounts using this password. For all other users, this scan leaves only one false login behind. After some days, this may be repeated with a different password.

Scenario #8:
A major US retailer reportedly had an internal malware analysis sandbox analyzing attachments. The sandbox software had detected potentially unwanted software, but no one responded to this detection. The sandbox had been producing warnings for some time before the breach was detected due to fraudulent card transactions by an external bank.

Scenario #9
Application logs are turned off. When a breach attempt occurs, security teams are unable to determine who accessed the app and what they tried to do.

Scenario #10
A business-critical application stops functioning following a change. Since multiple changes have occurred, each resulting in an application update, it is challenging to find which developer introduced the particular change that caused the issue. Developers have to review each application version manually to locate the problematic version. Since each application “save” translates to an update, the number of updates would make a manual process prohibitively expensive and time-consuming. On some platforms, developers can only review the application’s current version, so they won’t be able to find or revert to a stable version.

Scenario #11
A developer builds an automated process to load data into a financial system to complete order processing. The process handles around one thousand transactions per week with a 97% success rate. The 3% that fail are processed manually off of a daily Failed Transaction email.

The Failed Transaction email fails to get sent for a few days before its absence is noticed. Due to poor logging there is no easy way to find the failed records. Instead 100% of all transactions have to be investigated to find the failures, resulting in a significantly larger task.

Scenario #12
An application to process credit card payments at a conference is created. As part of its creation, a detailed log file is created to track the transactions and stored on a shared network drive. The logging includes records of the credit card details. A user browsing the network drive discovers this file and is able to obtain all of the credit card data.