Creating an Audit Policy - Page 2

 By Brien M. Posey
Page 2 of 3   |  Back to Page 1
Print Article

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.

This article was originally published on Nov 2, 2000
Get the Latest Scoop with Networking Update Newsletter