Creating an Audit Policy - Page 3
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
| CrossLinks |
|
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.



