Designing an effective audit policy is one of the trickiest tasks in Windows networking. It isn't that the auditing process itself is overly complicated or anything like that. Creating an audit policy is simple. What is complicated is making a useful and effective audit policy. Creating an effective audit policy is tricky because there is a very fine line between too much auditing and not enough auditing.
An overzealous auditing policy reduces the monitored server's performance, consumes excessive disk space, and produces such lengthy audit logs that it becomes almost impossible to find an important event in the log. On the other hand an audit policy that is too minimal might ignore a bone-a-fide security breach. It is therefore critically important to come up with an audit policy that is thorough enough that it will log serious incidents, but not so excessive that a recorded security breach will be lost among thousands of irrelevant log entries.
In the next few sections, I am going to discuss the various types of events that Windows Server 2003 allows you to log. As you read over these events, you should be mindful of your server's roles. The reason is because not all servers do the same job, and therefore you will want to custom tailor a server's audit policy based on what makes sense for the server's role. For example, if a server is acting as a domain controller, you might want to audit user logon events. If on the other hand, a server is simply a member server that is acting as a file and print server, then you may not want to audit logon events because the server is not authenticating logons (local logons being the exception). Instead, you might want to audit access to some of the more critical or confidential files that the server is hosting.
For domain controllers, logon events are probably one of the most important things that you can audit. After all, what is more important than knowing who is using your system and who has attempted to use your system? When it comes to auditing logon events though, the way in which you audit them should really be based on the number of users on your network.
As you may recall, Windows allows you to audit either the success or the failure of various events. If you have a large network with hundreds of users who are logging in and out all day long, you may not want to audit successful logging unless you have a specific need for doing so. Otherwise, your audit log will contain hundreds, if not thousands of references to users logging in successfully.
I have always found it more useful to audit logon failures. On a large network, it's perfectly normal to have several logon failures logged each day. After all, users sometimes forget passwords or type them in incorrectly. Where failure audits are useful though is in helping you to spot unusual patterns of activity. For example, if you see that a user who usually works during the day had some failed logon attempts at 3:00 AM, that could very well be a sign of suspicious activity. Likewise, if you see failed logon attempts for a lot of different user accounts in rapid succession, it could be a sign that someone is attempting a gain access to your network through brute force.
Object access auditing isn't all that important for domain controllers, but it is probably the most important type of auditing for file servers. The basic idea is that you can use object access auditing to watch over specific files and folders to see who is accessing them and when. Object access auditing must be enabled or disabled at the server level, but simply enabling it won't audit anything. You must then specify which resources you want to audit. I recommend auditing access to anything that is sensitive or confidential. For example, you might audit access to Human Resource records, the payroll database, etc.
In the past, auditing object access has really paid off for me. At one of the places where I used to work, we used to have problems with files disappearing or becoming corrupt for no apparent reason. Initially I thought that there was a problem with the server's disk storage. However by reviewing the audit logs, I learned that one of our administrators, who later admitted to having a vendetta against the company, was coming into the office at night and tampering with some of our databases.
As the name implies, auditing account management refers to auditing the creation and modification of user accounts. I recommend auditing both successes and failures for account management on your domain controllers. The reason why this is so important is because if someone manages to hack your system, often one of the first things that they will do after gaining control over a server is to create a user account with administrative privileges. This keeps the hacker from having to hack the network in the future. Instead, they can just log on in the same way that any other user would. Not only does this make the hacker's life easier, it also reduces their chances of being caught because using a legitimate user account helps the hacker's activity to blend in.
I recommend auditing both successful and failed policy changes on all of your servers. As the name implies, policy change auditing logs things like changes to user rights. Knowing when user rights change is definitely important, but more important is that fact that auditing policy changes helps to keep administrators honest. Think about it for a second. If you wanted to perform some sort of unauthorized administrative task, what's the first thing that you would do? Disable auditing? Well, disabling (or re-enabling) auditing is a type of policy change.
Therefore, if an administrator were to disable auditing so that they could do something sneaky and then re-enabled it when they were done, you might not catch exactly what it is that the administrator did while auditing was turned off, but you would catch the fact that the administrator in question turned off auditing for a period of time.
Privilege use auditing is one of those things that sounds like a good idea, but might not be. As you would expect from the name, privilege auditing creates an audit log every time that a user exercises the use of a privilege. The problem is that even through the normal course of activity, privileges are used constantly. Things like logging in, rebooting the system, or even adjusting the clock all constitute a privilege use.
Although there are certainly some privilege uses that might point to suspicious activity, I tend to think that privilege use is best left unaudited because auditing privilege use has a tendency to flood your audit logs with irrelevant noise entries. Unfortunately, Windows Server 2003 does not provide a mechanism for selecting which privileges you want to audit.
Auditing system events creates an audit log entry any time the system is rebooted or when you do something that "affects the system security or security log" (in Microsoft's words). Basically, what this means is that if you audit system events that an audit log entry will be created any time someone makes an adjustment to the audit logs (such as clearing the logs). Because very few system events are audited during the course of normal, day to day activity, I think that it's probably a good idea to audit system events on all of your servers.
I have to be honest and tell you that I don't have much experience with process tracking. Process tracking auditing exists primarily for the purpose of helping you to figure out which security settings are preventing an application from running correctly. You probably wouldn't use process tracking auditing on your servers unless you are trying to diagnose a problem.
Directory service auditing
The last type of auditing that Windows offers is directory service auditing. The basic idea behind this is that if you enable Directory Service Auditing, then Windows will create an audit log entry any time a user makes a modification to an Active Directory object. I tend to avoid using this particular type of auditing because it has a tendency to log irrelevant information. Besides, many of the most important changes to Active Directory objects can be audited by auditing account management.
As you can see, Windows allows you to audit a wide variety of events. You can view the audit logs by opening the Event Viewer console and selecting the Security container. In my opinion though, the Event Viewer is in desperate need of a major overhaul. The Event Viewer remains largely unchanged since its initial debut in Windows NT.
If you know exactly what it is that you are looking for, then the Event viewer really isn't too bad. If you right-click on the Security container and select the Properties command from the resulting shortcut menu, you will see the Security Properties sheet. This properties sheet has a Filter tab that contains various filtering options. For example, you can tell the Event Viewer to show you all of the error events, all of the failure audits, or even all of the audits related to a specific Event ID. There are actually quite a few different criteria that you can filter on, but these filtering capabilities are usually only effective if you know exactly what it is that you are looking for.
The Event Viewer has several major shortcomings. For example, if someone decided to attack your network right this second, how long would it take until you noticed the attack? If the attack came in from the Internet, then you would probably notice it right away because of various alerting features that are built in to your perimeter firewall. What if the attack was performed by a trusted employee who was already connected directly to your LAN and didn't need to cross the firewall?
Sadly, if the attacker didn't do any noticeable damage, the answer for many administrators is that the attack would be first detected tomorrow morning, or next week, or whenever someone decides to review the audit logs. That's because the Event Viewer doesn't contain any sort of alerting mechanism.
Another major shortcoming of the Event Viewer is that it provides the administrator with a server centric view. When the Event Viewer was initially created, the majority of the servers in corporate America were running NetWare. Those organizations that were running Windows NT typically only had a couple of servers, so it wasn't a huge deal to have to check each server's security logs individually.
Today though, Windows Server is the dominant network operating system. It is not at all uncommon for companies to have dozens of servers. You would think that Microsoft would have redesigned the auditing engine so that audits are stored in the Active Directory, which would make it possible to examine the audit logs of multiple servers simultaneously. For example, suppose that you suspected malicious activity on your network at a specific time. It would be handy to be able to perform a query that would show you all the audit log entries for your domain controllers within a specific period of time. After all, you never know which domain controller is going to process a request.
For right now though, the Event Viewer makes you look at one server at a time. There are several different third party products that extend the functionality of the audit logs though. One of my personal favorites is GFI LAN Guard Security Event Log Monitor. I don't want to turn this article into a product review, but I will tell you that the reason why I like this product is because it collects event log entries from all of your servers in real time.
Over time it analyzes the logs and looks for trends that exist as a result of normal activity. Once the software understands what is normal for your network, it makes it easier for it to spot things that are abnormal. The software uses these abnormalities in conjunction with know attack patterns, and knowledge of server roles to determine if and when your servers are under attack. The software is then able to send you a real time alert.
I'm not trying to tell you that you need to order GFI LAN Guard Security Event Log Monitor. What I am saying though is that Event Viewer is outdated and isn't up to the job of managing security event logs in an effective manner. If you are serious about keeping your network secure, then a third party event log monitoring application is an essential. You can find a list of several such products at this Web site.