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