Security is an ever increasing concern in almost every area of society today and computers are no exception. A detailed computer security plan should not only include policies and procedures to ensure that proper access rights are configured for all users, it must also include methods for verifying that these rights are effectively deployed throughout the network. Being able to see what your network users are doing is not a bad thing either.
Windows auditing is one such method for obtaining information about how effective your security practices are. In this article I will give a quick overview of Windows auditing and what it can do for you.
Windows auditing is a mechanism for tracking events. Knowing when and where these events occurred and who triggered them can help when doing Windows network forensics. It can also be very helpful with detecting certain types of problems like improper rights assignments in the file system.
Dozens of events can be audited in Windows. The events fall into several categories:
Each category has several event types that may be triggered. Each category may be enabled for auditing of successful of failed events. This allows you to track when a user was able or unable to do or access something. Enabling any of these audit categories will cause Windows to write messages to the event log whenever an audited event occurs.
There are dozens of events that may be audited in Windows, but I can see a strong reason to use only but a few of them.
For example, using the ‘audit account logon’ and the ‘audit account management’ events are very helpful in determining when and where a user was logged on when some network infraction occurred. Similarly, auditing object access can also produce useful forensic data. However the ‘audit process tracking’ setting probably only has usefulness when debugging applications.
In any event (no pun intended), having access to a wealth of audit data is much better than having too little or none at all. Windows auditing does make it possible to monitor many aspects of Windows network usage. This is especially useful in large Windows shops where multiple groups may administer different portions of the Windows network and all groups have to provide information about their activities to an audit team. In this scenario, Windows auditing can be used to provide empirical data to help prove that each admin team is in compliance with company standards and best practices.
I’ve already discussed a bit about what you can use Windows auditing for. However, let’s take a closer look at auditing logon events.
Several years ago I was asked to provide reports about who attempted and failed to access certain Domino (Domino is IBM’s competitor to MS Exchange) servers and databases. I thought that this was a silly thing to do. If the user failed to get access to a resource, more than likely it was because the user had no access rights to the resource. This meant that Domino was working as designed. If the user should have access to the resource, he could call the service desk and open a ticket in order to get access. Why then would we need to track this?
As it turns out, this was an excellent thing to do. I enabled Domino events (the equivalent of Windows auditing) on a few servers and sent the data through a series of processes that parsed and then exported the data to a SQL server. Once in a relational database, I could query the data as I saw fit.
Well, the reports showed that we had some very curious (devious?) users that would attempt to access all sorts of things (the president’s email) that they should not have been. In short we impressed the auditors and turned the proper corporate authorities on to these evil users. Score one for the good guys.
Do you see the point of this story? This basic technique can be applied to any system that produces audit logs. And therefore it also applies to Windows.
There is not a central repository for audit event data in Windows. Events are logged on the server for which the event occurred. So you will need some sort of tool to gather events from all relevant servers.
That brings us to a quick discussion of EventComb. EventComb is a free tool from Microsoft that can pull specified event log records from any number of servers into a text file. This tool will handle gathering the event data into a centralized spot. At this point you’ve got a few options to review the data EventComb has retrieved.
The option you choose is heavily dependant on the size of you network. For a small network, it may not worth the time to setup a system as described in option four. It is probably enough to use EventComb and view the log file manually. I even know of some single Windows server shops in which using EventComb is overkill.
The best sources of information about Windows auditing are The Windows product documentation and Mark Minasi’s book Mastering Windows Server 2003.
For more information about EventComb, search the Microsoft website.
For information about the grep tool, check the grep page at the free software foundation website at http://www.gnu.org/software/grep/.
For information about the find shell command, read the help screen on the find command by typing the following in a Windows command line ‘find /?’. The book NT Shell Scripting by Tim Hill is quite good as well.
Importing audit data into a relational database such as MS SQL Server is way beyond the scope of this article. To accomplish that task, you would need to know a programming language such as vbscript, SQL, and either SSIS or DTS. However, in a large environment it is well worth the effort to pursue this option.
Got a question? Post it on our Security Forums!