Sigma Specification V2.2.0 Release

.github/ISSUE_TEMPLATE/sigma-enhancement-proposal.yml

@@ -0,0 +1,152 @@
+name: "Sigma Enhancement Proposal (SEP)"
+description: "Propose a new feature or enhancement to the Sigma specification"
+title: "SEP: [Brief Title]"
+labels: ["enhancement", "SEP", "review-required"]
+assignees: []
+body:
+  - type: markdown
+    attributes:
+      value: |
+        ## Sigma Enhancement Proposal (SEP)
+        Thank you for proposing an enhancement to the Sigma specification! Please fill out this template completely to help maintainers and the community evaluate your proposal.
+
+        **Note:** The SEP number will be assigned by maintainers during the review process.
+
+  - type: input
+    id: author
+    attributes:
+      label: "Author(s)"
+      description: "Your name and GitHub username"
+      placeholder: "John Doe (@johndoe)"
+    validations:
+      required: true
+
+  - type: dropdown
+    id: sep_type
+    attributes:
+      label: "SEP Type"
+      description: "What type of enhancement is this?"
+      options:
+        - "New Detection Logic (correlation types, aggregation functions)"
+        - "New Field Modifiers (transformations, comparisons)"
+        - "New Rule Fields (metadata, configuration options)"
+        - "Schema Extensions (logsource categories)"
+        - "Format Enhancements (YAML structure, syntax improvements)"
+    validations:
+      required: true
+
+  - type: textarea
+    id: abstract
+    attributes:
+      label: "Abstract"
+      description: "A brief summary (200 words max) of what problem this solves and how"
+      placeholder: "This proposal introduces..."
+    validations:
+      required: true
+
+  - type: textarea
+    id: problem_statement
+    attributes:
+      label: "Problem Statement"
+      description: "Describe the current limitation or problem this proposal addresses"
+      placeholder: "Currently, Sigma rules cannot..."
+    validations:
+      required: true
+
+  - type: textarea
+    id: use_cases
+    attributes:
+      label: "Use Cases"
+      description: "Provide 2-3 concrete use cases that would benefit from this enhancement"
+      placeholder: |
+        1. Detection engineers need to...
+        2. SIEM administrators want to...
+        3. Rule developers require...
+    validations:
+      required: true
+
+  - type: textarea
+    id: specification
+    attributes:
+      label: "Detailed Specification"
+      description: "Technical specification of the proposed changes"
+      placeholder: "This proposal adds the following new fields/keywords..."
+    validations:
+      required: true
+
+  - type: textarea
+    id: syntax_examples
+    attributes:
+      label: "Syntax Examples"
+      description: "Provide concrete YAML examples of how the new feature would be used"
+      placeholder: |
+        ```yaml
+        title: Example Rule with New Feature
+        logsource:
+            category: process_creation
+        detection:
+            sel:
+                # Your example here
+        ```
+    validations:
+      required: true
+
+  - type: dropdown
+    id: backward_compatibility
+    attributes:
+      label: "Backward Compatibility Impact"
+      description: "How does this affect existing Sigma rules?"
+      options:
+        - "Fully backward compatible"
+        - "Requires minor rule updates"
+        - "Requires major rule migration"
+        - "Breaks existing rules"
+    validations:
+      required: true
+
+  - type: checkboxes
+    id: implementation_areas
+    attributes:
+      label: "Implementation Areas"
+      description: "Which areas of the Sigma ecosystem would be affected?"
+      options:
+        - label: "YAML structure changes"
+        - label: "Sigma conversion tools (pySigma)"
+        - label: "Backend updates"
+        - label: "Documentation"
+
+  - type: checkboxes
+    id: submitter_checklist
+    attributes:
+      label: "Submitter Checklist"
+      description: "Please confirm you have completed these steps"
+      options:
+        - label: "I have searched existing issues and SEPs to avoid duplicates"
+          required: true
+        - label: "I have provided concrete examples and use cases"
+          required: true
+        - label: "I have considered backward compatibility implications"
+          required: true
+        - label: "I have thought about implementation complexity"
+          required: true
+
+  - type: dropdown
+    id: implementation_help
+    attributes:
+      label: "Implementation Assistance"
+      description: "Are you willing to help implement this proposal?"
+      options:
+        - "Yes, I can help with implementation"
+        - "Yes, I can help with testing"
+        - "Yes, I can help with documentation"
+        - "I can provide guidance but not direct implementation"
+        - "I cannot help with implementation"
+    validations:
+      required: true
+
+  - type: textarea
+    id: additional_context
+    attributes:
+      label: "Additional Context"
+      description: "Any other context, screenshots, or information that would be helpful"
+      placeholder: "Additional information..."

