One of the main goals of Sigma as a project and Sigma rules specifically has always been to reduce the gap that existed in the detection rules space. As maintainers of the Sigma rule repository we’re always striving for reducing that gap and making robust and actionable detections accessible and available to everyone for free.
Today we’re introducing a new contribution to the Sigma project called log-source guides. The idea behind it is to provide specific guides on configuring a system’s audit policies so that the system actually creates the logs needed by the rules. An adequate audit policy is a crucial dependency often overlooked when deploying Sigma rules.
SIGMA Log-Source
Before we delve deeper, Let’s take a step back and talk a bit about how the log-source attribute is used in Sigma rules.
Every Sigma rule requires a section called log-source that indicates as the name suggests, the log source on which this detection will fire. A typical example would look like this:
product: windows category: process_creation
The “product” indicates that this rules is targeting the “Windows” product and a specific category called “process_creation” is used to indicate that this rule is using “Process Creation” events. You can read the full explanation of every field in the specification
To someone who isn’t familiar with Sigma or logging a couple of question will arise:
- Is “Process Creation” category using events “Sysmon/EventID 1” or maybe “Microsoft-Windows-Security-Auditing/EventID 4688”?
- The next question that arises: How would we collect these logs?
This is where the log-souce-guides enter the picture.
-Log-Source Guides
Starting from today, if you navigate to the Sigma main rule repository, you’ll see a new folder called “rules-documentation” this will be the location of the aforementioned “log-source-guides“ and future documentation projects teased here.
The log-source-guides will have a simple structure that reflects available log sources. So in the example of “process_creation” for the Windows product:
Structure
Now that we established the location of these guides, let’s talk about their structure and the information they provide. Every logsource guide will provide the following information:
Event Source(s)
This section will describe the source(s) used by the log-source. As a quick way for the reader to know exactly which channel or ETW provider is required to be able to receive the events.
Logging Setup
This section describe a step by step guide on how to enable the logging and which events are to be expected by enabling it. Let’s take the “Credential Validation” audit policy.
- The “Subcategory GUID” is the GUID for this specific audit policy which can be used with the auditpol command to enable the log (as we’ll see in a little bit).
- “Provider” indicates the exact ETW provider that is responsible for emitting these events.
- “Channel” is the Event Log channel where the generated events are emitted.
- “Event Volume” indicates the amount of logs to be expected by enabling that audit category or EventID.
- “API Mapping” is a direct link to jsecurity101TelemetrySource project.
- “EventIDs” are the events generated by enabling the policy or log.
Next comes the section on how you’ll be able to enable the log in question – in this example either via Group Policy or by using Auditpol.
Note: This section will obviously be different depending on the logs. Enabling Sysmon logs will be different than enabling Security logs.
Full Event(s) List
This section while not always be present and is meant to be a collection of all events generated by the event sources in question. It’s there as a quick reference for any event. As every event is linking to the MSDN documentation when possible.
Event Fields
The last section contains the specific event fields used by every event. While this section will be complete for certain log sources such as “process_creation”, it’s still a work in progress for logs such as security and will be populated over time.
The idea behind this is to provide the fields that the event generates as a reference. Since SIGMA rules aim to be as close to the original logs as possible and leave field mapping to the back end.
Linking Log-Source Guides and Rules
To make these log-source guides easily accessible. Every Sigma rules will now link to their respective logsource documentation via a unique ID that will be added to the “definition” section. Here is an example:
As part of this initial release documentation will be available for the for the following log-sources:
- product: windows / service: security
- product: windows / category: process_creation
- product: windows / category: ps_module
- product: windows / category: ps_script
In the coming weeks and months we’ll keep adding more documentation to cover every available log-source.
Sigma Log-Source Checker
As part of this release we’re also providing a new script we’re calling “sigma-logsource-checker“. The idea behind this script is to provide the user the ability to know which logs to enable based on the SIGMA rules they’re using.
It takes a Sigma rules folder as input, parses all the used log-source and Event IDs and suggests the Audit policies and logging configurations that should be enabled.
As an optional feature, It can also parse the XML output of gpresult
gpresult /x [results.xml]
and then suggests configuration changes based on current policy:
Note: This version will only check the Security Audit policy and PowerShell log configuration. We’ll keep improving it as we go along.
You can have a look at this today by visiting the Sigma HQ main repository
