Insufficient Logging & Monitoring

Taking a look at what OWASP had in regards to this, we will look at the threat agents and attack vectors, as well as the impacts.

“Exploitation of insufficient logging and monitoring is the bedrock of nearly every major incident.

Attackers rely on the lack of monitoring and timely response to achieve their goals without being detected.”

“Most successful attacks start with vulnerability probing. Allowing such probes to continue can raise the likelihood of successful exploit to nearly 100%.

In 2016, identifying a breach took an average of 191 days – plenty of time for damage to be inflicted.”

Now how do we tell if the application is vulnerable?

Insufficient logging, detection, monitoring and active response occurs any time:

  • Auditable events, such as logins, failed logins, and high-value transactions are not logged.
  • Warnings and errors generate no, inadequate, or unclear log messages.
  • Logs of applications and APIs are not monitored for suspicious activity.
  • Logs are only stored locally.
  • Appropriate alerting thresholds and response escalation processes are not in place or effective.
  • Penetration testing and scans by DAST tools (such as OWASP ZAP) do not trigger alerts.
  • The application is unable to detect, escalate, or alert for active attacks in real time or near real time.

You are vulnerable to information leakage if you make logging and alerting events visible to a user or an attacker (see A3:2017-Sensitive Data Exposure).

Now let’s look at what can be done.

As per the risk of the data stored or processed by the application:

  • Ensure all login, access control failures, and server-side input validation failures can be logged with sufficient user context to identify suspicious or malicious accounts, and held for sufficient time to allow delayed forensic analysis.
  • Ensure that logs are generated in a format that can be easily consumed by a centralized log management solutions.
  • Ensure high-value transactions have an audit trail with integrity controls to prevent tampering or deletion, such as append-only database tables or similar.
  • Establish effective monitoring and alerting such that suspicious activities are detected and responded to in a timely fashion.
  • Establish or adopt an incident response and recovery plan, such as NIST 800-61 rev 2 or later.

There are commercial and open source application protection frameworks such as OWASP AppSensor, web application firewalls such as ModSecurity with the OWASP ModSecurity Core Rule Set, and log correlation software with custom dashboards and alerting.

Scroll to Top
Scroll to Top