-## Version Management
+Welcome to the official Sigma Specification repository.
-The version number is in the form of 3 digits 'A.B.C':
+## A Quick Rundown
-- 'A' A major version that could break existing converters
-- 'B' A minor version with additions or modifications of functionality affecting but not breaking the converters
-- 'C' Reorganization of section, addition of examples etc.
+Here's what you can expect from each of the main subfolders within this repo. Please take a minute to educate yourself!
-## Current Version
+### Specification
-The Sigma format specifications is described in the file [Sigma_specification](Sigma_specification.md)
+[Specification](./specification/) will contain markdown files describing the Sigma specification format in details.
-There exists two other files in the repository to describe the different fields and tags to be used in Sigma rules:
+* [Sigma Rules Specification](./specification/sigma-rules-specification.md) - Describes what constitute a Sigma rule.
+* [Sigma Correlation Specification](./specification/sigma-correlation-rules-specification.md) - Describes the Sigma correlation format.
+* [Sigma Filters Specification](./specification/sigma-filters-specification.md) - Described the Sigma filters format.
-- [Tags_specification](Tags_specification.md) is a document that defines the standardized tags that can be used to categorize the different Sigma rules.
-- [Taxonomy_specification](Taxonomy_specification.md) is a document that defines the different field names and log sources that should be used to ensure sharable rules
+### JSON Schema
-## Work in Progress
+[Json-Schema](./json-schema/) will contain a list of JSON schemas for the following.
-This section lists upcoming developments and changes to the standard. Please note:
+* [Sigma Rules](/json-schema/sigma-detection-rule-schema.json)
+* [Sigma Correlation Rules](/json-schema/sigma-correlation-rules-schema.json)
+* [Sigma Filters](/json-schema/sigma-filters-schema.json)
-- That it's still in a process of dictation and feedback.
-- It is possible that some are added and then deleted before the finalization of the version.
+### Appendix
-Do not hesitate to open a discussion with tag `V2` in the title. Example `V2 proposal of new modifier X`.
+[Appendix](./appendix/) will contain additional files providing additional details to certain fields of a Sigma rule
-For more information, check the [version_2 branch](https://github.com/SigmaHQ/sigma-specification/tree/version_2)
+* [Sigma Modifiers Appendix](appendix/sigma-modifiers-appendix.md) is a document that defines the different modifiers that can be used in a Sigma rule.
+* [Sigma Tags Appendix](appendix/sigma-tags-appendix.md) is a document that defines the tags namespaces that can be used to categorize the different Sigma rules.
+* [Sigma Taxonomy Appendix](appendix/sigma-taxonomy-appendix.md) is a document that defines the different field names and log sources that are currently supported by SigmaHQ in order to ensure sharable rules.
-## Archive of Old Specifications
+### SigmaHQ
-Local copy [sigmahq Specification wiki 2022/09/24](archives/wiki.md) or the online [sigmahq Specification wiki](https://github.com/SigmaHQ/sigma/wiki/Specification)
+[SigmaHQ](./sigmahq/) will contain markdown files that describe rules and recommendations that are applied to the rules hosted in SigmaHQ main rule repository.
-## SigmaHQ
+> **Note**
+>
+> The SigmaHQ folder and the files contains within are not part of the sigma specification. They are there to ensure and easier management of the rules hosted in the main [rule repository](https://github.com/SigmaHQ/sigma/tree/master/rules)
-The following files are not part of the sigma specification. They are only helpers for the management of the main [rule repository](https://github.com/SigmaHQ/sigma/tree/master/rules)
+* [SigmaHQ Rule Convention](/sigmahq/sigmahq-rule-convention.md)
+* [SigmaHQ Filename Convention](/sigmahq/sigmahq-filename-convention.md)
+* [SigmaHQ Title Convention](/sigmahq/sigmahq-title-convention.md)
-[SigmaHQ Filename Normalisation](sigmahq/Sigmahq_filename_rule.md)
+## Version 2 Changes
+
+You can read more on the potential breaking changes and additional features introduced in version 2.0.0 of the specification [here](./other/version-2-changes.md)
diff --git a/Sigma_specification.md b/Sigma_specification.md
deleted file mode 100644
index a5cc754..0000000
--- a/Sigma_specification.md
+++ /dev/null
@@ -1,799 +0,0 @@
-# Sigma specification
-
-The following document defines the different aspects of the SIGMA specification.
-
-* Version 1.0.3
-* Release date 2022/12/28
-
-# Summary
-
-- [Summary](#summary)
-- [YAML File](#yaml-file)
- - [Filename](#filename)
- - [Data](#data)
-- [Structure](#structure)
- - [Schema](#schema)
- - [Rx YAML](#rx-yaml)
- - [Image](#image)
- - [Components](#components)
- - [Title](#title)
- - [Rule Identification](#rule-identification)
- - [Status (optional)](#status-optional)
- - [Description (optional)](#description-optional)
- - [License (optional)](#license-optional)
- - [Author (optional)](#author-optional)
- - [References (optional)](#references-optional)
- - [Date (optional)](#date-optional)
- - [Modified (optional)](#modified-optional)
- - [Log Source](#log-source)
- - [Detection](#detection)
- - [Search-Identifier](#search-identifier)
- - [General](#general)
- - [String Wildcard](#string-wildcard)
- - [Escaping](#escaping)
- - [Lists](#lists)
- - [Maps](#maps)
- - [Field Usage](#field-usage)
- - [Special Field Values](#special-field-values)
- - [Value Modifiers](#value-modifiers)
- - [Modifier Types](#modifier-types)
- - [Currently Available Modifiers](#currently-available-modifiers)
- - [Transformations](#transformations)
- - [Types](#types)
- - [Timeframe](#timeframe)
- - [Condition](#condition)
- - [Fields](#fields)
- - [FalsePositives](#falsepositives)
- - [Level](#level)
- - [Tags](#tags)
- - [Placeholders](#placeholders)
- - [Examples for placeholders](#examples-for-placeholders)
- - [Examples for conversions](#examples-for-conversions)
- - [Rule Collections](#rule-collections)
- - [Example](#example)
-- [History](#history)
-
-# YAML File
-
-## Filename
-
-To keep the file names interoperable use the following:
-
-- Length between 10 and 70 characters
-- Lowercase
-- No special characters only letters (a-z) and digits (0-9)
-- Use `_` instead of a space
-- Use `.yml` as a file extension
-
-example:
-
-- lnx_auditd_change_file_time_attr.yml
-- web_cve_2022_33891_spark_shell_command_injection.yml
-- sysmon_file_block_exe.yml
-
-## Data
-
-The rule files are written in [yaml format](https://yaml.org/spec/1.2.2/)
-To keep the rules interoperable use the following:
-
-- UTF-8
-- LF for the line break (the Windows native editor uses CR-LF)
-- Indentation of 4 spaces
-- Lowercase keys (e.g. title, id, etc.)
-- Single quotes `'` for strings and numeric values don't use any quotes (if the string contains a single quote, double quotes may be used instead)
-
-Simple Sigma example
-
-```yaml
-title: Whoami Execution
-description: Detects a whoami.exe execution
-references:
- - https://speakerdeck.com/heirhabarov/hunting-for-privilege-escalation-in-windows-environment
-author: Florian Roth
-date: 2019/10/23
-logsource:
- category: process_creation
- product: windows
-detection:
- selection:
- Image: 'C:\Windows\System32\whoami.exe'
- condition: selection
-level: high
-```
-
-# Structure
-
-The rules consist of a few required sections and several optional ones.
-
-```yaml
-title
-id [optional]
-related [optional]
- - id {rule-id}
- type {type-identifier}
-status [optional]
-description [optional]
-references [optional]
-author [optional]
-date [optional]
-modified [optional]
-tags [optional]
-logsource
- 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 [optional]
-level [optional]
-...
-[arbitrary custom fields]
-```
-
-## Schema
-
-### Rx YAML
-
-```yaml
-type: //rec
-required:
- title:
- type: //str
- length:
- min: 1
- max: 256
- logsource:
- type: //rec
- optional:
- category: //str
- product: //str
- service: //str
- definition: //str
- detection:
- type: //rec
- required:
- condition:
- type: //any
- of:
- - type: //str
- - type: //arr
- contents: //str
- length:
- min: 2
- rest:
- type: //any
- of:
- - type: //arr
- of:
- - type: //str
- - type: //map
- values:
- type: //any
- of:
- - type: //str
- - type: //arr
- contents: //str
- length:
- min: 2
- - type: //map
- values:
- type: //any
- of:
- - type: //str
- - type: //arr
- contents: //str
- length:
- min: 2
-optional:
- status:
- type: //any
- of:
- - type: //str
- value: stable
- - type: //str
- value: test
- - type: //str
- value: experimental
- - type: //str
- value: deprecated
- - type: //str
- value: unsupported
- description: //str
- references:
- type: //arr
- contents: //str
- author: //str
- date: //str
- modified: //str
- fields:
- type: //arr
- contents: //str
- falsepositives:
- type: //any
- of:
- - type: //str
- - type: //arr
- contents: //str
- length:
- min: 2
- level:
- type: //any
- of:
- - type: //str
- value: informational
- - type: //str
- value: low
- - type: //str
- value: medium
- - type: //str
- value: high
- - type: //str
- value: critical
-rest: //any
-```
-
-### Image
-
-
-
-## Components
-
-### Title
-
-**Attribute:** title
-
-A brief title for the rule that should contain what the rules is supposed to detect (max. 256 characters)
-
-### Rule Identification
-
-**Attributes:** id, related
-
-Sigma rules should be identified by a globally unique identifier in the *id* attribute. For this
-purpose randomly generated UUIDs (version 4) are recommended but not mandatory. An example for this
-is:
-
-```yml
-title: Test rule
-id: 929a690e-bef0-4204-a928-ef5e620d6fcc
-```
-
-Rule identifiers can and should change for the following reasons:
-
-* Major changes in the rule. E.g. a different rule logic.
-* Derivation of a new rule from an existing or refinement of a rule in a way that both are kept
- active.
-* Merge of rules.
-
-To be able to keep track of the relationships between detections, Sigma rules may also contain
-references to related rule identifiers in the *related* attribute. This allows to define common
-relationships between detections as follows:
-
-```yml
-related:
- - id: 08fbc97d-0a2f-491c-ae21-8ffcfd3174e9
- type: derived
- - id: 929a690e-bef0-4204-a928-ef5e620d6fcc
- type: obsoletes
-```
-
-Currently the following types are defined:
-
-* derived: The rule was derived from the referred rule or rules, which may remain active.
-* obsoletes: The rule obsoletes the referred rule or rules, which aren't used anymore.
-* merged: The rule was merged from the referred rules. The rules may be still existing and in use.
-* renamed: The rule had previously the referred identifier or identifiers but was renamed for whatever
- reason, e.g. from a private naming scheme to UUIDs, to resolve collisions etc. It's not
- expected that a rule with this id exists anymore.
-* similar: Use to relate similar rules to each other (e.g. same detection content applied to different log sources, rule that is a modified version of another rule with a different level)
-
-### Status (optional)
-
-**Attribute:** status
-
-Declares the status of the rule:
-
-* stable: the rule didn't produce any obvious false positives in multiple environments over a long period of time
-* test: the rule doesn't show any obvious false positives on a limited set of test systems
-* experimental: a new rule that hasn't been tested outside of lab environments and could lead to many false positives
-* deprecated: the rule is to replace or cover another one. The link between both rules is made via the `related` field.
-* unsupported: the rule can not be used in its current state (special correlation log, home-made fields...etc.)
-
-### Description (optional)
-
-**Attribute:** description
-
-A short description of the rule and the malicious activity that can be detected (max. 65,535 characters)
-
-### License (optional)
-
-**Attribute:** license
-
-License of the rule according the [SPDX ID specification](https://spdx.org/ids).
-
-### Author (optional)
-
-**Attribute**: author
-
-Creator of the rule. (can be a name, nickname, twitter handle...etc)
-
-### References (optional)
-
-**Attribute**: reference
-
-References to the source that the rule was derived from. These could be blog articles, technical papers, presentations or even tweets.
-
-### Date (optional)
-
-**Attribute**: date
-
-Creation date of the rule. Use the format YYYY/MM/DD
-
-### Modified (optional)
-
-**Attribute**: modified
-
-*Last* modification date of the rule. Use the format YYYY/MM/DD
-
-If one of the following fields or sections changed. Then the modified field must be updated:
-
-* Detection section
-* Level
-* Logsource (rare)
-* Status to `deprecated`
-* Title
-
-### Log Source
-
-**Attribute**: logsource
-
-This section describes the log data on which the detection is meant to be applied to. It describes the log source, the platform, the application and the type that is required in the detection.
-
-It consists of three attributes that are evaluated automatically by the converters and an arbitrary number of optional elements. We recommend using a "definition" value in cases in which further explanation is necessary.
-
-* category - examples: firewall, web, antivirus
-* product - examples: windows, apache, check point fw1
-* service - examples: sshd, applocker
-
-The "category" value is used to select all log files written by a certain group of products, like firewalls or web server logs. The automatic converter will use the keyword as a selector for multiple indices.
-
-The "product" value is used to select all log outputs of a certain product, e.g. all Windows Eventlog types including "Security", "System", "Application" and the new log types like "AppLocker" and "Windows Defender".
-
-Use the "service" value to select only a subset of a product's logs, like the "sshd" on Linux or the "Security" Eventlog on Windows systems.
-
-The "definition" can be used to describe the log source, including some information on the log verbosity level or configurations that have to be applied. It is not automatically evaluated by the converters but gives useful information to readers on how to configure the source to provide the necessary events used in the detection.
-
-You can use the values of 'category, 'product' and 'service' to point the converters to a certain index. You could define in the configuration files that the category 'firewall' converts to `( index=fw1* OR index=asa* )` during Splunk search conversion or the product 'windows' converts to `"_index":"logstash-windows*"` in Elasticsearch queries.
-
-Instead of referring to particular services, generic log sources may be used, e.g.:
-
-```yml
-category: process_creation
-product: windows
-```
-
-Instead of definition of multiple rules for Sysmon, Windows Security Auditing and possible product-specific rules.
-
-### Detection
-
-**Attribute**: detection
-
-A set of search-identifiers that represent properties of searches on log data.
-
-#### Search-Identifier
-
-A definition that can consist of two different data structures - lists and maps.
-
-#### General
-
-* All values are treated as case-insensitive strings
-* You can use wildcard characters `*` and `?` in strings (see also escaping section below)
-* Regular expressions are case-sensitive by default
-* You don't have to escape characters except the string quotation marks `'`
-
-#### String Wildcard
-
-Wildcards are used when part of the text is random.
-You can use :
-
-* `?` to replace a single mandatory character
-* `*` to replace an unbounded length wildcard
-
-example :
-
-* `progA.exe or progB.exe or ...` will be `prog?.exe`
-* `antivirus_V1.exe or antivirus_V21.2.1.exe or ...` will be `antivirus_V*.exe`
-
-Sigma has special modifiers to facilitate the search of unbounded strings
-
-* `*something` see [endswith modifier](#value-modifiers)
-* `something*` see [startswith modifier](#value-modifiers)
-* `*something*` see [contains modifier](#value-modifiers)
-
-#### Escaping
-
-The backslash character `\` is used for escaping of wildcards `*` and `?` as well as the backslash character itself. Escaping of the backslash is necessary if it is followed by a wildcard depending on the desired result.
-
-Summarized, there are the following possibilities:
-
-* Plain backslash not followed by a wildcard can be expressed as single `\` or double backslash `\\`. For simplicity reasons the single notation is recommended.
-* A wildcard has to be escaped to handle it as a plain character: `\*`
-* The backslash before a wildcard has to be escaped to handle the value as a backslash followed by a wildcard: `\\*`
-* Three backslashes are necessary to escape both, the backslash and the wildcard and handle them as plain values: `\\\*`
-* Three or four backslashes are handled as double backslash. Four a recommended for consistency reasons: `\\\\` results in the plain value `\\`.
-
-#### Lists
-
-Lists can contain:
-
-* strings that are applied to the full log message and are linked with a logical 'OR'.
-* maps (see below). All map items of a list are logically linked with 'OR'.
-
-Example for list of strings: Matches on 'EvilService' **or** 'svchost.exe -n evil'
-
-```yml
-detection:
- keywords:
- - EVILSERVICE
- - svchost.exe -n evil
-```
-
-Example for list of maps:
-
-```yml
-detection:
- selection:
- - Image|endswith: \\example.exe
- - Description|contains: Test executable
-```
-
-Matches an image file `example.exe` or an executable whose description contains the string `Test executable`
-
-#### Maps
-
-Maps (or dictionaries) consist of key/value pairs, in which the key is a field in the log data and the value a string or integer value. All elements of a map are joined with a logical 'AND'.
-
-Examples:
-
-Matches on Eventlog 'Security' **and** ( Event ID 517 **or** Event ID 1102 )
-
-```yml
-detection:
- selection:
- EventLog: Security
- EventID:
- - 517
- - 1102
-condition: selection
-```
-
-Matches on Eventlog 'Security' **and** Event ID 4679 **and** TicketOptions 0x40810000 **and** TicketEncryption 0x17
-
-```yml
-detection:
- selection:
- EventLog: Security
- EventID: 4769
- TicketOptions: '0x40810000'
- TicketEncryption: '0x17'
-condition: selection
-```
-
-#### Field Usage
-
-1. For fields with existing field-mappings, use the mapped field name.
-
-Examples from [the generic config `tools\config\generic\windows-audit.yml`](https://github.com/SigmaHQ/sigma/blob/master/tools/config/generic/windows-audit.yml#L23-L28) (e.g. use `Image` over `NewProcessName`):
-
-```yml
-fieldmappings:
- Image: NewProcessName
- ParentImage: ParentProcessName
- Details: NewValue
- ParentCommandLine: ProcessCommandLine
- LogonId: SubjectLogonId
-```
-
-2. For new or rarely used fields, use them as they appear in the log source and strip all spaces. (That means: Only, if the field is not already mapped to another field name.) On Windows event log sources, use the field names of the details view as the general view might contain localized field names.
-
-Examples:
-
-* `New Value` -> `NewValue`
-* `SAM User Account` -> `SAMUserAccount`
-
-3. Clarification on Windows events from the EventViewer:
- 1. Some fields are defined as attributes of the XML tags (in the `` header of the events). The tag and attribute names have to be linked with an underscore character '_'.
- 2. In the `` body of the event the field name is given by the `Name` attribute of the `Data` tag.
-
-Examples i:
-
-* `` will be `Provider_Name`
-* ` ` will be `Execution_ProcessID`
-
-Examples ii:
-
-* `NT AUTHORITY\SYSTEM` will be `User`
-* `MpKsl4eaa0a76` will be `ServiceName`
-
-#### Special Field Values
-
-There are special field values that can be used.
-
-* An empty value is defined with `''`
-* A null value is defined with `null`
-
-OBSOLETE: An arbitrary value except null or empty cannot be defined with `not null` anymore
-
-The application of these values depends on the target SIEM system.
-
-To get an expression that say `not null` you have to create another selection and negate it in the condition.
-
-Example:
-
-```yml
-detection:
- selection:
- EventID: 4738
- filter:
- PasswordLastSet: null
-condition:
- selection and not filter
-```
-
-#### Value Modifiers
-
-The values contained in Sigma rules can be modified by *value modifiers*. Value modifiers are
-appended after the field name with a pipe character `|` as separator and can also be chained, e.g.
-`fieldname|mod1|mod2: value`. The value modifiers are applied in the given order to the value.
-
-##### Modifier Types
-
-There are two types of value modifiers:
-
-* *Transformation modifiers* transform values into different values, like the two Base64 modifiers
- mentioned above. Furthermore, this type of modifier is also able to change the logical operation
- between values. Transformation modifiers are generally backend-agnostic. Means: you can use them
- with any backend.
-* *Type modifiers* change the type of a value. The value itself might also be changed by such a
- modifier, but the main purpose is to tell the backend that a value should be handled differently
- by the backend, e.g. it should be treated as regular expression when the *re* modifier is used.
- Type modifiers must be supported by the backend.
-
-Generally, value modifiers work on single values and value lists. A value might also expand into
-multiple values.
-
-##### Currently Available Modifiers
-
-###### Transformations
-
-* `contains`: puts `*` wildcards around the values, such that the value is matched anywhere in the
- field.
-* `all`: Normally, lists of values were linked with *OR* in the generated query. This modifier
- changes
- this to *AND*. This is useful if you want to express a command line invocation with different
- parameters where the order may vary and removes the need for some cumbersome workarounds.
-
- Single item values are not allowed to have an `all` modifier as some back-ends cannot support it.
- If you use it as a workaround to duplicate a field in a selection, use a new selection instead.
-* `base64`: The value is encoded with Base64.
-* `base64offset`: If a value might appear somewhere in a base64-encoded value the representation
- might change depending on the position in the overall value. There are three variants for shifts
- by zero to two bytes and except the first and last byte the encoded values have a static part in
- the middle that can be recognized.
-* `endswith`: The value is expected at the end of the field's content (replaces e.g. '*\cmd.exe')
-* `startswith`: The value is expected at the beginning of the field's content. (replaces e.g. 'adm*')
-* `utf16le`: transforms value to UTF16-LE encoding, e.g. `cmd` > `63 00 6d 00 64 00` (only used in combination with base64 modifiers)
-* `utf16be`: transforms value to UTF16-BE encoding, e.g. `cmd` > `00 63 00 6d 00 64` (only used in combination with base64 modifiers)
-* `wide`: alias for `utf16le` modifier
-* `utf16`: prepends a [byte order mark](https://en.wikipedia.org/wiki/Byte_order_mark) and encodes UTF16, e.g. `cmd` > `FF FE 63 00 6d 00 64 00` (only used in combination with base64 modifiers)
-* `windash`: Add a new variant where all `-` occurrences are replaced with `/`. The original variant is also kept unchanged.
-
-###### Types
-
-* `re`: value is handled as regular expression by backends. Currently, this is only supported by
- the Elasticsearch query string backend (*es-qs*). Further (like Splunk) are planned or have
- to be implemented by contributors with access to the target systems.
-
-#### Timeframe
-
- **Attribute**: timeframe
-
- Is a special Search-Identifier used **only** with Aggregation conditions
- Defines a time period in which the aggregation should be applied.
- The following format must be used: number + letter (in lowercase)
- - Xs seconds
- - Xm minutes
- - Xh hours
- - Xd days
-
-Example:
-```yml
- timeframe: 24h
- condition: selection | count(dst_port) by src_ip > 10
-```
-
-### Condition
-
-**Attribute**: condition
-
-The condition is the most complex part of the specification and will be subject to change over time and arising requirements. In the first release it will support the following expressions.
-
-- Logical AND/OR
-
- `keywords1 or keywords2`
-
-- 1/all of them
-
- Logical OR (`1 of them`) or AND (`all of them`) across all defined search identifiers. The search identifiers
- themselves are logically linked with their default behaviour for maps (AND) and lists (OR).
-
- The usage of `all of them` is discouraged, as it prevents the possibility of downstream users of a rule to generically filter unwanted matches. See `all of {search-identifier-pattern}` in the next section as the preferred method.
-
- Example: `1 of them` means that one of the defined search identifiers must appear.
-
-- 1/all of search-identifier-pattern
-
- Same as *1/all of them*, but restricted to matching search identifiers. Matching is done with * wildcards (any number of characters) at arbitrary positions in the pattern.
-
- Examples:
- - `all of selection*`
- - `1 of selection* and keywords`
- - `1 of selection* and not 1 of filter*`
-
-- Negation with 'not'
-
- `keywords and not filters`
-
-- Brackets
-
- `selection1 and (keywords1 or keywords2)`
-
-- Pipe (deprecated)
-
- `search_expression | aggregation_expression`
-
- A pipe indicates that the result of *search_expression* is aggregated by *aggregation_expression* and possibly
- compared with a value.
-
- The first expression must be a search expression that is followed by an aggregation expression with a condition.
-
- Aggregations in the condition are deprecated and will be replaced with [Sigma correlations](https://github.com/SigmaHQ/sigma/wiki/Specification:-Sigma-Correlations).
-
-- Aggregation expression (deprecated, see [Sigma Correlations specification](https://github.com/SigmaHQ/sigma/wiki/Specification:-Sigma-Correlations) for future plans)
-
- agg-function(agg-field) [ by group-field ] comparison-op value
-
- agg-function may be:
-
- - count
- - min
- - max
- - avg
- - sum
-
- All aggregation functions except count require a field name as parameter. The count aggregation counts all matching events if no field name is given. With field name it counts the distinct values in this field.
-
- Example: `count(UserName) by SourceWorkstation > 3`
-
- This comparison counts distinct user names grouped by SourceWorkstations.
-
-- Near aggregation expression (deprecated, see [Sigma Correlations specification](https://github.com/SigmaHQ/sigma/wiki/Specification:-Sigma-Correlations) for future plans)
-
- near *search-id-1* [ [ and *search-id-2* | and not *search-id-3* ] ... ]
-
- This expression generates (if supported by the target system and backend) a query that recognizes *search_expression* (primary event) if the given conditions are or are not in the temporal context of the primary event within the given time frame.
-
-Operator Precedence (least to most binding)
-
-- |
-- or
-- and
-- not
-- x of search-identifier
-- ( expression )
-
-The condition can be a list, in this case, each of them generates a query
-They are logically linked with OR.
-
-### Fields
-
-**Attribute**: fields
-
-A list of log fields that could be interesting in further analysis of the event and should be displayed to the analyst.
-
-### FalsePositives
-
-**Attribute**: falsepositives
-
-A list of known false positives that may occur.
-
-### Level
-
-**Attribute**: level
-
-The level field contains one of five string values. It describes the criticality of a triggered rule. While `low` and `medium` level events have an informative character, events with `high` and `critical` level should lead to immediate reviews by security analysts.
-
-- `informational`: Rule is intended for enrichment of events, e.g. by tagging them. No case or alerting should be triggered by such rules because it is expected that a huge amount of events will match these rules.
-- `low`: Notable event but rarely an incident. Low rated events can be relevant in high numbers or combination with others. Immediate reaction shouldn't be necessary, but a regular review is recommended.
-- `medium`: Relevant event that should be reviewed manually on a more frequent basis.
-- `high`: Relevant event that should trigger an internal alert and requires a prompt review.
-- `critical`: Highly relevant event that indicates an incident. Critical events should be reviewed immediately. It is used only for cases in which probability borders certainty.
-
-### Tags
-
-**Attribute**: tags
-
-A Sigma rule can be categorised with tags. Tags should generally follow this syntax:
-
-* Character set: lower-case letters, underscores and hyphens
-* no spaces
-* Tags are namespaced, the dot is used as separator. e.g. *attack.t1234* refers to technique 1234 in the namespace *attack*; Namespaces may also be nested
-* Keep tags short, e.g. numeric identifiers instead of long sentences
-* If applicable, use [predefined tags](./Tags_specification.md). Feel free to send pull request or issues with proposals for new tags
-
-### Placeholders
-
-Placeholders can be used to select a set of elements that can be expanded during conversion.
-Placeholders map a an identifier to a user defined value that can be set in config files for an
-automatic replacement during conversion runs. Placeholders are meaningful identifiers that users can
-easily expand themselves.
-
-#### Examples for placeholders
-
-* `%Administrators%` - Administrative user accounts
-* `%JumpServers%` - Server systems used as jump servers
-
-Some SIEM systems allow using so-called "tags" or "search macros" in queries and can integrate Sigma rules with placeholders directly. Others expand the placeholders values to wildcard strings or regular expressions.
-
-#### Examples for conversions
-
-Splunk
-
-* `AccountName: %Administrators%` convert to `tag=Administrators`
-
-Elastic Search
-
-* `SourceWorkstation: %JumpServers%` convert to `"SourceWorkstation": SRV110[12]`
-
-## Rule Collections
-
-A file may contain multiple YAML documents. These can be complete Sigma rules or *action documents*. A YAML document is handled as action document if the `action` attribute on the top level is set to:
-
-* `global`: Defines YAML content that is merged in all following YAML rule documents in this file. Multiple *global* action documents are accumulated.
-** Use case: define metadata and rule parts that are common across all Sigma rules of a collection.
-* `reset`: Reset global YAML content defined by *global* action documents.
-* `repeat`: Repeat generation of previous rule document with merged data from this YAML document.
-** Use case: Small modifications of previously generated rule.
-
-### Example
-A common use case is the definition of multiple Sigma rules for similar events like Windows Security EventID 4688 and Sysmon EventID 1. Both are created for process execution events. A Sigma rule collection for this scenario could contain three documents:
-
-1. A global action document that defines common metadata and detection indicators
-2. A rule that defines Windows Security log source and EventID 4688
-3. A rule that defines Windows Sysmon log source and EventID 1
-
-Alternative solution could be:
-
-1. A global action document that defines common metadata.
-2. The Security/4688 rule with all event details.
-3. A repeat action document that replaces the logsource and EventID from the rule defined in 2.
-
-# History
-* 2023/06/29 Specification V1.0.4
- * Complete the information for multiple conditions
-* 2022/12/28 Specification V1.0.3
- * Add missing `timeframe` attribute
-* 2022/11/17 Specification V1.0.2
- * Add missing optional field `date` and `modified`
-* 2022/10/18 Specification V1.0.1
- * Add String Wildcard section
-* 2022/09/18 Specification V1.0.0
- * Initial formalisation from the sigma wiki
-* 2017 Sigma creation
diff --git a/_config.yml b/_config.yml
deleted file mode 100644
index 94c42f2..0000000
--- a/_config.yml
+++ /dev/null
@@ -1,46 +0,0 @@
-title: Specs
-description: All the specifications of Sigma format
-show_downloads: false
-color-scheme: auto
-logo: /images/Sigma_0.3.png
-favicon: true
-
-plugins:
- - jekyll-sitemap
- - jekyll-seo-tag
- - jemoji
- - jekyll-remote-theme
-
-remote_theme: BDHU/minimalist
-
-sidebar:
- - name: Home
- icon:
- link: /sigma-specification/index.html
- - name: Rules
- icon:
- link: /sigma-specification/Sigma_specification.html
- - name: Tags
- icon:
- link: /sigma-specification/Tags_specification.html
- - name: Taxonomy
- icon:
- link: /sigma-specification/Taxonomy_specification.html
- - name: SigmaHQ Filename Normalisation
- icon:
- link: /sigma-specification/sigmahq/Sigmahq_filename_rule.html
- - name: Github repository
- icon:
- link: https://github.com/SigmaHQ/sigma-specification
- - name: SigmaHQ Rules
- icon:
- link: https://github.com/SigmaHQ/sigma
- - name: PySigma Converter
- icon:
- link: https://github.com/SigmaHQ/pySigma
-
-# https://github.com/github/pages-gem/issues/399#issuecomment-301827749
-# When running locally, we run into the following error —
-# GitHub Metadata: No GitHub API authentication could be found. Some fields may be missing or have incorrect data.
-# Adding the following line to avoid the issue
-github: [metadata]
\ No newline at end of file
diff --git a/appendix/sigma-modifiers-appendix.md b/appendix/sigma-modifiers-appendix.md
new file mode 100644
index 0000000..9d009ec
--- /dev/null
+++ b/appendix/sigma-modifiers-appendix.md
@@ -0,0 +1,87 @@
+# Modifiers
+
+The following document defines the standardized modifiers that can be used in Sigma.
+
+* Version 2.0.0
+* Release date 2024-08-08
+
+## Summary
+- [Summary](#summary)
+- [General](#general)
+ - [String only](#string-only)
+ - [Numeric only](#numeric-only)
+ - [Ip only](#ip-only)
+ - [String Encoding](#string-encoding)
+- [Specific](#specific)
+- [History](#history)
+
+## General
+
+* `all`: Normally, lists of values are linked with *OR* in the generated query. This modifier
+ changes this to *AND*. This is useful if you want to express a command line invocation with different
+ parameters where the order may vary and removes the need for some cumbersome workarounds.
+
+ Single item values are not allowed to have an `all` modifier as some back-ends cannot support it.
+ If you use it as a workaround to duplicate a field in a selection, use a new selection instead.
+
+* `startswith`: The value is expected at the beginning of the field's content. (replaces e.g. 'adm*')
+* `endswith`: The value is expected at the end of the field's content (replaces e.g. '*\cmd.exe')
+* `contains`: Puts `*` wildcards around the values, such that the value is matched anywhere in the
+ field.
+
+* `exists`: Defines that a certain field has to exist or must not exist in a log event by providing a boolean value. Note that this check only verifies the presence of a field, not its value, be it empty or null.
+* `cased`: Values are applied case sensitively. Default Sigma behavior is case-insensitive matching.
+
+### String only
+
+* `windash`: Creates all possible permutations of the `-`, `/`, `–` (en dash), `—` (em dash), and `―` (horizontal bar) characters. Windows command line flags can often be indicated by both characters. Using the `windash` modifier converts the aforementioned characters interchangeably and uses all possible permutation of strings in the selection.
+
+* `re`: Value is handled as a regular expression by backends. Regex is matched case-sensitive by default
+* `re` sub-modifiers:
+ * `i`: (insensitive) to enable case-sensitive matching.
+ * `m`: (multi line) to match across multiple lines. `^` /`$` match the start/end of line.
+ * `s`: (single line) to enable that dot (`.`) matches all characters, including the newline character.
+
+### Numeric only
+
+* `lt`: Field is less than the value
+* `lte`: Field is less or equal than the value
+* `gt`: Field is greater than the value
+* `gte`: Field is greater or equal than the value
+
+### Ip only
+
+* `cidr`: The value is handled as an CIDR by backends. Supports both IPv4 and IPv6 notations.
+
+### String Encoding
+
+* `base64`: The value is encoded with Base64.
+* `base64offset`: If a value might appear somewhere in a base64-encoded string the representation
+ might change depending on the position of the value in the overall string. There are three variants for shifts
+ by zero to two bytes and except the first and last byte the encoded values have a static part in
+ the middle that can be recognized.
+
+* `base64` sub-modifiers:
+ * `utf16le`: Transforms value to UTF16-LE encoding, e.g. `cmd` > `63 00 6d 00 64 00`
+ * `utf16be`: Transforms value to UTF16-BE encoding, e.g. `cmd` > `00 63 00 6d 00 64`
+ * `utf16`: Prepends a [byte order mark](https://en.wikipedia.org/wiki/Byte_order_mark) and encodes UTF16, e.g. `cmd` > `FF FE 63 00 6d 00 64 00`
+
+## Specific
+
+* `expand`: Modifier for expansion of placeholders in values. The final behavior of the replacement is determined by processing pipeline transformations. Current possibilities in pySigma are:
+ * Expand to value list (`ValueListPlaceholderTransformation`/`value_placeholders`)
+ * Replace with query expression in target query language (`QueryExpressionPlaceholderTransformation`/`query_expression_placeholders`)
+ * Replace placeholder with wildcard `*`, which should only be used as last resort. (`WildcardPlaceholderTransformation`/`wildcard_placeholders`)
+
+* `fieldref`: Modifies a plain string into a field reference. A field reference can be used to compare fields of matched
+ events directly at query/matching time.
+
+## History
+
+* 2024-08-08 Modifiers Appendix v2.0.0
+* 2023-05-27 Modifiers Appendix v1.0.4
+ * Update from PySigma 0.7.6
+ * Add `fieldref`
+* 2023-05-21 Modifiers Appendix v1.0.3
+ * Creation of the file
+* 2017 Sigma creation
diff --git a/Tags_specification.md b/appendix/sigma-tags-appendix.md
similarity index 65%
rename from Tags_specification.md
rename to appendix/sigma-tags-appendix.md
index ddfbde7..3f476b9 100644
--- a/Tags_specification.md
+++ b/appendix/sigma-tags-appendix.md
@@ -2,8 +2,8 @@
The following document defines the standardized tags that can be used to categorize the different Sigma rules.
-* Version 1.1.0
-* Release date 2023-06-20
+* Version 2.0.0
+* Release date 2024-08-08
## Summary
@@ -11,6 +11,7 @@ The following document defines the standardized tags that can be used to categor
- [Namespaces](#namespaces)
- [Namespace: attack](#namespace-attack)
- [Namespace: car](#namespace-car)
+ - [Namespace: stp](#namespace-stp)
- [Namespace: cve](#namespace-cve)
- [Namespace: tlp](#namespace-tlp)
- [namespace: detection](#namespace-detection)
@@ -18,10 +19,12 @@ The following document defines the standardized tags that can be used to categor
## Namespaces
-* attack: Categorization according to [MITRE ATT&CK](https://attack.mitre.org). To get the current supported version of ATT&CK please visite [MITRE CTI](https://github.com/mitre/cti)
+* attack: Categorization according to [MITRE ATT&CK](https://attack.mitre.org). To get the current supported version of ATT&CK please visit [MITRE CTI](https://github.com/mitre/cti)
* car: Link to the corresponding [MITRE Cyber Analytics Repository (CAR)](https://car.mitre.org/)
+* cve: Categorization according [MITRE CVE](https://cve.mitre.org/)
+* detection: Categorization according to the types of rules provided in the [SigmaHQ rule repository](https://github.com/SigmaHQ/sigma).
* stp: Rating of detection analytic robustness according to the [MITRE Summiting the Pyramid](https://center-for-threat-informed-defense.github.io/summiting-the-pyramid/) scheme.
-* tlp: [Traffic Light Protocol](https://www.first.org/tlp/)
+* tlp: [Traffic Light Protocol](https://www.first.org/tlp/).
### Namespace: attack
@@ -31,24 +34,38 @@ The following document defines the standardized tags that can be used to categor
Tactics:
-* initial_access: [Initial Access](https://attack.mitre.org/tactics/TA0001/)
+* initial-access: [Initial Access](https://attack.mitre.org/tactics/TA0001/)
* execution: [Execution](https://attack.mitre.org/tactics/TA0002/)
* persistence: [Persistence](https://attack.mitre.org/tactics/TA0003/)
-* privilege_escalation: [Privilege Escalation](https://attack.mitre.org/tactics/TA0004/)
-* defense_evasion: [Defense Evasion](https://attack.mitre.org/tactics/TA0005/)
-* credential_access: [Credential Access](https://attack.mitre.org/tactics/TA0006/)
+* privilege-escalation: [Privilege Escalation](https://attack.mitre.org/tactics/TA0004/)
+* defense-evasion: [Defense Evasion](https://attack.mitre.org/tactics/TA0005/)
+* credential-access: [Credential Access](https://attack.mitre.org/tactics/TA0006/)
* discovery: [Discovery](https://attack.mitre.org/tactics/TA0007/)
-* lateral_movement: [Lateral_Movement](https://attack.mitre.org/tactics/TA0008/)
+* lateral-movement: [Lateral_Movement](https://attack.mitre.org/tactics/TA0008/)
* collection: [Collection](https://attack.mitre.org/tactics/TA0009/)
* exfiltration: [Exfiltration](https://attack.mitre.org/tactics/TA0010/)
-* command_and_control: [Command and Control](https://attack.mitre.org/tactics/TA0011/)
+* command-and-control: [Command and Control](https://attack.mitre.org/tactics/TA0011/)
* impact: [Impact](https://attack.mitre.org/tactics/TA0040/)
### Namespace: car
-Use the CAR tag from the [analytics repository](https://car.mitre.org/analytics/) without the prepending `CAR-`. Example
+Use the CAR tag from MITRE [analytics repository](https://car.mitre.org/analytics/) without the prepending `CAR-`. Example
tag: `car.2016-04-005`.
+### Namespace: cve
+
+Use the CVE tag from [MITRE](https://cve.mitre.org) in lower case separated by dots. Example tag: `cve.2021-44228`.
+
+### Namespace: detection
+
+Use the detection tag to indicate the type of a rule. Example tag: `detection.threat-hunting`.
+
+The following tags are currently supported:
+
+* `detection.dfir`
+* `detection.emerging-threats`
+* `detection.threat-hunting`
+
### Namespace: stp
The [Summiting the Pyramid](https://center-for-threat-informed-defense.github.io/summiting-the-pyramid/) scheme created
@@ -60,7 +77,7 @@ by MITRE defines two score dimensions for scoring of the robustness:
Details for both dimensions are [defined here](https://center-for-threat-informed-defense.github.io/summiting-the-pyramid/levels/).
The *stp* namespace allows to score the robustness of the detection implemented by a Sigma rule according to this
-scheme. Because the event robustness depends on the event log source that is an enviromental property, Sigma allows to
+scheme. Because the event robustness depends on the event log source that is an environmental property, Sigma allows to
specify the robustness in the following ways:
* *analytic-only* defines just the analytic robustness in a tag like `stp.4`. This is usually appropriate for generic
@@ -68,27 +85,27 @@ specify the robustness in the following ways:
* *complete* defines the whole score in a tag like `stp.3k`. Such a tag should be chosen if the detection refers to a
concrete log source.
-### Namespace: cve
-
-Use the CVE tag from the [mitre](https://cve.mitre.org) in lower case seperated by dots. Example tag: `cve.2021.44228`.
-
### Namespace: tlp
All TLP levels defined by the [FIRST TLP-SIG](https://www.first.org/tlp/) in lower case. Example tag: `tlp.amber`.
-### namespace: detection
-
-Use the detection tag to indicate the type of a rule. Example tag: `detection.threat_hunting`.
+The following tags are currently supported:
-* dfir
-* emerging_threats
-* threat_hunting
+* `tlp.red`
+* `tlp.amber`
+* `tlp.amber-strict`
+* `tlp.green`
+* `tlp.clear`
## History
-* 2023-06-20 Tags V1.1.0
+
+* 2024-08-08 Tags Appendix v2.0.0
+* 2023-11-23 Tags Appendix v1.2.0
+ * Add Summiting the Pyramid
+* 2023-06-20 Tags Appendix v1.1.0
* Add detection namespace
-* 2022-12-19 Tags V1.0.1
+* 2022-12-19 Tags Appendix v1.0.1
* Minor updates and tweaks
-* 2022-09-18 Tags V1.0.0
- * Initial formalisation from the sigma wiki
+* 2022-09-18 Tags Appendix v1.0.0
+ * Initial formalization from the sigma wiki
* 2017 Sigma creation
diff --git a/Taxonomy_specification.md b/appendix/sigma-taxonomy-appendix.md
similarity index 89%
rename from Taxonomy_specification.md
rename to appendix/sigma-taxonomy-appendix.md
index 60a39f2..e47a28b 100644
--- a/Taxonomy_specification.md
+++ b/appendix/sigma-taxonomy-appendix.md
@@ -1,9 +1,9 @@
# Sigma Taxonomy
-The following document defines the field names and log sources that should be used in SIGMA rules to ensure sharable rules.
+The following document defines the field names and log sources that are allowed to be used in SIGMA rules that are shared on the official SigmaHQ repository.
-* Version 1.3.5
-* Release date 2023/01/21
+* Version 2.0.0
+* Release date 2024-08-08
## Summary
@@ -30,6 +30,14 @@ For a better comprehension, the log sources are organized by directory name simi
### Application Folder
+The *application* folder contains rules that are intended for application security monitoring. The rules are organized into folders per application technology. All rules define log sources as follows:
+
+* The *category* log source attribute is set to `application`. This can be used by processing pipelines to create a technology-agnostic conversion configuration in cases where the application technology stack is unknown.
+
+* The *product* log source attribute is set to the name of the technology and should be equal to the folder name.
+
+Because application logs are often ingested as raw text events with poor decomposition into fields by many target systems, these rules are keyword rules that don't match on specific fields.
+
| Product | Logsource | Event |
| ------------- | ----------------------------------------------- | ----- |
| django | category: application product: django | |
@@ -151,25 +159,31 @@ For a better comprehension, the log sources are organized by directory name simi
| windows | product: windows category: sysmon_status | EventID: - 4 - 16 Channel: Microsoft-Windows-Sysmon/Operational |
| windows | product: windows category: wmi_event | EventID: - 19 - 20 - 21 Channel: Microsoft-Windows-Sysmon/Operational |
| windows | product: windows service: application | Channel: Application |
+| windows | product: windows service: application-experience | Channel: - Microsoft-Windows-Application-Experience/Program-Telemetry - Microsoft-Windows-Application-Experience/Program-Compatibility-Assistant |
| windows | product: windows service: applocker | Channel: - Microsoft-Windows-AppLocker/MSI and Script - Microsoft-Windows-AppLocker/EXE and DLL - Microsoft-Windows-AppLocker/Packaged app-Deployment - Microsoft-Windows-AppLocker/Packaged app-Execution |
| windows | product: windows service: appmodel-runtime | Channel: Microsoft-Windows-AppModel-Runtime/Admin |
| windows | product: windows service: appxdeployment-server | Channel: Microsoft-Windows-AppXDeploymentServer/Operational |
| windows | product: windows service: appxpackaging-om | Channel: Microsoft-Windows-AppxPackaging/Operational |
| windows | product: windows service: bitlocker | Channel: Microsoft-Windows-BitLocker/BitLocker Management |
| windows | product: windows service: bits-client | Channel: Microsoft-Windows-Bits-Client/Operational |
+| windows | product: windows service: capi2 | Channel: Microsoft-Windows-CAPI2/Operational |
+| windows | product: windows service: certificateservicesclient-lifecycle-system | Channel: Microsoft-Windows-CertificateServicesClient-Lifecycle-System/Operational |
| windows | product: windows service: codeintegrity-operational | Channel: Microsoft-Windows-CodeIntegrity/Operational |
| windows | product: windows service: dhcp | Channel: Microsoft-Windows-DHCP-Server/Operational |
| windows | product: windows service: diagnosis-scripted | Channel: Microsoft-Windows-Diagnosis-Scripted/Operational |
| windows | product: windows service: dns-client | Channel: Microsoft-Windows-DNS Client Events/Operational |
| windows | product: windows service: dns-server | Channel: DNS Server |
-| windows | product: windows service: dns-server-audit | Channel: Microsoft-Windows-DNS-Server/Audit |
| windows | product: windows service: dns-server-analytic | Channel: Microsoft-Windows-DNS-Server/Analytical |
+| windows | product: windows service: dns-server-audit | Channel: Microsoft-Windows-DNS-Server/Audit |
| windows | product: windows service: driver-framework | Channel: Microsoft-Windows-DriverFrameworks-UserMode/Operational |
| windows | product: windows service: firewall-as | Channel: Microsoft-Windows-Windows Firewall With Advanced Security/Firewall |
-| windows | product: windows service: ldap_debug | Channel: Microsoft-Windows-LDAP-Client/Debug |
+| windows | product: windows service: hyper-v-worker | Channel: Microsoft-Windows-Hyper-V-Worker |
+| windows | product: windows service: kernel-event-tracing | Channel: Microsoft-Windows-Kernel-EventTracing |
+| windows | product: windows service: kernel-shimengine | Channel: - Microsoft-Windows-Kernel-ShimEngine/Operational - WinEventLog:Microsoft-Windows-Kernel-ShimEngine/Diagnostic |
+| windows | product: windows service: ldap | Channel: Microsoft-Windows-LDAP-Client/Debug |
| windows | product: windows service: lsa-server | Channel: Microsoft-Windows-LSA/Operational |
-| windows | product: windows service: microsoft-servicebus-client | Channel: Microsoft-ServiceBus-Client |
| windows | product: windows service: msexchange-management | Channel: MSExchange Management |
+| windows | product: windows service: ntfs | Channel: Microsoft-Windows-Ntfs/Operational |
| windows | product: windows service: ntlm | Channel: Microsoft-Windows-NTLM/Operational |
| windows | product: windows service: openssh | Channel: OpenSSH/Operational |
| windows | product: windows service: powershell | Channel: Microsoft-Windows-PowerShell/Operational |
@@ -177,9 +191,11 @@ For a better comprehension, the log sources are organized by directory name simi
| windows | product: windows service: printservice-admin | Channel: Microsoft-Windows-PrintService/Admin |
| windows | product: windows service: printservice-operational | Channel: Microsoft-Windows-PrintService/Operational |
| windows | product: windows service: security | Channel: Security |
-| windows | product: windows service: security-mitigations | Channel: - Microsoft-Windows-Security-Mitigations/Kernel Mode - Microsoft-Windows-Security-Mitigations/User Mode |
-| windows | product: windows service: smbclient-security | Channel: Microsoft-Windows-SmbClient/Security |
+| windows | product: windows service: security-mitigations | Channel: - Microsoft-Windows-Security-Mitigations/Kernel Mode - Microsoft-Windows-Security-Mitigations/User Mode |
+| windows | product: windows service: sense | Channel: Microsoft-Windows-SENSE/Operational |
+| windows | product: windows service: servicebus-client | Channel: - Microsoft-ServiceBus-Client/Operational - Microsoft-ServiceBus-Client/Admin |
| windows | product: windows service: shell-core | Channel: Microsoft-Windows-Shell-Core/Operational |
+| windows | product: windows service: smbclient-security | Channel: Microsoft-Windows-SmbClient/Security |
| windows | product: windows service: sysmon | Channel: Microsoft-Windows-Sysmon/Operational |
| windows | product: windows service: system | Channel: System |
| windows | product: windows service: taskscheduler | Channel: Microsoft-Windows-TaskScheduler/Operational |
@@ -307,11 +323,24 @@ You can find all possible field values in the [Sysmon Community Guide](https://g
## History
-* 2023/01/21 Taxonomy V1.3.5
+* 2024-08-08 Taxonomy Appendix v v2.0.0
+ * Fix the following windows services:
+ * Change `ldap_debug` to `ldap`
+ * Add new windows services:
+ * ``service: application-experience``
+ * ``service: capi2``
+ * ``service: certificateservicesclient-lifecycle-system``
+ * ``service: hyper-v-worker``
+ * ``service: kernel-event-tracing``
+ * ``service: kernel-shimengine``
+ * ``service: ntfs``
+ * ``service: sense``
+ * ``service: servicebus-client``
+* 2023-01-21 Taxonomy Appendix v1.3.5
* Add new product and its related service:
* `product: github`
* `service: audit`
-* 2023/01/18 Taxonomy V1.3.4
+* 2023-01-18 Taxonomy Appendix v1.3.4
* Add the following new windows services:
* `service: appxdeployment-server`
* `service: lsa-server`
@@ -327,19 +356,19 @@ You can find all possible field values in the [Sysmon Community Guide](https://g
* Add missing category folder
* Add missing product folder
* Add description for a special case when using only the `product` logsource
-* 2023/01/03 Taxonomy V1.3.3
+* 2023-01-03 Taxonomy Appendix v1.3.3
* Add windows service dns-server-analytic and bitlocker
* Add all the W3C fields names to the category `webserver`
* Update linux `file_create` category to `file_event`
-* 2022/12/19 Taxonomy V1.3.2
+* 2022-12-19 Taxonomy Appendix v1.3.2
* Minor tweak and updates to the syntax and text
-* 2022/11/13 Taxonomy V1.3.1
+* 2022-11-13 Taxonomy Appendix v1.3.1
* Add missing service shell-core
-* 2022/11/01 Taxonomy V1.3.0
+* 2022-11-01 Taxonomy Appendix v1.3.0
* Add missing windows services
-* 2022/10/25 Taxonomy V1.2.0
+* 2022-10-25 Taxonomy Appendix v1.2.0
* Order the windows logs
-* 2022/10/19 Taxonomy V1.1.0
+* 2022-10-19 Taxonomy Appendix v1.1.0
* Fix links and spelling
-* 2022/09/18 Taxonomy V1.0.0
- * First version
+* 2022-09-18 Taxonomy v1.0.0
+ * Initial release
diff --git a/archives/wiki.md b/archives/wiki.md
deleted file mode 100644
index 6e416ae..0000000
--- a/archives/wiki.md
+++ /dev/null
@@ -1,628 +0,0 @@
-# Structure
-
-The rules consist of a few required sections and several optional ones.
-
-```yaml
-title
-id [optional]
-related [optional]
- - type {type-identifier}
- id {rule-id}
-status [optional]
-description [optional]
-author [optional]
-references [optional]
-logsource
- 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 [optional]
-level [optional]
-tags [optional]
-...
-[arbitrary custom fields]
-```
-
-# Schema
-
-## Rx YAML
-
-```yaml
-type: //rec
-required:
- title:
- type: //str
- length:
- min: 1
- max: 256
- logsource:
- type: //rec
- optional:
- category: //str
- product: //str
- service: //str
- definition: //str
- detection:
- type: //rec
- required:
- condition:
- type: //any
- of:
- - type: //str
- - type: //arr
- contents: //str
- length:
- min: 2
- rest:
- type: //any
- of:
- - type: //arr
- of:
- - type: //str
- - type: //map
- values:
- type: //any
- of:
- - type: //str
- - type: //arr
- contents: //str
- length:
- min: 2
- - type: //map
- values:
- type: //any
- of:
- - type: //str
- - type: //arr
- contents: //str
- length:
- min: 2
-optional:
- status:
- type: //any
- of:
- - type: //str
- value: stable
- - type: //str
- value: test
- - type: //str
- value: experimental
- - type: //str
- value: deprecated
- - type: //str
- value: unsupported
- description: //str
- author: //str
- references:
- type: //arr
- contents: //str
- fields:
- type: //arr
- contents: //str
- falsepositives:
- type: //any
- of:
- - type: //str
- - type: //arr
- contents: //str
- length:
- min: 2
- level:
- type: //any
- of:
- - type: //str
- value: informational
- - type: //str
- value: low
- - type: //str
- value: medium
- - type: //str
- value: high
- - type: //str
- value: critical
-rest: //any
-```
-
-## Image
-
-
-
-# Components
-
-## Title
-
-**Attribute:** title
-
-A brief title for the rule that should contain what the rules is supposed to detect (max. 256 characters)
-
-## Rule Identification
-
-**Attributes:** id, related
-
-Sigma rules should be identified by a globally unique identifier in the *id* attribute. For this
-purpose random generated UUIDs (version 4) are recommended but not mandatory. An example for this
-is:
-
-```
-title: Test rule
-id: 929a690e-bef0-4204-a928-ef5e620d6fcc
-```
-
-Rule identifiers can and should change for the following reasons:
-
-* Major changes in the rule. E.g. a different rule logic.
-* Derivation of a new rule from an existing or refinement of a rule in a way that both are kept
- active.
-* Merge of rules.
-
-To being able to keep track on relationships between detections, Sigma rules may also contain
-references to related rule identifiers in the *related* attribute. This allows to define common
-relationships between detections as follows:
-
-```
-related:
- - id: 08fbc97d-0a2f-491c-ae21-8ffcfd3174e9
- type: derived
- - id: 929a690e-bef0-4204-a928-ef5e620d6fcc
- type: obsoletes
-```
-
-Currently the following types are defined:
-
-* derived: Rule was derived from the referred rule or rules, which may remain active.
-* obsoletes: Rule obsoletes the referred rule or rules, which aren't used anymore.
-* merged: Rule was merged from the referred rules. The rules may be still existing and in use.
-* renamed: The rule had previously the referred identifier or identifiers but was renamed for any
- other reason, e.g. from a private naming scheme to UUIDs, to resolve collisions etc. It's not
- expected that a rule with this id exists anymore.
-* similar: Use to relate similar rules to each other (e.g. same detection content applied to different log sources, rule that is a modified version of another rule with a different level)
-
-## Status (optional)
-
-**Attribute:** status
-
-Declares the status of the rule:
-
-- stable: the rule is considered as stable and may be used in production systems or dashboards.
-- test: an almost stable rule that possibly could require some fine tuning.
-- experimental: an experimental rule that could lead to false results or be noisy, but could also identify interesting
- events.
-- deprecated: the rule is replace or cover by another one. The link is made by the `related` field.
-- unsupported: the rule can not be use in its current state (special correlation log, home-made fields)
-
-
-## Description (optional)
-
-**Attribute:** description
-
-A short description of the rule and the malicious activity that can be detected (max. 65,535 characters)
-
-## License (optional)
-
-**Attribute:** license
-
-License of the rule according the [SPDX ID specification](https://spdx.org/ids).
-
-## Author (optional)
-
-**Attribute**: author
-
-Creator of the rule.
-
-## References (optional)
-
-**Attribute**: reference
-
-References to the source that the rule was derived from. These could be blog articles, technical papers, presentations or even tweets.
-
-## Log Source
-
-**Attribute**: logsource
-
-This section describes the log data on which the detection is meant to be applied to. It describes the log source, the platform, the application and the type that is required in detection.
-
-It consists of three attributes that are evaluated automatically by the converters and an arbitrary number of optional elements. We recommend using a "definition" value in cases in which further explication is necessary.
-
-* category - examples: firewall, web, antivirus
-* product - examples: windows, apache, check point fw1
-* service - examples: sshd, applocker
-
-The "category" value is used to select all log files written by a certain group of products, like firewalls or web server logs. The automatic conversion will use the keyword as a selector for multiple indices.
-
-The "product" value is used to select all log outputs of a certain product, e.g. all Windows Eventlog types including "Security", "System", "Application" and the new log types like "AppLocker" and "Windows Defender".
-
-Use the "service" value to select only a subset of a product's logs, like the "sshd" on Linux or the "Security" Eventlog on Windows systems.
-
-The "definition" can be used to describe the log source, including some information on the log verbosity level or configurations that have to be applied. It is not automatically evaluated by the converters but gives useful advice to readers on how to configure the source to provide the necessary events used in the detection.
-
-You can use the values of 'category, 'product' and 'service' to point the converters to a certain index. You could define in the configuration files that the category 'firewall' converts to `( index=fw1* OR index=asa* )` during Splunk search conversion or the product 'windows' converts to `"_index":"logstash-windows*"` in ElasticSearch queries.
-
-Instead of referring to particular services, generic log sources may be used, e.g.:
-
-```
-category: process_creation
-product: windows
-```
-
-Instead of definition of multiple rules for Sysmon, Windows Security Auditing and possible product-specific rules.
-
-## Detection
-
-**Attribute**: detection
-
-A set of search-identifiers that represent properties of searches on log data.
-
-### Search-Identifier
-
-A definition that can consist of two different data structures - lists and maps.
-
-### General
-
-* All values are treated as case-insensitive strings
-* You can use wildcard characters `*` and `?` in strings (see also escaping section below)
-* Regular expressions are case-sensitive by default
-* You don't have to escape characters except the string quotation marks `'`
-
-### Escaping
-
-The backslash character `\` is used for escaping of wildcards `*` and `?` as well as the backslash character itself. Escaping of the backslash is necessary if it is followed by a wildcard depending on the desired result.
-
-Summarized, there are the following possibilities:
-
-* Plain backslash not followed by a wildcard can be expressed as single `\` or double backslash `\\`. For simplicity reasons the single notation is recommended.
-* A wildcard has to be escaped to handle it as a plain character: `\*`
-* The backslash before a wildcard has to be escaped to handle the value as a backslash followed by a wildcard: `\\*`
-* Three backslashes are necessary to escape both, the backslash and the wildcard and handle them as plain values: `\\\*`
-* Three or four backslashes are handled as double backslash. Four a recommended for consistency reasons: `\\\\` results in the plain value `\\`.
-
-### Lists
-
-Lists can contain:
-
-* strings that are applied to the full log message and are linked with a logical 'OR'.
-* maps (see below). All map items of a list are logically linked with 'OR'.
-
-Example for list of strings: Matches on 'EvilService' **or** 'svchost.exe -n evil'
-
-```
-detection:
- keywords:
- - EVILSERVICE
- - svchost.exe -n evil
-```
-
-Example for list of maps:
-
-```
-detection:
- selection:
- - Image|endswith: \\example.exe
- - Description|contains: Test executable
-```
-
-Matches an image file `example.exe` or an executable whose description contains the string `Test executable`
-
-### Maps
-
-Maps (or dictionaries) consist of key/value pairs, in which the key is a field in the log data and the value a string or integer value. All elements of a map are joined with a logical 'AND'.
-
-Examples:
-
-Matches on Eventlog 'Security' **and** ( Event ID 517 **or** Event ID 1102 )
-
-```
-detection:
- selection:
- - EventLog: Security
- EventID:
- - 517
- - 1102
-condition: selection
-```
-
-Matches on Eventlog 'Security' **and** Event ID 4679 **and** TicketOptions 0x40810000 **and** TicketEncryption 0x17
-
-```
-detection:
- selection:
- - EventLog: Security
- EventID: 4769
- TicketOptions: '0x40810000'
- TicketEncryption: '0x17'
-condition: selection
-```
-
-### Field Usage
-
-1. For fields with existing field-mappings, use the mapped field name.
-
-Examples from [the generic config `tools\config\generic\windows-audit.yml`](https://github.com/SigmaHQ/sigma/blob/master/tools/config/generic/windows-audit.yml#L23-L28) (e.g. use `Image` over `NewProcessName`):
-```
-fieldmappings:
- Image: NewProcessName
- ParentImage: ParentProcessName
- Details: NewValue
- ParentCommandLine: ProcessCommandLine
- LogonId: SubjectLogonId
-```
-
-2. For new or rarely used fields, use them as they appear in the log source and strip all spaces. (That means: Only, if the field is not already mapped to another field name.) On Windows event log sources, use the field names of the details view as the general view might contain localized field names.
-
-Examples:
-* `New Value` -> `NewValue`
-* `SAM User Account` -> `SAMUserAccount`
-
-3. Clarification on Windows events from the EventViewer:
- 1. Some fields are defined as attributes of the XML tags (in the `` header of the events). The tag and attribute names have to be linked with an underscore character '_'.
- 2. In the `` body of the event the field name is given by the `Name` attribute of the `Data` tag.
-
-Examples i:
-* `` will be `Provider_Name`
-* ` ` will be `Execution_ProcessID`
-
-Examples ii:
-* `NT AUTHORITY\SYSTEM` will be `User`
-* `MpKsl4eaa0a76` will be `ServiceName`
-
-### Special Field Values
-
-There are special field values that can be used.
-
-* An empty value is defined with `''`
-* A null value is defined with `null`
-
-OBSOLETE: An arbitrary value except null or empty cannot be defined with `not null` anymore
-
-The application of these values depends on the target SIEM system.
-
-To get an expression that say `not null` you have to create another selection and negate it in the condition.
-
-Example:
-
-```
-detection:
- selection:
- EventID: 4738
- filter:
- PasswordLastSet: null
-condition:
- selection and not filter
-```
-
-### Value Modifiers
-
-The values contained in Sigma rules can be modified by *value modifiers*. Value modifiers are
-appended after the field name with a pipe character `|` as separator and can also be chained, e.g.
-`fieldname|mod1|mod2: value`. The value modifiers are applied in the given order to the value.
-
-#### Modifier Types
-
-There are two types of value modifiers:
-
-* *Transformation modifiers* transform values into different values, like the two Base64 modifiers
- mentioned above. Furthermore, this type of modifier is also able to change the logical operation
- between values. Transformation modifiers are generally backend-agnostic. Means: you can use them
- with any backend.
-* *Type modifiers* change the type of a value. The value itself might also be changed by such a
- modifier, but the main purpose is to tell the backend that a value should be handled differently
- by the backend, e.g. it should be treated as regular expression when the *re* modifier is used.
- Type modifiers must be supported by the backend.
-
-Generally, value modifiers work on single values and value lists. A value might also expand into
-multiple values.
-
-#### Currently Available Modifiers
-
-##### Transformations
-
-* `contains`: puts `*` wildcards around the values, such that the value is matched anywhere in the
- field.
-* `all`: Normally, lists of values were linked with *OR* in the generated query. This modifier
- changes
- this to *AND*. This is useful if you want to express a command line invocation with different
- parameters where the order may vary and removes the need for some cumbersome workarounds.
-
- Single item values are not allowed to have an `all` modifier as some back-ends cannot support it.
- If you use it as a workaround to duplicate a field in a selection, use a new selection instead.
-* `base64`: The value is encoded with Base64.
-* `base64offset`: If a value might appear somewhere in a base64-encoded value the representation
- might change depending on the position in the overall value. There are three variants for shifts
- by zero to two bytes and except the first and last byte the encoded values have a static part in
- the middle that can be recognized.
-* `endswith`: The value is expected at the end of the field's content (replaces e.g. '*\cmd.exe')
-* `startswith`: The value is expected at the beginning of the field's content. (replaces e.g. 'adm*')
-* `utf16le`: transforms value to UTF16-LE encoding, e.g. `cmd` > `63 00 6d 00 64 00` (only used in combination with base64 modifiers)
-* `utf16be`: transforms value to UTF16-BE encoding, e.g. `cmd` > `00 63 00 6d 00 64` (only used in combination with base64 modifiers)
-* `wide`: alias for `utf16le` modifier
-* `utf16`: prepends a [byte order mark](https://en.wikipedia.org/wiki/Byte_order_mark) and encodes UTF16, e.g. `cmd` > `FF FE 63 00 6d 00 64 00` (only used in combination with base64 modifiers)
-* `windash`: Add a new variant where all `-` occurrences are replaced with `/`. The original variant is also kept unchanged.
-
-##### Types
-
-* *re*: value is handled as regular expression by backends. Currently, this is only supported by
- the Elasticsearch query string backend (*es-qs*). Further (like Splunk) are planned or have
- to be implemented by contributors with access to the target systems.
-
-## Condition
-
-**Attribute**: condition
-
-The condition is the most complex part of the specification and will be subject to change over time and arising requirements. In the first release it will support the following expressions.
-
-- Logical AND/OR
-
- `keywords1 or keywords2`
-
-- 1/all of search-identifier
-
- Same as just 'keywords' if keywords are defined in a list. X may be:
-
- - 1 (logical or across alternatives)
- - all (logical and across alternatives)
-
- Example: `all of keywords` means that all items of the list keywords must appear, instead of the default behaviour of any of the listed items.
-
-- 1/all of them
-
- Logical OR (`1 of them`) or AND (`all of them`) across all defined search identifiers. The search identifiers
- themselves are logically linked with their default behaviour for maps (AND) and lists (OR).
-
- The usage of `all of them` is discouraged, as it prevents the possibility of downstream users of a rule to generically filter unwanted matches. See `all of {search-identifier-pattern}` in the next section as the preferred method.
-
- Example: `1 of them` means that one of the defined search identifiers must appear.
-
-- 1/all of search-identifier-pattern
-
- Same as *1/all of them*, but restricted to matching search identifiers. Matching is done with * wildcards (any number of characters) at arbitrary positions in the pattern.
-
- Examples:
- - `all of selection*`
- - `1 of selection* and keywords`
- - `1 of selection* and not 1 of filter*`
-
-- Negation with 'not'
-
- `keywords and not filters`
-
-- Brackets
-
- `selection1 and (keywords1 or keywords2)`
-
-- Pipe (deprecated)
-
- `search_expression | aggregation_expression`
-
- A pipe indicates that the result of *search_expression* is aggregated by *aggregation_expression* and possibly
- compared with a value.
-
- The first expression must be a search expression that is followed by an aggregation expression with a condition.
-
- Aggregations in the condition are deprecated and will be replaced with [Sigma correlations](https://github.com/SigmaHQ/sigma/wiki/Specification:-Sigma-Correlations).
-
-- Aggregation expression (deprecated, see [Sigma Correlations specification](https://github.com/SigmaHQ/sigma/wiki/Specification:-Sigma-Correlations) for future plans)
-
- agg-function(agg-field) [ by group-field ] comparison-op value
-
- agg-function may be:
-
- - count
- - min
- - max
- - avg
- - sum
-
- All aggregation functions except count require a field name as parameter. The count aggregation counts all matching events if no field name is given. With field name it counts the distinct values in this field.
-
- Example: `count(UserName) by SourceWorkstation > 3`
-
- This comparison counts distinct user names grouped by SourceWorkstations.
-
-- Near aggregation expression (deprecated, see [Sigma Correlations specification](https://github.com/SigmaHQ/sigma/wiki/Specification:-Sigma-Correlations) for future plans)
-
- near *search-id-1* [ [ and *search-id-2* | and not *search-id-3* ] ... ]
-
- This expression generates (if supported by the target system and backend) a query that recognizes *search_expression* (primary event) if the given conditions are or are not in the temporal context of the primary event within the given time frame.
-
-Operator Precedence (least to most binding)
-
-- |
-- or
-- and
-- not
-- x of search-identifier
-- ( expression )
-
-If multiple conditions are given, they are logically linked with OR.
-
-## Fields
-
-**Attribute**: fields
-
-A list of log fields that could be interesting in further analysis of the event and should be displayed to the analyst.
-
-## FalsePositives
-
-**Attribute**: falsepositives
-
-A list of known false positives that may occur.
-
-## Level
-
-**Attribute**: level
-
-The level field contains one of five string values. It describes the criticality of a triggered rule. While `low` and `medium` level events have an informative character, events with `high` and `critical` level should lead to immediate reviews by security analysts.
-
-- `informational`: Rule is intended for enrichment of events, e.g. by tagging them. No case or alerting should be triggered by such rules because it is expected that a huge amount of events will match these rules.
-- `low`: Notable event but rarely an incident. Low rated events can be relevant in high numbers or combination with others. Immediate reaction shouldn't be necessary, but a regular review is recommended.
-- `medium`: Relevant event that should be reviewed manually on a more frequent basis.
-- `high`: Relevant event that should trigger an internal alert and requires a prompt review.
-- `critical`: Highly relevant event that indicates an incident. Critical events should be reviewed immediately.
-
-## Tags
-
-**Attribute**: tags
-
-A Sigma rule can be categorised with tags. Tags should generally follow this syntax:
-
-* Character set: lower-case letters, underscores and hyphens
-* no spaces
-* Tags are namespaced, the dot is used as separator. e.g. *attack.t1234* refers to technique 1234 in the namespace *attack*; Namespaces may also be nested
-* Keep tags short, e.g. numeric identifiers instead of long sentences
-* If applicable, use [predefined tags](./Tags). Feel free to send pull request or issues with proposals for new tags
-
-## Placeholders
-
-Placeholders can be used to select a set of elements that can be expanded during conversion.
-Placeholders map a an identifier to a user defined value that can be set in config files for an
-automatic replacement during conversion runs. Placeholders are meaningful identifiers that users can
-easily expand themselves.
-
-### Examples for placeholders
-
-* `%Administrators%` - Administrative user accounts
-* `%JumpServers%` - Server systems used as jump servers
-
-Some SIEM systems allow using so-called "tags" or "search macros" in queries and can integrate Sigma rules with placeholders directly. Others expand the placeholders values to wildcard strings or regular expressions.
-
-### Examples for conversions
-
-Splunk
-
-* `AccountName: %Administrators%` convert to `tag=Administrators`
-
-Elastic Search
-
-* `SourceWorkstation: %JumpServers%` convert to `"SourceWorkstation": SRV110[12]`
-
-# Rule Collections
-
-A file may contain multiple YAML documents. These can be complete Sigma rules or *action documents*. A YAML document is handled as action document if the `action` attribute on the top level is set to:
-
-* `global`: Defines YAML content that is merged in all following YAML rule documents in this file. Multiple *global* action documents are accumulated.
-** Use case: define metadata and rule parts that are common across all Sigma rules of a collection.
-* `reset`: Reset global YAML content defined by *global* action documents.
-* `repeat`: Repeat generation of previous rule document with merged data from this YAML document.
-** Use case: Small modifications of previously generated rule.
-
-## Example
-A common use case is the definition of multiple Sigma rules for similar events like Windows Security EventID 4688 and Sysmon EventID 1. Both are created for process execution events. A Sigma rule collection for this scenario could contain three documents:
-
-1. A global action document that defines common metadata and detection indicators
-2. A rule that defines Windows Security log source and EventID 4688
-3. A rule that defines Windows Sysmon log source and EventID 1
-
-Alternative solution could be:
-
-1. A global action document that defines common metadata.
-2. The Security/4688 rule with all event details.
-3. A repeat action document that replaces the logsource and EventID from the rule defined in 2.
diff --git a/favicon.ico b/favicon.ico
deleted file mode 100644
index ccd77c5..0000000
Binary files a/favicon.ico and /dev/null differ
diff --git a/images/Sigma_0.3.png b/images/Sigma_0.3.png
deleted file mode 100644
index 0bd0db1..0000000
Binary files a/images/Sigma_0.3.png and /dev/null differ
diff --git a/images/Sigma_Schema.png b/images/Sigma_Schema.png
deleted file mode 100644
index 261401c..0000000
Binary files a/images/Sigma_Schema.png and /dev/null differ
diff --git a/json-schema/sigma-correlation-rules-schema.json b/json-schema/sigma-correlation-rules-schema.json
new file mode 100644
index 0000000..04ca96a
--- /dev/null
+++ b/json-schema/sigma-correlation-rules-schema.json
@@ -0,0 +1,204 @@
+{
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "title": "Sigma Meta rule specification V2.0.0 (2024-08-08)",
+ "type": "object",
+ "required": [
+ "title",
+ "correlation"
+ ],
+ "properties": {
+ "title": {
+ "type": "string",
+ "maxLength": 256,
+ "description": "A brief title for the rule that should contain what the rules is supposed to detect"
+ },
+ "id": {
+ "type": "string",
+ "description": "A globally unique identifier for the Sigma rule. This is recommended to be a UUID v4, but not mandatory.",
+ "format": "uuid"
+ },
+ "description": {
+ "type": "string",
+ "description": "A short description of the rule and the malicious activity that can be detected",
+ "maxLength": 65535
+ },
+ "author": {
+ "type": "string",
+ "description": "Creator of the rule. (can be a name, nickname, twitter handle, etc.)"
+ },
+ "references": {
+ "type": "array",
+ "description": "References to the source that the rule was derived from. These could be blog articles, technical papers, presentations or even tweets",
+ "uniqueItems": true,
+ "items": {
+ "type": "string"
+ }
+ },
+ "date": {
+ "type": "string",
+ "description": "Creation date of the meta rule. Use the ISO 8601 format YYYY-MM-DD",
+ "pattern": "^\\d{4}-(0[1-9]|1[012])-(0[1-9]|[12][0-9]|3[01])$"
+ },
+ "modified": {
+ "type": "string",
+ "description": "Last modification date of the meta rule. Use the ISO 8601 format YYYY-MM-DD",
+ "pattern": "^\\d{4}-(0[1-9]|1[012])-(0[1-9]|[12][0-9]|3[01])$"
+ },
+ "correlation": {
+ "type": "object",
+ "required": [
+ "type",
+ "rules",
+ "timespan",
+ "condition"
+ ],
+ "description": "represents the correlation searched for on the log data",
+ "properties": {
+ "type": {
+ "type": "string",
+ "maxLength": 16,
+ "description": "Defines the corelation type",
+ "oneOf": [
+ {
+ "const": "event_count"
+ },
+ {
+ "const": "value_count"
+ },
+ {
+ "const": "temporal"
+ },
+ {
+ "const": "temporal_ordered"
+ }
+ ]
+ },
+ "rules":{
+ "description": "Refers to one or multiple Sigma or Correlations rules",
+ "uniqueItems": true,
+ "anyOf": [
+ {
+ "type": "array",
+ "items": {
+ "anyOf":[
+ {
+ "type": "string",
+ "minLength": 2
+ },
+ {
+ "type": "string",
+ "format": "uuid"
+ }
+ ]
+
+ }
+ }
+ ]
+ },
+ "alias":{
+ "type": "object",
+ "description": "defines field name aliases that are applied to correlated Sigma rules",
+ "additionalProperties":{
+ "anyOf": [
+ {
+ "type": "object",
+ "items": {
+ "type": "string"
+ }
+ }
+ ]
+ }
+ },
+ "group-by": {
+ "type": "array",
+ "description": "defines one or multiple fields which should be treated as separate event occurrence scope",
+ "uniqueItems": true,
+ "items": {
+ "type": "string"
+ }
+ },
+ "timespan": {
+ "type": "string",
+ "maxLength": 10,
+ "description": "defines a time period in which the correlation should be applied. used: `number + letter (in lowercase)`"
+ },
+ "condition": {
+ "type": "object",
+ "description": "The condition defines when a correlation matches",
+ "uniqueItems": true,
+ "minItems": 1,
+ "maxItems": 3,
+ "anyOf": [
+ {
+ "gt": {
+ "description": "The count must be greater than the given value",
+ "type": "integer"
+ }
+ },
+ {
+ "gte": {
+ "description": "The count must be greater than or equal the given value",
+ "type": "integer"
+ }
+ },
+ {
+ "lt": {
+ "description": "The count must be lesser than the given value",
+ "type": "integer"
+ }
+ },
+ {
+ "lte": {
+ "description": "The count must be lesser than or equal the given value",
+ "type": "integer"
+ }
+ },
+ {
+ "eq": {
+ "description": "The count must be equal the given value",
+ "type": "integer"
+ }
+ },
+ {
+ "field": {
+ "description": "name of the field to counts values",
+ "type": "string",
+ "maxLength": 256
+ }
+ }
+ ]
+ }
+ }
+ },
+ "level": {
+ "type": "string",
+ "description": "The criticality of a triggered rule",
+ "oneOf": [
+ {
+ "const": "informational",
+ "description": "Rule is intended for enrichment of events, e.g. by tagging them. No case or alerting should be triggered by such rules because it is expected that a huge amount of events will match these rules"
+ },
+ {
+ "const": "low",
+ "description": "Notable event but rarely an incident. Low rated events can be relevant in high numbers or combination with others. Immediate reaction shouldn't be necessary, but a regular review is recommended"
+ },
+ {
+ "const": "medium",
+ "description": "Relevant event that should be reviewed manually on a more frequent basis"
+ },
+ {
+ "const": "high",
+ "description": "Relevant event that should trigger an internal alert and requires a prompt review"
+ },
+ {
+ "const": "critical",
+ "description": "Highly relevant event that indicates an incident. Critical events should be reviewed immediately. It is used only for cases in which probability borders certainty"
+ }
+ ]
+ },
+ "generate": {
+ "type": "boolean",
+ "description": "defines if the rules referred from the correlation rule should be converted as stand-alone rules"
+ }
+ }
+}
diff --git a/sigma-schema.json b/json-schema/sigma-detection-rule-schema.json
similarity index 88%
rename from sigma-schema.json
rename to json-schema/sigma-detection-rule-schema.json
index 7f15f24..49dccd1 100644
--- a/sigma-schema.json
+++ b/json-schema/sigma-detection-rule-schema.json
@@ -1,6 +1,6 @@
{
- "$schema": "http://json-schema.org/draft-07/schema#",
- "title": "Sigma rule specification V1.0.4 (2023/06/29)",
+ "$schema": "https://json-schema.org/draft/2020-12/schema#",
+ "title": "Sigma rule specification V2.0.0 (2024-08-08)",
"type": "object",
"required": ["title", "logsource", "detection"],
"properties": {
@@ -34,7 +34,7 @@
"description": "The rule was derived from the referred rule or rules, which may remain active"
},
{
- "const": "obsoletes",
+ "const": "obsolete",
"description": "The rule obsoletes the referred rule or rules, which aren't used anymore"
},
{
@@ -54,6 +54,16 @@
}
}
},
+ "name": {
+ "type": "string",
+ "maxLength": 256,
+ "description": "a unique human-readable name that can be used instead of the id as a reference in correlation rules"
+ },
+ "taxonomy":{
+ "type": "string",
+ "maxLength": 256,
+ "description": "Defines the taxonomy used in the Sigma rule"
+ },
"status": {
"type": "string",
"oneOf": [
@@ -102,13 +112,13 @@
},
"date": {
"type": "string",
- "description": "Creation date of the rule. Use the format YYYY/MM/DD",
- "pattern": "^\\d{4}/(0[1-9]|1[012])/(0[1-9]|[12][0-9]|3[01])$"
+ "description": "Creation date of the rule. Use the ISO 8601 format YYYY-MM-DD",
+ "pattern": "^\\d{4}-(0[1-9]|1[012])-(0[1-9]|[12][0-9]|3[01])$"
},
"modified": {
"type": "string",
- "description": "Last modification date of the rule. Use the format YYYY/MM/DD",
- "pattern": "^\\d{4}/(0[1-9]|1[012])/(0[1-9]|[12][0-9]|3[01])$"
+ "description": "Last modification date of the rule. Use the ISO 8601 format YYYY-MM-DD",
+ "pattern": "^\\d{4}-(0[1-9]|1[012])-(0[1-9]|[12][0-9]|3[01])$"
},
"logsource": {
"type": "object",
@@ -125,6 +135,10 @@
"service": {
"description": "A subset of a product's logs, like sshd",
"type": "string"
+ },
+ "definition":{
+ "description": "can be used to describe the log source",
+ "type": "string"
}
}
},
@@ -228,6 +242,14 @@
"type": "string",
"pattern": "^[a-z0-9_-]+\\.[a-z0-9._-]+$"
}
+ },
+ "scope":{
+ "description": "A list of intended scope of the rule",
+ "type": "array",
+ "items": {
+ "type": "string",
+ "minLength": 2
+ }
}
}
}
diff --git a/json-schema/sigma-filters-schema.json b/json-schema/sigma-filters-schema.json
new file mode 100644
index 0000000..6726169
--- /dev/null
+++ b/json-schema/sigma-filters-schema.json
@@ -0,0 +1,114 @@
+{
+ "$schema": "https://json-schema.org/draft/2020-12/schema#",
+ "title": "Sigma Global Filter specification V2.0.0 (2024-08-08)",
+ "type": "object",
+ "required": [
+ "title",
+ "logsource",
+ "filter"
+ ],
+ "properties": {
+ "title": {
+ "type": "string",
+ "maxLength": 256,
+ "description": "A brief title for the rule that should contain what the rules is supposed to detect"
+ },
+ "id": {
+ "type": "string",
+ "description": "A globally unique identifier for the Sigma rule. This is recommended to be a UUID v4, but not mandatory.",
+ "format": "uuid"
+ },
+ "description": {
+ "type": "string",
+ "description": "A short description of the rule and the malicious activity that can be detected",
+ "maxLength": 65535
+ },
+ "date": {
+ "type": "string",
+ "description": "Creation date of the meta filter. Use the format YYYY-MM-DD",
+ "pattern": "^\\d{4}-(0[1-9]|1[012])-(0[1-9]|[12][0-9]|3[01])$"
+ },
+ "modified": {
+ "type": "string",
+ "description": "Last modification date of the meta filter. Use the format YYYY-MM-DD",
+ "pattern": "^\\d{4}-(0[1-9]|1[012])-(0[1-9]|[12][0-9]|3[01])$"
+ },
+ "logsource": {
+ "type": "object",
+ "description": "The log source that the rule is supposed to detect malicious activity in.",
+ "properties": {
+ "category": {
+ "description": "Group of products, like firewall or process_creation",
+ "type": "string"
+ },
+ "product": {
+ "description": "A certain product, like windows",
+ "type": "string"
+ },
+ "service": {
+ "description": "A subset of a product's logs, like sshd",
+ "type": "string"
+ }
+ }
+ },
+ "filter": {
+ "type": "object",
+ "required": ["rules","selection","condition"],
+ "description": "A set of search-identifiers that represent properties of searches on log data",
+ "additionalProperties": {
+ "description": "A Search Identifier: A definition that can consist of two different data structures - lists and maps.",
+ "anyOf": [
+ {
+ "type": "array",
+ "items": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "integer"
+ },
+ {
+ "type": "object",
+ "items": {
+ "type": "string"
+ }
+ }
+ ]
+ }
+ },
+ {
+ "type": "object",
+ "items": {
+ "type": "string"
+ }
+ }
+ ]
+ },
+ "properties": {
+ "rules": {
+ "type": "array",
+ "description": "list of the rule where add the filter",
+ "minItems": 1,
+ "uniqueItems": true,
+ "items": {
+ "type": "string"
+ }
+ },
+ "selection": {
+ "type": "array",
+ "description": "the filter detection logic",
+ "minItems": 1,
+ "uniqueItems": true,
+ "items": {
+ "type": "string"
+ }
+ },
+ "condition": {
+ "type": "string",
+ "description": "The relationship between the search identifiers to create the detection logic. selection or not selection"
+ }
+ }
+ }
+ }
+}
diff --git a/media/images/sigma_logo_dark.png b/media/images/sigma_logo_dark.png
new file mode 100644
index 0000000..d7987ed
Binary files /dev/null and b/media/images/sigma_logo_dark.png differ
diff --git a/media/images/sigma_logo_light.png b/media/images/sigma_logo_light.png
new file mode 100644
index 0000000..3babfa4
Binary files /dev/null and b/media/images/sigma_logo_light.png differ
diff --git a/other/version-2-changes.md b/other/version-2-changes.md
new file mode 100644
index 0000000..63f24da
--- /dev/null
+++ b/other/version-2-changes.md
@@ -0,0 +1,41 @@
+# Changes and Feature Introduced in V2.0.0
+
+The following is a non-exhaustive list of changes between the v1 and v2 specification.
+
+## Sigmac
+
+As of August 1st 2024 the `sigmac` toolchain has reached it's end of life, and its corresponding [repository](https://github.com/SigmaHQ/legacy-sigmatools) has been archived. The `sigmac` toolchain doesn't take into account new feature introduced in the second version specification.
+
+The `pySigma` library and it's corresponding command line interface `sigma-cli`, provide full support for version 2 of the specification.
+
+## Date & Modified Field
+
+The latest version of the specification drops support for the date format using a slash `/` separator (YYYY/MM/DD), and now it only recommend the usage of the ISO 8601 format with the a `-` separator (YYYY-MM-DD).
+
+## Tags Field
+
+The latest version of the specification changed the use of "underscore" and "dots" in favour of "dashes" for the following tag namespaces:
+
+* ATT&CK
+* CVE
+* Detection
+
+## Related Field
+
+The related field type `obsoletes` has been changed to `obsolete` for consistency purposes.
+
+## Rx Schema
+
+The latest version of the specification drops the support for the [Rx-Schema](https://github.com/SigmaHQ/sigma-specification/blob/69ce07a4068a9668098eef148ab874862625bbeb/archives/wiki.md#rx-yaml) in favour of a [JSON schema](/json-schema/).
+
+## Modifiers
+
+The latest version of the specification and by extension the `pySigma` library, introduces a new set of modifier. You can check the full list of all currently supported modifiers in the [Sigma Modifiers Appendix](./appendix/sigma-modifiers-appendix.md).
+
+## Correlation
+
+The latest version of the specification drops the usage of the old aggregation expression, in favour of a new format titled meta/correlation rules. Check out the [Sigma Correlation Rules Specification](/specification/sigma-correlation-rules-specification.md) for full details.
+
+## Sigma Filters
+
+Check out the [Sigma Filters Specification](/specification/sigma-filters-specification.md) for a detailed description of the format.
diff --git a/sigmahq/Sigmahq_filename_rule.md b/sigmahq/sigmahq-filename-convention.md
similarity index 98%
rename from sigmahq/Sigmahq_filename_rule.md
rename to sigmahq/sigmahq-filename-convention.md
index c43d7a0..be9e285 100644
--- a/sigmahq/Sigmahq_filename_rule.md
+++ b/sigmahq/sigmahq-filename-convention.md
@@ -1,10 +1,9 @@
-# SigmaHQ Filename Normalisation
+# SigmaHQ Filename Conventions
This document describe a soft convention to name rule files. The following convention has been set to help with the management of the rules files repository and is not part of the SIGMA specification.
-## Summary
+## Summary
-- [Summary](#summary)
- [Product](#product)
- [Cloud](#cloud)
- [Category](#category)
@@ -98,7 +97,7 @@ The naming convetion for rules using linux services is the as follows:
### Windows
-The naming convetion for rules using windows services is the as follows:
+The naming convention for rules using windows services is the as follows:
- Filename must start with `win_`
- Followed by the service name and underscore at the end `service_`. Example: `applocker_`
diff --git a/sigmahq/sigmahq_conventions.md b/sigmahq/sigmahq-rule-convention.md
similarity index 74%
rename from sigmahq/sigmahq_conventions.md
rename to sigmahq/sigmahq-rule-convention.md
index 9bd991c..962d691 100644
--- a/sigmahq/sigmahq_conventions.md
+++ b/sigmahq/sigmahq-rule-convention.md
@@ -1,18 +1,22 @@
# SigmaHQ Rule Conventions
-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 specification please read the [Sigma_specification.md](../Sigma_specification.md).
+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](/specification/sigma_rules.md)
## Summary
- [Summary](#summary)
- [Structure](#structure)
- [Filenames](#filenames)
+- [Indentation](#indentation)
- [Titles](#titles)
- [Status](#status)
+- [Description](#description)
- [References](#references)
- [Detection](#detection)
- [Item Lists](#item-lists)
-- [False Postivess](#false-postivess)
+- [False Positives](#false-positives)
## Structure
@@ -51,7 +55,7 @@ level [required]
## Filenames
-All rule filename must follow the convention described in [Sigmahq_filename_rule.md](./Sigmahq_filename_rule.md)
+All rule filename must follow the convention described in the [SigmaHQ Filename Convention](./sigmahq_filename_convention.md) file.
## Indentation
@@ -74,7 +78,7 @@ All newly created rules must start with a status of `experimental`
## Description
- 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 symbole `|` to signify a multiline string. Example:
+- 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:
```yml
description: |
@@ -85,7 +89,7 @@ description: |
## References
- All rules must provide a public reference, if possible.
-- References to the MITRE ATT&CK website are not allowed. Instead they shloud be expressed as tags using the appropriate MITRE tags.
+- 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.
## Detection
@@ -113,7 +117,14 @@ detection:
- '\example_3.exe'
```
-## False Postives
+### Condition
+
+- When possible, it is recommended to use conditions in the form `1 of selection_*` or `1 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.
+
+## False Positives
- 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:
@@ -128,4 +139,4 @@ falsepositives:
Also please note the following
-- Keywords such as `None`, `Pentest`, `Penetration Test`, `Red Team` are not accepted as valid values.
+- Keywords such as `None`, `Pentest`, `Penetration Test`, `Red Team`, Etc, are not accepted as valid values.
diff --git a/sigmahq/sigmahq_title_rule.md b/sigmahq/sigmahq-title-convention.md
similarity index 74%
rename from sigmahq/sigmahq_title_rule.md
rename to sigmahq/sigmahq-title-convention.md
index ddc88e8..0167791 100644
--- a/sigmahq/sigmahq_title_rule.md
+++ b/sigmahq/sigmahq-title-convention.md
@@ -1,98 +1,106 @@
-# SigmaHQ Rule Conventions
-
-This document provides general guidelines and tips on how to write titles for sigma rules.
-
-Note that this is by no means an exhaustive list. It is meant to be a general guide for inspiration and to have an easily sharable resource for new contributors (e.g. a resource to link at in PR discussions).
-
-## Summary
-
-- [Summary](#summary)
-- [Generality](#generality)
-- [Structure](#structure)
- - [Prefix (Optional)](#prefix-optional)
- - [Suffix (Optional)](#suffix-optional)
- - [Main Title](#main-title)
-
-## Generality
-
-Bearing in mind that the title is one of the first things that an analyst will see. It should therefore be used as a clue and be as clear as possible to guide the assessment of the alert.
-
-The title and level of the rule must be consistent
-
-## Structure
-
-Titles can be split with "-" : `Prefix - Main Title - Sufix`
-
-### Prefix (Optional)
-
-It is used to give a category, type of malware or name a threat actor. The choice depends highly on the type of rule.
-
-Examples:
-
-- HackTool
-- PUA
-- Remote Access Tool
-
-Specific wording example:
-
-- "ATP27 - "
-- "ATP29 - "
-- "UNC2452 - "
-- "UNC4841 - "
-
-### Suffix (Optional)
-
-Sometimes the detections are duplicated across different `logsource`s with little changes to their logic. This is common in the case of Process Creation rules targeting the PowerShell process. Those rules are typically duplicated for the different PowerShell `logsource`s using ScriptBlockText to check for the same characteristics. A suffix in this case will be used to differentiate between the rules of the different `logsource`s.
-
-Example:
-
-```yaml
-title: Invoke-Obfuscation Obfuscated IEX Invocation
-title: Invoke-Obfuscation Obfuscated IEX Invocation - PowerShell
-title: Invoke-Obfuscation Obfuscated IEX Invocation - PowerShell Module
-title: Invoke-Obfuscation Obfuscated IEX Invocation - Security
-title: Invoke-Obfuscation Obfuscated IEX Invocation - System
-```
-
-### Main Title
-
-The point of a description is to explain the alert in a meaningful way.
-
-The title does not need to use the terms "Detect" or "Detection". It doesn't have to be a sentence. A keyword style increases the information density.
-
-We use a simple formula to describe the alert.
-Example:
-
-- "7Zip Compressing ..."
-- "Add User to ..."
-- "Bypass UAC Using ..."
-- "Renamed xxx Execution"
-- "UAC Bypass Using ..."
-
-Rules of level `informational` or `low` are not intended to be used to create alerts on their own. Their purpose is to conserve events or criteria of relevance, to be used in correlations or for ideas for threat hunting. A rule of those levels will by definition not create false positives as they should not be used for alerting.
-
-The title should therefore be general and should not indicate that the rule describes suspicious or malicious behavior.
-
-Example : `Net.exe Execution`
-
-`medium` rules can have environment dependent false positives and require a tuning/evaluation phase before deploying to production environments.
-
-Keywords used to indicate this:
-
-- "Potential "
-
-`high` rules requires a prompt review.
-
-Keywords used to indicate this:
-
-- "Suspicious "
-
-`critical` rules should be reviewed immediately
-The title must therefore be precise and indicate the specific threat.
-
-Keywords used to indicate this:
-
-- "Malware"
-- "Exploit"
-- "... Attempt"
-- " Activity"
+# SigmaHQ Title Conventions
+
+This document provides general guidelines and tips on how to write titles for sigma rules.
+
+Note that this is by no means an exhaustive list. It is meant to be a general guide for inspiration and to have an easily sharable resource for new contributors (e.g. a resource to link at in PR discussions).
+
+## Table Of Content
+
+- [Summary](#summary)
+- [Generality](#generality)
+- [Structure](#structure)
+ - [Prefix (Optional)](#prefix-optional)
+ - [Suffix (Optional)](#suffix-optional)
+ - [Main Title](#main-title)
+
+## Summary
+
+Bearing in mind that the title is one of the first things that an analyst will see. It should therefore be used as a clue and be as clear as possible to guide the assessment of the alert.
+
+The title and level of the rule must be consistent
+
+## Structure
+
+Titles can be split with "-" : `Prefix - Main Title - Suffix`
+
+### Prefix (Optional)
+
+It is used to give a category, type of malware or name a threat actor. The choice depends highly on the type of rule.
+
+Examples:
+
+- HackTool
+- PUA
+- Remote Access Tool
+
+Specific wording example:
+
+- "ATP27 - "
+- "ATP29 - "
+- "UNC2452 - "
+- "UNC4841 - "
+
+### Suffix (Optional)
+
+Sometimes the detections are duplicated across different `logsource`s with little changes to their logic. This is common in the case of Process Creation rules targeting the PowerShell process. Those rules are typically duplicated for the different PowerShell `logsource`s using ScriptBlockText to check for the same characteristics. A suffix in this case will be used to differentiate between the rules of the different `logsource`s.
+
+Example:
+
+```yaml
+title: Invoke-Obfuscation Obfuscated IEX Invocation
+title: Invoke-Obfuscation Obfuscated IEX Invocation - PowerShell
+title: Invoke-Obfuscation Obfuscated IEX Invocation - PowerShell Module
+title: Invoke-Obfuscation Obfuscated IEX Invocation - Security
+title: Invoke-Obfuscation Obfuscated IEX Invocation - System
+```
+
+### Main Title
+
+The point of a description is to explain the alert in a meaningful way.
+
+The title does not need to use the terms "Detect" or "Detection". It doesn't have to be a sentence. A keyword style increases the information density.
+
+We use a simple formula to describe the alert.
+Example:
+
+- "7Zip Compressing ..."
+- "Add User to ..."
+- "Bypass UAC Using ..."
+- "Renamed xxx Execution"
+- "UAC Bypass Using ..."
+
+#### Informational / Low Level Rules
+
+Events matching rules of level `informational` or `low` are not intended to be used to create alerts on their own. Their purpose is to conserve events or criteria of relevance, to be used in correlations or for ideas for threat hunting. A rule of those levels will by definition not create false positives as they should not be used for alerting.
+
+The title should therefore be general and should not indicate that the rule describes suspicious or malicious behavior.
+
+Example : `Net.exe Execution`
+
+#### Medium Level Rules
+
+Events matching `medium` level rules rules can have environment dependent false positives and require a tuning/evaluation phase before deploying to production environments.
+
+Keywords used to indicate this:
+
+- "Potential "
+
+#### High Level Rules
+
+Events matching `high` level rules requires a prompt review.
+
+Keywords used to indicate this:
+
+- "Suspicious "
+
+#### Critical Level Rules
+
+Events matching `critical` level rules should be reviewed immediately
+The title must therefore be precise and indicate the specific threat.
+
+Keywords used to indicate this:
+
+- "Malware"
+- "Exploit"
+- "... Attempt"
+- " Activity"
diff --git a/specification/sigma-correlation-rules-specification.md b/specification/sigma-correlation-rules-specification.md
new file mode 100644
index 0000000..e9a050b
--- /dev/null
+++ b/specification/sigma-correlation-rules-specification.md
@@ -0,0 +1,562 @@
+# Sigma Correlation Rules Specification
+
+The following document defines the standardized correlation that can be used in Sigma rules.
+
+* Version 2.0.0
+* Release date 2024-08-08
+
+- [Introduction](#introduction)
+ - [Compatibility](#compatibility)
+ - [Expression of Relationships In The Condition of Sigma Rules](#expression-of-relationships-in-the-condition-of-sigma-rules)
+ - [Type of Correlation rules](#type-of-correlation-rules)
+- [Correlation rules](#correlation-rules)
+ - [File Structure](#file-structure)
+ - [YAML File](#yaml-file)
+ - [Schema](#schema)
+ - [Syntax](#syntax)
+ - [Components](#components)
+ - [Title](#title)
+ - [Identification](#identification)
+ - [Description](#description)
+ - [Author](#author)
+ - [References](#references)
+ - [Date](#date)
+ - [Modified](#modified)
+ - [Correlation section](#correlation-section)
+ - [Correlation type](#correlation-type)
+ - [Related rules](#related-rules)
+ - [Aliases](#aliases)
+ - [Grouping](#grouping)
+ - [Time Selection](#time-selection)
+ - [Condition](#condition)
+ - [Level](#level)
+ - [Generate](#generate)
+ - [Correlation Types](#correlation-types)
+ - [Event Count (event\_count)](#event-count-event_count)
+ - [Value Count (value\_count)](#value-count-value_count)
+ - [Temporal Proximity (temporal)](#temporal-proximity-temporal)
+ - [Ordered Temporal Proximity (temporal\_ordered)](#ordered-temporal-proximity-temporal_ordered)
+ - [Field Name Aliases](#field-name-aliases)
+ - [Field Name Aliases Example](#field-name-aliases-example)
+- [Examples](#examples)
+ - [Failed Logins Followed by Successful Login](#failed-logins-followed-by-successful-login)
+- [History](#history)
+
+# Introduction
+
+Sometimes you need more advanced searches than simple selections.
+For this purpose, you can use meta-rules that correlate multiple Sigma rules.
+
+## Compatibility
+
+When generating a backend specific query, Sigma correlations might exceed the capabilities of that targeted backend. \
+Or the Sigma correlation might require a feature that is only supported partially by the target backend. \
+Therefore target-specific restrictions should be handled in a way that ensures that the generated queries do not create results that:
+
+* Could be misinterpreted
+* Change the intention/context in which the rule matches
+* Cause a huge amount of false positives
+* Cause false negatives
+
+An error must be raised by the conversion backend if it would generate a query from a rule which contains a feature that is not supported but specified as must. Examples are:
+
+* The target system can aggregate an occurrence count but cannot apply a condition to filter the aggregated counts.
+* The target system is not able to aggregate an occurrence count according to the given grouping criteria.
+* It is only possible to generate a query up to an intermediate correlation rule of a chain.
+
+The conversion backend should issue a warning to raise the user’s awareness about restrictions for aspects specified as "should". \
+Examples are:
+
+* Temporal relationships are recognized, but the order of the events cannot be recognized by the target system. This could cause false positives by differently ordered events.
+* Temporal relationships are only recognized within static time boundaries, e.g. a `timespan` of 1h only matches if all events appear within a full hour, but not if some events appear in the previous and another event in the current hour. This could cause false negatives.
+
+## Expression of Relationships In The Condition of Sigma Rules
+
+This was the first approach defined in Sigma with aggregations and the near operator and is now obsolete. \
+Sigma correlations are not based on this approach for the following reasons:
+
+* The coupling of rules describing singular events and relationships between multiple events is inconsistent, as the rule writer must decide which rule contains the relationship definition in case of temporal relationships.
+* It was inflexible because one Sigma rule refers exactly to one log source, which restricts the expression of relationships to events from the same log source.
+* One of the goals of Sigma rules was to keep the condition logic simple. Especially the specification of temporal relationships can get quite complex in a query expression. Specifying correlation chains adds further complexity.
+* The pipe syntax sometimes caused the rule contributors to consider it as a Splunk query or another target system-specific query language. Expressing these relationships in a “Sigmaish” way should not cause these associations.
+
+## Type of Correlation rules
+
+The purpose is to cover a detection like:
+
+* X invalid login alerts on a unique host.
+* Invalid login alert on the same host but from X remote.
+* Alert A, B and C in the same `timespan`.
+
+
+# Correlation rules
+
+The rules in a multi-document YAML that build a correlation rule are not producing individual, independent queries. They are used as a tool to define more complex constructs out of basic Sigma detections. Therefore only the outermost correlation rule may define meta information such as status, level, date or anything else.
+
+## File Structure
+### YAML File
+
+To keep the file names interoperable use the following:
+
+- Length between 10 and 70 characters
+- Lowercase
+- No special characters, only letters (a-z) and digits (0-9)
+- Use `_` instead of a space
+- Use `.yml` as a file extension
+
+As a best practice use the prefix `mr_`.
+
+
+### Schema
+
+[Sigma Correlation Rules JSON Schema](/json-schema/sigma-correlation-rules-schema.json)
+
+### Syntax
+
+A Sigma correlation is a dedicated YAML document.
+Like Sigma rules , correlation rules have a title and a unique id to identify them.
+
+## Components
+
+### Title
+
+**Attribute:** title
+
+**Use:** mandatory
+
+A brief title for the rule that should contain what the rule is supposed to detect (max. 256 characters)
+
+### Identification
+
+**Attribute:** id
+
+**Use:** optional
+
+Sigma meta-rules should be identified by a globally unique identifier in the *id* attribute.
+For this purpose randomly generated UUIDs (version 4) are recommended but not mandatory.
+
+An example for this is:
+
+```yml
+title: login brute force
+id: 0e95725d-7320-415d-80f7-004da920fc11
+```
+
+### Description
+
+**Attribute:** description
+
+**Use:** optional
+
+A short description of the rule and the malicious activity that can be detected (max. 65,535 characters)
+
+### Author
+
+**Attribute**: author
+
+**Use:** optional
+
+Creator of the rule. (can be a name, nickname, twitter handle...etc)
+
+### References
+
+**Attribute**: reference
+
+**Use:** optional
+
+References to the source that the rule was derived from. \
+These could be blog articles, technical papers, presentations or even tweets.
+
+### Date
+
+**Attribute**: date
+
+**Use:** optional
+
+Creation date of the meta rule. \
+Use the ISO 8601 date with separator format: `YYYY-MM-DD`
+
+### Modified
+
+**Attribute**: modified
+
+**Use:** optional
+
+*Last* modification date of the meta rule. \
+Use the ISO 8601 date with separator format : `YYYY-MM-DD`
+
+### Correlation section
+
+#### Correlation type
+
+**Attribute:** type
+
+**Use:** mandatory
+
+Can be :
+- event_count
+- value_count
+- temporal
+- temporal_ordered
+
+#### Related rules
+
+**Attribute:** rules
+
+**Use:** mandatory
+
+Refers to one or multiple Sigma or Correlations rules.
+Allowing the user to chain multiple correlations together.
+A rule can be referred to by the `id` or `name` of a Sigma rule.
+
+`name` is a per correlation **unique** human-readable name that improves the readability of correlation rules.
+In this case, the tool must be able to manage the name-to-id translation automatically and the referenced rule name has to be defined in the respective rule.
+
+```yaml
+title: login brute force
+id: 0e95725d-7320-415d-80f7-004da920fc11
+correlation:
+ rules:
+ - 5638f7c0-ac70-491d-8465-2a65075e0d86 # ID of the low firewall rule for action: block
+ - firewall_block # The internal tools have a lookup table to the correct rule `id` by `name`
+```
+
+#### Aliases
+
+**Attribute:** aliases
+
+**Use:** optional
+
+defines field name aliases that are applied to correlated Sigma rules.
+The defined aliases can then be defined in `group-by` and allows aggregation across different fields in different event types.
+
+See the example in the chapter [Field Name Aliases](#field-name-aliases) to get a better understanding.
+
+#### Grouping
+
+**Attribute:** group-by
+
+**Use:** mandatory
+
+optionally defines one or multiple fields which should be treated as separate event occurrence scope. Examples:
+ * count events by user
+ * temporal proximity must occur on one system by the same user
+
+#### Time Selection
+
+**Attribute:** timespan
+
+**Use:** mandatory
+
+defines a time period in which the correlation should be applied.
+The following format must be used: `number + letter (in lowercase)`
+- Xs seconds
+- Xm minutes
+- Xh hours
+- Xd days
+
+example for 1h30 : `timespan: 90m`
+
+#### Condition
+
+**Attribute:** condition
+
+**Use:** mandatory
+
+The condition defines when a correlation matches:
+
+* for an *event_count* correlation it defines the event count that must appear within the given time frame to match.
+* for a *value_count* correlation it defines the count of distinct values contained in the field specified in the
+ mandatory *field* attribute.
+* For a *temporal* or *temporal_ordered* correlation it specified the count of different event types (Sigma rules
+ matching) in the given time frame.
+
+It is a map of exactly one condition criterion:
+
+* `gt`: The count must be greater than the given value
+* `gte`: The count must be greater than or equal the given value
+* `lt`: The count must be lesser than the given value
+* `lte`: The count must be lesser than or equal the given value
+* `eq`: The count must be equal the given value
+
+Example:
+```yaml
+condition:
+ gte: 100
+```
+
+To define a range, you can use the conjunction 'AND' in the mapping.
+
+Example "101 to 200":
+```yaml
+condition:
+ gt: 100
+ lte: 200
+```
+
+If you need more complex constructs, you can always chain correlation rules together.
+See the examples at the far bottom, for more details.
+
+### Level
+
+**Attribute:** level
+
+**Use:** optional
+
+defines a severity level adjustment if the correlation matches.
+This allows to give single event hits a low or informational severity and increasing this to higher levels in case of correlating appearances of events.
+
+### Generate
+
+**Attribute:** generate
+
+**Use:** optional
+
+defines if the rules referred from the correlation rule should be converted
+as stand-alone rules or if only the correlation query should be generated (default).
+
+## Correlation Types
+### Event Count (event_count)
+
+Counts events occurring in the given time frame specified by the referred Sigma rule or rules.
+The resulting query must count events for each group specified by group-by separately.
+The condition finally defines how many events must occur to generate a search hit.
+
+Requires :
+ - `group-by`
+ - `timespan`
+ - `condition`
+
+Simple example : More than or equal 100 failed login attempts to a destination host in an hour:
+
+```yaml
+title: Many failed logins
+id: 0e95725d-7320-415d-80f7-004da920fc11
+correlation:
+ type: event_count
+ rules:
+ - 5638f7c0-ac70-491d-8465-2a65075e0d86
+ group-by:
+ - ComputerName
+ timespan: 1h
+ condition:
+ gte: 100
+```
+
+### Value Count (value_count)
+
+Counts values in a field defined by `field`.
+The resulting query must count field values separately for each group specified by group-by.
+The condition finally defines how many values must occur to generate a search hit.
+
+Requires:
+ - `group-by`
+ - `timespan`
+ - `condition`
+ - `field` in condition section.
+
+Simple example : Failed logon attempts with more than 100 different user accounts per source and destination at a day:
+
+```yaml
+title: Failed login
+id: 0e95725d-7320-415d-80f7-004da920fc12
+correlation:
+ type: value_count
+ rules:
+ - 5638f7c0-ac70-491d-8465-2a65075e0d86
+ group-by:
+ - ComputerName
+ - WorkstationName
+ timespan: 1d
+ condition:
+ field: User
+ gte: 100
+```
+
+### Temporal Proximity (temporal)
+
+All events defined by the rules referred by the rule field must occur in the time frame defined by timespan.
+The values of fields defined in group-by must all have the same value (e.g. the same host or user).
+
+The time frame should not be restricted to boundaries if this is not required by the given backend.
+
+Simple example : Reconnaissance commands defined in three Sigma rules are invoked in arbitrary order within 5 minutes on a system by the same user:
+
+```yaml
+correlation:
+type: temporal
+ rules:
+ - recon_cmd_a
+ - recon_cmd_b
+ - recon_cmd_c
+ group-by:
+ - ComputerName
+ - User
+ timespan: 5m
+```
+
+### Ordered Temporal Proximity (temporal_ordered)
+
+The *temporal_ordered* correlation type behaves like *temporal* and requires in addition that the events appear in the
+order provided in the *rule* attribute.
+
+Example: many failed logins as defined above are followed by a successful login by of the same user account within 1 hour:
+
+```yaml
+correlation:
+ type: temporal_ordered
+ rules:
+ - many_failed_logins
+ - successful_login
+ group-by:
+ - User
+ timespan: 1h
+```
+
+Note:
+Even if the rule many_failed_logins groups by the "ComputerName" field, the correlation rule only uses its own `group-by` "User".
+
+## Field Name Aliases
+
+Sometimes correlation of values in the same fields is not sufficient. E.g. a correlation rule might require to aggregate events that appear from a source address in one event and the same address as destination in another event. A Sigma correlation rule can contain an `aliases` attribute that defines an alias for different field names in events matched by different Sigma rules. The alias field names can then be referenced in `group-by` attributes and are resolved to their respective field names.
+
+Aliases are defined as follows:
+
+```
+aliases:
+ :
+ :
+[...]
+```
+
+The field names referenced in aliases must not necessarily appear in the Sigma rules, but in the events matched by the Sigma rules.
+
+`` is the name given by the `name` attribute. \
+The `name` attribute is optional in general, but has to be defined, if you want to use `aliases`.
+
+### Field Name Aliases Example
+
+The following correlation rule defines field name aliases `internal_ip` and `remote_ip` that are used in the `group-by` attribute. \
+The `internal_ip` alias references the field `destination.ip` in the events matched by the Sigma rule `internal_error` and `source.ip` in the events matched by the Sigma rule `new_network_connection`. \
+The correlation rule then only matches if the events appear with the same address in the respective fields of the events matching the referenced Sigma rules.
+
+Rule internal_error
+
+```yaml
+name: internal_error
+detection:
+ selection:
+ http.response.status_code: 500
+ condition: selection
+```
+
+Rule new_network_connection
+
+```yaml
+name: new_network_connection
+detection:
+ selection:
+ event.category: network
+ event.type: connection
+ event.outcome: success
+ condition: selection
+```
+
+The correlation rule
+```yaml
+title: —
+id: —
+correlation:
+ type: temporal
+ rules:
+ - internal_error
+ - new_network_connection
+ group-by:
+ - internal_ip
+ - remote_ip
+ timespan: 10s
+ aliases:
+ internal_ip:
+ internal_error: destination.ip
+ new_network_connection: source.ip
+ remote_ip:
+ internal_error: source.ip
+ new_network_connection: destination.ip
+```
+
+# Examples
+This section gives complete examples in order to make it easier for people new to Sigma to get started and for showcasing new features of the Sigma standard. Use them as a blueprint for your own ideas.
+
+## Failed Logins Followed by Successful Login
+
+The following Correlation describes a use case in which an attacker successfully performs a brute-force attack. This example helps in showcasing some highlights:
+ - You can use YAMLs multi document feature (`---`) to have everything grouped together in one file
+ - Rules can be referenced in a human-friendly way using their unique `name`.
+ - Correlations can be chained to express more complex use cases
+
+```yml
+title: Correlation - Multiple Failed Logins Followed by Successful Login
+id: b180ead8-d58f-40b2-ae54-c8940995b9b6
+status: experimental
+description: Detects multiple failed logins by a single user followed by a successful login of that user
+references:
+ - https://reference.com
+author: Florian Roth (Nextron Systems)
+date: 2023-06-16
+correlation:
+ type: temporal_ordered
+ rules:
+ - multiple_failed_login
+ - successful_login
+ group-by:
+ - User
+ timespan: 10m
+falsepositives:
+ - Unlikely
+level: high
+---
+title: Multiple failed logons
+id: a8418a5a-5fc4-46b5-b23b-6c73beb19d41
+description: Detects multiple failed logins within a certain amount of time
+name: multiple_failed_login
+correlation:
+ type: event_count
+ rules:
+ - failed_login
+ group-by:
+ - User
+ timespan: 10m
+ condition:
+ gte: 10
+---
+title: Single failed login
+id: 53ba33fd-3a50-4468-a5ef-c583635cfa92
+name: failed_login
+logsource:
+ product: windows
+ service: security
+detection:
+ selection:
+ EventID:
+ - 529
+ - 4625
+ condition: selection
+---
+title: Successful login
+id: 4d0a2c83-c62c-4ed4-b475-c7e23a9269b8
+description: Detects a successful login
+name: successful_login
+logsource:
+ product: windows
+ service: security
+detection:
+ selection:
+ EventID:
+ - 528
+ - 4624
+ condition: selection
+```
+
+# History
+
+* 2024-08-08 Specification v2.0.0
diff --git a/specification/sigma-filters-specification.md b/specification/sigma-filters-specification.md
new file mode 100644
index 0000000..67607a8
--- /dev/null
+++ b/specification/sigma-filters-specification.md
@@ -0,0 +1,177 @@
+# Sigma Filters Specification
+
+The following document defines the standardized global filter that can be used with Sigma rules.
+
+* Version 2.0.0
+* Release date 2024-08-08
+
+- [Introduction](#introduction)
+- [Global filter](#global-filter)
+ - [File Structure](#file-structure)
+ - [YAML File](#yaml-file)
+ - [Schema](#schema)
+ - [Syntax](#syntax)
+ - [Components](#components)
+ - [title](#title)
+ - [Identification](#identification)
+ - [Description](#description)
+ - [Date](#date)
+ - [Modified](#modified)
+ - [Log source](#log-source)
+ - [Global Filter](#global-filter-1)
+ - [Relative rules](#relative-rules)
+ - [filter selection](#filter-selection)
+ - [filter condition](#filter-condition)
+- [Examples](#examples)
+- [History](#history)
+
+
+# Introduction
+
+The purpose of Filter rules is to apply the same tuning on many rules with the goal to suppress matches of multiple rules. This is most commonly useful for environment specific tuning where a false positive prone application is used in an organization and its false positives are accepted.
+
+Example: A valid GPO script that triggers multiple Sigma rules.
+
+# Global filter
+
+## File Structure
+
+### YAML File
+
+To keep the file names interoperable use the following:
+
+- Length between 10 and 70 characters
+- Lowercase
+- No special characters only letters (a-z) and digits (0-9)
+- Use `_` instead of a space
+- Use `.yml` as a file extension
+
+As a best practice use the prefix `mf_`
+
+
+### Schema
+
+[Sigma Filters JSON Schema](/json-schema/sigma-filters-schema.json)
+
+
+### Syntax
+
+A Sigma global filter is a dedicated YAML document.
+Like Sigma rules, "Filter" rules have a `title` and a unique `id` to identify them.
+It has no `level` or `status` because its purpose is to enrich an existing Sigma rule.
+
+
+## Components
+
+### title
+
+**Attribute:** title
+
+**Use:** mandatory
+
+A brief title for the rule that should contain what the rule is supposed to detect (max. 256 characters)
+
+### Identification
+
+**Attribute:** id
+
+**Use:** optional
+
+Sigma meta-rules should be identified by a globally unique identifier in the *id* attribute.
+For this purpose randomly generated UUIDs (version 4) are recommended but not mandatory.
+
+An example for this is:
+
+```yml
+title: login brute force
+id: 0e95725d-7320-415d-80f7-004da920fc11
+```
+
+### Description
+
+**Attribute:** description
+
+**Use:** optional
+
+A short description of the rule and the malicious activity that can be detected (max. 65,535 characters)
+
+### Date
+
+**Attribute**: date
+
+**Use:** optional
+
+Creation date of the meta filter. \
+Use the ISO 8601 date with separator format : YYYY-MM-DD
+
+### Modified
+
+**Attribute**: modified
+
+**Use:** optional
+
+*Last* modification date of the meta filter. \
+Use the ISO 8601 date with separator format : YYYY-MM-DD
+
+### Log source
+
+**Attribute**: logsource
+
+**Use:** mandatory
+
+Read more on the `logsource` attribute in the [Sigma Rules Specification](/specification/sigma-rules-specification.md)
+
+
+### Global Filter
+
+**Attribute**: filter
+
+**Use:** mandatory
+
+#### Relative rules
+
+**Attribute:** rules
+
+**Use:** mandatory
+
+refers to one or multiple Sigma rules where to add the filter
+
+
+#### filter selection
+
+**Attribute**: selection
+
+**Use:** mandatory
+
+Read more on the 'detection' section in the [Sigma Rules Specification](/specification/sigma-rules-specification.md)
+
+#### filter condition
+
+**Attribute**: condition
+
+**Use:** mandatory
+
+Read more on the 'detection' field in the [Sigma Rules Specification](/specification/sigma-rules-specification.md)
+
+# Examples
+
+This section gives complete examples in order to make it easier for people new to Sigma to get started and for showcasing new features of the Sigma standard. Use them as a blueprint for your own ideas.
+
+```yaml
+title: Filter Administrator account
+description: The valid administrator account start with adm_
+logsource:
+ category: process_creation
+ product: windows
+filter:
+ rules:
+ - 6f3e2987-db24-4c78-a860-b4f4095a7095 # Data Compressed - rar.exe
+ - df0841c0-9846-4e9f-ad8a-7df91571771b # Login on jump host
+ selection:
+ User|startswith: 'adm_'
+ condition: selection
+```
+
+# History
+
+* 2024-08-08 Specification v2.0.0
diff --git a/specification/sigma-rules-specification.md b/specification/sigma-rules-specification.md
new file mode 100644
index 0000000..9fdd255
--- /dev/null
+++ b/specification/sigma-rules-specification.md
@@ -0,0 +1,739 @@
+# Sigma Rules Specification
+
+- Version 2.0.0
+- Release date 2024-08-08
+
+# Summary
+
+- [Summary](#summary)
+- [Yaml File](#yaml-file)
+ - [Filename](#filename)
+ - [Data](#data)
+- [Structure](#structure)
+- [Components](#components)
+ - [Title](#title)
+ - [Identification](#identification)
+ - [Name](#name)
+ - [Taxonomy](#taxonomy)
+ - [Status](#status)
+ - [Description](#description)
+ - [License](#license)
+ - [Author](#author)
+ - [References](#references)
+ - [Date](#date)
+ - [Modified](#modified)
+ - [Log Source](#log-source)
+ - [Detection](#detection)
+ - [Search-Identifier](#search-identifier)
+ - [General](#general)
+ - [String Wildcard](#string-wildcard)
+ - [Escaping](#escaping)
+ - [Lists](#lists)
+ - [Maps](#maps)
+ - [Field Usage](#field-usage)
+ - [Special Field Values](#special-field-values)
+ - [Field Existence](#field-existence)
+ - [Value Modifiers](#value-modifiers)
+ - [Modifier Types](#modifier-types)
+ - [Placeholders](#placeholders)
+ - [Standard Placeholders](#standard-placeholders)
+ - [Keywords search](#keywords-search)
+ - [Condition](#condition)
+ - [Fields](#fields)
+ - [FalsePositives](#falsepositives)
+ - [Level](#level)
+ - [Tags](#tags)
+ - [Scope](#scope)
+- [Rule Correlation](#rule-correlation)
+- [Sigma Filters](#sigma-filters)
+- [History](#history)
+
+# Yaml File
+
+## Filename
+
+To keep the file names interoperable use the following:
+
+- Length between 10 and 70 characters
+- All characters of the filename should be in lowercase
+- No special characters only letters (a-z) and digits (0-9)
+- Use `_` instead of a space
+- Use `.yml` as a file extension
+
+example:
+
+- lnx_auditd_change_file_time_attr.yml
+- web_cve_2022_33891_spark_shell_command_injection.yml
+- sysmon_file_block_exe.yml
+
+## Data
+
+The rule files are written in [yaml format](https://yaml.org/spec/1.2.2/)
+To keep the rules interoperable use:
+
+- UTF-8
+- LF for the line break (the Windows native editor uses CR-LF)
+- Indentation of 4 spaces
+- Lowercase keys (e.g. title, id, etc.)
+- Strings values use Single quotes `'` . If the string contains a single quote, double quotes may be used instead
+- Numeric values don't use any quotes
+
+Below is a simple Sigma rule example:
+
+```yaml
+title: Whoami Execution
+description: Detects a whoami.exe execution
+references:
+ - https://speakerdeck.com/heirhabarov/hunting-for-privilege-escalation-in-windows-environment
+author: Florian Roth
+date: 2019-10-23
+logsource:
+ category: process_creation
+ product: windows
+detection:
+ selection:
+ Image: 'C:\Windows\System32\whoami.exe'
+ condition: selection
+level: high
+```
+
+# Structure
+
+The rules consist of a few required sections and several optional ones.
+
+```yaml
+title
+id [optional]
+name [optional]
+related [optional]
+ - type {type-identifier}
+ id {rule-id}
+taxonomy [optional]
+status [optional]
+description [optional]
+license [optional]
+references [optional]
+author [optional]
+date [optional]
+modified [optional]
+logsource
+ 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 [optional]
+level [optional]
+tags [optional]
+scope [optional]
+...
+[arbitrary custom fields]
+```
+
+The Json schema is defined in [sigma-detection-rule-schema.json](/json-schema/sigma-detection-rule-schema.json)
+
+# Components
+
+## Title
+
+**Attribute:** title
+
+**Use:** mandatory
+
+A brief title for the rule that should contain what the rule is supposed to detect (max. 256 characters)
+
+## Identification
+
+**Attributes:** id, related
+
+**Use:** optional
+
+Sigma rules should be identified by a globally unique identifier in the *id* attribute. \
+For this purpose randomly generated UUIDs (version 4) is used. \
+An example for this is:
+
+```yml
+title: Test rule
+id: 929a690e-bef0-4204-a928-ef5e620d6fcc
+```
+
+It is better to write a rule with a new id for the following reasons:
+
+* Major changes in the rule. E.g. a different rule logic.
+* Derivation of a new rule from an existing or refinement of a rule in a way that both are kept
+ active.
+* Merging of rules.
+
+To be able to keep track of the relationships between detections, Sigma rules may also contain
+references to related rule identifiers in the *related* attribute. \
+This allows to define common relationships between detections as follows:
+
+```yml
+related:
+ - id: 08fbc97d-0a2f-491c-ae21-8ffcfd3174e9
+ type: derived
+ - id: 929a690e-bef0-4204-a928-ef5e620d6fcc
+ type: obsolete
+```
+
+Currently the following types are defined:
+
+* `derived`: The rule was derived from the referred rule or rules, which may remain active.
+* `obsolete`: The rule obsoletes the referred rule or rules, which aren't used anymore.
+* `merged`: The rule was merged from the referred rules. The rules may still exist and are in use.
+* `renamed`: The rule had previously the referred identifier or identifiers but was renamed for whatever
+ reason, e.g. from a private naming scheme to UUIDs, to resolve collisions etc. It's not
+ expected that a rule with this id exists anymore.
+* `similar`: Use to relate similar rules to each other (e.g. same detection content applied to different log sources, rule that is a modified version of another rule with a different level)
+
+## Name
+
+**Attribute:** name
+
+**Use:** optional
+
+`name` is a **unique** human-readable name that can be used instead of the *id* as a reference in correlation rules. \
+The goal is to improve the readability of correlation rules.
+
+## Taxonomy
+
+**Attribute:** taxonomy
+
+**Use:** optional
+
+Defines the taxonomy used in the Sigma rule. A taxonomy can define:
+
+* field names, example: `process_command_line` instead of `CommandLine`.
+* field values, example: a field `image_file_name` that only contains a file name like `example.exe` and is transformed into `ImageFile: *\\example.exe`.
+* logsource names, example: `category: ProcessCreation` instead of `category: process_creation`
+
+
+The Default taxonomy is `sigma`. \
+A custom taxonomy must be handled by the used tool or transformed into the default taxonomy.
+
+More information on the default taxonomy can be found in the [Sigma Taxonomy Appendix](/appendix/sigma-taxonomy-appendix.md) file.
+
+## Status
+
+**Attribute:** status
+
+**Use:** optional
+
+Declares the status of the rule:
+
+- `stable`: the rule is considered as stable and may be used in production systems or dashboards.
+- `test`: a mostly stable rule that could require some slight adjustments depending on the environement.
+- `experimental`: an experimental rule that could lead to false positives results or be noisy, but could also identify interesting
+ events.
+- `deprecated`: the rule is replaced or covered by another one. The link is established by the `related` field.
+- `unsupported`: the rule cannot be use in its current state (old correlation format, custom fields)
+
+## Description
+
+**Attribute:** description
+
+**Use:** optional
+
+A short and accurate description of the rule and the malicious or suspicious activity that can be detected (max. 65,535 characters)
+
+## License
+
+**Attribute:** license
+
+**Use:** optional
+
+License of the rule according the [SPDX ID specification](https://spdx.org/ids).
+
+## Author
+
+**Attribute**: author
+
+**Use:** optional
+
+Creator of the rule. (can be a name, nickname, twitter handle...etc) \
+If there is more than one, they are separated by a comma.
+
+## References
+
+**Attribute**: reference
+
+**Use:** optional
+
+References to the sources that the rule was derived from. \
+These could be blog articles, technical papers, presentations or even tweets.
+
+## Date
+
+**Attribute**: date
+
+**Use:** optional
+
+Creation date of the rule. \
+Use the ISO 8601 date with separator format : YYYY-MM-DD
+
+## Modified
+
+**Attribute**: modified
+
+**Use:** optional
+
+*Last* modification date of the rule. \
+Use the ISO 8601 date with separator format : YYYY-MM-DD
+
+Reasons to change the modified date:
+
+* changed title
+* changed detection section
+* changed level
+* changed logsource (rare)
+* changed status to `deprecated`
+
+## Log Source
+
+**Attribute**: logsource
+
+**Use:** mandatory
+
+This section describes the log data on which the detection is meant to be applied to. \
+It describes the log source, the platform, the application and the type that is required in the detection.
+
+It consists of three attributes that are evaluated automatically by the converters and an arbitrary number of optional elements. \
+We recommend using a "definition" value in cases in which further explanation is necessary.
+
+* category - examples: firewall, web, antivirus
+* product - examples: windows, apache, check point fw1
+* service - examples: sshd, applocker
+
+The `category` value is used to select all log files written of a logical group. \
+This may cover one or more sources of information depending on the system. \
+e.g. "antivirus" for the scan result, "webserver" for the web access logs.
+
+The `product` value is used to select all log outputs of a certain product. \
+It can be as generic as an operating system or the name of a particular software package. \
+e.g. "windows" will include "Security", "System", "Application" and the other like "AppLocker" and "Windows Defender"...
+
+The `service` value is used to select a more specific subset of logs. \
+e.g. "sshd" on Linux or the "Security" Eventlog on Windows systems.
+
+The `definition` can be used to describe the log source, including some information on the log verbosity level or configurations that have to be applied. \
+It is not automatically evaluated by the converters but gives useful information to readers on how to configure the source to provide the necessary events used in the detection.
+
+The `category`, `product` and `service` can be used alone or in any combination. \
+Their values are in **lower case** and spaces are replaced by a `_` , characters `.` and `-` are allowed.
+
+- Windows Channel "System" -> `service: system`
+- "Process Creation" -> `category: process_creation`
+- Cloud OneLogin events -> `service: onelogin.events`
+- Windows Channel "Microsoft-Windows-Windows Firewall With Advanced Security" -> `service: firewall-as`
+
+You can use the values of `category`, `product` and `service` to point the converters to a certain index. \
+In the configuration files, it can be defined that the category `firewall` converts to `( index=fw1* OR index=asa* )` during Splunk search conversion or the product `windows` converts to `"_index":"logstash-windows*"` in Elasticsearch queries.
+
+The advantages of this abstract approach is that it does not limit the rule to a specific telemetry source.
+
+Instead creating multiple rules for the different telemetry sources such as `Sysmon`, `Microsoft-Windows-Security-Auditing`, `Microsoft-Windows-Kernel-Process` and all the other possible product-specific sources, a generic log source may be used. \
+e.g.:
+
+```yml
+category: process_creation
+product: windows
+```
+
+More details can be found in the [Sigma Taxonomy Appendix](/appendix/sigma-taxonomy-appendix.md) file, and [SigmaHQ Logsource Guides](https://github.com/SigmaHQ/sigma/tree/master/documentation/logsource-guides)
+
+## Detection
+
+**Attribute**: detection
+
+**Use:** mandatory
+
+A set of search-identifiers that represent properties of searches on log data.
+
+### Search-Identifier
+
+A definition that can consist of two different data structures - lists and maps.
+
+### General
+
+* All values are treated as case-insensitive strings.
+* You can use wildcard characters `*` and `?` in strings (see also [escaping](#escaping) section below).
+* Regular expressions are case-sensitive by default.
+* You don't have to escape characters except the string quotation marks `'`.
+
+### String Wildcard
+
+Wildcards are used when part of the text is random.
+You can use :
+
+* `?` to replace a single mandatory character.
+* `*` to replace an unbounded length wildcard.
+
+example:
+
+* `progA.exe or progB.exe or ...` will be `prog?.exe`
+* `antivirus_V1.exe or antivirus_V21.2.1.exe or ...` will be `antivirus_V*.exe`
+
+Sigma has special modifiers to facilitate the search of unbounded strings
+
+* `*something` see [endswith modifier](#value-modifiers).
+* `something*` see [startswith modifier](#value-modifiers).
+* `*something*` see [contains modifier](#value-modifiers).
+
+### Escaping
+
+The backslash character `\` is used for escaping of wildcards `*` and `?` as well as the backslash character itself. Escaping of the backslash is necessary if it is followed by a wildcard depending on the desired result.
+
+Summarized, these are the following possibilities:
+
+* Plain backslash not followed by a wildcard can be expressed as single `\` or double backslash `\\`. For simplicity reasons the single notation is recommended.
+* A wildcard has to be escaped to be handled as a plain character. eg: `\*`, `\?`.
+* The backslash before a wildcard has to be escaped to handle the value as a backslash followed by a wildcard: `\\*`.
+* Three backslashes are necessary to escape both, the backslash and the wildcard and handle them as plain values: `\\\*`.
+* Three or four backslashes are handled as double backslash. Four is recommended for consistency reasons: `\\\\` results in the plain value `\\`.
+
+### Lists
+
+Lists can contain:
+
+* strings that are applied to the full log message and are linked with a logical 'OR'.
+* maps (see below). All map items of a list are logically linked with 'OR'.
+
+Example for list of strings: Matches on 'EvilService' **or** 'svchost.exe -n evil'
+
+```yml
+detection:
+ keywords:
+ - 'EVILSERVICE'
+ - 'svchost.exe -n evil'
+```
+
+Example for list of maps:
+
+```yml
+detection:
+ selection:
+ - Image|endswith: '\\example.exe'
+ - Description|contains: 'Test executable'
+```
+
+The example above matches an image value ending with `example.exe` **or** an executable with a description containing the string `Test executable`.
+
+### Maps
+
+Maps (or dictionaries) consist of key/value pairs, in which the key is a field in the log data and the value is a string or integer value. All elements of a map are joined with a logical 'AND'.
+
+Examples:
+
+The example below, matches on EventLog 'Security' **and** ( Event ID 517 **or** Event ID 1102 )
+
+```yml
+detection:
+ selection:
+ EventLog: Security
+ EventID:
+ - 517
+ - 1102
+ condition: selection
+```
+
+Matches on Eventlog 'Security' **and** Event ID 4679 **and** TicketOptions 0x40810000 **and** TicketEncryption 0x17
+
+```yml
+detection:
+ selection:
+ EventLog: Security
+ EventID: 4769
+ TicketOptions: '0x40810000'
+ TicketEncryption: '0x17'
+ condition: selection
+```
+
+### Field Usage
+
+1. For fields with existing field-mappings, use the mapped field name.
+
+Below is an example mapping `sigma` taxonomy name to built-in windows events:
+
+```yml
+fieldmappings:
+ Image: NewProcessName
+ ParentImage: ParentProcessName
+ Details: NewValue
+ ParentCommandLine: ProcessCommandLine
+ LogonId: SubjectLogonId
+```
+
+2. For new or rarely used fields, use them as they appear in the log source and strip all spaces. (This means: Only, if the field is not already mapped to another field name.) On Windows event log sources, use the field names of the details view as the general view might contain localized field names.
+
+Example:
+
+* `New Value` -> `NewValue`
+* `SAM User Account` -> `SAMUserAccount`
+
+3. Clarification on Windows events from the EventViewer:
+ 1. Some fields are defined as attributes of the XML tags (in the `` header of the events). The tag and attribute names have to be linked with an underscore character '_'.
+ 2. In the `` body of the event the field name is given by the `Name` attribute of the `Data` tag.
+
+Examples i:
+
+* `` will be `Provider_Name`
+* ` ` will be `Execution_ProcessID`
+
+Examples ii:
+
+* `NT AUTHORITY\SYSTEM` will be `User`
+* `MpKsl4eaa0a76` will be `ServiceName`
+
+### Special Field Values
+
+There are special field values that can be used.
+
+* An empty value is defined with `''`
+* A null value is defined with `null`
+
+The application of these values depends on the target SIEM system.
+
+To get an expression that say `not null` you have to create another selection and negate it in the condition.
+
+Example:
+
+```yml
+detection:
+ selection:
+ EventID: 4738
+ filter:
+ PasswordLastSet: null
+ condition: selection and not filter
+```
+
+### Field Existence
+
+In some case a field can be optional in the event. You can use the `exists` modifiers to check it.
+
+Example:
+
+```yml
+detection:
+ selection:
+ EventID: 4738
+ PasswordLastSet|exists: true
+ condition: selection
+```
+
+
+### Value Modifiers
+
+The values contained in Sigma rules can be modified by *value modifiers*. Value modifiers are
+appended after the field name with a pipe character `|` as separator and can also be chained, e.g.
+`fieldname|mod1|mod2: value`. The value modifiers are applied in the given order to the value.
+
+#### Modifier Types
+
+There are two types of value modifiers:
+
+* *Transformation modifiers* transform values into different values, like the two Base64 modifiers
+ mentioned below. Furthermore, this type of modifiers is also able to change the logical operation
+ between values. Transformation modifiers are generally backend-agnostic. Meaning: you can use them
+ with any backend.
+* *Type modifiers* change the type of a value. The value itself might also be changed by such a
+ modifier, but the main purpose is to tell the backend that a value should be handled differently
+ by the backend, e.g. it should be treated as regular expression when the *re* modifier is used.
+ Type modifiers must be supported by the backend.
+
+Generally, value modifiers work on single values and value lists. A value might also expand into
+multiple values.
+
+[List of modifiers](appendix/appendix_modifier.md)
+
+### Placeholders
+
+Placeholders are used as values that get their final meaning at conversion or usage time of the rule. This can be, but is not restricted to:
+
+* Replacement of placeholders with a single, multiple or-linked values or patterns. Example: the placeholder `%Servers%` is replaced with
+ the pattern `srv*` because servers are named so in the target environment.
+* Replacement of placeholders with a query expression. Example: replacement of `%servers%` with a lookup expression `LOOKUP(field, servers)`
+ that looks up the value of `field` in a lookup table `servers`.
+* Conducting lookups in tables or APIs while matching the Sigma rule that contains placeholders.
+
+From Sigma 1.1 placeholders are only handled if the *expand* modifier is applied to the value containing the placeholder.
+A plain percent character can be used by escaping it with a backslash. Examples:
+
+* `field: %name%` handles `%name%` as literal value.
+* `field|expand: %name%` handles `%name%` as placeholder.
+* `field|expand: \%plain%name%` handles `%plain` as plain value and `%name%` as placeholder.
+
+Placeholders must be handled appropriately by a tool that uses Sigma rules. If the tool isn't able to handle placeholders, it must reject the rule.
+
+#### Standard Placeholders
+
+The following standard placeholders should be used:
+
+* `%Administrators%`: Administrative user accounts
+* `%JumpServers%`: Server systems used as jump servers
+* `%Workstations%`: Workstation systems
+* `%Servers%`: Server systems
+* `%DomainControllers%`: Domain controller systems
+
+Custom placeholders can be defined as required.
+
+### Keywords search
+
+Contrary to the Field Usage, It's a matter of searching for keywords across an entire event. \
+They are built by using a list under a search-identifiers.
+
+```yml
+detection:
+ mimikatz_keywords:
+ - 'event::clear'
+ - 'event::drop'
+ condition: mimikatz_keywords
+```
+Give : "event::clear" **or** "event::drop"
+
+To have a **and** operator , we use the `'|all':` modifier
+```yaml
+detection:
+ keywords_cmdlet:
+ '|all':
+ - 'OabVirtualDirectory'
+ - ' -ExternalUrl '
+ condition: keywords_cmdlet
+```
+Give : "OabVirtualDirectory" **and** " -ExternalUrl "
+
+Some rules use simply `keywords` as search-identifiers name to facilitate identification.
+
+### Condition
+
+**Attribute**: condition
+
+**Use:** mandatory
+
+The condition is the most complex part of the specification and will be subject to change over time and arising requirements. In the first release it will support the following expressions.
+
+- Logical AND/OR
+
+ `keywords1 or keywords2`
+
+- 1/all of them
+
+ Logical OR (`1 of them`) or AND (`all of them`) across all defined search identifiers not starting with an underscore `_`. The search identifiers
+ themselves are logically linked with their default behavior for maps (AND) and lists (OR).
+
+ The usage of `all of them` is discouraged, as it prevents the possibility of downstream users of a rule to generically filter unwanted matches. See `all of {search-identifier-pattern}` in the next section as the preferred method.
+
+ Example: `1 of them` means that one of the defined search identifiers must appear. A search identifier `_example`
+ wouldn't be included because detections starting with underscores are excluded by convention.
+
+- 1/all of search-identifier-pattern
+
+ Same as *1/all of them*, but restricted to matching search identifiers. Matching is done with * wildcards (any number of characters) at arbitrary positions in the pattern.
+
+ Examples:
+ - `all of selection*`
+ - `1 of selection* and keywords`
+ - `1 of selection* and not 1 of filter*`
+
+- Negation with 'not'
+
+ `keywords and not filters`
+
+- Brackets
+
+ `selection1 and (keywords1 or keywords2)`
+
+Operator Precedence (least to most binding)
+
+- or
+- and
+- not
+- x of search-identifier
+- ( expression )
+
+The condition can be a list, in this case, each of them generates a query
+They are logically linked with OR.
+
+## Fields
+
+**Attribute**: fields
+
+**Use:** optional
+
+A list of log fields that could be interesting in further analysis of the event and should be displayed to the analyst.
+
+## FalsePositives
+
+**Attribute**: falsepositives
+
+**Use:** optional
+
+A list of known false positives that may occur.
+
+## Level
+
+**Attribute**: level
+
+**Use:** optional
+
+The level field contains one of five string values. It describes the criticality of a triggered rule. While `low` and `medium` level events have an informative character, events with `high` and `critical` level should lead to immediate reviews by security analysts.
+
+- `informational`: Rule is intended for enrichment of events, e.g. by tagging them. No case or alerting should be triggered by such rules because it is expected that a huge amount of events will match these rules.
+- `low`: Notable event but rarely an incident. Low rated events can be relevant in high numbers or combination with others. Immediate reaction shouldn't be necessary, but a regular review is recommended.
+- `medium`: Relevant event that should be reviewed manually on a more frequent basis.
+- `high`: Relevant event that should trigger an internal alert and requires a prompt review.
+- `critical`: Highly relevant event that indicates an incident. Critical events should be reviewed immediately. It is used only for cases in which probability borders certainty.
+
+## Tags
+
+**Attribute**: tags
+
+**Use:** optional
+
+A Sigma rule can be categorized with tags. Tags should generally follow this syntax:
+
+* Character set: lower-case letters, numerals, underscores and hyphens
+* no spaces
+* Tags are namespaced, the dot is used as separator. e.g. *attack.t1234* refers to technique 1234 in the namespace *attack*; Namespaces may also be nested
+* Keep tags short, e.g. numeric identifiers instead of long sentences
+* Feel free to send pull request or issues with proposals for new tags
+
+[More information about tags](/appendix/sigma-tags-appendix.md)
+
+## Scope
+
+**Attribute**: scope
+
+**Use:** optional
+
+A list of the intended scopes of the rule. This would allow you to define if a rule is meant to trigger on specific set of types of machines that might have a specific software installed.
+
+For example , if you have a rule for a registry key being set, where the key only exists on windows server installations./
+A scope with the value `server` can be added to limit this rule only to Windows Servers.
+
+# Rule Correlation
+
+Correlation allows several events to be linked together. /
+To make it easier to read these corelation rules, they are written in meta-rules.
+
+Check out the [Sigma Correlation Rules Specification](/specification/sigma-correlation-rules-specification.md) for more details.
+
+# Sigma Filters
+
+To adapt the rules to the environment, it is sometimes useful to put the same exclusion in several rules. /
+Their maintenance can become difficult, with a meta-filter it is possible to write it in a single place.
+
+Check out the [Sigma Filters Specification](/specification/sigma-filters-specification.md) for more details.
+
+# History
+
+* 2024-08-08 Specification v2.0.0
+* 2023-06-29 Specification v1.0.4
+* 2022-12-28 Specification v1.0.3
+
+
+