This document describes an additional set of rule conventions enforced by the SigmaHQ rule repository in order to ensure an easy to maintain rule base.
For the general Sigma rule specification please read see this
- Summary
- Structure
- Filenames
- Indentation
- Titles
- Status
- Description
- References
- Detection
- False Positives
The rules consist of a few required sections and several optional ones.
title [required]
id [required]
related [optional]
- id {rule-id}
type {type-identifier}
status [required]
description [required]
references [required]
author [required]
date [required]
modified [optional]
tags [required]
logsource [required]
category [optional]
product [optional]
service [optional]
definition [optional]
...
detection
{search-identifier} [optional]
{string-list} [optional]
{map-list} [optional]
{field: value} [optional]
...
condition
fields [optional]
falsepositives [required]
level [required]
All rule filename must follow the convention described in the SigmaHQ Filename Convention file.
The recommended indentation is 4
spaces.
All SigmaHQ rule titles must use title casing
Example:
title: Suspicious Office Child Process
All newly created rules must start with a status of experimental
- All rule descriptions must explain what the rule detects. A best practice therefore is to start with the word
Detects
- If a description text is too long or it's expressing multiple ideas. It's advised to use the pipe symbol
|
to signify a multiline string. Example:
description: |
Detects password dumper activity by monitoring remote thread creation EventID 8 in combination with the lsass.exe process as TargetImage.
The process in field Process is the malicious program. A single execution can lead to hundreds of events.
- All rules must provide a public reference, if possible.
- References to the MITRE ATT&CK website are not allowed. Instead they should be expressed as tags using the appropriate MITRE tags.
- References to git-based platforms such as Github or Gitlab must be provided as permalinks instead of main or master branch links. This is to avoid any future confusion in the intended reference in case the maintainers of said branches introduce new changes.
Single item list must be expressed in the same line instead of multi-line.
Example of single list items:
detection:
selection:
Image|endswith: '\example.exe'
Example of multi item list:
detection:
selection:
Image|endswith:
- '\example_1.exe'
- '\example_2.exe'
- '\example_3.exe'
- When possible, it is recommended to use conditions in the form
1 of selection_*
or1 of selection_*
in order to make them more readable. - When filtering values in the condition, it's recommended to name the filters in one of two ways:
filter_main_*
: For filters that are mandatory to the rule's logic, or if the excluded behavior or software is present by default or very common.filter_optional_*
: For filters that are based on behaviors or software that aren't part of the default installation of the OS or service being targeted.
- If the rule author expects false positives (found during testing or via external references), then it must be expressed as clear as possible. For example:
falsepositives:
- During software X installation the process Y is known to behave similarly as Z
- Administrators or administrator scripts might sometimes generate similar activity
- In cases where the author doesn't know of any false positives then value the should be
Unknown
. - If the rule author doesn't expect false positives the value should be
Unlikely
.
Also please note the following
- Keywords such as
None
,Pentest
,Penetration Test
,Red Team
, Etc, are not accepted as valid values.