Let’s start with the basics.

Many years ago I watched as analysts, who might now adorn the title threat hunters, write queries in their SIEM to detect malicious activities.

Others (aka the majority) simply configured their SIEM and used the off-the-shelf queries the vendor bundled with it.

The development and sharing of detection queries was non-existent.

What was duly needed at the time was a standard. A way to write a query once and use it everywhere, on any system.

Introducing Sigma.

Sigma has been around for about three years. Though in the last year it has seen a marked increase in adoption.

Sigma is for log files what Snort is for network traffic and YARA is for files.

Essentially Sigma allows researchers and analysts to define the log sources and search-identifiers that can be used to detect something.

Sigma rules can be easily converted into other query languages to match the systems on which they will be used. As shown above, a Sigma rule could be automatically translated into Splunk’s query language, SPL, or Google Chronicle’s YARA-L 2.0 queries (to name but two…).

Sigma rules are structured in a YAML format.

The Sigma YAML fields follow the specification set by the authors of Sigma, and documented on the GitHub wiki for the project.

SIEM Rules Sigma template

Generally, a good Sigma rule has the following fields;

title: # title of the rule
description: # a short description of the rule and the malicious activity that can be detected
status: # rule status; stable, test, experimental, deprecated, unsupported
author: # creator of the rule
references: # References to the source that the rule was derived from
level: # describes the criticality of a triggered rule; informational, low, medium, high, critical
tags: # set of tags (lower-case letters, underscores and hyphens) separated by a comma 
logsource: # describes the log data on which the detection is meant to be applied to
detection: # represents search-identifiers that represent searches on log data
fields: # a list of log fields that could be interesting in further analysis of the event and should be displayed to the analyst.
falsepositives: # a list of known false positives that may occur.

A collection of existing public rules can be browsed in the Sigma Github repo showing how these fields are defined for detections.

Next week I’ll cover how to construct the logsource and detection fields to quickly create effective rules.




Join the Signals Corps on Discord

Join our public community of intelligence analysts and researchers sharing new content hourly.


Obstracts

Obstracts

Turn any blog into structured threat intelligence.

Stixify

Stixify. Extract machine readable intelligence from unstructured data.

Extract machine readable intelligence from unstructured data.


Vulmatch

Vulmatch

Know when software you use is vulnerable, how it is being exploited, and how to detect an attack.

SIEM Rules

SIEM Rules. Your detection engineering database.

View, modify, and deploy SIEM rules for threat hunting.