Special Coverage: Windows Server 2008

Auditing and Compliance in Windows Server 2008

Rob Campbell and Joel Yoker

At a Glance:

• Increasing importance of compliance
• Understanding change in your environment
• Challenges of auditing security events
• Technical aspects of auditing

In the world of information technology, change is constant. If your IT organization is like most, you are under increasing pressure to understand the changes that occur in your environment. As the complexity and scale of IT environments increases, so does the impact of

administrative errors and accidental data disclosures. Today's society demands accountability for such events, thus organizations are now being held legally responsible for safeguarding the information under their care.

As a result, auditing change in your environment has become important. Why? Auditing provides the means to understand and manage change in today's large, highly distributed IT environments. In this article, we'll cover common challenges most organizations face, the landscape of compliance and regulation in IT, some of the basics of auditing in Windows®, and how the functionality of Windows Server® 2008 and Microsoft® System Center Operations Manager 2007 Audit Collection Services (ACS) can complement a comprehensive auditing strategy.

Auditing Challenges

A quick glance at news headlines shows that data disclosure is becoming an everyday problem. Many of these incidents involve legal action, financial loss, and public relations issues for the organizations responsible. The ability to explain what changes occurred or identify issues quickly is the key to reducing the impact of data disclosure incidents.

For example, let's say your organization is responsible for managing personally identifiable information (PII) for a given customer base. While there are multiple ways to protect the information contained on the systems you manage, compromise can still happen. Proper auditing could allow the organization to know exactly which systems were compromised and perhaps what data was lost. Without auditing, the impact of the data loss could be much greater, largely because there would be no way to estimate the extent of the compromise.

So why aren't IT organizations doing this already? The fact is, most organizations do not fully understand the technical aspects of auditing. While senior management generally understands concepts such as backup and restore, the inherent complexity of auditing changes in the environment is a hard message to convey. As a result, questions about auditing often arise only after a significant incident occurs. For example, basic auditing may be enabled but if the system is not configured to audit for a particular change, due to a lack of planning, that information will not be collected.

Moreover, audited security events have some inherent issues that IT professionals must deal with. One such difficulty is the distribution of systems within today's large computing environments, which presents significant collection and aggregation challenges since change can occur on any system or set of systems at any given time. That leads to another challenge—correlation. Translating relationships between events on single and multiple systems is often necessary to provide true meaning to what is occurring.

Yet another issue is that auditing typically transcends traditional organizational boundaries. Different organization or team structures exist for different reasons and may not be easy to bridge. Many organizations have a directory services team, a messaging infrastructure team, and a desktop team, but there is likely only one security team responsible for all of these areas. What's more, the dedicated security people for your organization may not be physically present at all locations. For instance, branch offices often rely on a single person or small team for all tasks including Security event log management.

Finally, the sheer quantity of events is challenging. Audited security events occur with much higher volumes than other types of event logging. The number of events collected makes it difficult to effectively retain and review the logs. Furthermore, by stipulating retention requirements for this information, current and proposed regulations are not helping to reduce this burden in today's computing infrastructures.

In the past, auditing of access to information could be summarized as a desire to know and an attempt to be secure. Now, as organizations—and the senior management responsible for them—are being held legally accountable for loss of information or lack of proper safeguards, it is critical for IT administrators to familiarize themselves with the regulations that may be applicable to their environments. For global companies, the challenges are even more complex since each country has its own regulations concerning information and the protection thereof. Some examples of existing regulatory compliance legislation are listed in Figure 1, along with the associated expectations placed upon IT organizations.

Figure 1 Regulations and what they mean to IT professionals

Given all the legal pressure, what are IT professionals to do? IT managers and technicians need to build a clear and concise story to present to those both inside and outside the organization. This includes developing a proper auditing strategy, which requires proactive measures and investments. The key concept here is that auditing cannot be an afterthought in design, as it too often is.

IT challenges such as these can typically be solved by a combination of people, process, and technology. With auditing, it's the process, that matters. Therefore, the first step should be to master the basics so you can respond to your organization's needs and requirements around regulatory compliance. Let's cover some of the fundamentals of auditing in Windows, then we'll dive into the changes in Windows Server 2008 and Windows Vista®.

