Creating an Audit Policy
By auditing your system on a regular basis, you'll know what your users are up to--and you'll be able to spot attempted network intrusions.
Every day I receive hundreds of letters from systems administrators all over the world. I am often surprised at how many of these letters ask the question, How can I tell if someone has been tampering with my system? In this series of articles, I'll answer that question.
To put auditing in a real-world perspective, consider this: Setting up Windows security without using auditing is like installing an expensive home security system without any type of alarm. Sure, the locks will keep some intruders out; but if someone breaks into your house, wouldn't you like to know about it? The same principle applies to Windows. Setting permissions will keep most of your users from doing things they aren't supposed to, but if a user or an outside intruder does happen to get past your security settings, it would be nice to be aware of the fact.
|"The first rule of auditing is restraint. Just because you can audit something doesn't mean you should."|
What Should You Audit?
In Windows 2000, you can audit just about any action by either the system or by a user. Such actions can be audited on a success or failure basis. For example, suppose you're auditing user logins. A success audit is a situation in which a user logs in successfully. A failure audit, on the other hand, is a situation in which a user tries to log in but is denied access.
It's impossible to discuss every possible audit situation within my space limitations. Even if I could talk about all of them, you'd probably be asleep halfway through the list. Therefore, I'll start out by giving you a general idea of the type of events you can audit. As the articles in the series progress, you'll gradually see examples of more events that you can audit. For now, just know that you can audit the success or failure of events such as logins, file accesses, deleting files, and attempts to change security settings such as group memberships.
The first rule of auditing is restraint. Just because you can audit something doesn't mean you should. The first year I was solely in charge of a corporate network, I learned a valuable lesson about auditing. As a new administrator, I was very gung-ho about security. I got the bright idea to audit every possible event. One day, our network had a serious security breach. I knew I had the audit logs to look at, and I couldn't wait to nail the responsible person (especially because I had a good idea who it might be). However, the audit logs contained so many entries from all the events I was monitoring that it was nearly impossible to locate the event I was searching for. I eventually found the event two weeks later; but by that time, the person responsible had already done more damage. At the time, I was working with NetWare, but the lesson is the same for Windows NT and Windows 2000: Audit only the events that really matter.
When you're planning which events to audit, you should also keep in mind that auditing events consumes system resources such as memory, processing power, and disk space. The more events you audit, the more of these resources are consumed. Auditing an excessive number of events may dramatically slow down your servers.