DOCSEARCHbyAlgolia
Submit Docs

Sigma Specification

repository·main·Indexed 42 days ago

https://github.com/sigmahq/sigma-specification

A generic signature format for SIEM systems used to describe detection logic, correlations, and filters. It provides formal JSON schemas for validation, taxonomy for interoperability, and guidelines for rule management. Supports versions up to v2.1.0, including the Metric operator for correlation rules and migration paths from sigmac to pySigma.

Tokens
19.1K
Snippets
37
Records
82
Agent score
53%

What's inside Sigma

  1. Overview of the Sigma Specification repository

    main

    The Sigma Specification repository provides the official generic signature format for SIEM (Security Information and Event Management) systems. It is organized into several key areas to help developers and security researchers implement or validate Sigma-compatible rules:

    • Specification: Detailed markdown documentation describing the Sigma rule, correlation, and filter formats, including appendices for modifiers, tags, and taxonomy.
    • JSON Schema: Formal JSON schemas used to validate Sigma detection rules, correlation rules, and filters.
    • SigmaHQ: Guidelines and conventions (rules, filenames, and titles) used specifically for managing rules within the SigmaHQ main rule repository.
    • Version Changes: Documentation regarding breaking changes and new features between major versions.

  2. Use Placeholders in Sigma rules

    main

    Placeholders (e.g., %Servers%) are used for values that are resolved at conversion time. To handle a placeholder, the |expand modifier must be applied to the value.

    Standard Placeholders:

    • %Administrators%: Administrative user accounts
    • %JumpServers%: Jump server systems
    • %Workstations%: Workstation systems
    • %Servers%: Server systems
    • %DomainControllers%: Domain controller systems

    Note: A plain percent character can be escaped with a backslash (e.g., \%plain%).

    detection:
    selection:
        server_name|expand: '%Servers%'

  3. Backend Compatibility and Constraints for Correlation Rules

    main

    When converting Sigma correlation rules to backend-specific queries (e.g., Splunk, Sentinel, ELK), the conversion backend must handle capability gaps.

    Error Handling (Must)

    An error must be raised if the target backend cannot support a feature specified as a requirement. Examples include:

    • The backend can aggregate counts but cannot apply conditions to filter those aggregated counts.
    • The backend cannot aggregate counts based on the specified grouping criteria.
    • The backend can only process up to an intermediate rule in a correlation chain.

    Warning Handling (Should)

    A warning should be issued if the backend supports a feature partially or with limitations that might affect accuracy. Examples include:

    • Temporal Order: The backend recognizes temporal relationships but cannot guarantee the order of events, potentially leading to false positives.
    • Time Boundaries: Temporal relationships are only recognized within static boundaries (e.g., a timespan of 1h only matches events within a fixed clock hour), potentially leading to false negatives.

  4. Align Sigma rule titles with severity levels

    main

    The wording of a title must reflect the rule's severity level to ensure analysts respond appropriately:

    LevelPurposeTitle Keywords/Style
    Informational / LowFor threat hunting or correlation; not for alerting.General and neutral. Do not imply maliciousness. (e.g., Net.exe Execution)
    MediumMay cause environment-dependent false positives; requires tuning.Use Potential
    HighRequires prompt review.Use Suspicious
    CriticalRequires immediate review.Must be precise and indicate specific threats. Use Malware, Exploit, ... Attempt, or <Threat Actor> Activity

  6. Use Field Name Aliases for Cross-Event Correlation

    main

    When correlating events where the same logical entity (e.g., an IP address) appears in different field names (e.g., source.ip in one rule and destination.ip in another), use the aliases attribute.

    This allows you to define a common name in the group-by section that maps to different source fields depending on which Sigma rule is being matched.

    Note: To use aliases, the referenced Sigma rules must have a name attribute defined.

    title: Cross-field IP correlation
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

  7. Define Process Creation Events

    main

    Process creation events use the generic log source category: process_creation. You can restrict these events to a specific operating system using the product field.

    Example for Windows process creation:

    category: process_creation
product: windows

    Field names for process creation events follow the Sysmon schema. Key fields include:

    • UtcTime: Event timestamp
    • ProcessGuid: Unique identifier for the process
    • Image: Full path to the executable
    • CommandLine: The command line arguments used to launch the process
    • ParentImage: Path to the parent process executable
    • User: The user context of the process

  9. Identify Sigma rules with ID and Related attributes

    main

    Sigma rules use a globally unique identifier in the id attribute, typically a version 4 UUID. To maintain relationships between different versions or types of detections, use the related attribute with specific relationship types.

    Relationship Types:

    • derived: The rule was derived from the referred rule(s), which may remain active.
    • obsolete: The rule obsoletes the referred rule(s), which are no longer used.
    • merged: The rule was merged from the referred rules.
    • renamed: The rule was renamed (e.g., from a private scheme to UUIDs).
    • similar: Relates similar rules (e.g., same logic applied to different log sources).
    title: Test rule
id: 929a690e-bef0-4204-a928-ef5e620d6fcc

related:
  - id: 08fbc97d-0a2f-491c-ae21-8ffcfd3174e9
    type: derived
  - id: 929a690e-bef0-4204-a928-ef5e620d6fcc
    type: obsolete

  10. Evolution of Relationship Expressions in Sigma

    main

    The current Sigma Correlation specification has moved away from the obsolete approach of using aggregations and the near operator within a single rule's condition.

    Why the old approach was replaced:

    • Inconsistency: It was unclear whether a relationship definition should reside in the rule describing the singular event or the rule describing the relationship.
    • Inflexibility: Rules were restricted to a single log source, making it difficult to express relationships between different types of events.
    • Complexity: Specifying temporal relationships and correlation chains in a single condition made the logic too complex and difficult to maintain.
    • Syntax Confusion: The previous pipe syntax often led users to mistake Sigma rules for target-specific languages like Splunk SPL.

  11. Understand the Sigma Specification components

    main

    The Sigma specification is composed of several distinct formats and supporting documentation:

    Core Formats

    • Sigma Rules: Defines what constitutes a standard Sigma rule.
    • Sigma Correlation Rules: Defines the format for correlation logic.
    • Sigma Filters: Defines the Sigma filters format.

    Appendices (Supporting Data)

    • Modifiers: Defines the different modifiers available for use within a Sigma rule.
    • Tags: Defines the tag namespaces used for rule categorization.
    • Taxonomy: Defines supported field names and log sources to ensure rule interoperability across different systems.

  12. Log source taxonomy for Application logs

    main

    Application log rules are designed for application security monitoring and are often keyword-based because application logs frequently lack structured field decomposition.

    When defining log sources for application technologies:

    • Set the category attribute to application.
    • Set the product attribute to the specific technology name (matching the folder name).

    Common application log sources include:

    • Django: category: application, product: django
    • Python: category: application, product: python
    • Ruby on Rails: category: application, product: ruby_on_rails
    • Spring Framework: category: application, product: spring
    • SQL: category: application, product: sql
    • RPC Firewall: category: application, product: rpc_firewall