Auditing Security Events

All audited events are recorded in the Windows Security event log. These events are usually not immediately actionable and are often informational in nature. Each event records a simple Audit Success or Audit Failure for a specific type of access that has occurred. This is different from the Application or System event logs, where problems can be identified via color coding (hint: look for the red events to home in on the problem).

The Security event log is different because audited events often are hidden by their volume, and as noted previously, correlation of security data can present a significant challenge. Even a simple data breach on a single system is problematic. The Security event log would need to be analyzed to identify which account was used to access the data, requiring an administrator to trace back through the log to try to find the account. Unfortunately, today's sophisticated attacks are often coordinated and distributed, making that sort of analysis quite difficult for the victim.

That said, it is important to understand the key elements that enable information to be recorded in the Security event log in Windows: Audit Policy and System Access Control Lists (SACLs). Audit Policies are configurable settings for a local machine through Group Policy or Local Security Policy and define the collection of success and failure events for specific types of access. The following primary Audit Policy categories have been present in Windows for many years (more on the new Granular Audit Policy in Windows Server 2008 later):

• Audit account logon events
• Audit account management
• Audit directory service access
• Audit logon events
• Audit object access
• Audit policy change
• Audit privilege use
• Audit process tracking
• Audit system events

The need to define Audit Policy and these associated categories is typically well understood by most IT organizations, but Audit Policy represents only a portion of the solution. SACLs also play a significant role in the implementation of a holistic auditing plan. Two specific Audit Policy categories—audit directory service access and audit object access—are fully dependent on SACLs to return information in the Security event log. So what exactly are SACLs?

Each object—file, registry, or directory service—has an Access Control List (ACL) with one or more Access Control Entries (ACEs) divided into two types: a discretionary access control list (DACL) and a SACL (the latter defines settings that log access attempts to secured objects). Each ACE in a SACL specifies the types of access attempts by a specified trustee that should be logged in the Security event log. ACEs define logging of successful and/or failed access attempts against specified objects. Figure 2 shows the use of a SACL on an object to generate events for specific types of access.

Figure 2** Using a SACL on an object **(Click the image for a larger view)

Understanding the relationship between Audit Policy and SACLs is critical since configuration is necessary to capture the "correct" audited events as it relates to changes in the environment. As mentioned, the audit directory service access and the audit object access audit policies only enable the generation of audits in the Security event log for those specific categories, but events are only generated if an object has an auditing ACE configured in its SACL. Once these pieces are in place, security events are generated by the Windows Local Security Authority (LSA) and are written to the Security event log.

Events consist of two distinct areas: the header, which is static and is predefined for each event identifier (Event ID), and the body, which is dynamic and contains different details for different events. Figure 3 shows these two elements in a sample Windows Server 2008 security event. Understanding these event components is important for the analysis phase of any auditing project and is of particular interest with respect to how information is returned in tools such as ACS.

Figure 3** The header and body of an audited event **(Click the image for a larger view)

Windows Eventing 6.0

Now that we understand the problem, how does Windows Server 2008 help organizations face these challenges? Windows Server 2008 is the first server release to contain the new Windows Eventing 6.0 event subsystem, which vastly improves the landscape around security event management. Note that while we are focusing on Windows Server 2008 here, 95 percent of the new feature set also exists in Windows Vista.

One of the first things many people will notice with Windows Eventing 6.0 is the new user interface. The new Event Viewer Microsoft Management Console (MMC) snap-in offers an excellent Overview and Summary page, flexible Custom Views, and greatly enhanced Explain Text. These interfaces can help the end user or system administrator find event information and configure important event log options directly from the Event Viewer itself.

A key problem that often impacted security data within the event log was data retention. Previously, the Event Log subsystem (including all logs) faced scalability limits. If those limits were exceeded, the entire subsystem would stop logging events. That's not the case with Windows Eventing 6.0, however, and organizations are now limited only by the amount of available disk space. But note that very large event logs can be cumbersome to analyze since each individual log entry must be evaluated when filtering, so you'll definitely want to keep your log at a manageable size.

