SIGMA RULES IN THREAT HUNTING PROCESSES
What is Sigma?
Sigma is an open source framework that allows writing rules to analyze logs, similar to YARA for files or Snort for network analysis.
- Snort → Network Traffic
- WOUND → Files
- Sigma → Logs
can be memorable. SIEMs, analytics, scripting etc. for a data source. As a collaborative resource:
- Operation System
can be given as an example. As for detecting:
- Web Access
- Process Execution
- Windows Events
- Network Events can be given as an example.
Sigma rules are written using a predefined syntax in YAML format and then converted (using sigmac or online converter) into a format that fits the target SIEM or platform used in the organization. As supported targets:
- Splunk (Dashboard and Plugin)
- ElasticSearch Query Strings, Query DSL
- Windows Defender Advanced Threat Protection (WDATP) etc. supported by platforms.
Sigma rules are a powerful tool that makes it easy to analyze different types of logs and detect specific action or threat. It can be used in two ways:
1-) Identification of Suspicious Activity / Incident and Notification of Warning
Sigma rules can be integrated into SIEMs and can detect different events directly, thus helping to detect and stop them before they can be damaged further.
2-) Threat Hunting
Sigma rules can be used in threat hunting processes. Rules can be used to identify when and with what techniques a particular attack or threat (for example, APT Groups) is targeted.
By applying Sigma rules on old logs, it can be checked whether there are violations (over the stored logs).
Normally, the detection time of a violation is a long process. However, thanks to these rules, axioms can be taken faster in the incident response process by detecting and analyzing suspicious activities.
Using Sigma Rules for Threat Hunting
Sigma is a universal sign language for analysis of logs and allows you to write rules about threat detection. The flexibility of Sigma rules allows you to use detect rules created by other individuals and use them in your own locale, as the rule can be compiled for any SIEM and log source.
First of all, creating a detection rule is not an easy task. The main reasons for this are:
1. First of all, it is necessary to find parameters or phrases that can be used to detect the threat by considering an analysis of the threat through existing examples or by finding them in technical reports and threat intelligence sources.
2. Another reason is that a proper set of rules is required that does not trigger false positive alerts and is not too strict to prevent threats from being ignored. Detection rules can be studied through a pyramid known as the Pyramid of Pain. In thinking here, attack indicators are progressively progressing as a scale of “pain” on the attacker side as these indicators are detected and blocked by security products.
Here, the time for the security teams to determine the indicators varies according to the degree of damage. For example, the hash value of a file is easy to detect, but becomes more difficult when the hash value bits are changed by threat actors. However, one of the issues that should be well known is that it is equally difficult for threat actors to change the behavior of the threat and regulate its detectability.
Rule Writing with Sigma
Sigma is very easy to use. Because Sigma uses the YAML format, as we mentioned above, and it should be worked with a compiler that supports it. VSCode, Atom, Sublime Text or Webstorm can be used as compilers. You can download the repo from the link below.
By going to the sample rules in the rules directory in the downloaded project, edits and rewriting rules can be made here. In order to examine the rule structure, let's start to explain the relevant parameters through a rule we pulled from the rules section in the repo.
– Title and Logsource:
Here, information about the rule, such as status, description and reference, is specified in a title. In the logsource field, data such as product (windows, unix, apache, zeek etc.), category (firewall, proxy, web server, apt), service (SSH, PowerShell) etc. can be defined.
– Description: Contains detailed information about what the rule does and how it works.
– Condition: This is the part where it is specified how the rule will be processed on the platform to be integrated.
Descriptions of other parameters are as follows:
– Author: The person who wrote the rule
– Category: As stated above, the category information to which the rule belongs (like apt)
– Product: Product information from whichever product it was taken from (such as windows)
– Date: The date the rule was created
– Level: The criticality level information of the created rule (low, medium, high, critical)
– Status: Indicates the status of the rule and takes three different values.
– Stable: The rule is considered stable and can be used across platforms.
– Test: Rule knowledge with most of the work done, final tests done
– Experimental: Rule not recommended to be used in the preparation phase
– References: References of keywords and reference information about the rule can be written in this section. These can be blog articles, technical articles, presentations or even tweets.
– Metadata: Consists of title, status, description, references and tags.
The basic rule format is as in the image below:
In addition, compiling these rules for different platforms can be done with the tool or online tool.
1-) It can be done with the "sigmac" tool written in python as a tool. Installation is very simple.
2-) As another option, Uncoder.io tool can be used. With this tool, the integration of the sigma rule with different SIEMs can be done easily.
As an example, as indicated in the image below, the conversion of the sigma rule we examined above into Qradar format is seen.