SANS ISC: Sigma rules! The generic signature format for SIEM systems.

• SANS Site Network
  • Current Site
  • SANS Internet Storm Center
  • Other SANS Sites Help
  • Graduate Degree Programs
  • Security Training
  • Security Certification
  • Security Awareness Training
  • Penetration Testing
  • Industrial Control Systems
  • Cyber Defense Foundations
  • DFIR
  • Software Security
  • Government OnSite Training

SANS ISC InfoSec Forums

What Snort is to network traffic, and YARA to files, is Sigma to logs. By creating and using Sigma rules you’ll have generic rules which can be shared and run against different targets (e.g. SIEMs).

Sigma solves the issue of everyone working on their own analysis, searches and dashboards of log data they’ve collected by having a standardized format to create rules to be reused and shared with others, supporting many different target systems. Many targets are supported currently: Splunk (plainqueries and dashboards),  ElasticSearch Query Strings,  ElasticSearch Query DSL, Kibana, Elastic X-Pack Watcher, Logpoint, Microsoft Defender Advanced Threat Protection (MDATP), Azure Sentinel / Azure Log Analytics, Sumologic, ArcSight, QRadar, Qualys, RSA NetWitness, PowerShell, Grep with Perl-compatible regular expression support, LimaCharlie, ee-outliers.

Some of the use cases for Sigma are:

• Describe the detection methods and make it available.
• Invest in generating rules for Sigma and use on many different (e.g. SIEM) systems.
• Share the signature as an appendix of your analysis.
• Use Sigma to share the signature with other threat intel communities.

A Sigma rule is a YAML file, following the specification which be found here, having the following sections:

• metadata (id, tags, author, title, references, level)
• status (experimental or normal), the status is being used to filter on experimental or normal rules.
• the log source, which defines the source of the log data
• detections (one or more selectors, timeframe and condition)
• optional tags
• false positives, describing scenarios where false positives could be triggered as help for the analyst

The detection is the most important part of the rule, defining when the rule will be triggered. It consists of one or more selectors, each selector can be a map (all joined with a logical function and) or list (logical function or) and be nested. The map or list will contain the column to test (using wildcards for fields) and a value, with optional transformations (contains, all, base64, startswith, endswith, etc.) or type modifiers (regular expression). An optional timeframe will define the period for the selector to be aggregated on. The condition will tie everything together, evaluating the selectors using an expression that is usually complex. Within the condition, logical functions like and/or, not, one of, any of and aggregations expressions (count, min, max, avg and sum) on selectors (which can use wildcards) can be used.

As an example, this rule detects the removal of immutable file attributes on linux systems logged by auditd. The selection will evaluate logs where the field type equals ’EXECVE’, and a0 contains “chattr” and a1 contains “-i”. (a0 and a1 are both arguments to execv). If the condition (in this case, if selection evaluates to true) applies, the rule will trigger.

title: Remove Immutable File Attribute
id: a5b977d6-8a81-4475-91b9-49dbfcd941f7
description: Detects removing immutable file attribute
status: experimental
tags:
    - attack.defense_evasion
    - attack.t1222
author: Jakob Weinzettl, oscd.community
date: 2019/09/23
logsource:
    product: linux
    service: auditd
detection:
    selection:
        type: 'EXECVE'
        a0|contains: 'chattr'
        a1|contains: '-i'
    condition: selection
falsepositives:
    - Administrator interacting with immutable files (for instance backups)
level: medium
references:
    - https://github.com/redcanaryco/atomic-red-team/blob/master/atomics/T1222/T1222.yaml

Selections and conditions can become very sophisticated, allowing fine grained control and evaluations. A more complex detection is given below, where it will trigger if the sum of the question lengths, grouped by src_ip within 1m meeting the “selection” criteria (on each dns query).

detection:
    selection:
        query: '*'
    timeframe: 1m
    condition: selection | sum(question_length) by src_ip > 300000

The Sigma repository contains besides many rules, also sigmac, the sigma compiler. The sigma compiler compiles the Sigma rule to a different target system, e.g. Elasticsearch. If you want to play around with Sigma, it will be easiest to setup a docker container. As an example, we will use sigmac to compile the rule to an elasticsearch query, with as configuration of elk-windows resulting into the following query:

$ git clone https://github.com/Neo23x0/sigma
$ docker run -v $(pwd):/work python:3
$ cd /work/sigma
$ python tools/setup.py install
$ tools/sigmac -I -t es-qs -c elk-windows ./rule.yaml
(type:"EXECVE" AND a0.keyword:*chattr* AND a1.keyword:*\-i*)

Another way to test and play with Sigma and the results it transforms into, is by using the website https://uncoder.io/ (powered by SOC Prime). Uncoder.io can convert Sigma (and other rules and queries) to many different formats, allowing easy experimenting.
 

References:

• https://github.com/Neo23x0/sigma/
• https://github.com/Neo23x0/sigma/wiki/Specification
• https://uncoder.io/
• https://www.sans.org/cyber-security-summit/archives/file/summit_archive_1544043890.pdf
• https://www.slideshare.net/secret/gvgxeXoKblXRcA

Remco Verhoef (@remco_verhoef)
ISC Handler - Founder of DutchSec
PGP Key