sigma-cli: the index clause is part of the query

The token selects the store

A converted query often begins with an index, a sourcetype, or a table name. That token is which data the search will read. Removing it, or swapping it, is a different query even when the rest of the line is identical. A hit count belongs to the token that was actually used.

The token is easy to skip because it looks like plumbing. It is part of the question.

Logsource is not automatically that token

The YAML logsource names a product and a category, such as Windows process creation. A pipeline turns that into a store name in the target language. The pipeline can be wrong, or two pipelines can emit two store names. Write the logsource from the YAML and the token from the query. If they name different ideas, say so instead of assuming the pipeline was faithful.

A saved file whose header lists the pipelines helps you see which mapping produced the token. The token is still what you quote as the store that was searched.

What to file

File the rule id, the logsource product and category, the index or table token from the query, and the hit count. If you compare two counts, show both tokens. Do not write “the same search” when the tokens differ.

Worked case: six hits in the wrong store

The lab rule’s logsource is Windows process creation. One converted query starts with index=lab_sysmon and returns 6 rows. Another, from a different pipeline, starts with index=lab_winevent and returns 0. A draft averages them to 3 and says the rule matched three times.

The note keeps 6 with lab_sysmon and 0 with lab_winevent. The logsource is the same YAML category. The stores are not the same search. There is no average. Anyone who cites a count names the token.

logsource: product windows, category process_creation
query A: index=lab_sysmon  hits: 6
query B: index=lab_winevent  hits: 0
write: two stores, two counts
not: the rule matched three times