Sigma Logsource Coverage¶

Sigma rules declare the telemetry they need via a logsource (product + category or service). Whether a rule can actually fire on your grid depends on two things: whether Security Onion collects that telemetry, and whether the Sigma conversion pipeline maps the rule's logsource and field names onto the fields Security Onion actually stores. This page maps the endpoint and cloud logsources in the SigmaHQ ruleset across both, so you can tell at a glance which rules work out of the box, which need additional endpoint configuration, and which need telemetry Security Onion does not collect.

By default Security Onion imports the SigmaHQ core package (stable/test rules of high/critical level) plus the emerging threats add-on — see Sigma Packages to change this. Detection counts are shown as default (all rules): rules in the default packages, with the all-rules package total (every stable/test/experimental rule of medium level and above) in parentheses. Counts are current as of mid-2026. Note that a rule being supported is separate from it being enabled — see Enable Sigma Rules on Import for controlling which rules are active by default.

How to read the tables:

• ✅ Supported — telemetry is collected once the Security Onion Elastic Agent (which includes Elastic Defend) is deployed to the endpoint, and the conversion pipeline scopes the rule correctly. No extra configuration.
• ⚠️ Partial — a subset of the category's telemetry is collected or mapped; some rules in the category will never match. See notes.
• 🔧 Requires setup — telemetry exists only if you configure something extra (deploy Sysmon, enable a Windows audit feature, or add an integration).
• ❌ Not collected — no equivalent telemetry; these rules will never fire.

The Playbooks column shows Guided Analysis Playbook status for each logsource (see Detections): ✅ playbooks are published for this logsource, 🔄 in development, Planned, or — not currently planned. Where the status is the same for every logsource in a table, it is stated in the section text instead of a column.

Windows endpoint — Elastic Defend¶

Elastic Defend is the default endpoint telemetry agent for Security Onion. These categories are fully covered by Defend events, and the conversion pipeline scopes each one to the matching Defend event type (shown in the Telemetry column). They work out of the box. Guided Analysis Playbooks are published for all of these categories.

⚠️ registry_event is partial: Defend records registry value modifications only. Rules matching key paths work, but rules requiring key create/delete/rename semantics need Sysmon EID 12/14 (7 of the 40 all-rules detections). Playbooks cover the Defend-answerable subset.

Windows endpoint — requires Sysmon¶

Elastic Defend does not emit equivalent events for these categories. Deploying Sysmon with an appropriate configuration provides the telemetry; without it, these rules will never fire. Guided Analysis Playbooks are not currently planned for these categories.

Windows event log channels¶

These logsources target specific Windows event log channels. The default agent policy collects the core channels (Security, System, Application, Windows Defender, PowerShell, WMI-Activity); a few sources additionally require the corresponding Windows feature or audit policy to be enabled on the endpoint.

✅ wmi_event, wmi — the WMI-Activity Operational channel natively records WMI provider loads and permanent event subscriptions (EID 5857–5861), so Sysmon EID 19–21 is not required. However, rules matching on the Sysmon field names (EventNamespace, Consumer, Filter) will not fire against the channel's fields; match on the event ID instead.

🔧 Other service channels — ~30 low-volume channels (AppLocker, BITS, CodeIntegrity, Exchange management, task scheduler, print service, NTLM, …). Conversion scoping is automatic, but these channels are not collected by the default agent policy; each needs its channel added and, in some cases, the Windows feature enabled.

Linux and macOS endpoints¶

Elastic Defend covers the core endpoint categories on Linux and macOS as well.

Cloud and SaaS¶

These require the corresponding Elastic integration to be configured — nothing is collected out of the box. Conversion support varies: m365 rules are fully mapped to the O365 integration's fields and dataset; the other products currently have no conversion mappings, so even with the integration collecting data, their rules need custom field mappings before they can match. Guided Analysis Playbooks are not currently planned for these logsources.