Jump to: navigation, search

Deploying Auditing Settings and Reporting What is Configured

Versione del 10 Apr 2008 alle 07:29 di 83.103.19.92 (Discussione) (Nuova pagina: Within Windows you might want to track who is performing specific tasks. This might be to meet a regulatory compliance, or to just track when users perform tasks on desktops and serve...)
(diff) ←Older revision | view current revision (diff) | Newer revision→ (diff)

Within Windows you might want to track who is performing specific tasks. This might be to meet a regulatory compliance, or to just track when users perform tasks on desktops and servers. The benefits of deploying auditing settings to all computers include better control of the environment, audit trails for security reasons, and tracking of events for forensics. The big question boils down to how should these settings be deployed correctly, efficiently, and with assurance that the settings will be persistent? The answer is simple and efficient: Group Policy. Here, we will look at the settings that need to be deployed, the methods to deploy them, and options to verify that the settings are still in place. Audit Settings

There are numerous audit settings that you need to consider for configuration on both desktops and servers in the environment. You not only need to consider the individual settings, but also whether you want to track successful access or failed access. This is a relatively easy decision, if you want to track when someone performs a task successfully, establish successful audit tracking. Failed access is when they attempt to perform the task or access a resource, but don’t have the permission to do so.

The settings that you have to consider include the following:

Audit account logon events – This will audit each time a user is logging on or off from another computer in which the computer performing the auditing is used to validate the account.

Audit account management – This will audit each event that is related to a user managing an account (user, group, or computer) in the user database on the computer where the auditing is configured. Examples of these events include:

   * Creating a user account
   * Adding a user to a group
   * Renaming a user account
   * Changing a password for a user account 

Audit directory service access – This will audit each event that is related to a user accessing an Active Directory object which has been configured to track user access through the System Access Control List (SACL) of the object.

The SACL of an Active Directory object specifies three things:

   * The account (typically user or group) that will be tracked
   * The type of access that will be tracked, such as read, create, modify, etc
   * Success or failure access to the object 

Audit logon events – This will audit each event that is related to a user logging on to, logging off from, or making a network connection to the computer configured to audit logon events.

Audit object access – This will audit each event when a user accesses an object. Objects include files, folders, printers, Registry keys, and Active Directory objects. In reality, any object that has an SACL will be included in this form of auditing. Like the Auditing of directory access, each object has its own unique SACL, allowing for targeted auditing of individual objects.

Audit policy change – This will audit each event that is related to a change to one of the three “policy” areas on a computer. These policy areas include:

   * User Rights Assignment
   * Audit Policies
   * Trust relationships 

Audit privilege use – This will audit each event that is related to a user performing a task that is controlled by a user right.

Audit process tracking – This will audit each event that is related to processes on the computer.

Audit system events – This will audit every event that is related to a computer restarting or being shut down. Events that are related to the system security and security log will also be tracked when this auditing is enabled. Deploying Audit Settings

There are two methods to deploy audit settings to desktops and servers. The first, manually, is really for computers that are not joined to a domain. This method is very cumbersome and not efficient. When manually establishing settings on multiple computers, there is also a greater chance that the settings will not be correct. In order to establish audit settings manually, the local Group Policy Object (GPO) must be accessed. This is done by typing gpedit.msc from the Run command off of the Start menu. Once in the local GPO, you will maneuver down to the following node: Computer Configuration|Security Settings|Local Policies|Audit Policy.

For those enterprises and small companies that have Windows Active Directory installed, you won’t want to use the manual method. Instead, you will want to deploy the audit settings using GPOs from within Active Directory. The configuration within the GPO will be the same, it is just the GPO that will be different. Ideally, you will place the appropriate target computer accounts in an organizational unit (OU), then link a GPO to that OU. Finally, configure the audit settings within the GPO and it will automatically configure all computer accounts in the OU.

Verifying Audit Settings

Once the audit settings are deployed using Active Directory and GPOs, how are you certain that they are configured properly on the target computer? The need to verify the settings falls under both the IT staff responsibility, as well as the security auditor responsibility. Regardless of the reason for the verification of the settings, the steps to verify them are the same.

The first option to verify the settings is to run the Resultant Set of Policies (RSoP) tool on the target computer. The easiest way to do this is to run rsop.msc from the Run command off of the Start menu. This will display all of the settings configured via Group Policy, as well as indicating which GPO setting came from. From the standpoint of verifying that the GPOs are properly configuring the target computer, this is by far one of the most powerful and effective methods to verify the settings are correct.

The next option to verify the settings is to access the Local Security Policy on the target computer. This is done by accessing the Control Panel. Once in the Control Panel, select the Administrative Tools. There, you will find the Local Security Policy. This tool shows the actual configurations on the computer.

There are also a slew of tools that can be used to evaluate what the audit settings are set to. At the top of this tool list is DumpSec, which is a free and stable tool for gathering information such as audit settings. DumpSec does a good job of gathering the security from the computer and showing it in a logical and easy format. The results can then be printed or saved to a file for future analysis. DumpSec can be obtained from www.somarsoft.com. Conclusion

Audit settings are important for any company, to ensure that users are not performing tasks on desktops and servers that they should not be doing. Auditing also allows IT administrators the ability to check for any malicious activity on any computer, either by an internal user or outside attacker. Getting the settings on the target computer can either be manual or automated via Group Policy in Active Directory. Once the settings are established on the target computer, it is important to periodically verify that the settings are correct. There are numerous options for verifying these settings, including built in tools and free third party tools. About Derek Melber