Introduction
In Windows 7 and Windows Server 2008, administrators have potentially more control over the individual audit policy than in earlier versions of Windows Operating Systems. Additional categories and subcategories have been added on these platforms for more granular auditing control.
Existing Tool
Unfortunately, these new subcategories are not exposed in the Group Policy Management Console (GPMC) interface. The GPMC interface only allows us to configure audit policy at the category level. Administrators must use the Windows built-in Auditpol command-line tool to cope with custom audit policy for Windows 7-based and Windows Server 2008-based computers.
The Auditpol policy command-line tool can be used to:
- Set and query the system audit policy
- Set and query the per-user audit policy
- Set and query the auditing options
- Set and query the security descriptor used to delegate access to an audit policy
- Report or back up an audit policy to a CSV file
- Load an audit policy from a CSV file
- Clears the audit policy
- Removes all per-user audit policy settings
- Disables all system audit policy settings
Windows auditing can be very verbose. Using subcategories, administrators have better control to auditing very specific events. This reduces the generation of a huge number of irrelevant events and hiding important ones. Combined with the Windows Event Collector service, we can build a detection tool that aggregates only the most important events suitable for a specific intrusion detection task.
The snapshot above shows Auditpol in action to retrieve all subcategories and their audit policy. Similarly, we can use the Auditpol /set command to enable granular auditing. For more help, just type Auditpol /? at the prompt.
Sample
The tool presented here, which I call Audit Policy Browser, partly fills the gap of a missing User Interface for the new audit policy subcategories. Using this tool, administrators can enumerate all available Audit Policy categories and their associated subcategories. For any subcategory selected, the corresponding audit policy settings (No Audit - Audit successful attempts - Audit failed attempts) are shown.
This tool does not use the full potential of Auditpol which is also available in the API mentioned later. This exercise is left to the readers.
Programmatic Model
In my knowledge, the only available API to manage this new Audit Policy framework is the so called Authorization Functions which is part of the Audit Policy Functions which can be found at http://msdn.microsoft.com/en-us/library/aa375742(VS.85).aspx.
Only a part of the Authorization Functions has been made available in .NET. The Audit Policy Functions are not (yet) available in .NET or in COM.
To implement this project, I wrapped the available Windows API in a set of C++ classes that manage the different logical levels of the Audit Policy infrastructure. The error handling is not shown in the snapshot below.
The object model below shows the classes hierarchy.
Access to the subcategories policy is made in three steps:
- Enumerate the Audit Policy categories:
GUID* pGuid = NULL;
ULONG uCount = 0;
AuditEnumerateCategories(&pGuid, &uCount)
GUID* pCurrentGuid = pGuid;
for(ULONG i=0; i<uCount; i++)
{
m_vAuditPolicyCategories.push_back(
new CAuditPolicyCategory(pCurrentGuid));
pCurrentGuid++;
}
- Enumerate the Audit Policy subcategories:
GUID* pGuid = NULL;
ULONG uCount = 0;
AuditEnumerateSubCategories(
m_pGuid,
FALSE ,
&pGuid,
&uCount);
GUID* pCurrent = pGuid;
for(ULONG i=0; i<uCount; i++)
{
m_vAuditPolicySubCategories.push_back(
new CAuditPolicySubCategory(pCurrent));
pCurrent++;
}
- Retrieve the subcategories associated policy:
ULONG uCount = 1;
PAUDIT_POLICY_INFORMATION pAudit_Policy_Information = NULL;
AuditQuerySystemPolicy(m_pGuid, uCount, &pAudit_Policy_Information);
m_policy = new CAuditPolicy(m_pGuid,
pAudit_Policy_Information->AuditingInformation);
Environment
The code has been developed using Visual Studio 2008 and tested on Windows 7.
Because of the fact that the application reads administrative related information, User Account Control (UAC) expects it to run with an elevated token. For this reason, the application's manifest has been tagged as requiring administrative credentials. When launching the application, it will thus ask to elevate when started from a non-administrative account. Don't be afraid, this tool only inquires the system. No modification whatsoever is made by this tool to the system although this is potentially possible using the Microsoft API.
As a matter of fact, administrative credential is also expected when retrieving the policy settings with Auditpol /get /category:*
Suggestions
The following items could be implemented in order to use the full potential of this technology:
- Manage potential runtime errors when invoking the API
- Export the content to an XML file in order to be consumed by other components
- Retrieve the effective user-policies
- Modify the user and system policy settings
Links
History
- 26 Feb. 2010: First version.