SIGMA RULES IN THREAT HUNTING PROCESSES

December 8, 2022June 8, 2023

Contents Hide

1 SIGMA RULES IN THREAT HUNTING PROCESSES

2 What is Sigma?

3 1-) Identification of Suspicious Activity / Incident and Notification of Warning

4 2-) Threat Hunting

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:

Firewall
Operation System
proxy
WebServer

can be given as an example. As for detecting:

Web Access
Authentication
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
kibana
logpoint
Qradar
ArcSight
PowerShell
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.

Link: https://github.com/Neo23x0/sigma

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: