How to Choose Which Sigma Rules to Deploy First

Event ID 4688 carries no command line until you turn on one Group Policy setting. Audit Process Creation logs the new process name and the parent, and that is all. Enable "Include command line in process creation events" and ProcessCommandLine starts populating. Leave it off and every Sigma rule whose detection keys on CommandLine matches nothing, forever, without erroring. The rule loads. The rule runs. The rule returns zero.

That is the whole problem with picking rules by severity. A critical rule that reads a field you do not collect is worth less than an informational rule that reads a field you do. Severity describes how bad the activity is. It says nothing about whether you can see the activity.

Severity is the wrong first sort

/rules?severity=critical is a real filter and it crosses all nine domains at once. Windows process creation sits next to cloud audit logs, next to identity sign-in events, next to container runtime telemetry. A SOC that runs Windows event forwarding and nothing else will find most of that page unusable, and will find out one rule at a time, after deploying each one.

Rank on three axes, in this order.

1. Telemetry. Do you collect the log source, and are the specific fields populated?

2. Cost. What does the rule scan, and how often does it fire?

3. Severity. Among the rules that survive the first two, which activity hurts most?

Cost is the axis people skip. A selection anchored on Image|endswith: '\rundll32.exe' touches a narrow slice of process creation events. A selection that is a bare CommandLine|contains with no image anchor evaluates a substring match against every process creation event in the estate. Both can carry level: high. They are not the same rule to operate.

Step 1: inventory the log sources you genuinely have

Not the ones in the onboarding doc. The ones producing events this week, with the fields filled in. Sigma addresses log sources through three keys, product, category and service, and each one maps to something concrete you either have or do not.

Fill in the right-hand column honestly for your estate, then check the fields, not just the channel. A host forwarding 4688 without command line auditing is a host that has category: process_creation on paper and half of it in practice. If the distinction between a channel and a populated field is new, what is security telemetry covers the ground underneath this step.

Step 2: filter the catalog down to what that inventory allows

The catalog list takes exactly these parameters: q, domain, format, severity, tier, sort and page. Start wide and cut.

• /rules?domain=windows for the Windows estate

• /rules?domain=windows&tier=free if you want only rules whose body is open with no account

• /rules?q=rundll32 to search by name

• /rules?domain=cloud&severity=high once you get to a cloud estate

• /rules?sort=updated to see what moved recently

One honest limitation. There is no logsource filter parameter, and q matches against title and summary only, so searching for image_load will not reliably return every rule that uses it. domain narrows the field to a readable page, and the logsource read happens on the rule page itself. For scripting the first pass, /api/rules?domain=windows returns the same projection as JSON, unauthenticated, though never a rule body.

Step 3: read prerequisites and telemetry requirements before the description

The description tells you what the rule is for. The prerequisites tell you whether it will work. Read them in that order, because the second one is the disqualifier.

Every published rule page carries, with no sign-in required: the resolved logsource (product, category, service, definition), linked telemetry requirements, a prerequisites note, limitations, the known false positives from the rule body, MITRE technique links, linked threat entities, severity, license and attribution, and the version changelog. Publishing those as first-class fields rather than burying them in a YAML comment is what makes this procedure possible at all.

The logsource.definition string is the one most people scroll past. It is where the author writes the requirement in prose, and it is often the sentence that tells you the rule needs a specific audit subcategory, a Sysmon config section, or a registry setting you have never applied.

Step 4: check false positives and limitations against your own estate

A false positive list is not a warning label. It is a question about your environment. "Administrative scripts" is a footnote in an estate with fifty servers and a disaster in an estate where a management platform pushes signed PowerShell to every endpoint on the hour. Read each entry as: does this thing happen here, and how often?

Limitations are the mirror image. A rule that matches on Image|endswith is defeated by a renamed binary. Where Sysmon is present, OriginalFileName closes that gap. On 4688 it does not exist, so the limitation is permanent for you, not merely noted.

