What is Sigma?
To provide context, but addressed more deeply below, Sigma, originally developed by Florian Roth and Thomas Patzke, is a standardized way of expressing and sharing detection rules that help identify potential security threats by analyzing logs and events within an organization’s network. It’s another commonly shared language for security researchers and analysts.
Transform your Sigma Rules Effortlessly!
Building off this concept, SigmAIQ is a wrapper for pySigma and pySigma backends & pipelines. It allows detection engineers to easily convert Sigma rules and rule collections to SIEM/product queries without having to worry about the overhead of ensuring the correct pipelines and output formats are used by each pySigma-supported backend. Below we will take an in-depth look into Sigma Rules and the value of an open-source repository for detection engineers, streamlining processes that could be written manually and instead providing a free, installable library for building, testing, implementing, and tuning logic to detect threats.
As noted in the disclaimer, SigmAIQ is actively maintained and updated, and the open-source nature of Sigma additionally allows for further collaboration in an ever-evolving threat landscape. Within our platform and the repository available in Github, SigmAIQ allows AttackIQ to contribute new rules to the cybersecurity community and deliver users valuable detection information around our content.
How to use Sigma Rules to Improve Detections
Purpose
The purpose of this documentation is to demonstrate how mitigation recommendations in the AttackIQ platform can be used to improve overall detection efficacy. More specifically, we will be demonstrating how Sigma Rules can be automatically translated to vendor-specific queries in the AttackIQ platform, and then implemented into a vendor product to ensure the tactics, techniques, and procedures of the tests are detected by your vendor product and AttackIQ. Although the specific instructions for creating a detection rule varies across vendor products, the general process and specific steps inside the AttackIQ platform is the same across all vendor products.
Disclaimer
As this is a new offering from AttackIQ, some of the recommended Sigma Rule mappings to scenarios and other content may be incomplete. We are actively working on improving the Sigma Rule mappings to both historical, current, and future content.
In addition, it is important to test any detection rules for security products before implementing them in a production environment. This will ensure the detection rules will trigger for the intended TTPs to detect (true positives) while avoiding alerting on behavior that is benign or normal for a particular environment (false positives). Queries from recommended Sigma Rules may need to be customized to eliminate certain false positive activity based on your own environment.
Before implemented any new detection rules in production, it is best practice to notify all relevant parties, such as your organizations blue team and SOC. Ensure you follow any specific policies and procedures before implemented new detections/alerts in your security products.
Sigma Rules Overview
Sigma is a generic and open signature format that is primarily used to describe events in logs that should be matched for a detection. Sigma is used as a standard in the cybersecurity industry for detection engineering, as using a single standardized format allows users to easily create and share detection rules for log events, regardless of the specific security/SIEM products that are used in an environment. Instead, detection rules are translated from the single Sigma format to a specific query for a security product.
Sigma Rule Fields & Schema
Sigma is written in YAML format, and a Sigma Rule is a single YAML file that typically contains the following fields:
- title: The title of the Sigma Rule, i.e. what the rule detects
- id: A unique, randomly generated UUID given to a rule
- description: A description of the rule and activity the rule is trying to detect
- status: The stage of the rule, i.e. how confident it will detect true positives and avoid false positives; stable, test, development.
- references: Any URLs/citations that were used to help develop the rule
- author: Who created the rule
- date: The date the rule was created
- tags: Tags are commonly used to denote MITRE ATT&CK mapping (i.e. attack.collection, attack.t1560.001), or what TTP(s) the rule is associated with
- logsource: The type of OS the rule applied to, as well as any specific log categories (i.e. process_creation) or services (i.e. auditd) the rule applies to
- detection: This is arguably the most important field, as it contains the field names/values to detect (typically denoted as ‘selection’ fields), what fields/values to filter out (typically denoted as ‘filter’ fields) as well as the condition field that describes what combination of selections and filters results in a true positive detection.
The fields inside of the ‘detection’ field typically use Sysmon field names by default. Even if the original log source is not Sysmon, the Sysmon field names in the Sigma Rule can be converted to the correct field names by community maintained pySigma Python libraries, a GUI Sigma Rule converter such as sigconverter.io, or in the AttackIQ platform via our opensource pySigma wrapper SigmAIQ.
Sigma Rule Example
The following Sigma Rule is an example from the official Sigma Repository. The rule is titled Pass the Hash Activity 2, and as the description denotes, it is meant to detect the ‘Pass the Hash’ attack on Windows.
In the ‘detection’ field, we can see we have two ‘selection’ fields, one ‘filter’ field, and one ‘condition’ field. Although we will only ever have one ‘condition’ field, we can have any number of selection and filter fields. While there is no ‘correct’ name for these fields, best practices suggest to name anything that should be matched on as ‘selection*’ or ‘sel_*’, and anything to act as a filter for false positives as ‘filter*’.
These selection and filter fields are then referenced in the ‘condition’ field to determine what log events should constitute a match. In the case of this Sigma Rule, this rule will match any log event with all fields and values from either of the selection fields, but does not contain the field ‘TargetUserName’ with the value of ‘ANONYMOUS LOGON’. In addition, a log event must include all criteria from a selection field, not some values from one selection and some values from another. For example, this event would match, as all fields/values match what’s defined in selection_logon9:
2023-10-03T10:00:00.000Z - EventID=4624, LogonType=9, LogonProcessName=seclogo, TargetUserName=Admin
But this event would not, as the EventId and LogonType match selection_logon9, but the LogonProcessNamematches the LogonProcessName defined in selection_logon3:
2023-10-03T10:00:00.000Z - EventID=4624, LogonType=9, LogonProcessName=NtLmSsp, TargetUserName=Admin
For more information, please see the official SigmaHQ Sigma Github Repository.
Sigma and AttackIQ
Setup
For the purpose of this demonstration, we will be running the scenario “Mshta Script” in an assessment on a Windows 10 asset. We will also be attempting to detect the scenario with the “Splunk ES Stream” integration. Ensure your test asset has Sysmon installed and enabled, or command line process auditing configured, so the required logs are successfully forwarded to Splunk. As seen below, we have already run the assessment, and the scenario was not prevented, and also not detected:
Accessing Scenario Mitigations
In order to remediate the lack of detections for this scenario, we can implement one of the Sigma Rules that is mapped to the scenario in the AttackIQ platform. In the results page, click on the scenario, then under Mitigations, click on Detection Rules:
Run result running MSHTA Script on a test asset. No detections present.
Note, you can also view scenario specific mitigations/detection rules in the main menu on the left side of the screen. After navigating to the Scenarios page, click on an individual scenario, then the Mitigations. In this scenario details mitigations tab, you will see the Detection Rules section on the left.
Navigation example for finding detection rules in a scenario modal.
Selecting a Sigma Rule
Clicking the Detection Rules tab will show the list of mapped Sigma Rules by their title and description. If you click a rule, you will be able to see the native Sigma rule in YAML format, as well as a list of vendor product queries the Sigma Rule can be translated to successfully. Note that not all rules can be translated to each product; the success of the translation is dependent upon fields and conditions that may or may not be present/supported by certain vendor products. Below, we have clicked on the rule “Suspicious MSHTA.EXE Execution Patterns”. This rule should be specific enough for the environment we are working in as to only detect malicious behavior, as we do not expect mshta.exe in our environment to run any commands that match the strings in the rule. The rule should also be applicable to the logs that are collected in your environment, as not all rules may be applicable if certain log types/sources are not collected and cannot be analyzed.
Selecting a specific Sigma Rule from the list of recommended Sigma Rules for the Mshta Script scenario.
As we are testing Splunk detections in this documentation, we will click the Splunk vendor icon below. This will automatically translate the Sigma Rule into a Splunk search:
Selecting the technology in the horizontal tabs will automatically translate the Sigma Rule to a query for the selected technology.
Also note that we can select a variety of output formats right above the search string. This will change the output format of the query, depending on specific output formats the product supports. Selecting the “Stanza” output format for Splunk will automatically create an entry that can be placed in a Splunk savedsearches.conf file to automatically create an Enterprise Security Correlation Search:
Depending on the technology and Sigma Rule, a variety of output formats for the converted Sigma Rule can be selected.
Testing a Sigma Rule
Although we will be using Splunk for this process, the same principals apply regardless of what security product is used to test and create detection rules:
- Use the translated Sigma Rule query to search for the activity, with a large enough timeframe to also capture any potential false positives
- Ensure the TTPs are found with the query
- Edit the query manually to remove any false positives
- Repeat steps 1-3 until little to no false positives remain
- Implement rule based on organization policy/procedures
The general idea is that we want to search our logs with the query to make sure we can find the true positive events, while also not finding any false positive events. Be sure to search through a large timeframe, ideally multiple days/weeks, to get a large enough dataset of logs; this way, we can ensure we can catch edge cases/false positives now while testing before the alert is put into production.
Below, we are searching Splunk for the last week based on the default query found in the last section:
Searching the converted Sigma Rule in Splunk to ensure no false positives over the last 7 days.
Only eight events were returned for two hosts, one of is the asset we are testing on (note: the time difference is due to timezone display preferences for the Splunk user). All events returned are as a result of AttackIQ testing; in other words, our converted Sigma Rule has returned zero false positives over the past week of data.
We can also explore the CommandLine field, which shows the exact command being run in the scenario that the Sigma Rule matched against:
The CommandLine fields, which is part of our Sigma Rule detection selection.
Since there are no false positives, we are satisfied with this rule and will create an alert in Splunk for it then re-run our assessment. The process for creating an alert will depend on your security control(s); below is our newly created Splunk Enterprise Security Correlation Search:
A Splunk Enterprise Security Correlation Search has been created from the converted Sigma Rule. The title of the search is the same title as the Sigma Rule.
After re-running the assessment, we can see that our most recent result has a detection as well as an alert! Under the “Alerts” section, we can see the name of our Splunk Enterprise Security Correlation Search that we created from the selected Sigma Rule:
Detection and alert results after rerunning the assessment.
