There’s an old episode of Blackadder Goes Forth where Baldrick proudly presents a bullet into which he’s carved his own name. His reasoning being that if he is in possession of the bullet that has his name on, then nobody else will be able to shoot him with it.
It’s that sort of logic which probably keeps those who maintain security devices such as IPS or firewalls but never keep or audit the log files in blissful ignorance of their impending doom! I’ll take a recent incident I’m aware of where a production server was found to have been compromised and contained rootkits. Surprisingly for the team who immediately went to inspect the IPS device that was supposed to be affording the server some protection, the logs were empty. The reason being that the device had been plugged into the wrong port – it wasn’t actually offering any protection at all.
Now this demonstrates failing in more than just an inability to check logs. We could talk about change control and testing and the skills of those maintaining the server room and we’ll come back to all of those topics at a later date, but since the device was presumed to have been in the corerct place and running for a number of months, the fact that no-one had noticed that the logs were empty before is plain neglegent.
I have recently discovered an excellent blog dedicated to log file management from Dr Anton Chuvakin, the “Security Warrior”. If you have even a passing interest in the subject then I recommend you head straight over there. Anton lists his 6 mistakes of log management:
1. Not logging at all
2. Not looking at the logs
3. Storing logs for too short a time
4. Prioritizing the log records before collection
5. Ignoring the logs from applications
6. Only looking at what you know is bad
A common excuse for all of the above is a lack of time, resource and skills. It’s true, log analysis can be time consuming and it takes a practiced eye to identify important anomolies. But let’s be clear, this is far preferable to the time and expense it takes to resolve a security incident or rebuild a rooted server. Here are some reasons from Anton as to why you should bother to look at logs:
– Situational awareness: you know what is going on with your network devices and applications
– Discovery of new threats
– More value out of your network and security infratructure – you’ve paid for it!
– Measuring security and performance; especially for reporting trends and metrics
– For compliance and regulations
– For incident investigation and forensics
The following lists summarise the value of logging and monitoring and why you need to be doing it.
Analysis & Mining
Now, who has a cunning plan?