Architecture

Enrichment pipeline

When a Sigma rule matches an event, the detector’s monitor creates a raw finding and hands it to Ruleset Management in memory. An asynchronous enrichment step then fetches the triggering event and the matching rule’s metadata, assembles an enriched document, and bulk-indexes it into wazuh-findings-v5-{category}*. The enrichment never reads raw findings back from an index, so it works whether or not they are stored (see What is a finding?).

The complete flow is shown in the sequence diagram below:

sequenceDiagram
    participant A as Wazuh Manager
    participant I as Wazuh Indexer
    participant RM as Ruleset Management
    participant SI as Source index
    participant RI as Rules index
    participant WF as wazuh-findings-v5-{category}*

    A->>I: Ingest event
    I->>RM: Monitor evaluates event against Sigma rules
    RM->>RM: Rule matches → create raw finding (in memory)
    RM->>RM: Queue finding for enrichment
    RM->>SI: Fetch triggering event by document ID
    SI-->>RM: Event source
    RM->>RM: Resolve log category from the event
    alt Rule metadata cached
        RM->>RM: Read from in-memory cache
    else Cache miss
        RM->>RI: Fetch rule metadata (pre-packaged + custom rules indices)
        RI-->>RM: Rule metadata
        RM->>RM: Cache the result
    end
    RM->>RM: Assemble enriched document
    alt Batch full
        RM->>WF: Bulk-index accumulated findings
    else Periodic flush
        RM->>WF: Bulk-index accumulated findings
    end

Enrichment is fire-and-forget: it never blocks the monitor run that produced the raw finding, and failures are logged without propagating to the caller. Concurrency is bounded so that heavy finding volume can’t overload the transport layer; findings that arrive while the concurrency limit is reached are queued and processed as capacity frees up.

Detector provisioning

Threat detectors for Wazuh integrations are created dynamically based on CTI content rather than fixed configuration:

• Enabled status: controlled by CTI to activate or deactivate detectors globally.
• Scan interval: customizable per integration (e.g., critical integrations can have shorter intervals).
• Source indices: defines the target indices or index patterns the detector monitors. If no source indices are provided, the detector falls back to the legacy per-category events pattern.
• Triggers and threat intelligence matching: not used. Detectors are created with no triggers, so a detection is recorded as a finding instead of raising an alert, and with threat_intel_enabled set to false, because Indicators of Compromise (IoCs) are matched by the Wazuh Engine as it processes events.

Any change in the CTI catalog is reflected in detector configuration without requiring code changes or restarts. The catalog owns the detectors it creates: each content update rebuilds them, which is why a provisioned detector accepts no user change other than enabling or disabling it.

Behavior notes

• Rule metadata caching: rule metadata (severity level, compliance mappings, MITRE ATT&CK tags) is cached in memory, keyed by rule ID, so repeated findings from the same detector don’t repeatedly query the rules indices. The cache size is bounded by enriched_findings_rule_cache_max_size (see Configuration); least-recently-used entries are evicted and re-fetched on demand.
• Category resolution: if the triggering event doesn’t carry a recognized log category, enrichment is skipped for that finding and a warning is logged.
• Document layout: the enriched document is a copy of the triggering event’s source, with rule metadata nested under wazuh.rule (id, title, tags, and any of level, status, compliance, MITRE present in the rule). The original event source is never mutated.
• Write semantics: enriched findings are indexed as new documents, never overwriting an existing enriched finding for the same event.

Technical parameters

See Configuration for the settings that control batch size, flush interval, concurrency, and cache size.

System indices

Access control

Access to Ruleset Management is governed by the default Wazuh roles. The plugin authorizes requests against two action namespaces: the Wazuh custom actions cluster:admin/wazuh/securityanalytics/* and the upstream OpenSearch actions cluster:admin/opensearch/securityanalytics/* (see Permissions).

• all_access — full access: create/update/delete detectors, rules, integrations, and correlations; read findings and alerts.
• wazuh_manager — no access to the Ruleset Management API. The role can read the enriched findings in wazuh-findings-v5-*, but not create, update or delete any Ruleset Management resource.

No default Wazuh role grants write access; to allow it without granting all_access, define a role with the actions above and map it to the user.