README.md

@@ -59,13 +59,19 @@ Here's what you can expect from each of the main subfolders within this repo. Pl
 - [SigmaHQ Rule Convention](./sigmahq/sigmahq-rule-convention.md)
 - [SigmaHQ Filename Convention](./sigmahq/sigmahq-filename-convention.md)
 - [SigmaHQ Title Convention](./sigmahq/sigmahq-title-convention.md)
+- [SigmaHQ Regression Convention](./sigmahq/sigmahq-regression-convention.md)
 
 ## Version Changes
 
 You can read more on the potential breaking changes and additional features introduced in version:
 
-- [1.0.0 to 2.0.0](./other/version-1.0-2.0.md)
-- [2.0.0 to 2.1.0](./other/version-2.0-2.1.md)
+- [1.0.0 to 2.0.0](./changelog/version-1.0-2.0.md)
+- [2.0.0 to 2.1.0](./changelog/version-2.0-2.1.md)
+- [2.1.0 to 2.2.0](./changelog/version-2.1-2.2.md)
+
+## Sigma Enhancement Proposals
+
+History of the approved / discarded SEP are in [sigma_enhancement_proposals_changelog](./changelog/sigma_enhancement_proposals_changelog.md)
 
 ## Other folder
 

changelog/sigma_enhancement_proposals_changelog.md

