What is a detection rule? Sigma explained for beginners

Every server, application and network device writes logs: who logged in, which process started, which file was read, which request arrived. Almost every security incident leaves traces in those logs. The problem is volume: a small environment produces millions of lines a day, and nobody can read them. A detection rule is the answer. It is a precise description of one pattern that is worth a human’s attention, written so that a machine can check every incoming log line against it and raise an alert when the pattern matches.

An analogy

Think of a smoke detector. It does not understand fire; it watches for one measurable signal, particles in the air above a threshold, and makes noise when it sees it. A detection rule is a smoke detector for logs: it watches for one signal, for example a user account created and added to the administrators group within a minute, and raises an alert. A good security team runs hundreds of such detectors, each tuned to one kind of smoke, and treats the alerts as the start of an investigation rather than proof that something is wrong.

Why a shared format matters

Until recently every log tool had its own query language. A rule written for Splunk could not be used in Elastic, and a rule written for Elastic was useless to a team running Grafana Loki. Detections were locked inside products, and every team wrote the same ones from scratch. Sigma fixes this by separating the description of the pattern from the query that implements it. You write the rule once in Sigma’s plain YAML format, and a converter turns it into the query language of your tool. The same rule file can therefore be published on GitHub, reviewed by other people, and adopted by teams running completely different systems. The public SigmaHQ rule library contains thousands of rules contributed this way, and many vendors ship Sigma support in their products.

What a Sigma rule contains

You do not need to write rules to benefit from them, but it helps to know the parts. Every Sigma rule has a title and a short description; a logsource section that says which kind of log it applies to, for example Windows security events or a web server access log; a detection section that states which field values, alone or in combination, make an event a match; and a level that says how serious a hit is, from informational to critical. Rules also carry metadata: an author, references to the research the rule is based on, tags that map it to the MITRE ATT&CK catalogue of attacker techniques, and a status that tells you whether it is experimental or well tested.

Where Sigma fits next to your log system

Sigma does not store or search logs. That remains the job of your log platform, whether that is Grafana Loki, Elastic, Splunk, Microsoft Sentinel or a plain Linux journal. The workflow looks like this:

1. Logs are collected and shipped to a central store, as described in the monitoring topic of this encyclopedia.
2. You pick rules from the public library or write your own in Sigma format.
3. A converter, normally sigma-cli, translates each rule into a query for your platform.
4. You run the query, either on a schedule as an alert rule in the platform or on demand when hunting through old data.
5. Matches become alerts; a person looks at them and decides whether they are real.

You can see the library’s shape without installing anything beyond Git; the directory names alone show which platforms and log sources have community coverage:

git clone --depth 1 https://github.com/SigmaHQ/sigma.git
ls sigma/rules/
ls sigma/rules/linux/

Because the conversion depends on field names, most backends also need a small pipeline that maps Sigma’s standard field names onto the names your logs actually use. The how-to Try Sigma rules against your own logs shows this in practice.

What detection rules are not

• They are not proof. A match means the pattern occurred, not that an attacker caused it; many rules fire on legitimate administration.
• They are not complete. Attackers change their methods, and a rule library only covers what someone has already seen and described.
• They are not a replacement for hardening. A well-configured system produces fewer alerts and gives the ones that remain more meaning.

Official documentation

• Sigma documentation
• SigmaHQ/sigma on GitHub