While auditing file and folder access on a client’s home computer or a networked office machine is probably overkill, I recommend auditing any publicly accessible computer, whether it’s networked or not. Auditing file and folder access allows you to test your security policy and determine whether any users are trying to use the machine in an unauthorized manner.

For example, fellow TechRepublic contributor and friend Troy Thompson teaches high school computing courses. Since a classroom full of high school kids is about as hostile an environment as you’re going to find, Troy audits each machine to detect any unauthorized use.

Enabling auditing
Before you can audit file and folder access, you must enable the Audit Object Access setting in the machine’s group policy. Log on to the machine with a local administrative account and open the Control Panel. Double-click the Administrative Tools icon and then the Local Security Policy icon. Doing so will display the machine’s group policy settings.

Navigate through the console tree to Security Settings | Local Policies | Audit Policy. When you select the Audit Policy container, the column to the right will display a number of different events that you can audit, as shown in Figure A.

Figure A
You can audit a number of events.

As you can imagine, it’s easy to get carried away with the idea of an ultrasecure machine by auditing absolutely everything. But this is a bad idea for several reasons. First, the audit process builds log files. Each entry in the log consumes a small amount of hard disk space. If too many audited events occur, your machine could run out of hard disk space. Second, each audit also consumes a small amount of CPU time and memory. So excessive auditing can negatively affect system performance.

Perhaps the best reason for not auditing everything is information overload. I have seen situations in which several hundred events are audited every minute. This makes it virtually impossible to locate anything useful within the logs because the useful log entries blend in with the garbage entries. My advice is to use discretion when creating an audit policy. Don’t audit anything that you don’t absolutely need to know about. The more you refine which events are audited, the more meaningful each audited event will become.

Let’s take a look at some of the available auditing options. Obviously, which audits are appropriate for your needs will vary depending on your environment. For general purpose auditing, though, I recommend auditing logon events so that you can tell when users have logged on or off. I also recommend auditing object access (i.e., files and folders). Auditing object access will allow you to see who does what to designated files and folders. Finally, I recommend auditing policy changes. This is a big one, because if someone is tampering with the machine’s security policy, you really need to know about it.

To enable these types of auditing, double-click the appropriate option within the Local Security Policy Settings console. You will then see a dialog box similar to the one shown in Figure B. As you can see in this figure, you can implement a failure audit and/or a success audit for each event.

Figure B
You can perform success and/or failure audits for each event.

So how do you know whether to perform a success or a failure audit? Well, that’s really up to you. For logins and policy changes, I recommend auditing both success and failures. For example, a success audit of login actions would create an audit log entry every time someone logged in successfully. A failure audit of the same event would write an audit log entry every time someone entered a password incorrectly. Likewise, a success audit on policy changes would let you know that someone changed a security policy, while a failure audit would tell you that someone tried to change a security policy but didn’t actually manage to make the change happen.

When it comes to auditing object access, I recommend also enabling success and failure audits. Just because success and failure audits are enabled for object access, though, it doesn’t mean that you actually have to use them. Every object that you audit access for has an entire range of audit options. Enabling success and failure audits simply make these options available to you.

Auditing object access
You must be careful which objects you audit or you will end up with the information overload problems. It’s very easy to end up with information overload because if you audit a folder, the audit applies to every object within the folder and within any subfolders. The audit applies to child objects, grandchild objects, and so on. So when possible, I recommend auditing objects at the file level. For example, if you needed to know who made the most recent changes to an Excel spreadsheet, it would be better to audit the actual XLS file than the folder containing it.

I also recommend that you avoid auditing system files and folders. Doing so can also result in information overload. For example, if you were to audit the Windows folder, you would end up with countless audit log entries because the system is constantly accessing files found in this folder. If you really wanted to audit Windows, a better solution might be to audit the registry files.

To audit a file or folder, right-click it and select the Properties command from the resulting menu. You’ll see the object’s Properties sheet. Select the Properties sheet’s Security tab, and click the Advanced button to display the Access Control Settings Properties sheet for the object. Select the Auditing tab. Then, click the Add button, and you’ll be presented with a list of users and groups. Select the users or groups that you wish to audit, and click OK.

For example, years ago, I worked for a large insurance company. At the company, a woman on the administrative staff was deliberately doing things to sabotage the system. Before we confronted her with this information, we needed to build a case against her. So we created audit policies that applied only to her. This way, we could watch every move she made without being flooded with thousands of log entries pertaining to other users.

Once you have selected a user or group, you’ll see the dialog box shown in Figure C. As you can see, you can enable success and/or failure audits for many types of access to the file or folder on a user or group basis.

Figure C
You can audit a number of different access types for files and folders.

Viewing audit results
You might be curious to know how to view the audit results. Open the Control Panel and double-click the Administrative Tools icon and then the Event Viewer icon. When the Event Viewer opens, click the Security container to see the security logs, as shown in Figure D. In the figure, you’ll notice how many log entries were applied in a matter of a few seconds. This is why it’s so important to use discretion when creating an audit policy. If you want to get more information on a particular event, simply double-click it.

Figure D
This is what the security log looks like.