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.

Server roles

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.

Logon events

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

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.

Account management

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.

Policy change

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

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.

System events

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.

Process tracking

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.

Event Viewer

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
.