-## 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 rules format specifications is described in the file [Sigma_specification](Sigma_specification.md)
-The Sigma Meta rules format specifications is described in the file [Sigma_meta_rules](Sigma_meta_rules.md)
-The Sigma Meta filter format specifications is described in the file [Sigma_meta_filter](Sigma_meta_filter.md)
+[Specification](./specification/) will contain markdown files describing the Sigma specification format in details.
-There exists other files in the repository to describe the different modifiers, 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.
-- [appendix_modifier](appendix/appendix_modifier.md) is a document that defines the different modifiers that can be used in a Sigma rule.
-- [appendix_tags](appendix/appendix_tags.md) is a document that defines the standardized tags that can be used to categorize the different Sigma rules.
-- [appendix_taxonomy](appendix/appendix_taxonomy.md) is a document that defines the different field names and log sources that should be used to ensure sharable rules.
+### JSON Schema
-## SigmaHQ
+[Json-Schema](./json-schema/) will contain a list of JSON schemas for the following.
-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) under SigmaHQ
+* [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)
-[SigmaHQ Filename Normalisation](/sigmahq/Sigmahq_filename_rule.md)
-[SigmaHQ Rule Conventions](/sigmahq/sigmahq_conventions.md)
-[SigmaHQ Title Normalisation](/sigmahq/sigmahq_title_rule.md)
+### Appendix
+
+[Appendix](./appendix/) will contain additional files providing additional details to certain fields of a Sigma rule
+
+* [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.
+
+### SigmaHQ
+
+[SigmaHQ](./sigmahq/) will contain markdown files that describe rules and recommendations that are applied to the rules hosted in SigmaHQ main rule repository.
+
+> **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)
+
+* [SigmaHQ Rule Convention](/sigmahq/sigmahq-rule-convention.md)
+* [SigmaHQ Filename Convention](/sigmahq/sigmahq-filename-convention.md)
+* [SigmaHQ Title Convention](/sigmahq/sigmahq-title-convention.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/V2_changes.md b/V2_changes.md
deleted file mode 100644
index e1e89c1..0000000
--- a/V2_changes.md
+++ /dev/null
@@ -1,27 +0,0 @@
-The following is a non-exhaustive list of changes between the v1 and v2 specifications.
-
-
-# Sigmac
-
-Warning `sigmac` will not be able to convert all the specification of this version. \
-Only `pySigma` and the corresponding `sigma-cli` provide full support for version 2.
-
-# Date
-
-Legacy sigma rule use YYYY/MM/DD or YYYY-MM-DD format for the date. \
-Version 2 only use ISO 8601 with separator format : YYYY-MM-DD
-
-# New Modifiers
-
-- `windash` : creates all possible permutations of the `-` and `/` characters. Windows command line flags can often be indicated by both characters. Using the `windash` modifier converts `-` values into `/` and vice versa and uses all possible permutation of strings in the selection. This will be used for all `CommandLine` fields in windows > `process_creation` rules.
-- `exists` that allows to define that a certain field exists or doesn't exists in a log event by providing
- a boolean value. Currently we use filters with `field: null` as a workaround for this purpose, which is less descriptive.
-
-
-# Correlation
-
-- Remove aggregation expression in Sigma rule file, see [Sigma meta rules](/Sigma_meta_rules.md)
-
-# Global filter
-
-- Adds the ability to make filter rule files, see [Sigma meta filter](/Sigma_meta_filter.md)
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/appendix_modifier.md b/appendix/sigma-modifiers-appendix.md
similarity index 67%
rename from appendix/appendix_modifier.md
rename to appendix/sigma-modifiers-appendix.md
index ed12940..8bf7afa 100644
--- a/appendix/appendix_modifier.md
+++ b/appendix/sigma-modifiers-appendix.md
@@ -1,88 +1,87 @@
-# Modifiers
-
-The following document defines the standardized modifiers that can be used in Sigma.
-
-* Version 2.0.0
-* Release date 2024-01-01
-
-## 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.
-* `cased`: Values are applied case sensitively. Default Sigma behaviour is case-insensitive matching.
-
-### String only
-
-* `windash`: Creates all possible permutations of the `-` and `/` characters. Windows command line flags can often be indicated by both characters. Using the `windash` modifier converts `-` values into `/` and vice versa 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
- * `i`: (insensitive) `re` sub-modifier to enable case-sensitive matching.
- * `m`: (multi line) `re` sub-modifier to match across multiple lines. `^` /`$` match the start/end of line.
- * `s`: (single line) `re` sub-modifier 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
-
-
-### 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.
-
-* `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)
-
-
-## 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
-* 2023-05-27
- * Update from PySigma 0.7.6
- * Add `fieldref`
-* 2023-05-21 v1.0.3
- * Creation of the file
-* 2017 Sigma creation
+# Modifiers
+
+The following document defines the standardized modifiers that can be used in Sigma.
+
+* Version 2.0.0
+* Release date 2024-08-12
+
+## 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-12 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/appendix/appendix_tags.md b/appendix/sigma-tags-appendix.md
similarity index 66%
rename from appendix/appendix_tags.md
rename to appendix/sigma-tags-appendix.md
index 04d7ae7..776f8fa 100644
--- a/appendix/appendix_tags.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.2.0
-* Release date 2023-11-23
+* Version 2.0.0
+* Release date 2024-08-12
## Summary
@@ -19,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
@@ -32,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
@@ -61,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
@@ -69,29 +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-11-23 Tags V1.2.0
+
+* 2024-08-12 Tags Appendix v2.0.0
+* 2023-11-23 Tags Appendix v1.2.0
* Add Summiting the Pyramid
-* 2023-06-20 Tags V1.1.0
+* 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/appendix/appendix_taxonomy.md b/appendix/sigma-taxonomy-appendix.md
similarity index 91%
rename from appendix/appendix_taxonomy.md
rename to appendix/sigma-taxonomy-appendix.md
index 60a39f2..717500e 100644
--- a/appendix/appendix_taxonomy.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-12
## Summary
@@ -151,25 +151,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 +183,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 +315,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-12 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 +348,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/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/schema/meta-rule-schema.json b/json-schema/sigma-correlation-rules-schema.json
similarity index 96%
rename from schema/meta-rule-schema.json
rename to json-schema/sigma-correlation-rules-schema.json
index 53e14a9..e694314 100644
--- a/schema/meta-rule-schema.json
+++ b/json-schema/sigma-correlation-rules-schema.json
@@ -1,204 +1,204 @@
-{
- "$schema": "https://json-schema.org/draft/2020-12/schema",
- "title": "Sigma Meta rule specification V2.0.0 (2024/xx/xx)",
- "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"
- }
- }
-}
\ No newline at end of file
+{
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "title": "Sigma Meta rule specification V2.0.0 (2024-08-12)",
+ "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/schema/detection-rule-schema.json b/json-schema/sigma-detection-rule-schema.json
similarity index 98%
rename from schema/detection-rule-schema.json
rename to json-schema/sigma-detection-rule-schema.json
index 629ad47..22bcdb0 100644
--- a/schema/detection-rule-schema.json
+++ b/json-schema/sigma-detection-rule-schema.json
@@ -1,6 +1,6 @@
{
- "$schema": "https://json-schema.org/draft/2020-12/schema",
- "title": "Sigma rule specification V2.0.0 (2024/xx/xx)",
+ "$schema": "https://json-schema.org/draft/2020-12/schema#",
+ "title": "Sigma rule specification V2.0.0 (2024-08-12)",
"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"
},
{
diff --git a/schema/meta-filter-schema.json b/json-schema/sigma-filters-schema.json
similarity index 93%
rename from schema/meta-filter-schema.json
rename to json-schema/sigma-filters-schema.json
index f6e4525..63084be 100644
--- a/schema/meta-filter-schema.json
+++ b/json-schema/sigma-filters-schema.json
@@ -1,114 +1,114 @@
-{
- "$schema": "http://json-schema.org/draft-07/schema#",
- "title": "Sigma Global Filter specification V2.0.0 (2024/01/01)",
- "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"
- }
- }
- }
- }
-}
+{
+ "$schema": "https://json-schema.org/draft/2020-12/schema#",
+ "title": "Sigma Global Filter specification V2.0.0 (2024-08-12)",
+ "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 76%
rename from sigmahq/sigmahq_conventions.md
rename to sigmahq/sigmahq-rule-convention.md
index d221000..962d691 100644
--- a/sigmahq/sigmahq_conventions.md
+++ b/sigmahq/sigmahq-rule-convention.md
@@ -1,7 +1,8 @@
# 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).
+
+For the general Sigma rule specification please read see [this](/specification/sigma_rules.md)
## Summary
@@ -54,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
@@ -77,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: |
@@ -88,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
@@ -116,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:
@@ -131,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/Sigma_meta_rules.md b/specification/sigma-correlation-rules-specification.md
similarity index 83%
rename from Sigma_meta_rules.md
rename to specification/sigma-correlation-rules-specification.md
index 4ffbca7..c5296e7 100644
--- a/Sigma_meta_rules.md
+++ b/specification/sigma-correlation-rules-specification.md
@@ -1,9 +1,9 @@
-# Sigma Correlation
+# 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/09/01
+* Release date 2024-08-12
- [Introduction](#introduction)
- [Compatibility](#compatibility)
@@ -44,13 +44,13 @@ The following document defines the standardized correlation that can be used in
# Introduction
-Sometimes you need more advanced searches than simple selections.
-For that you can use meta-rules that correlate multiple Sigma rules.
+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 required a feature that is only supported partially by the target 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
@@ -68,7 +68,7 @@ The conversion backend should issue a warning to raise the user’s awareness ab
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.
+* 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
@@ -84,9 +84,9 @@ Sigma correlations are not based on this approach for the following reasons:
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
+* 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
@@ -100,7 +100,7 @@ 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)
+- No special characters, only letters (a-z) and digits (0-9)
- Use `_` instead of a space
- Use `.yml` as a file extension
@@ -109,12 +109,12 @@ As a best practice use the prefix `mr_`.
### Schema
-[meta-rule-schema](/schema/meta-rule-schema.json)
+[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.
+Like Sigma rules , correlation rules have a title and a unique id to identify them.
## Components
@@ -174,7 +174,7 @@ These could be blog articles, technical papers, presentations or even tweets.
**Use:** optional
Creation date of the meta rule. \
-Use the ISO 8601 date with separator format : YYYY-MM-DD
+Use the ISO 8601 date with separator format: `YYYY-MM-DD`
### Modified
@@ -183,7 +183,7 @@ Use the ISO 8601 date with separator format : YYYY-MM-DD
**Use:** optional
*Last* modification date of the meta rule. \
-Use the ISO 8601 date with separator format : YYYY-MM-DD
+Use the ISO 8601 date with separator format : `YYYY-MM-DD`
### Correlation section
@@ -230,6 +230,8 @@ correlation:
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
@@ -253,7 +255,6 @@ The following format must be used: `number + letter (in lowercase)`
- Xh hours
- Xd days
-
example for 1h30 : `timespan: 90m`
#### Condition
@@ -284,7 +285,7 @@ condition:
gte: 100
```
-To select a range , you can use the map AND
+To define a range, you can use the conjunction 'AND' in the mapping.
Example "101 to 200":
```yaml
@@ -332,14 +333,14 @@ Simple example : More than or equal 100 failed login attempts to a destination h
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
+ type: event_count
+ rules:
+ - 5638f7c0-ac70-491d-8465-2a65075e0d86
+ group-by:
+ - ComputerName
+ timespan: 1h
+ condition:
+ gte: 100
```
### Value Count (value_count)
@@ -360,16 +361,16 @@ Simple example : Failed logon attempts with more than 100 different user account
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
+ type: value_count
+ rules:
+ - 5638f7c0-ac70-491d-8465-2a65075e0d86
+ group-by:
+ - ComputerName
+ - WorkstationName
+ timespan: 1d
+ condition:
+ field: User
+ gte: 100
```
### Temporal Proximity (temporal)
@@ -384,14 +385,14 @@ Simple example : Reconnaissance commands defined in three Sigma rules are invoke
```yaml
correlation:
type: temporal
- rules:
- - recon_cmd_a
- - recon_cmd_b
- - recon_cmd_c
- group-by:
- - ComputerName
- - User
- timespan: 5m
+ rules:
+ - recon_cmd_a
+ - recon_cmd_b
+ - recon_cmd_c
+ group-by:
+ - ComputerName
+ - User
+ timespan: 5m
```
### Ordered Temporal Proximity (temporal_ordered)
@@ -403,13 +404,13 @@ Example: many failed logins as defined above are followed by a successful login
```yaml
correlation:
- type: temporal_ordered
- rules:
- - many_failed_logins
- - successful_login
- group-by:
- - User
- timespan: 1h
+ type: temporal_ordered
+ rules:
+ - many_failed_logins
+ - successful_login
+ group-by:
+ - User
+ timespan: 1h
```
Note:
@@ -444,9 +445,9 @@ Rule internal_error
```yaml
name: internal_error
detection:
- selection:
- http.response.status_code: 500
- condition: selection
+ selection:
+ http.response.status_code: 500
+ condition: selection
```
Rule new_network_connection
@@ -454,11 +455,11 @@ Rule new_network_connection
```yaml
name: new_network_connection
detection:
- selection:
- event.category: network
- event.type: connection
- event.outcome: success
- condition: selection
+ selection:
+ event.category: network
+ event.type: connection
+ event.outcome: success
+ condition: selection
```
The correlation rule
@@ -466,21 +467,21 @@ The correlation rule
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
+ 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
@@ -503,13 +504,13 @@ references:
author: Florian Roth (Nextron Systems)
date: 2023-06-16
correlation:
- type: temporal_ordered
- rules:
- - multiple_failed_login
- - successful_login
- group-by:
- - User
- timespan: 10m
+ type: temporal_ordered
+ rules:
+ - multiple_failed_login
+ - successful_login
+ group-by:
+ - User
+ timespan: 10m
falsepositives:
- Unlikely
level: high
@@ -519,43 +520,43 @@ 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
+ 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
+ product: windows
+ service: security
detection:
- selection:
- EventID:
- - 529
- - 4625
- condition: selection
+ 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
+ product: windows
+ service: security
detection:
- selection:
- EventID:
- - 528
- - 4624
- condition: selection
+ selection:
+ EventID:
+ - 528
+ - 4624
+ condition: selection
```
# History
-* 2024/09/01 Specification V2.0.0
- * First release
\ No newline at end of file
+
+* 2024-08-12 Specification v2.0.0
diff --git a/Sigma_meta_filter.md b/specification/sigma-filters-specification.md
similarity index 82%
rename from Sigma_meta_filter.md
rename to specification/sigma-filters-specification.md
index 420c612..d07a7c9 100644
--- a/Sigma_meta_filter.md
+++ b/specification/sigma-filters-specification.md
@@ -1,9 +1,9 @@
-# Sigma Filter
+# 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/09/01
+* Release date 2024-08-12
- [Introduction](#introduction)
- [Global filter](#global-filter)
@@ -29,9 +29,11 @@ The following document defines the standardized global filter that can be used w
# 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
@@ -49,7 +51,7 @@ As a best practice use the prefix `mf_`
### Schema
-[meta-filter-schema](/schema/meta-filter-schema.json)
+[Sigma Filters JSON Schema](/json-schema/sigma-filters-schema.json)
### Syntax
@@ -117,7 +119,7 @@ Use the ISO 8601 date with separator format : YYYY-MM-DD
**Use:** mandatory
-See log source in [sigma specification](Sigma_specification.md)
+Read more on the `logsource` attribute in the [Sigma Rules Specification](/specification/sigma-rules-specification.md)
### Global Filter
@@ -141,7 +143,7 @@ refers to one or multiple Sigma rules where to add the filter
**Use:** mandatory
-See Detection in [sigma specification](Sigma_specification.md)
+Read more on the 'detection' section in the [Sigma Rules Specification](/specification/sigma-rules-specification.md)
#### filter condition
@@ -149,7 +151,7 @@ See Detection in [sigma specification](Sigma_specification.md)
**Use:** mandatory
-See Detection in [sigma specification](Sigma_specification.md)
+Read more on the 'detection' field in the [Sigma Rules Specification](/specification/sigma-rules-specification.md)
# Examples
@@ -162,14 +164,14 @@ 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
+ 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/09/01 Specification V2.0.0
- * First release
\ No newline at end of file
+
+* 2024-08-12 Specification v2.0.0
diff --git a/Sigma_specification.md b/specification/sigma-rules-specification.md
similarity index 81%
rename from Sigma_specification.md
rename to specification/sigma-rules-specification.md
index 2472178..cd74a9b 100644
--- a/Sigma_specification.md
+++ b/specification/sigma-rules-specification.md
@@ -1,9 +1,7 @@
-# Sigma specification
+# Sigma Rules Specification
- Version 2.0.0
-- Release date 2024/09/01
-
-Take a look at [V1-V2 changes](V2_changes.md)
+- Release date 2024-08-12
# Summary
@@ -34,7 +32,7 @@ Take a look at [V1-V2 changes](V2_changes.md)
- [Maps](#maps)
- [Field Usage](#field-usage)
- [Special Field Values](#special-field-values)
- - [Field Existance](#field-existance)
+ - [Field Existence](#field-existence)
- [Value Modifiers](#value-modifiers)
- [Modifier Types](#modifier-types)
- [Placeholders](#placeholders)
@@ -47,7 +45,7 @@ Take a look at [V1-V2 changes](V2_changes.md)
- [Tags](#tags)
- [Scope](#scope)
- [Rule Correlation](#rule-correlation)
-- [Global filter](#global-filter)
+- [Sigma Filters](#sigma-filters)
- [History](#history)
# Yaml File
@@ -80,7 +78,7 @@ To keep the rules interoperable use:
- 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
-Simple Sigma example
+Below is a simple Sigma rule example:
```yaml
title: Whoami Execution
@@ -113,6 +111,7 @@ related [optional]
taxonomy [optional]
status [optional]
description [optional]
+license [optional]
references [optional]
author [optional]
date [optional]
@@ -139,7 +138,7 @@ scope [optional]
[arbitrary custom fields]
```
-The Json schema is defined in [sigma-schema.json](schema/sigma-schema.json)
+The Json schema is defined in [sigma-detection-rule-schema.json](/json-schema/sigma-detection-rule-schema.json)
# Components
@@ -171,7 +170,7 @@ 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.
-* Merge of rules.
+* 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. \
@@ -182,13 +181,13 @@ related:
- id: 08fbc97d-0a2f-491c-ae21-8ffcfd3174e9
type: derived
- id: 929a690e-bef0-4204-a928-ef5e620d6fcc
- type: obsoletes
+ type: obsolete
```
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.
+* `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
@@ -196,7 +195,8 @@ Currently the following types are defined:
* `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
-**Attributes:** name
+
+**Attribute:** name
**Use:** optional
@@ -219,7 +219,7 @@ Defines the taxonomy used in the Sigma rule. A taxonomy can define:
The Default taxonomy is `sigma`. \
A custom taxonomy must be handled by the used tool or transformed into the default taxonomy.
-More information in [Appendix Taxonomy](appendix/appendix_taxonomy.md)
+More information on the default taxonomy can be found in the [Sigma Taxonomy Appendix](/appendix/sigma-taxonomy-appendix.md) file.
## Status
@@ -230,11 +230,11 @@ More information in [Appendix Taxonomy](appendix/appendix_taxonomy.md)
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.
+- `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 (special correlation log, home-made fields)
+- `unsupported`: the rule cannot be use in its current state (old correlation format, custom fields)
## Description
@@ -242,7 +242,7 @@ Declares the status of the rule:
**Use:** optional
-A short description of the rule and the malicious activity that can be detected (max. 65,535 characters)
+A short and accurate description of the rule and the malicious or suspicious activity that can be detected (max. 65,535 characters)
## License
@@ -267,7 +267,7 @@ If there is more than one, they are separated by a comma.
**Use:** optional
-References to the source that the rule was derived from. \
+References to the sources that the rule was derived from. \
These could be blog articles, technical papers, presentations or even tweets.
## Date
@@ -289,6 +289,7 @@ Use the ISO 8601 date with separator format : YYYY-MM-DD
Use the ISO 8601 date with separator format : YYYY-MM-DD
Reasons to change the modified date:
+
* changed title
* changed detection section
* changed level
@@ -325,19 +326,20 @@ 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. \
+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.
+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 abstractive approach is that it does not limit the rule to a specific telemetry.
+The advantages of this abstract approach is that it does not limit the rule to a specific telemetry source.
-Instead of definition of multiple rules for Sysmon, Windows Security Auditing and all other possible product-specific, a generic log sources may be used. \
+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
@@ -345,9 +347,7 @@ category: process_creation
product: windows
```
-The rule can be use with Sysmon, Windows Security Auditing and possible product-specific like EDR.
-
-More information in [appendix_taxonomy](appendix/appendix_taxonomy.md) and [SigmaHQ documentation](https://github.com/SigmaHQ/sigma/blob/master/documentation/README.md)
+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
@@ -363,29 +363,29 @@ 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 `'`
+* 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
+* `?` to replace a single mandatory character.
+* `*` to replace an unbounded length wildcard.
-example :
+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)
+* `*something` see [endswith modifier](#value-modifiers).
+* `something*` see [startswith modifier](#value-modifiers).
+* `*something*` see [contains modifier](#value-modifiers).
### Escaping
@@ -394,9 +394,9 @@ The backslash character `\` is used for escaping of wildcards `*` and `?` as wel
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: `\*`
-* 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: `\\\*`
+* 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
@@ -410,21 +410,21 @@ Example for list of strings: Matches on 'EvilService' **or** 'svchost.exe -n evi
```yml
detection:
- keywords:
- - 'EVILSERVICE'
- - 'svchost.exe -n evil'
+ keywords:
+ - 'EVILSERVICE'
+ - 'svchost.exe -n evil'
```
Example for list of maps:
```yml
detection:
- selection:
- - Image|endswith: '\\example.exe'
- - Description|contains: 'Test executable'
+ 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`
+The example above matches an image value ending with `example.exe` **or** an executable with a description containing the string `Test executable`.
### Maps
@@ -432,35 +432,35 @@ Maps (or dictionaries) consist of key/value pairs, in which the key is a field i
Examples:
-Matches on Eventlog 'Security' **and** ( Event ID 517 **or** Event ID 1102 )
+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
+ 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
+ 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 mapping `sigma` taxonomy name to windows event build in:
+Below is an example mapping `sigma` taxonomy name to built-in windows events:
```yml
fieldmappings:
@@ -473,7 +473,8 @@ fieldmappings:
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.
-Examples:
+Example:
+
* `New Value` -> `NewValue`
* `SAM User Account` -> `SAMUserAccount`
@@ -506,15 +507,14 @@ Example:
```yml
detection:
- selection:
- EventID: 4738
- filter:
- PasswordLastSet: null
-condition:
- selection and not filter
+ selection:
+ EventID: 4738
+ filter:
+ PasswordLastSet: null
+ condition: selection and not filter
```
-### Field Existance
+### Field Existence
In some case a field can be optional in the event. You can use the `exists` modifiers to check it.
@@ -522,10 +522,10 @@ Example:
```yml
detection:
- selection:
- EventID: 4738
- PasswordLastSet|exists: true
-condition: selection
+ selection:
+ EventID: 4738
+ PasswordLastSet|exists: true
+ condition: selection
```
@@ -591,21 +591,21 @@ They are built by using a list under a search-identifiers.
```yml
detection:
- mimikatz_keywords:
- - 'event::clear'
- - 'event::drop'
- condition: mimikatz_keywords
+ 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
+ keywords_cmdlet:
+ '|all':
+ - 'OabVirtualDirectory'
+ - ' -ExternalUrl '
+ condition: keywords_cmdlet
```
Give : "OabVirtualDirectory" **and** " -ExternalUrl "
@@ -626,7 +626,7 @@ The condition is the most complex part of the specification and will be subject
- 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 behaviour for maps (AND) and lists (OR).
+ 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.
@@ -697,7 +697,7 @@ The level field contains one of five string values. It describes the criticality
**Use:** optional
-A Sigma rule can be categorised with tags. Tags should generally follow this syntax:
+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
@@ -705,7 +705,7 @@ A Sigma rule can be categorised with tags. Tags should generally follow this syn
* 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/appendix_tags.md)
+[More information about tags](/appendix/sigma-tags-appendix.md)
## Scope
@@ -713,29 +713,27 @@ A Sigma rule can be categorised with tags. Tags should generally follow this syn
**Use:** optional
-A list of intended scope of the rule.
+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 , you have a rule for a registry key with exist only on windows server./
-The logsource will be `category: registry_set` and the scope `server`
+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.
-See [Sigma Meta Rules](Sigma_meta_rules.md)
+Check out the [Sigma Correlation Rules Specification](/specification/sigma-correlation-rules-specification.md) for more details.
-# Global filter
+# 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.
-See [Sigma Meta Filter](Sigma_meta_filter.md)
+Check out the [Sigma Filters Specification](/specification/sigma-filters-specification.md) for more details.
# History
-* 2024/09/01 Specification V2.0.0
- * First release
-* 2023/06/29 Specification V1.0.4
- * Complete the information for multiple conditions
-* 2022/12/28 Specification V1.0.3
- * Add missing `timeframe` attribute
+
+* 2024-08-12 Specification v2.0.0
+* 2023-06-29 Specification v1.0.4
+* 2022-12-28 Specification v1.0.3
+
+
+