@@ -0,0 +1,8 @@
+# Sigma Enhancement Proposal (SEP)
+
+This file contains all SEPs and their status.
+
+| Github                                                           | Title                                                | status   | target |
+| ---------------------------------------------------------------- | ---------------------------------------------------- | -------- | ------ |
+| [199](https://github.com/SigmaHQ/sigma-specification/issues/199) | Allow Tags in correlation rule                       | approved | v2.2.0 |
+| [192](https://github.com/SigmaHQ/sigma-specification/issues/192) | Update sigma-appendix-taxonomy with new folder names | approved | v2.2.0 |

changelog/version-2.1-2.2.md

@@ -0,0 +1,37 @@
+# Changes and Feature Introduced in V2.2.0
+
+The following is a non-exhaustive list of changes between the v2.1.0 and v2.2.0 specification.
+
+<!-- mdformat-toc start --slug=github --no-anchors --maxlevel=6 --minlevel=2 -->
+
+- [Generality](#generality)
+- [Modifiers](#modifiers)
+- [Tags](#tags)
+- [Taxonomy](#taxonomy)
+- [Correlation](#correlation)
+- [Filter](#filter)
+- [Rules](#rules)
+
+<!-- mdformat-toc end -->
+
+## Generality
+
+## Modifiers
+
+- `re` : Provides a more detailed definition and descripions
+
+## Tags
+
+## Taxonomy
+
+## Correlation
+
+- Add `tags` field
+
+## Filter
+
+- Filters can now reference all available rules by using the `filter.rules: any` declaration [PR #430](https://github.com/SigmaHQ/pySigma/pull/430)
+
+## Rules
+
+- `Lists` and `Maps` : add scalar value

json-schema/sigma-correlation-rules-schema.json

@@ -1,6 +1,6 @@
 {
   "$schema": "https://json-schema.org/draft/2020-12/schema",
-  "title": "Sigma Meta rule specification V2.1.0 (2025-07-25)",
+  "title": "Sigma Meta rule specification V2.2.0 (2025-XX-XX)",
   "type": "object",
   "required": ["title", "correlation"],
   "properties": {
@@ -71,6 +71,15 @@
       "maxLength": 256,
       "description": "Defines the taxonomy used in the Sigma correlation rule"
     },
+    "tags": {
+      "description": "Tags to categorize a Sigma rule.",
+      "type": "array",
+      "uniqueItems": true,
+      "items": {
+        "type": "string",
+        "pattern": "^[a-z0-9_-]+\\.[a-z0-9._-]+$"
+      }
+    },
     "correlation": {
       "type": "object",
       "required": ["type", "rules", "timespan"],

sigmahq/sigmahq-regression-convention.md

@@ -0,0 +1,134 @@
+# SigmaHQ Regression Testing Conventions
+
+This document describes an additional set of custom fields for Sigma rules enforced in the SigmaHQ rule repository in order to ensure a better quality of rules as well as preventing their regression over time.
+
+<!-- mdformat-toc start --slug=github --no-anchors --maxlevel=6 --minlevel=2 -->
+
+- [Custom Fields](#custom-fields)
+  - [`regression_tests_path` Field](#regression_tests_path-field)
+    - [Info.yml Structure](#infoyml-structure)
+      - [id](#id)
+      - [description](#description)
+      - [date](#date)
+      - [modified](#modified)
+      - [author](#author)
+      - [rule_metadata](#rule_metadata)
+      - [regression_tests_info](#regression_tests_info)
+  - [`simulation` Field](#simulation-field)
+    - [Atomic Red Team Entry Structure](#atomic-red-team-entry-structure)
+
+<!-- mdformat-toc end -->
+
+## Custom Fields
+
+SigmaHQ rules extend the specification defined in the [Sigma Rule Specification](../specification/sigma-rules-specification.md) by adding the following custom fields for regression testing purposes:
+
+- `regression_tests_path`
+- `simulation`
+
+Below is a detailed description of each field and its structure and purpose.
+
+### `regression_tests_path` Field
+
+The `regression_tests_path` field is used to specify the path to the regression tests associated with the rule. This field helps in organizing and locating the tests for each rule as well ease of automation in the testing process.
+
+The path should point to an `info.yml` that will be located in a mirror file directory to the rule itself in the `regression_data` folder and without the `.yml` extension. For example, if the rule is located at:
+
+```yaml
+rules/windows/process_creation/win_suspicious_process_creation.yml
+```
+
+Then the corresponding `regression_tests_path` should be:
+
+```yaml
+regression_tests_path: regression_data/windows/process_creation/win_suspicious_process_creation/info.yml
+```
+
+This file will contain the necessary information for executing the regression tests for the rule.
+
+The `regression_data` folder should mirror the structure of the `rules` folder to maintain consistency and ease of navigation.
+
+Inside each rule's corresponding folder in `regression_data` there should:
+
+- An `info.yml` file containing metadata about the regression tests.
+- One or more test data files (e.g., `.evtx`, `.json`, `.log`, etc.) that will be used for testing the rule.
+
+#### Info.yml Structure
+
+The `info.yml` file should have the following structure:
+
+```yaml
+id [required]
+description [required]
+date [required]
+modified [optional]
+author [required]
+rule_metadata:
+    - id [required]
+      title [required]
+regression_tests_info:
+    - name [required]
+      type [required]
+      provider [required]
+      match_count [required]
+      path [required]
+
+```
+
+##### id
+
+The `id` field is used to uniquely identify the regression test information file. This identifier helps in tracking and referencing the specific set of regression tests associated with a rule.
+
+##### description
+
+The `description` field provides a brief overview of the tests contained within the `info.yml` file. This description helps in understanding the purpose and scope of the regression tests defined for the rule.
+
+##### date
+
+The `date` field indicates when the regression test information file was created.
+
+##### modified
+
+The `modified` field indicates the last date when the regression test information file was updated.
+
+##### author
+
+The `author` field specifies the individual or team responsible for creating the regression test information file.
+
+##### rule_metadata
+
+The `rule_metadata` section contains a list of metadata entries for the rule, including:
+
+- `id`: The unique identifier for the rule.
+- `title`: The title of the rule.
+
+##### regression_tests_info
+
+The `regression_tests_info` section contains a list of regression test entries, each with the following fields:
+
+- `name`: The name of the regression test. Can be anything that helps identify the test. For example: "Sysmon Test Data".
+- `type`: The type of regression test (e.g., evtx, splunk, elastic, sql).
+- `provider`: The source or provider of the test data. For example: "Windows-Microsoft-Sysmon".
+- `match_count`: The expected number of matches for the test. For most cases, this will be `1`. Except for correlation type rules or cases where we want all condition to be matched
+- `path`: The path to the test data file.
+
+### `simulation` Field
+
+The `simulation` field is a list of entries that describe different simulation or emulation frameworks tests. Currently the only format supported is for the `Atomic Red Team` framework. Additional formats such as `Caldera` will be added in the future.
+
+#### Atomic Red Team Entry Structure
+
+Each entry in the `simulation` list for Atomic Red Team should have the following structure:
+
+```yaml
+simulation:
+    - type [required]
+      name [required]
+      technique [required]
+      atomic_guid [required]
+```
+
+- `type`: The type of simulation framework. For Atomic Red Team, this should be `atomic-red-team`.
+- `name`: The name of the Atomic Red Team test.
+- `technique`: The MITRE ATT&CK technique identifier associated with the test (e.g., `T1059`).
+- `atomic_guid`: The unique identifier for the Atomic Red Team test (e.g., `d4f6b8c2-3e5b-4c1a-9f3b-2c3e4f5a6b7c`).