Microsoft Windows security logs are records of information related to login attempts (success and failure), elevated privileges, directory service access, policy changes, privilege use, and other security events, as defined in a system's audit policy. In the Common Information Model, Windows security log data can be mapped to any of the following data models, depending on the field: Authentication, Performance, Updates, Vulnerabilities, Endpoint, Event Signatures, and Change. These logs are one of the primary tools used by system administrators to detect and investigate unauthorized activity and to troubleshoot system problems.
There are over 400 loggable events. We recommend following Microsoft’s official guidance for “Stronger” security visibility. The Audit Policy Recommendations page from Microsoft TechNet provides detailed configuration settings per operating system from Windows 7 / Server 2008 and later.
How can I use this data?
When your Splunk deployment is ingesting Windows security logs, you can use the data to achieve the following objectives:
- Recognize improper use of system administration tools
- Create a timebound picture of network activity
- Monitor for signs of Windows privilege escalation attacks
- Detect techniques in the Orangeworm attack group
The following sections provide information on configuring Splunk software to ingest this data source. To configure the device or software, we recommend that you leverage official Microsoft resources.
Getting Windows Security data in
Splunk Docs contains extensive guidance on getting data into your Splunk deployment. If your deployment is not already ingesting Windows Security data, the following topics can assist you in preparing to work with this data type:
- Splunk Enterprise
- Splunk Cloud
The recommended index is oswinsec. If you have already started ingesting the data sources into another index, then you can usually proceed, though you should consider whether you should separate Windows Security logs from Process Launch Logs and both from Application and System logs, based on who likely will need access or be prohibited access.
The source type is wineventlog:security. If you have already started ingesting data with a different sourcetype, we recommend that you switch over to the standardized source types.
The supported input type is WinEventLog://Security.
In addition, you will need the Splunk Add-On for Microsoft Windows. The add-on can be downloaded here and the official documentation can be accessed here. Read and follow the documentation carefully to understand all the essential information you need to work with this data source, including how to install the add-on, configure Microsoft Windows security log collection, and configure Splunk. If you do not use the Splunk TA for Windows to ingest data, then keep in mind you may need to go through extra work to align field names to get value out of Splunk Security Essentials and other Splunk content.
At a very high level, common ranges are:
- Workstation: 4-6 MB/day (Including Application, System, and Security Logs)
- Application Servers: 25-50 MB/day
- Domain Controllers: 50-500 MB/day depending on the number of users
These ranges can vary dramatically. For example, with highly active Active Directory controllers with thousands of simultaneous users, you could see more volume.
When deploying audit policies, usually new systems or an increase in system log messages show up first in Splunk. If you already have some logs coming in and want to validate that you’re getting the new ones, look for the delta between your old policy and your new one, and google “Windows Event ID” – that will usually give you something specific to search for (though you may have to take the action that gets logged, if it’s less common). A good example is “Windows Process Creation Event ID,” which quickly nets you “Event ID 4688” as the first result.