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.
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.
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.
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.
Turn any blog into structured threat intelligence.
Extract machine readable intelligence from unstructured data.
Know when software you use is vulnerable, how it is being exploited, and how to detect an attack.
View, modify, and deploy SIEM rules for threat hunting.