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.
As you’re no doubt aware, Windows 2000 has a very robust security system. However, all the security in the world does little good if you don’t know how to check up on it. That’s where auditing comes in. Auditing is a process by which Windows lets you know what’s going on both with the system itself and with the users.
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.
Designing an Audit Policy
Creating an effective audit policy is a fine balancing act between auditing enough events to be effective, but not so many events that the ones that really matter get lost. So, you have to carefully plan your audit policy. Fortunately, over the years, I’ve refined some auditing techniques that you can use to develop an effective audit policy. Some of the techniques I’ll discuss are general enough that they apply to just about any networking situation. You can use these techniques on all your servers, whether you’re running Windows 2000, Windows NT, NetWare, or something else that supports auditing. Other techniques I’ll discuss are specific to Windows 2000; I’ll point them out along the way.
When designing an audit policy, you first need to decide how long you need to keep the audit logs. As I mentioned, depending on how many events you audit, these logs can become quite large. If you plan to keep only a few days’ worth of logs, they may consume a considerable amount of space on the server; but the space consumed will remain fairly constant, because you’ll be constantly overwriting old logs with new ones. On the other hand, if you need to keep logs for an extended period of time, you must determine how much space you can afford to use on each server. From there, you can make plans to archive the audit logs as needed. Keep in mind that even archived logs consume space, so you’ll need a permanent storage volume for them. (One option might be to burn the old audit logs to a CD.) Deciding Which Systems to Audit
As you might have derived from the previous paragraph, each computer contains its own audit logs. There is no central security log for the entire organization. Therefore, you’ll also have to decide which systems you want to audit. Unless you have a compelling reason to do otherwise, I recommend not auditing workstations. All your users’ files should be stored on the server–therefore, if someone gets past security and manages to access a workstation’s local hard disk, they probably won’t get anything of value. So, it’s pointless to audit workstations. If you’re thinking of auditing workstations anyway, remember that someone has to take time to review the audit logs for every workstation that you’ve audited.
|"Each computer contains its own audit logs. There is no central
security log for the entire organization."
I recommend auditing only servers, unless you have a compelling reason to do otherwise. Domain controllers should always be audited, because they play such a large role in your network’s security. You can decide whether to audit other servers based on their role in your organization.
Setting a Time to Review Logs
The next thing you’ll have to plan for when designing an audit policy is a set time to review the audit logs. Remember that simply auditing an event doesn’t mean the system will alert you to the event–it’s still up to you to read the audit logs and to determine when an event that appears in the logs represents a security breach or an attempted security breach. The frequency with which you review your audit logs should depend on the size of your organization and how big a target you are.
For example, I used to work as a consultant for the United States Army. Needless to say, the military has a lot of sensitive data to protect, and it’s a very big target for hacker attacks. Common policy at the time was to review the audit logs several times each day. Such a policy may be overkill for your organization, but you might read the logs first thing each morning just to make sure that nothing happened overnight.
I mentioned earlier that you should audit your domain controllers. I recommend performing a failure audit on all login attempts. If your network is very big, you’ll probably get a lot of these events–after all, people constantly forget or mistype their passwords. However, when you look through your security logs, you can ignore these isolated events. (People who forgot their passwords will usually call to have them reset, thus verifying that the incident was legitimate, and not an attempted security breach.) You’re looking for incidents involving multiple failed logins after business hours–these are almost always hack attempts.
I also recommend auditing any sensitive data. At the very least, you should audit successful deletions and modifications. That way, if critical data is erased, you can determine who erased it. Depending on your needs, you might also audit failures and other events such as creations or reads. When auditing sensitive data under Windows 2000, be sure to audit the Everyone group instead of just the Users group; the Everyone group includes users who logged in anonymously, whereas the Users group doesn’t.
Events to Audit
Finally, always audit administrative tasks such as permissions changes or the creation of new accounts. If a hacker gains access to your network, the first thing he will usually do is to create a new user account with administrative privileges. Needless to say, if this happens, you need to know about it. Therefore, it’s a good practice to review the security logs to make sure that any administrative tasks were authorized changes made by legitimate administrators.
Now that I’ve covered some basic auditing techniques, it’s time to begin building the audit policy you’ve planned. I’ll cover the process for doing so in part 2 of this series. //
Brien M. Posey is an MCSE who works as a freelance writer. His past experience includes working as the Director of Information Systems for a national chain of health care facilities and as a network engineer for the Department of Defense. Because of the extremely high volume of e-mail that Brien receives, it’s impossible for him to respond to every message, although he does read them all.