You can significantly improve Windows' log reporting capabilities with a few key changes.

Your SIEM works by collecting log data from across the enterprise IT environment. The more detailed and comprehensive these logs are, the more accurate its insights will be.

Although Windows has a basic set of log reporting capabilities built in, the operating system's out-of-the-box configuration isn't quite optimal for advanced SIEM users. Streamlining audit policies lets enterprise security professionals enjoy improved alarming, reporting, and compliance outcomes. It's a vital step towards achieving best-in-class security using an SIEM solution in a Windows environment.

Lumifi has continuously refined its approach to Windows Audit Policy configuration since 2015. Our SIEM experts regularly refine their methods in response to real-world feedback and implementation data. This document is the result of years of cumulative insight into what works best when deploying an advanced SIEM solution in an enterprise Windows environment.

How Windows Handles Basic and Advanced Security Policies

The Windows Security Settings menu features two kinds of audit policies:

• Basic policies (shown in blue)
• Advanced policies (shown in green)

Some of these policies are redundant. If there is a discrepancy between the two, the advanced policy takes precedence. Any green policy will override the corresponding policy in blue.

While it's technically possible to configure Windows Audit Policy logs exclusively through policies in the Advanced Audit Policy Configuration folder, Lumifi recommends editing both in specific ways. Before we explain exactly how, we'll have to verify exactly which policies are currently active.

How to Check Your Current Auditing Policy

To find out exactly what policies your device is running, open the admin command prompt and execute the following command:

auditpol /get /category:*

This will provide you with a long two-columned list of system processes and their auditing status. Some of these processes will have "No Auditing" status, while others have "Success" or "Success and Failure". They should correspond to the Group Policy Object you are currently editing.

Save this report before making any changes to your Windows Audit Policy. This way, you'll be able to make another report at the end of the process and compare the two. This helps to ensure the desired changes took place.

Using the command-line interface ensures that you see accurate information about your audit policies. Since the regular user interface responds to your level of user permissions, it's possible for you to see local audit policies that do not reflect your overall system's policies.

What If Audit Policies Don't Match the Current Group Policy Object?

You can try using the now-deprecated Resultant Set of Policy tool (rsop.msc) to generate an audit policy. Its results may not be accurate in terms of policy settings, but it will show you which GPO policies are in effect. You can use this information to track down discrepancies and resolve them.

Configuring Audit Policies in Windows

Enabling policies won't necessarily hurt your security posture, but it will impact performance and resource allocation in your SIEM solution. Lumifi recommends being selective and trying to capitalize on the highest-value audit policy logs whenever possible.

This is particularly true for SaaS-based SIEM service models. Users with UEBA-based solutions will need to collect more logs to improve the accuracy of those systems. We'll cover the differences in a more detailed format below.

Advanced Policy Configuration, Step-by-Step:

Account logon

If you are using an SIEM 1.0-style platform or have limits on EPS or storage, enable the following audit policies as shown:

We highly recommend moving to a higher-performance UEBA system. If you have this kind of system, you can enable all four policies as shown here:

Account Management

Account Management is important regardless of the type of SIEM system you are using. Every subcategory listed here should be audited on Success or Failure: 

Detailed Tracking

Here, optimal policy configuration depends on the unique characteristics of your IT environment. There are scenarios where auditing DPAPI activity or Process Creation and Termination may be advisable. Have a Lumifi security expert take you through the best configuration for your SIEM.

Here is an sample configuration designed for a UEBA or UBA system:

DS Access

These are generally operational policies that produce high alert volumes. We do not generally advise configuring these, although they may be useful in certain situations, such as when using system access control lists. For most users, it' best to leave these Not Configured:

Logon/Logoff

Of the eleven different audit policies contained here, Lumifi recommends enabling only seven. This should provide you with the optimal balance of security and system efficiency:

Object Access

UEBA system users must enable Detailed File Share here. There is potential value for other SIEM systems as well, but these are best approached on a case-by-case basis.

Note that three audit policies have been set to "No Auditing". This enables the end server admin to enable them for troubleshooting. To set them this way, select Configure and then click away without selecting Success or Failure.

Audit File Share adds value to SIEM log reporting but can produce extremely high volume on File Servers. Lumifi only recommends enabling it if you are sure you can handle that volume.

Also, keep in mind that Audit File System will be very verbose during patching. We recommend keeping it disabled for Windows Firewall, since Windows will write a log for everything it sends. Emitting these logs through a tool like nxlog may introduce race conditions.

Policy Change

Using WMI with Windows 10 and Server 2016 (or later versions) will increase the robustness and frequency of 4703 events. This is especially true when remote endpoint monitoring tools make frequent connections.

Lumifi requests Policy Change > Audit Authorization Policy Change be changed from "Success and Failure" to only "Failure".

Privilege use

While there are good reasons to enable Sensitive and Non-Sensitive Privilege use, they will generally change Windows rights based on user or account permissions on a "per action" basis. Lumifi recommends leaving these off at the beginning, and then reviewing usage on a server-by-server basis after SIEM implementation is finished.

For example, it might make sense to enable auditing for Sensitive Privilege on high risk servers to monitor driver loading and unloading, or file restoring activities.

Lumifi recommends leaving Audit Sensitive Privilege set to "No Auditing" and and reviewing after implementation is finished.

System

System audit policies are important! Make sure these are enabled as shown:

Global Object Access Auditing

You can use global object access auditing to write custom policies. Talk to a Windows audit policy expert at Lumifi to find out how you can use this subcategory to create and deploy highly customized policy configurations.