Sexing up the logs

The title of this blog is false – a pure marketing ploy. Quite simply there is nothing sexy about logs. Few of us take any enjoyment out of reviewing them but there are plenty of mandates around telling us that we have to. For example, section 10 of the PCI DSS states: Review logs for all system components at least daily. Log reviews must include those servers that perform security functions like intrusion detection system (IDS) and authentication, authorization, and accounting protocol (AAA) servers (for example, RADIUS). Section A.10 of ISO27001 states: Audit logs recording user activities, exceptions, and information security events shall be produced and kept for an agreed period to assist in future investigations and access control monitoring. The importance of keeping logs is also called out in Basel II, SOX, and so on.

For anything you want to know about logs there’s only one resource. That of self-proclaimed “security warrior” Anton Chuvakin. His latest blog is on the “top eleven reasons to hate logs.” I recommend reading back through Anton’s archive – there’s a wealth of good guidance.

Let’s remember that we don’t “do security” just for the sake of compliance. Compliance is a side-effect of having a well planned security governance regime. The top level objectives are about protecting data assets (the CIA triad of confidentiality, integrity, and availability). Where does the review of log files come in and what risks are we mitigating? Well, logs support analysis processes – we learn a lot about what’s going on within our systems. Reviewing security event logs provides us with increased situational awareness of our environment, while storing logs enables us to perform trend analysis and observe behaviour on systems over time and identify anomolies.

Here’s an example. Let’s say that every morning at 9am you would expect to see log output stating a successful startup sequence for a particular device or application. If one morning this log entry fails to appear then you have an anomoly to investigate. Of course the issue might not be security related, or it might be. The fact is that some anomolous behavious causes you to investigate and find out what the problem is. Another example is when you consider what is normal system user behaviour. If the log files show that an individual who usually accesses an account during office hours and a weekend from London is now accessing the account in the middle of the night from Elbonia then there’s another anomoly for you to investigate. Suspicious behaviour or just on holiday? A review of the logs will likely reveal additional activity that lets you determine which it is.

There’s much more to talk about on this topic – consolidating logs and getting them into a format that makes them easier to review is probably foremost in the minds of some, deciding what to log and how long to keep records for will be of interest to other.