How much logging is enough logging? (A10.2017 — Insufficient logging and monitoring)

Thexssrat
Thexssrat
May 14 · 4 min read

Introduction

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 organization. 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 auditable.

Photo by Campaign Creators on Unsplash

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.

Photo by Sigmund on Unsplash

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.

Photo by Taras Chernus on Unsplash

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:

For example, if you are a bank, you should always log in when people withdraw money but you should log the entire trial. From entering the code the customer withdrawing their card from the machine should be logged.

Photo by Helga Christina on Unsplash

We also need to make sure that our logs are not decentralized where they are needed across many different servers. To achieve this, our logs need to be easily digestible by a centralized solution that 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

Examples

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.

Photo by Markus Spiske on Unsplash

CodeX

Everything connected with Tech & Code

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store