Of course, this still leaves it up to the IT administrator to develop an archiving plan for event logs over many systems. To help with this on the local server level, a feature that is now exposed in Windows Eventing 6.0 is the "Archive the log when full, do not overwrite events" option. In previous versions of Windows, this option could only be set directly via modification of the AutoBackupLogFiles registry value. While this supplies a mechanism for local archive of logs, it does not provide a solution for management of these files over time, nor does it address the aggregation problem that occurs across multiple systems. Audit Collection Services does provide a complete solution for this, which we'll get to in a bit.

The new interface is just the beginning. The real power of Windows Eventing 6.0 is the new Windows Event Log service and underlying XML-based engine. These components are what deliver the increased scalability, accessibility, and management options. Events are now stored in a flexible XML format that enables custom solutions that can tap into this information natively.

Windows Eventing 6.0 also provides the capability to associate administrative actions with specific events. It does this by integrating the Windows Event Collector service with the Task Scheduler to provide for task-based eventing. This is a new paradigm for the Task Scheduler, which was previously limited to triggering events based on time. The "Attach Task to this Event" wizard (available on the context menu of any event in the Windows Server 2008 Event Viewer) provides an easy way to start a program, send an e-mail, or display a message any time a specific event is logged. This can be very useful when attempting to identify specific actions taking place in your environment that can be isolated to a specific security event. For example, if you are auditing changes to the "Schema Update Allowed" registry key on your domain controllers, you can create a task that sends an e-mail to specific security administrators to notify them when this registry key is modified.

In addition to the new ability to collect and store a large number of event entries, you can also now better control what events are recorded in the event log. This is accomplished through a new feature called Granular Audit Policy (GAP). In previous versions of Windows, the nine broad audit categories often resulted in event overload. Those top-level categories can now be controlled by 50 granular subcategories, each of which represents a related subset of events.

This gives you the capability to filter non-critical information from the event log without losing visibility at the category level. For example, if on a particular system you want to monitor changes only to the registry, but not the file system, previously you could choose only to report success or failure on the Object Access category. With GAP, you can now filter out subcategories such as File System, Certification Services, and File Share and only report events on the Registry subcategory. To explore the GAP subcategories on a Windows Server 2008 system, you must run the Auditpol command from an elevated command prompt. To list the available GAP subcategories, type the following:

auditpol /list /subcategory:*

To get a list of GAP subcategories configured on your system, type this:

auditpol /get /category:*

Note that GAP is not configurable through the standard Group Policy user interface and must be managed through auditpol.exe. The Knowledge Base article at support.microsoft.com/kb/921469 has guidance on how to deploy GAP settings through Group Policy for Windows Server 2008 and Windows Vista systems.

Windows Server 2008 can also capture both old and new values of the specific types in the Security event log. In previous versions of Windows, the auditing subsystem only logged the name of the Active Directory® object attribute or registry value that was changed—it did not log the previous and current values of the attribute. This new capability applies to Active Directory Domain Services, Active Directory Lightweight Directory Services, and the Windows registry. By enabling Audit Success or Audit Failure on the subcategories of "Registry" or "Directory Service Changes" and setting the associated SACLs, detailed events will be raised in the event log for actions on these objects. This can be performed using the following auditpol commands:

auditpol /set /subcategory:"Registry" /success:enable
auditpol /set /subcategory:"Directory Service     
    Changes" /success:enable

For registry changes, these appear as Event ID 4657 events as shown in Figure 4.

Figure 4** Before and after a registry change **(Click the image for a larger view)

This feature is particularly useful when attempting to track changes on Active Directory objects. For Directory Service Changes, these changes appear in a pair of Event ID 5136 events, as shown in Figure 5. Each event has the directory service Object, Attribute, and Operation in the body of the event. For changes to attributes with existing data, we see two operations: Value Deleted and Value Added. For attributes which have not been populated, we would only see the Value Added operation when data is written to that attribute. For example, when a successful modify operation is performed on an attribute of a user object, such as telephoneNumber, Active Directory logs the previous and current values of the attribute in detailed event log entries

