Secrets of Windows Event Auditing
The mountain of access audit requirements continues to grow. So, too, do the questions surrounding access to corporate data, such as:
- Who has access to what?
- Who is accessing the data?
- What controls are in place around management of permissions?
These questions—and others—have become as common a part of IT discussions as server capacity or software deployment.
Although audit requirements are impossible to ignore, the tactics that constitute an ideal approach for your specific requirements remain elusive. Every organization differs in terms of applications, firewalls, network configuration and other intricacies. Most share common fundamental components, including Microsoft Active Directory and its related Windows file systems.
Windows and Active Directory have become staples in virtually every enterprise. Auditing security events across these platforms is a ubiquitous challenge relevant to almost every IT manager. However, the obvious solutions present hidden challenges.
Microsoft Windows Servers, including Active Directory servers, have built-in event-logging capabilities. You can configure these event logs to capture critical security events such as creating user account and security group membership changes. However, capturing the right information in the right way so you can act on it is a tricky business. There are a number of steps you must take to configure Windows event logging. Even then, the results can be unsatisfying.
Configure Windows Event Logging
Conventional wisdom around audit response says to simply capture everything that happens from every system. Turn up logging and put a mechanism in place to convert logs into some long-term storage format that’s searchable, available for reporting and convenient for archiving.
Security Information and Event Management (SIEM) and Log Management solutions typically subscribe to this line of thinking. This gives them the advantage of being able to monitor hundreds of solutions from different vendors—from network hardware to software applications—with a common approach. Needless to say, implementing this approach is easier said than done.
Here are a few steps you should take when configuring Windows and Active Directory Event Logging, whether for integration with an SIEM solution or simply to capture for future auditing.
1. Determine the Events You Need
First, you need to understand which events you need to track. You’ll also need to gather the associated event identifiers (IDs). Complicating this task is that the event ID numbering is different between versions of Windows. For example, Windows Server 2008 uses four-digit event IDs along with audit subcategories for each of the main audit categories.
There are many events that look similar to each other, so you really need to know that you’re logging the right event. A single action will often generate numerous events in the log, so it’s important to understand the interrelationship between the event IDs.
The subcategories in Windows Server 2008 can be useful because you can enable auditing on some events, but not others. This is a step in the right direction for Microsoft auditing. For example, instead of treating all Account Management events the same, you can enable auditing on Security group management but disable audit on Distribution group management.
You have to use a command-line tool to apply audit settings to subcategories. You still won’t get advanced filtering capabilities, such as alerts on changes to high-risk groups or actions taken by a subset of users.
There are also Account Management audit events and Directory Service Access audit events that overlap. This complicated matters further. If both are enabled, you could see more duplicate events, which creates confusion about where to find the best event data. “Before” and “After” values are written to different events. In many cases, you’ll need to correlate multiple events to answer even basic questions.
2. Enable Auditing on Desired Objects
Once you know the set of events you need to audit and have the associated event IDs, you need to enable auditing on the objects themselves. In some cases, default settings may be enough.
You can manage audit settings on an object-by-object basis, so it’s important to understand what the audit settings are and apply any changes you need to meet your requirements. For example, you can right-click on an object, navigate to the security tab and click “Advanced.” This will let you apply changes on the Auditing tab, such as disallowing inherited audit settings from parent objects or adding specific audit settings to this particular object or all child objects.
In other words, if you enable auditing on security groups, you still need to ensure that auditing is enabled on those specific security group objects. Typically, enabling audit on directory objects is as simple as enabling “Audit Account Management” in the appropriate Group Policy Object. Keep in mind, though, that audit settings differ slightly in various versions of Windows. If you have a mixed environment, be sure to consult the documentation for appropriate audit setting instructions. Also ensure your audit policies are properly configured on each Active Directory Domain Controller.
You can also use the Active Directory Service Interfaces Editor, or ADSI Edit, to apply a “don’t audit” flag on attributes you’d like to filter outside of the auditing process. This removes all auditing of that attribute for all objects, so do this carefully. For example, you won’t be able to distinguish between administrative user accounts and other accounts.
3. Configure Event Log Settings
The third step is to configure log settings. You need to set the appropriate access permissions so advanced users looking to cover their tracks can’t clear logs to hide their tracks. If the log security policy isn’t enabled, any authenticated user has sufficient access to write and clear application logs. By default, System and Security logs can only be cleared by system software or administrators.
You also need to set the maximum log size and retention rules based on your requirements and particular environment. These settings help you control how large log files can grow and what happens when they reach that maximum size. This is critical, because you need your log collection systems to be able to handle the logs efficiently. When they grow too large, logs can significantly slow server performance.
System logs are not ideally designed for easy searching, flexible reporting or long-term archiving. They’re subject to correct and diligent configuration. Assuming everything is perfectly deployed and maintained, you should be able to collect the data you need related to audit reporting. Extracting useful information and generating actionable results from that data is an entirely new challenge.
For example, a single action often generates multiple log events. This makes it difficult to distinguish specific actions, like a user who isn’t in the finance department accessing finance files. Each event is labelled with an event ID and language that often seems cryptic to untrained business managers and auditors. You’ll need to spend significant time and effort translating log data during audit or entitlement review processes.
It’s also worth considering that event logs only capture a small portion of what happens. For example, there may be a pre-defined set of object and attribute changes in Active Directory that appear in the Security Event Log. A change to the description attribute on a security group would not appear in the log.
You could potentially configure event logs to capture changes to attributes that aren’t available by default, but most organizations don’t. This creates a layer of management and configuration that can cause headaches. Logs also often leave out critical information, such as who did it or what the value was before the change occurred (in case you need to revert).
SIEM and log management solutions can sometimes improve the situation by making logs easier to search, report and archive. Many organizations underestimate the initial and ongoing effort required to get the answers they need.
For some organizations, this might still be the best approach because the cost and effort can be weighed against the end result—long-term storage of event logs from potentially hundreds of systems and the ability to meet access control, retention and compliance requirements. If your primary focus is your Windows network environment and you’d like simpler reporting, reduced cost and effort, and better control over event response, there is an alternative.
An Alternate Approach
What you really need is information, not logs. Don’t start the process thinking about how to best collect logs. Start by considering the real human actions important to your business. Are newly created user accounts important? Do you want to know who’s changing the security group member lists? Do you need to know who you should add to the group? Do you care when a department member opens a file relevant to that department? Do you want to know when members of your IT group access that data? These questions are critical.
Don’t limit yourself to what’s showing up in the event logs. You can think about what you really want, which is answers to those types of questions. You need answers to questions and information that’s actionable and understandable by non-IT personnel.
By collecting information from the source rather than event logs, you get access to more information, better details and a more reliable, consistent approach. It’s also easier to manage because there are no audit settings or numeric event IDs.
If you need an enterprise log management, you can still organize your information for easy integration and upload. You’d be helping the process quite a bit by filtering out the unwanted data and providing exactly what you need in an easy-to-read format.
Secrets of Windows
Auditing Is Not for the Meek
While security event information is clearly useful and important, capturing that information from Windows event logging presents a number of challenges and significant effort. Those challenges can be managed with enough time, effort and cost. The end results may still miss the target, though.
Capturing event information without relying on event logs helps you generate the answers you need without implementing and managing Windows security event log auditing. The conventional approach generates data. The improved approach creates answers with less effort, better reporting and actionable information.
David Rowe, CEO of NetVision
TechNet Magazine November 2011
Enjoy reading
