Task 9.1: Configuring an Audit Policy for Object Access
Auditing is an integral component of security for any system or network. Auditing is the tracking and recording of events in a log. What events? Well, that’s up to you. An audit policy can be set on individual systems, configured for groups of systems, or configured for every system in the enterprise.
Auditing must be set up in advance. If you don’t have auditing turned on before the event, you won’t have any audited information recorded about the event. You will place a more elaborate audit policy on systems that are more exposed, on your most critical infrastructure systems, and on systems that hold your most sensitive information assets.
When you implement an audit policy, you should also configure the Security log in Event Viewer to increase its size and to avoid overwriting the existing log data. This should be part of the process as you develop your monitoring plan for the Audit log.
Scenario
You are an administrator in an Active Directory environment. You need to record all accesses to sensitive content on one of your systems. You are concerned about actual and attempted access to a folder on a system that contains sensitive documents.
Scope of Task
Duration
This task should take 30 minutes.
Setup
This audit policy should apply to authenticated users and should include Read, Modify, Create, and Delete access to the file and folder content.
The audited events will be written to the Security log in the Event Viewer application on the server holding the sensitive content. Completion of Tasks 4.8 and 6.1 is required before beginning this exercise.
Caveat
Auditing can easily overwhelm a system, a network, and your administrators. Thousands of events can occur on a system every hour. The system can become so busy recording all the event details that resources available to service actual client requests become limited. If you are using a collection and analysis application, these thousands of events—for numerous systems—must be sent over the network to the central database for storage and analysis. None of this activity does you any good unless a responsible human is involved to interpret the output and react if necessary. The monitoring of event logs can consume most, if not all, of an administrator’s time.
Auditing should be configured only if you intend to regularly review and use the information that will be generated from the audit policy.
Procedure
For this task, you will build a new Auditing GPO for object access and link it to the organizational unit (OU) that contains the system that holds the sensitive content. To complete the object access auditing, you must configure auditing in the system access control list (SACL) on the system that holds the sensitive content for the folder where the critical data is stored.
Equipment Used
For this task, you must have:
- Windows Server 2003 domain controller system
- Windows XP Professional system, which is a member of the domain (the system that holds the sensitive data)
- Domain Administrator access
Details
Configuring an Auditing GPO for Object Access
1. Log on to the Windows Server 2003 domain controller system as the Domain Administrator.
2. Select Start ⇒ Programs ⇒ Administration Tools ⇒ Active Directory Users And Computers (ADUC).
3. In the left pane, expand the domain. Click on the OU named Confidential Servers that you created in Task 6.1.
4. In the left pane, right-click on the OU named Confidential Servers and select Properties.
5. Select the Group Policy tab.
In Task 6.1, this OU was configured with an IPSec policy to require encrypted communications. You will first disable this policy to avoid any potential conflicts with this task. If you have already disabled or deleted this GPO, skip to step 8.
6. Double-click on the IPSec Secure Servers Policy in the area under Disabled. You should receive a Confirm Disable warning message.
7. Click Yes to confirm that you intend to disable the IPSec GPO.
8. On the Group Policy tab, click New to create a new GPO.
9. Name the new GPO Object Access Audit Policy.
10. On the Group Policy tab, click Edit.
11. In the left pane, expand Computer Configuration ⇒ Security Settings ⇒ Local Policies, and select Audit Policy.
12. In the right pane, double-click on Audit Object Access to open its properties dialog box.
13. Under Define These Policy Settings, enable the Success and Failure check boxes.
14. Click OK to close the Audit Object Access Properties dialog box.
15. Confirm that Success and Failure are enabled for the Audit Object Access policy.
16. Next you’ll configure the Security log properties, where the audited events are recorded. In the Group Policy dialog box, in the left pane select Event Log.
17. In the right pane, double-click the Maximum Security Log Size Policy.
18. Enable the Define This Policy Setting check box, and set the log size to 500032 kilobytes (500 MB). Click OK.
Log file sizes must be in increments of 64 KB. Each event logged adds approximately 500 bytes to the log file size. Each file access can trigger the logging of 4–12 events. If you conservatively assume 12 events logged per file access and 1,000 accesses each day, you get 180 MB per month added to the Security log for object access in this folder. In this example, you should schedule to turn the Security log at least once each month.
To turn the log, save the log as a file to a secure location, and then clear all events on that log in Event Viewer. It is common to generate, and separately and securely store, an MD5 hash value for each log file to validate the integrity of the log file, if needed, in the future. This proves that the log file has not been tampered with since it was generated and archived. Hashing was discussed briefly in Phase 6 in the VPN/IPSec exercises.
There are many other events that are written to the Security log and increase its size. Measure, evaluate, and determine the correct file size for the Security log in your environment. Adjust this file size as necessary over time.
19. In the right pane, double-click Prevent Local Guests Group From Accessing Security Log Policy.
20. Select the Define This Policy Setting check box, and select the Enabled option. Click OK.
21. In the right pane, double-click the Retention Method For Security Log Policy.
22. Check the Define This Policy Setting check box, and select Do Not Overwrite Events (Clear Log Manually). Click OK.
23. You will get a Confirm Setting Change warning regarding another policy setting that can shut down this system if the log files cannot be written to because of the Do Not Overwrite setting you just defined. You will not be implementing that additional policy. Click Yes to confirm your Do Not Overwrite setting.
24. Confirm your settings in the Event Log section of the Audit Policy GPO.
25. Close the GPO to save it. Click Close to close the Confidential Servers Properties dialog box.
Moving the Resource Server into the Proper OU
1. In ADUC, locate the system that holds the sensitive data that you need to implement auditing on. The default location for all nondomain controller systems is the Computers container.
2. Right-click on the resource server and select Move.
3. In the Move dialog box, select the Confidential Servers OU and click OK. This places the resource server into the Confidential Servers OU, making it subject to the new Auditing policy.
4. Confirm that your resource server is now located in the Confidential Servers OU.
In this task, you are using an XP Professional system as the resource server. In the graphic, the resource server is an XP Professional system named SHOTGUN.
5. Close ADUC.
Refreshing the Group Policies on the XP Professional System
1. Log on to the Windows XP Professional system as the Domain Administrator.
2. Select Start ⇒ Run.
3. In the Open field, type gpupdate /force and click OK.
This opens a command window that says Refreshing Policy, and may take a few moments to complete. This reapplies all GPOs that affect the XP Professional system, right now. Since we relocated the XP Professional system into a new OU with different GPOs, you want to be certain that the Auditing GPO is currently applied to, and effective on, this system right away. The GPO would have automatically refreshed within two hours by default.
Configuring Auditing for Object Access on the Resource Server
1. On the Windows XP Professional system, launch the Explorer application.
2. In the left pane, expand the folders as necessary to locate the folder named STUFF.
3. Select the STUFF folder.
In Task 4.8, you created a folder named STUFF on an XP Professional system and placed some sensitive content in it. If that folder and content is still available, use it. If not, create a new folder named STUFF and place a new text document in it.
4. Right-click on the STUFF folder and select Properties.
5. On the Security tab, click Advanced. Select the Auditing tab of the Advanced Security Settings For STUFF dialog box.
6. Click Add to build the SACL to implement auditing on this folder.
7. In the Select User, Computer, Or Group dialog box, click Advanced.
8. Click the Find Now button to display a list of users, computers, and groups in the domain.
9. Select Authenticated Users from the resulting Name (FQDN) list. Click OK to accept Authenticated Users.
10. In the Select User, Computer, Or Group dialog box, click OK to close the dialog box.
11. In the resulting Auditing Entry For STUFF dialog box, select Successful and Failed for the following access types:
- List Folder/Execute File
- Create Files/Write Data
- Create Folders/Append Data
- Delete Subfolders And Files
- Delete
With the Auditing GPO linked to the OU that contains the system holding sensitive content, these settings will audit successful and attempted access for all authenticated users. Access types being audited include Read, Modify (Write), Create, and Delete accesses to the file and folder content. These auditing attributes will now be inherited by all newly created content in the STUFF folder by default.
12. Confirm your settings, and click OK to close the Auditing Entry For STUFF dialog box.
13. In the Advanced Security Settings For STUFF dialog box, enable the Replace Auditing Entries On All Child Objects With Entries Shown Here That Apply To Child Objects check box.
With this setting enabled, these auditing attributes will now be inherited by all existing and newly created content in the STUFF folder.
14. Click OK to close the Advanced Security Settings For STUFF dialog box.
You may see a progress dialog box that monitors the writing of the new SACL attributes to all existing content in the STUFF folder. This could take quite a while if the folder contains numerous files and folders.
If this folder is accessed a lot, the auditing processes can consume massive resources on this system and degrade system performance severely. Auditing should only be configured if you intend to regularly review and use the information that will be generated from the audit policy.
Criteria for Completion
You have completed this task when you have built a new Auditing GPO that is linked to the Confidential Servers OU and configured the SACL on the sensitive-content folder on the server (the XP Professional system in this case) holding the sensitive content.