Before you audit anything, you should understand successes and failures. When you audit an event, you can audit it by success, failure, or both. For example, suppose you can audit logins to the network but auditing success may be overkill because they would create a security log entry every time that someone logged in. This is an issue on networks with a large number of users. As I mentioned in Part I, the log file would grow quickly and become unmanageable.

A more effective technique might be to use a failure audit for network logins. A failure audit would create a security log entry only if a user tried to log in and was unsuccessful. You could then review the audit log to see who had trouble logging in to the network. If a user’s name appears only once in the security log, then you could probably assume that the user simply typed their password incorrectly. If you discover that a particular user has tried to log in unsuccessfully a number of times-especially after business hours-then you may want to investigate the invalid login as a possible hack attempt.

By identifying a potential security breach, you can take steps to prevent the hack attempt. These steps might include things like creating a policy that disables user accounts after three bad login attempts within a few minutes.

[tags]windows server 2003, audit policy, audit policies[/tags]