Deciding What to Audit

Deciding What to Audit
Avoid auditing if you don't need it. Security audits, like tax audits, can be time-consuming and can waste a lot of resources. When you enable auditing, the system must write an event record to the Security log for each audit check the system performs. This activity can degrade your computer's performance, so you'll want to be selective about which events you choose to monitor. In addition, indiscriminate auditing adds to the log many events that might be of little value to you, thereby making the real security issues more difficult to find. And because the Security log has a fixed size, filling it with unimportant events could displace other, more significant events.

Here are some suggestions for what you should consider auditing:

Audit failed logon attempts, which might indicate that someone is trying to log on with various invalid passwords.
If you're concerned about someone using a stolen password to log on, audit successful logon events.
To detect use of sensitive files (such as a payroll data file, for example) by unauthorized users, audit successful read and write access as well as failed attempts to use the file by suspected users or groups.
If you use your computer as a Web server, you'll want to know whether an attacker has defaced your Web pages. By auditing write access to the files that make up the Web pages, you'll know whether your site has been vandalized.
Logging printer failures quickly identifies people who attempt to access a printer for which they don't have permission. You might also want to log successes (at least for users or groups suspected of abusing the privilege) to determine, for example, who's using all the expensive color ink cartridges.
To detect virus activity, audit successful write access to program files (files with .exe, .com, and .dll file name extensions).
If you're concerned that someone is misusing administrative privileges, audit successful incidents of privilege use, account management, policy changes, and system events.
Troubleshooting
--------------------------------------------------------------------------------

No security event is recorded for some logon failures.

If you audit account logon failures, you might discover that certain failed logon attempts don't appear in the Security log. In particular, if an account is locked out because of too many incorrect password entries, the user's next attempt should generate an event with ID 642 and the description "account locked out." Although this works as expected with domain-based accounts, failed logon attempts using a locked-out local user account don't generate the error. This is a bug in Windows 2000, and a patch is available. For details, see Microsoft Knowledge Base article Q314786.