IT managers - logs can save you

Ask a security firm, and it is usually willing to tell you, what it thinks is the biggest threat on the horizon. Most times, the answer is also the one getting the biggest coverage in the media -- the latest Microsoft flaw, or the current hacker exploit. This makes us feel happy, as it means we are getting it right, but it also raises doubts. Maybe these people have the same attention span we do. That would be seriously worrying.

But I got a different answer from security testing firm NTA Monitor the other day. The technical director, Roy Hills, had plenty of stories about conventional dangers. He regularly finds Web sites where the software used to build them (Front Page, most often) is on the same server without a password. Not only can you deface the Web site, but the company has kindly placed the tools in your hands to do it with.

NTA Monitor has also done its fair share of exposing flaws in software, having recently nailed bugs in Borderware and Check Point.

But, in Hills' experience, the most widespread danger he uncovers comes from a source that most of us rarely think of: logfiles.

Every product on your network, pretty much, will have the option to log its activities, and what is done with and through it. If you have an incident -- which could be anything from a blackmail attempt through a hacker attack or a police raid -- these logs may be the only way to sort out what happened. When the dust settles, they may be the only comeback you have. They may be the only thing between you and getting the culprit.

One customer asked for help because of a blackmail email from Russia. The sender claimed to have extracted the customer data from their servers, and wanted money. Before calling in the police, the customer wanted to know if the claim was actually plausible.

This firm was reluctant to go public -- even as far as contacting the police -- as any leaks of its information would open it to legal action under the Data Protection Act. If its security was lax, that constitutes misuse of its customer data.

It turned out that the company had lots of logs for its system, but not enough to make an audit trail. Given the number of routes into data, it would be impossible to rule out the blackmailer's claim, but a good set of logs could have allowed the company to decide it was very unlikely, and perhaps called the blackmailer's bluff.

Given their importance, the offhand way people treat their logs is a bit surprising. The first danger is not to turn the log on -- on the grounds that traffic gets monitored elsewhere, and it would use up a lot of disk space. This is no excuse, according to Hills: "Disk is dirt cheap," he says.

Other companies log, but don't keep them long enough. Hills tells of a bank where everything was logged, but overwritten every 30 minutes. "Had they been attacked, they would have had no record of what happened," he said.

More tragic perhaps are the people who log everything they can think of, but still don't get it right. All the stuff should be logged somewhere you can get to it, and where it can't be easily messed with. "It is surprising how many people have the server logs on the server itself, in public folders," said Hills. That makes it just a bit too easy for an attacker to cover his tracks.

Something that too many people don't think of is time synchronisation. An incident is likely to involve several different systems, and you will not be able to piece together what happened unless you can track from one log to another. The log of your database application might pick up a very dodgy SQL query: "List all the column titles in the database and then, oh yes, send me all the data." But it won't tell you who made it -- they've signed in, so it looks like a staff member. Either a hacker has cracked the password, or you have a rogue insider.

To find out more, you need to see if anything strange happened at the same time. Any firewall activity, any VPN tunnels staying open longer than normal? If the time on your other servers has drifted significantly away from the database server, then you simply cannot make this kind of enquiry.

NTA's customer had just this problem. In the end, they stalled the blackmailer, he failed to provide any evidence that he had the data he said he had (and he was not traceable), and eventually just disappeared.

You might not be so lucky. If anything untoward happens on your company's systems, you may well need log information that will stand up in court. It could be the difference between a scary event and one that costs you and your company very dearly.

To have your say online click on TalkBack and go to the ZDNet UK forums.