Every once in awhile I get asked why detailed event logging is so important when setting up cybersecurity controls at a business. In this article will attempt to explain why this is critically important.

To log or not to log, that is question…

When it comes to logging security events and being able to make use of what is being logged, it’s often the case that what is originally done is not fit for the task at hand. Either the information is incomplete, imprecise or just confusing.

For logs to be useful they need to actionable and they need to tell a sufficiently detailed story after the fact, so that it is possible to get a reasonable picture of what is going on – to either stop a hacker in their tracks (if you are quick enough to do so) or to recreate an understanding of what went on and what was accessed, so you can work out what the data breach ‘blast radius’ is and what needs to be done to put things back to a known good state. It’s also an opportunity to learn and work out what can be improved to stop it occurring again.

Now if your logging regime leaves a lot to be desired, you going to find working out what really occurred a lot harder than it should be. A bit like looking for a needle in multiple haystacks in the dark.

What to log?

Now that we have worked out you need to log things much better, what do you need to be logging? It comes down to the 4 W’s, namely:

• WHEN – a precise timestamp (UTC)
• WHO – what account is performing the action
• WHERE – what machine/service and from which IP
• WHAT – what was done

With these 4 things logged in sufficient detail to be actionable, you have enough information to chain events together over time, say via a SIEM, for instance:

• You can track what an account did in a given period of time over a number of systems or services
• You track what an IP did across a number of systems or services
• You can track who was accessing a system or service

Such information naturally leads to behavioural analysis (machine learning, AI, etc) so you can set thresholds on when systems should be accessed and what they should be doing.

Also recording such information allows you to more easily pull in and combine data sources and other log sources as required. For instance:

• IP addresses can be processed to extract rough geolocation and IP block ownership details.
• User login details can be enhanced with role and rights information.
• User access could be tied to physical access control logs – was someone really in the office when they did something?

Where to store the logs?

Please do not fall into the mistake that storing the logs on the original system is sufficient. If a hacker does break-in, the first thing they will want to do is cover up their tracks and make the logging go silent or ‘ignore’ their activity – if the logs only exist on the server, then they can fiddle with these to their heart’s content. Whereas if the logs instantly get copied to a remote logging service that does not permit remote log tampering, there is no way the hacker from their server can cover up their trail. For all they know, the game could be up already and they will be booted out ASAP. In fact most hackers will go looking for such remote logging, and actually stop if they find it, its a clear indication they are in an environment that is properly monitored and controlled.

How long to keep logs?

You should keep logs secure for at least one year. By secure a mean they are stored encrypted with a crypto signature attached – so you are confident they cannot be modified without it being detected. Also, store the archives in at least two locations. So if one does get compromised, you still have a backup to refer back to.

Also, do encrypt them and do NOT store the encryption key with the logs… This is because the logs themselves have value to a hacker, they could contain just enough information to help stage a social engineering attack.

Putting this together

In the above diagram, we have a few systems on the left-hand side generating events that need to get logged. Such events follow the 4 W’s principle as shown (which your CISO enforces via the ISMS policies). Such events get copied into two systems, one being the long term secure archive service, the other the SIEM.

The SIEM, based on its rules and its understanding of what is normal behaviour could generate a Security Alert that gets handed into the respective Product/System Owner as well as a Security Analyst to examine. It could also be passed onto a customer’s SOC if this is part of a SAAS environment which supports such integration (on the basis that a SAAS customer is best placed to understand its own users).

If the security event is found to be valid, then a process of Forensic Analysis is undertaken to work out at which stage of the MITRE ATT&CK lifecycle the attack is at and therefore who needs to be involved and what needs to be done. It could be that the attack is from an APT (Advanced Persistent Threat) in which case the Police and special agencies get involved to assist with analysis and eventual lockdown (I say eventually as they might want you to leave things alone for a while to gather more intel).

The involvement of the authorities is why your logging archive needs to be secure and provably so, it could be used as evidence in a court case. Also, such logging can prove your compliance with relevant standards around data management (for instance the right to be forgotten).

In Conclusion

I hope I have been able to provide you with enough of an insight into why it’s important to log with sufficient detail and ensure you keep such information secure. It really is the linchpin to ongoing proper security with your systems.

BTW feel free to use my diagram, just let people know where you got it from.