Det är något som alltid fascinerat mig: hur många som sparar loggar utan att någonsin fundera på hur de ska användas vid t.ex. ett intrång. De är nöjda med att kunna kryssa för ”vi har loggning” i ett testformulär och sedan… ja… vad då? ”Vem bryr sig? Vi loggar ju”. Allt klart. När något händer, finns det ingen plan eller någon metod för hur man ska få ut något ur drivorna med arkiverade loggar. Men som sagt: ”Vi loggar ju”.

Tillbaka till mina gamla blogginlägg från förr: texten är på Engelska.

Can’t see the forest for the logs?

Do you remember those old analog TVs, where you could pull the antenna cable out to look at the whirling static of white and black dots? For all intents and purposes, what you see is more or less random and no one could possibly call what you see on the TV-screen “information”. But that is what it is. However, when we talk about “information”, we often mean “useful information”. The bad news is that it can be hard to know what is useful now or in the future.

When working with computer generated logs, this can be disastrous. Logs? I’m not talking about the kind that used to be trees. Many applications store informational, warning and alert events in files or databases. Those databases and files are what we call logs. We often install systems and applications without thinking why and what should be written into them. All logs can give potential clues when we try to track an intrusion or when we try to find the cause of a failure. But when the time comes to look for those clues, they may not be there for us and there are quite a few reasons for that:

We have no plan why we log

Ask operations and they tell you logs are for troubleshooting. The guys in security talk about auditing and forensics and the web master needs to know how the site is doing on the big market called the Internet (assuming we’re talking about a web site, off course). Logs can cater to all those needs, if we set the system up that way. But that is a job for an IT-architect and should be done long before the system is actually built. At this time I want to remind you that organizations should have a set of written policies dealing with security and rules. This is outside the scope of this discussion, but the relevant parts of the security policies must be used to decide how to build the logging architecture.

We wait too long

Logs are often setup to start overwriting the oldest entries after some time or when they get larger than a preset size. In short, we could be too late to actually see something, since the log data has been erased. The solution is to understand what will use the logs for and how much history we need. This should be decided when we design the system and must be applied system wide. Yup, I’m repeating myself, I know!

We log all the wrong things and forget to log the right things

Did you know that the web server Microsoft Internet Information Services 6.0 doesn’t log the referer (yes it’s spelled that way!) tag by default? The referer (sic!) tag can show the address of the site the user was surfing on, when he clicked on a link to your site. It’s probably not so interesting to log just for security purposes, but it is very important if you want to know which search phrases or sites link to your site. Do you only log failed logon attempts? Then you won’t know when they actually managed to break in.

We fail to understand the consequences of our settings

If you setup your logs to rollover after a specified time or size, you don’t have to worry about them filling up the disk. Computer criminals know that this is a common practice and often try to hide their tracks by generating a massive amount of events in relevant logs until they rollover and delete the evidence. If we allow it to fill up, an attacker may be able to cause a system to fail by generating events until the system cannot log anything more. If we don’t transfer our logs to a secure system, an attacker that succeeds in taking over a system can destroy all evidence by clearing the logs. And if we do transfer the logs, the total cost of ownership goes up. All choices have their merits and flaws.

We log inconsequentially

The days of everything being “one server – one system” are long gone. Many larger systems consist of servers, network equipment and even cloud services working in unison. We must make sure we log everything as dictated by the policy on all parts of the system where possible.

… And my favorite: we have no idea what to do with it!

Ok, so you now have megabytes of data at your disposal. Whether you want to detect problems and security issues before they happen or want information enough to nail the attackers afterwards, you can seldom just rely on reading the logs manually. You need tools, procedures and scheduled time for it. This is a huge area and there are hordes of free and commercial products and appliances that can help you finding what you’re looking for or hide it from your eyes by being totally useless tools. The right tools for intrusion detection may be totally useless when it comes to troubleshooting stability issues.

This post in one sentence: thought applied before action saves the future.