Figure 5** Before and after a Directory Service Change event **(Click the image for a larger view)

If a new object is created, values of the attributes that are populated at the time of object creation are logged. If an object is moved within a domain, the previous and new location (in the form of the distinguished name) is logged. This "old and new" feature is enabled by default when the appropriate Audit Policy settings are in place. If there is an attribute you want to keep private, such as employee ID number changes, you can specifically exclude attributes by making a simple schema modification. By modifying the searchFlags property of the attribute in the schema to 0x100 (value 256 -NEVER_AUDIT_VALUE), as shown in Figure 6, the Directory Services Changes event will not be raised when changes to the attribute occur.

Figure 6** Excluding an attribute from Directory Service Changes **(Click the image for a larger view)

Finally, one of the great new features in Windows Eventing 6.0 is Event Subscriptions. As mentioned before, accessing and reviewing the event log is a key system administration task. The new Event Subscriptions capability provides a way to forward events directly between systems. Event Subscriptions consist of an Event Collector that gathers events and Event Sources that are configured to forward events to specified hosts. The ability to consume events is provided by the Windows Event Collector service (new with Windows Eventing 6.0), and the subscriber functionality is built into the Windows Event Log service. A collector can be configured to gather events from many event sources, which can be either Windows Server 2008 or Windows Vista systems.

All data collected from event sources resides in a discrete Event Log, named Forwarded Events (ForwardedEvents.evtx) and managed by the Event Log service on the collector. Configuration on both endpoints (collector and source) is necessary and can be automated (winrm quickconfig –q on the source; wecutil qc /q on the collector). It is important to note that this event subscription capability was not designed for enterprises or to replace systems that deliver events to an external database.

One example where this capability may be leveraged is with a small Web farm. Suppose you have a small set of systems associated with a particular Web site (including Web servers and SQL servers). Those systems can consolidate their Security event log information on a single system using the new Event Subscription functionality. Larger environments will typically require a more advanced event log consolidation toolset.

Audit Collection Services

Given all of the new capabilities of Windows Server 2008, the real solution for long-term management and archiving of Security event log information is through a centralized database of auditing information. Audit Collection Services is a core feature of System Center Operations Manager 2007. ACS provides a mechanism for the forwarding, collection, storage, and analysis of security event data. Security events are collected in near real-time and stored in a central SQL repository. ACS also gives organizations a method of providing least privilege access to audit information since no physical access to the systems actually being audited is required. Let's look at how ACS works.

ACS has three main components. First, there is the Forwarder, which is the portion of the Operations Manager agent that transmits the event log data from the client to the ACS infrastructure. Forwarders transmit data to the second component, the Collector, which is the server-side listener. ACS Forwarders connect over TCP port 51909 to communicate with their assigned Collector in a secure fashion. Prior to transmission, the event log data is normalized into XML, meaning excess information is stripped and the event information is summarized into mapped fields based on event specific header and body information. Once the information reaches the collector, it is sent to the third and final component—the ACS Database. This becomes the repository for long-term storage of security event information. Once stored, the information can be mined directly through SQL queries or rendered using HTML reports using SQL Server® Reporting Services. ACS provides three default views, as shown in Figure 7.

Figure 7 ACS views

From a performance perspective, a single ACS collector can handle a peak maximum of 100,000 events per second and a continuous maximum of 2,500 events per second. For planning purposes, a single ACS collector can support up to 150 domain controllers, 3000 member servers, or 20,000 workstations based on default Audit Policy settings. In one tested, real-world scenario, around 150 domain controllers showed a maximum of approximately 140 events per second with a peak average of 500,000 events per hour. In just 14 days (the default retention setting for ACS), over 150GB of security-event data was stored in the SQL Server database. A more aggressive Audit Policy and associated SACL configuration will obviously generate even more data (per hour, per day, and overall).

