A10. 2017 Insufficient Logging & Monitoring


It seems at first sight that this is not really a vulnerability but more a best practice but nothing could be further from the truth. If an ongoing attack is not detected in time or at all, our other security measures might be tampered with without us even knowing. In the event of an attack, we should be informed in a timely manner and with the correct level of detail.

This vulnerability type is a particularly nasty one because it is very hard to quantify exactly how much logging and monitoring is required to be safe. Besides being hard to quantify this is not easy to detect either. The hacker needs to have access to the logging to audit them which is often a sensitive topic since these logs often contain private information about the organisation. It should still be possible though for any tester to acquire an environment where they can test what is logged with certain actions.

You might be wondering how we quantify what to log and monitor, since it's so hard to do that. Basically a group of experts over at OWASP got together to define which items should be logged to be deemed safe and easily auditeable.

What do we need to log?

It is really important to always log at least the following items:

It is very important that whenever one of these events occurs, that enough logging occurs with a proper message detailing the event. This is often a fine balance between including too much information which might clog up your hard drive space and not logging enough which might leave you vulnerable in the event of an attack.

These logs are very important but they are useless if nobody checks them. All of the security loggings should be monitored and audited regularly to ensure no suspicious activity has taken place that the monitoring has missed. Whenever an event occurs that indicates suspicious activity there should be an alert sent out as well to keep those responsible informed about any potential ongoing attacks.

What adds an extra layer of complexity again is the location of your log files. We can't simply store them on the machine itself because if that machine is compromised and the attacker erases the logging files they are gone forever. We will look at mitigation steps for this risk in the next chapter.

As you can imagine when a penetration tester or bug bounty hunters are hacking a corporate network, alarm bells should go ringing off everywhere so if no alerts are triggered we can safely report this as an issue as well.

These logs should not be visible to the end user under any circumstance! They contain valuable information and should be treated with the same integrity as personal data.

How can we prevent this?

It is really important here that we do a proper risk analysis. We have to ensure we log all the details that matter but also to nog overrun our logging system and to keep the logs for as long as needed but again not for too long. As a general guideline we should always log the following events:

We also need to make sure that our logs are not decentralised where they are seeded across many different servers. To achieve this, our logs need to be easily digestible by a centralised solution which allows us to consult and monitor our logs in a timely fashion.

It's also good to have a plan at hand for when things do go wrong and you eventually run into an incident. A good starting point for this would be https://csrc.nist.gov/publications/detail/sp/800-61/rev-2/final


We don't have to think very hard to find issues that could arise from insufficient logging and monitoring. One example could be that an attacker could brute force our systems without our knowledge or that they would attempt to install a backdoor with unknown outgoing and incoming traffic. All of these things can not be avoided with logging and monitoring but they can be caught by them.