Whether your Windows XP workstation is a part of a huge corporate network, or just a machine at your home office that you use for checking e-mail, it is important to know what's going on with the operating system. For instance, simply mistyping the URL to a search engine can land you on a hostile Web site. Such sites can modify your security settings, hijack your browser, plant spyware, or possibly steal important passwords.
Your first line of defense should be to implement a security solution that includes up-to-date antivirus software, antimalware software, and a correctly configured firewall. You should also configure Windows XP to use the most restrictive security settings. Even with all of this protection in place, things can slip through the cracks, so it's equally important for your computer to have a good audit policy in place. An audit policy makes a log of the events that have occurred on your computer. If damage has occurred to your system, you can review these settings to try to figure out what went wrong. Even if your system hasn't experienced a security breach, you can use the audit log to find out what sorts of attacks are being attempted against your PC.
Enabling audit logging
To enable audit logging on a Windows XP system, you will have to log in as a user with local administrative privileges. After doing so, open Control Panel and then click the Performance And Maintenance link, followed by the Administrative Tools link. Next, double-click the Local Security Policy icon to open the Local Security Settings container. Now, navigate through the console tree to Security Settings | Local Policies | Audit Policy. When you do, you will see the screen shown in Figure A.
|This is where you set the local audit policy.|
When you double-click on any of the audit policy elements, you'll see a screen similar to the one shown in Figure B that allows you to audit successes, failures, or both. The first audit policy element is Account Logon Events. If you were to do a success audit, a log entry would be created every time someone successfully logged in to the machine. A failure audit would be generated any time that someone attempted to log in to the machine, but was not able to successfully authenticate.
|You can audit success or failure events.|
There are also a few other audit options available within the console at Security Settings | Local Policies | Security Options. These additional audit policies work a little bit differently from the other audit policy elements I mentioned above. These settings are either enabled or disabled. There is no success or failure option associated with them. The reason these objects behave differently is because they are global in scope. For example, you can audit the access of global system objects, as well as the use of backup and restore privileges. You can also set an option to shut down the system if it is unable to log auditing information, although I don't recommend using this option.
The Event Viewer
All of this audit information is logged to the Security container within the Event Viewer, as shown in Figure C. You can access the log by opening Control Panel and clicking the Performance And Maintenance link, then the Administrative Tools link. Next, double-click the Event Viewer icon. Once the Event Viewer opens, select the Security container to view your audit log. To view more detailed information about a log entry, double-click the entry. This will open the Event properties sheet, as shown in Figure D.
|The Event Viewer contains all of your computer's security audit logs.|
|Double-clicking an event causes Windows to display additional information about the event.|
Pitfalls of auditing
I would be negligent if I didn't explain that it takes a certain skill to properly set up auditing events. As you've seen, it is extremely easy to enable auditing for an event. You've also seen that there are only a handful of event types that you can audit. It might seem as though the most appropriate thing to do is to enable success and failure auditing for all types of events.
However, selecting all events is actually a really bad idea. The success and failure of every available event can quickly fill up the audit logs. There is a finite amount of space that is set aside for the audit logs. By default, that amount of space is 512 KB. You can change the default log size by right-clicking the Security container within the Event Viewer and selecting the Properties command from the resulting shortcut menu. For now though, let's just assume that you have a maximum log file size of 512 KB.
For instance, if you select the audit option that tells Windows XP to shut down the system if it can't write data to the log files, and the log file reaches 512 KB, then you won't be able to boot the system. This is why I recommend not using that option. It's better to allow Windows to simply overwrite old events as needed.
Whichever option you choose, it's conceivable that the event logs will eventually reach 512 KB in size. Since audit log data is text based, a 512-KB file can store a large number of log entries. This can present a particular problem when searching for a particular event. Events are organized by date and time. Therefore, if the audit log is 512 KB in size and contains entries from the last month, and you're looking for an event that happened yesterday, finding that event will be relatively easy. Imagine how hard it would be to find the event that you are looking for, however, if you had hundreds of log entries for every single day. Worse yet, imagine what it would be like to try to find an event that just happened if Windows is logging over a thousand events per hour.
So, if you enable every possible auditing option, Windows can bombard the log file with thousands of entries. The vast majority of these entries will likely be irrelevant to your search. It's therefore best to limit the scope of the objects being audited. By auditing only the really important events, you are much more likely to be able to find the events that really matter to you.
What to audit
What are the really important events that you should be auditing? The truth is that it varies depending on your situation. At a minimum, I would suggest auditing the success and failure of account logon events, account management, and policy changes. You may want to audit additional event types, but that's up to you. Generally, I would not audit directory service access or system events, because these are the options that tend to really flood your audit logs. When deciding what to audit, remember that if an event has already occurred, it's too late to go back and audit it. So you need to anticipate the types of events that could occur and be set up to audit them.