The important point to realize here is that with this volume of data, no human could possibly review every event in a typical large enterprise environment. Conversely, organizations should not be afraid of the numbers represented here. Understanding the changes that are happening in your environment comes at the cost of analyzing a large amount of data.

This is where ACS shines. Through SQL Server Reporting Services and ACS, you can turn issues typically buried within the Security event log into something that is as easily identifiable as the color-coded events found with the Application event log. While ACS includes a set of default reports, extending these for your environment's specific needs is simple.

Take the following scenario: due to the sensitivity of external trusts in the environment, management has asked that we develop a report detailing the creation of Active Directory Trusts. After doing some research, we know that a trustedDomain object is created in the cn=System container within the specific domain naming context in Active Directory when a Trust is created. After editing the SACL on this container to audit successful creation of any Trusted Domain object, we then have the ability to capture security events each time an object of this type is created. This is rendered in a 566 event in the Security event log on the DC the trust creation was performed on. We can then write a simple SQL query to retrieve this information from ACS:

select * from AdtServer.dvAll 
where EventID = '566' and
String05 like '%trustedDomain%'
order by CreationTime desc

To get this into a report, use the version of Visual Studio® 2005 that is included with SQL Server 2005 Reporting Services as it is specifically provided for report development. After completing the wizard, reports very similar to the one in Figure 8 will be easy to create. What's more, any change in the environment that can be represented in the Security event log can be summarized into a similarly great looking report.

Figure 8** Sample ACS report **(Click the image for a larger view)

Developing an Audit Plan

Now that we understand the challenges as well as the legal and the technical aspects of auditing, how should IT administrators go about developing an "audit plan" for their organization? Like most things, developing a comprehensive audit policy is a multi-step process. The first step is to determine what should be audited. This includes analyzing your environment and determining what types of events and changes should generate audits. This could include simple items such as account lockouts, sensitive group changes, trust creation, or complex changes such as modifications of configuration elements within applications in your environment. The key here is that management must be involved in determining the "what" in an audit plan. This exercise needs to be done on paper and should be repeated at a regular interval—not just after significant incidents.

The second step involves identifying how audit information concerning specific changes is returned in the form of security events. Audit information is sometimes cryptic and not easily readable. Prior to implementation, correlations must be established between security events and various actions to understand what the security events really mean. After an incident is not the time to figure out the relationships of events to actions.

The third step is when the rubber meets the road, that is, when you implement your Audit Policy and SACLs. As discussed previously, you will need to define Audit Policy settings (to enable generation of security events) and SACLs (to generate audit trails for associated actions) in the directory, file system, and registry to get a complete picture of changes in these areas.

All this brings us to the fourth and final step—collection, triggers and analysis. Depending on the size and needs of your organization, these can be covered with the native Windows Server 2008 capabilities or with advanced solutions such as System Center Operations Manager's Audit Collection Services functionality. A common mistake made by most organizations is only setting Audit Policy without defining SACLs. The last step is all about implementing a technology solution for reporting and sharing data with the stakeholders within your organization. As mentioned before, most organizations have an established entity responsible for security, and an audit plan needs to be structured around existing organizational elements to be effective. The key to this final step is collecting and presenting information in a meaningful way to all those responsible for understanding change in the environment.

Most IT organizations are one significant event away from merely thinking about a comprehensive audit plan to actually requiring one. Windows Server 2008 provides enhanced mechanisms for collection and analysis of security event data compared to previous platforms. Advanced collection and reporting technologies such as ACS expose problems once obscured by event volume and distribution, making these changes instantly obvious.

Like most IT problems, process is the primary challenge. Additional configuration and analysis is always required to capture what IT managers expect, so developing a deep understanding of your environment's requirements and the capabilities of the Windows platform will allow you to meet these challenges head-on. Good hunting.

Rob Campbell and Joel Yoker Rob Campbell is a Senior Technical Specialist and Joel Yoker is a Senior Consultant on the Microsoft Federal team. Rob and Joel are both focused on developing and deploying security solutions for United States Federal government customers.

© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited.