Why Should I Use Security Event Logs?

You Have To Plan Ahead To Catch An Intruder

Businessman working on laptop at home
Laflor/E+/Getty Images

Hopefully you keep your computers patched and updated and your network is secure. However, it is fairly inevitable that you will at some point be hit with malicious activity- a virus, worm, Trojan horse, hack attack or otherwise. When that happens, if you have done the right things before the attack you will make the job of determining when and how the attack succeeded that much easier.

If you’ve ever watched the TV show CSI, or just about any other police or legal TV show, you know that even with the slimmest shred of forensic evidence the investigators can identify, track and catch the perpetrator of a crime.

But, wouldn’t it be nice if they didn’t have to sift through fibers to find the one hair that actually belongs to the perpetrator and do DNA testing to identify its owner? What if there was a record kept on each person of who they came into contact with and when? What if there was a record kept of what was done to that person?

If that were the case, investigators like those in CSI might be out of business. The police would find the body, check the record to see who last came into contact with the deceased and what was done and they would already have the identity without having to dig. This is what logging provides in terms of supplying forensic evidence when there is malicious activity on your computer or network.

If a network administrator does not turn on logging or does not log the correct events, digging up forensic evidence to identify the time and date or method of an unauthorized access or other malicious activity can be just as difficult as looking for the proverbial needle in a haystack.

Often the root cause of an attack is never discovered. Hacked or infected machines are cleaned and everyone returns to business as usual without truly knowing if the systems are protected any better than they were when they got hit in the first place.

Some applications log things by default. Web servers like IIS and Apache generally log all incoming traffic.

This is mainly used to see how many people visited the web site, what IP address they used and other metrics-type information regarding the web site. But, in the case of worms like CodeRed or Nimda, the web logs can also show you when infected systems are trying to access your system because they have certain commands they attempt that will show up in the logs whether they are successful or not.

Some systems have various auditing and logging functions built in. You can also install additional software to monitor and log various actions on the computer (see Tools in the linkbox to the right of this article). On a Windows XP Professional machine there are options to audit account logon events, account management, directory service access, logon events, object access, policy change, privilege use, process tracking and system events.

For each of these you can choose to log success, failure or nothing. Using Windows XP Pro as the example, if you did not enable any logging for object access you would have no record of when a file or folder was last accessed. If you enabled only failure logging you would have a record of when someone tried to access the file or folder but failed due to not having the proper permissions or authorization, but you would not have a record of when an authorized user accessed the file or folder.

Because a hacker may very well be using a cracked username and password they may be able to successfully access files. If you view the logs and see that Bob Smith deleted the company financial statement at 3am on Sunday it might be safe to assume that Bob Smith was sleeping and that perhaps his username and password have been compromised. In any event, you now know what happened to the file and when and it gives you a starting point for investigating how it happened.

Both failure and success logging can provide useful information and clues, but you have to balance your monitoring and logging activities with system performance. Using the human record book example from above- it would help investigators if people kept a log of everyone they came into contact with and what happened during the interaction, but it would certainly slow people down.

If you had to stop and write down who, what and when for every encounter you had all day it might severely impact your productivity. The same thing is true of monitoring and logging computer activity. You can enable every possible failure and success logging option and you will have a very detailed record of everything that goes on in your computer. However, you will severely impact performance because the processor will be busy recording 100 different entries in the logs every time someone presses a button or clicks their mouse.

You have to weigh out what sorts of logging would be beneficial with the impact on system performance and come up with the balance that works best for you. You should also keep in mind that many hacker tools and Trojan horse programs such as Sub7 include utilities that allow them to alter log files to conceal their actions and hide the intrusion so you can’t rely 100% on the log files.

You can avoid some of the performance issues and possibly the hacker tool concealment issues by taking certain things into consideration when setting up your logging. You need to gauge how large the log files will get and make sure you have enough disk space in the first place. You also need to set up a policy for whether old logs will be overwritten or deleted or if you want to archive the logs on a daily, weekly or other periodic basis so that you have older data to look back on as well.

If it’s possible to use a dedicated hard drive and / or hard drive controller you will have less performance impact because the log files can be written to the disk without having to fight with the applications you’re trying to run for access to the drive. If you can direct the log files to a separate computer – possibly dedicated to storing log files and with completely different security settings- you might be able to block an intruder’s ability to alter or delete the log files as well.

A final note is that you should not wait until it’s too late and your system is already crashed or compromised before viewing the logs. It is best to review the logs periodically so you can know what is normal and establish a baseline.

That way, when you do come across erroneous entries you can recognize them as such and take proactive steps to harden your system rather than doing the forensic investigation after its too late.