sigma v0.22 releases: Generic Signature Format for SIEM Systems


Generic Signature Format for SIEM Systems

What is Sigma?

Sigma is a generic and open signature format that allows you to describe relevant log events in a straightforward manner. The rule format is very flexible, easy to write, and applicable to any type of log file. The main purpose of this project is to provide a structured form in which researchers or analysts can describe their once developed detection methods and make them shareable with others.

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

This repository contains:

  • Sigma rule specification in the Wiki
  • Open repository for sigma signatures in the ./rulessubfolder
  • A converter that generates searches/queries for different SIEM systems [work in progress] 2017 Talk

Sigma - Generic Signatures for Log Events

Use Cases

  • Describe your once discovered detection method in Sigma to make it sharable
  • Share the signature in the appendix of your analysis along with file hashes and C2 servers
  • Share the signature in threat intel communities – e.g. via MISP
  • Provide Sigma signatures for malicious behavior in your own application (Error messages, access violations, manipulations)
  • Integrate a new log into your SIEM and check the Sigma repository for available rules
  • Write a rule converter for your custom log analysis tool and process new Sigma rules automatically
  • Provide a free or commercial feed for Sigma signatures

Sigma Converter

The converter is currently under development in the devel-sigmac branch of this project. It has currently the following capabilities:

  • Parsing of Sigma rule files
  • Conversion of searches into Elasticsearch and Splunk queries

Planned main features are:

  • Conversion of aggregation expressions (after the pipe character)
  • Output of Kibana JSON configurations

Support for further SIEM solutions can be added by developing a corresponsing output backend class.


Why Sigma

Today, everyone collects log data for analysis. People start working on their own, processing numerous white papers, blog posts and log analysis guidelines, extracting the necessary information and build their own searches and dashboard. Some of their searches and correlations are great and very useful but they lack a standardized format in which they can share their work with others.

Others provide excellent analyses for threat groups, sharing file indicators, C2 servers and YARA rules to detect the malicious files, but describe a certain malicious service install or remote thread injection in a separate paragraph. Security analysts, who read that paragraph then extract the necessary information and create rules in their SIEM system. The detection method never finds a way into a repository that is shared, structured and archived.

The lower layers of the OSI layer are well known and described. Every SIEM vendor has rules to detect port scans, ping sweeps and threats like the ‘smurf attack’. But the higher layers contain numerous applications and protocols with special characteristics that write their own custom log files. SIEM vendors consider the signatures and correlations as their intelectual property and do not tend to share details on the coverage.

Sigma is meant to be an open standard in which detection mechanisms can be defined, shared and collected in order to improve the detection capabilities on the application layers for everyone.



Windows ‘Security’ Eventlog: Access to LSASS Process with Certain Access Mask / Object Type (experimental) sigma_rule example2

Sysmon: Remote Thread Creation in LSASS Process sigma_rule example1

Web Server Access Logs: Web Shell Detection sigma_rule example3

Sysmon: Web Shell Detection sigma_rule example4

Windows ‘Security’ Eventlog: Suspicious Number of Failed Logons from a Single Source Workstation sigma_rule example5


The beta version of the rule converter ‘sigmac’ converting a non-correlation rule into an ElasticSearch query sigmac_converter

Changelog v0.22


  • ‘windash’ modifier
  • DNIF backend
  • Hedera backend
  • StreamAlert backend
  • SQLite backend can handle null values.
  • Support for different Windows log sources.


  • Various config improvements.


  • Wrapping expressions from expanding modifiers into ORed subexpressions.
  • Various mapping fixes.


git clone


Copyright 2016-2018 Thomas Patzke, Florian Roth