Step 5: now rank by severity

Sort the survivors by severity and deploy from the top. This is the last step, not the first, and by the time you reach it the list is short enough to read.

Worked example: 4688 with command line auditing, no Sysmon

Take a modest, common position. Windows Security channel forwarded, Audit Process Creation on, command line inclusion on, logon events on, no Sysmon anywhere, PowerShell script block logging not yet deployed.

What that rules in:

• category: process_creation rules that use Image, CommandLine, ParentImage and the user fields. 4688 maps NewProcessName, ProcessCommandLine and ParentProcessName onto them.

• service: security rules over logon and account activity, 4624, 4625, 4672, 4720, subject to the audit subcategories being enabled.

What it rules out, immediately and permanently until something changes:

• Every image_load, registry_set, file_event, pipe_created, dns_query and process_access rule. Those categories have no producer in this estate. That takes most LSASS access detection with it, so the T1003.001 shelf is closed regardless of how many rules on it are critical.

• service: powershell rules keyed on 4104 script block content.

• Process creation rules that use fields 4688 does not carry: OriginalFileName, Hashes, ParentCommandLine, CurrentDirectory, IntegrityLevel, ProcessGuid, and the signature and file-metadata fields.

That last bullet is the subtle one. The category matches, the rule looks deployable, and the field is silently absent. Reading the telemetry requirements on the rule page is what catches it before deployment rather than after.

What survives, and what it catches

Here is the shape of a rule that survives this filter. It reads two fields, both of which 4688 provides once command line auditing is on.

title: Rundll32 execution without arguments
id: 5b0b3b5a-2d2b-4a9a-9d1d-2c2b3c7d1e4f
status: experimental
description: Detects rundll32.exe started with no DLL or export on the command line.
logsource:
    category: process_creation
    product: windows
detection:
    selection:
        Image|endswith: '\rundll32.exe'
    no_args:
        CommandLine|endswith:
            - 'rundll32.exe'
            - 'rundll32.exe"'
    condition: selection and no_args
falsepositives:
    - Installers and legacy management tooling that spawn a placeholder process
level: medium
tags:
    - attack.defense_evasion
    - attack.t1218.011

What it catches: a process that has no legitimate reason to exist without arguments. Rundll32's entire job is to load a DLL and call an export. Started bare, it is a host process waiting for something to be injected into it, which is the default spawn target for several post-exploitation frameworks. T1218.011.

What it misses: an operator who changes the spawn target to another signed binary, injection into an already-running process (which never produces a process creation event at all), and a renamed copy of rundll32.exe, because Image|endswith sees the name on disk and this estate has no OriginalFileName to fall back on.

Known false positives: printer and driver installation flows, and some older management agents. Baseline for a week before alerting.

Summary

Ordering by severity produces a deployment list that assumes telemetry you may not have. Ordering by telemetry produces a shorter list where every entry can actually fire. Inventory your log sources and the populated fields first, filter the catalog by domain, read each candidate's logsource, telemetry requirements, prerequisites, limitations and false positives before its description, and only then sort what is left by severity. We publish those fields on every rule page precisely so this pass is possible without deploying anything. What we cannot do is see your telemetry for you. You take one rule at a time, and that is the right pace for this work anyway.

Start here, then narrow:

/rules?domain=windows
/rules?domain=windows&tier=free
/rules?domain=windows&severity=high
/api/rules?domain=windows

Windows telemetry worth confirming before you deploy anything from that list:

Security 4688   process creation (enable command line inclusion)
Security 4624   successful logon
Security 4625   failed logon
Security 4672   special privileges assigned to new logon
Security 4720   user account created
Security 5156   WFP permitted connection (Filtering Platform Connection auditing)
PowerShell 4104 script block logging (Microsoft-Windows-PowerShell/Operational)
Sysmon 1,3,7,10,11,13,22  everything the categories above depend on