Practical tools for system, network, security, and operations administrators.

SEC-C0088 · Logging, SIEM & Detection

Detection Engineering Guide

Write a detection for a log you already collect, test it on a lab event, and name an owner.

Updated 25 October 2026 · Pillar guide

This is an original planning guide. It is not a vendor manual, an official standard, or legal advice. Example addresses use documentation ranges. Review every command before you paste it.

A detection is a question of your own logs

A detection watches events you already collect and raises a hand when the event matches a story you can explain. Failed sign-ins for one account, many accounts failing together, a sign-in that your identity provider already recorded in two distant places: those are stories. This page does not tell you how to cause them on a system you do not own. A lab account you created, and one wrong password you type yourself, is the test.

Sigma is the vendor-neutral way to write that story. The platform guides turn it into the language your SIEM actually runs. The validator checks a rule's shape. The coverage mapper asks which stories you have. A rule that matches every event is a rule you delete.

Every detection has an owner, a threshold, and a tuning date. A page at 3 a.m. for a single typo is a detection you have not finished. The incident guide is what a human does after a true page.

You test by replaying a log you are allowed to hold, or by the one lab failure. You do not generate a flood of attempts, and you do not borrow a word list.

One lab failure, one rule, one threshold

Create a lab account. Type the wrong password once. Find that one event in the log you already have. Draft a rule that names that account pattern and a count higher than one, so the single typo does not page. The generator for your platform drafts the syntax. Read it. If it would match all failures in the company with no threshold, narrow it.

Run the draft against the lab event and against a normal event that should stay quiet. Keep both results. A rule you have not seen fire and have not seen stay quiet is a guess.

Write the owner and the first tuning date. The first week is when you expect to be wrong.

Impossible travel and password spraying are detections of what your identity logs already show. You do not spoof a location and you do not try passwords against other people to create the log.

A change you can finish

The production change is one rule, in the platform you run, after the lab fire and the lab quiet. The platform guide is the syntax.

Rollback is disabling that rule, which you do once in the lab so the switch is real.

  1. Name the story in one sentence.
  2. Confirm the log already exists.
  3. Create one lab event you are allowed to create.
  4. Draft the rule and delete any match-everything clause.
  5. See it fire on the lab event and stay quiet on a normal one.
  6. Set a threshold and an owner.
  7. Disable it once so rollback is real.

Mistakes that outlive the command

detection engineering fails in the same few ways. Each one looks finished on the day you type it. The list is here so the ticket can forbid them before the window, not so you can recognise them in an incident review.

Decisions to write down before the window

One decision for detection engineering: The story is one sentence a second person understands. The log is already collected. The test event is a lab event you created. The rule fired once and stayed quiet once. A threshold above a single typo is set. The platform guide owns the syntax. Rollback is disable, and you have used it. No attack tooling and no word list were used. An owner and a tuning date are written. And a true page goes to the incident guide.

The hour you stop

Write the hostname or the system name, the owner, and the clock time before you change anything for detection engineering. If the system is serving people and you do not have a spare, this hour is a plan, not a change. A plan you can read tomorrow is a success. A change you cannot undo is not.

Use a lab or a copy. The log line you test with is one you created, or one you are already allowed to hold. You do not point a tool at a network, a mailbox, or an account you do not administer. The tools on this site run in the browser. They do not log in, and they do not scan.

prompt-for-this is a reminder that a secret is missing. It is not a password, a token, or a key you save. The real secret stays in the password store. If a draft, a log, or a ticket still contains a live secret, stop and rotate it. Then delete the copy.

One change. A firewall, a detection, a DNS record, and a policy do not share a window. If two things move and the outcome is wrong, you will not know which one did it. The rollback is the previous value, written down while the system still works.

A second person reads the scope aloud: which host, which domain, which account. If they cannot find it in the ticket, the ticket is not ready. Silence is not agreement.

Documentation addresses stay in the lab. 192.0.2.0/24, 198.51.100.0/24, and 203.0.113.0/24 are not your production network. example.com is not your domain. Replace them before a real record or a real rule is published.

Do not allow every address because a test failed. A rule, a header, or a detection that matches the world is a draft you delete. Management stays on the prefix you named. A service port opens when the service is ready, for the clients you named.

Keep the previous file. A generator draft is not the previous file. The previous file is what you reload if the new one is wrong. You practised the reload on the lab, with a console or a second session open when the change can lock you out.

If a step fails twice, stop. The failure is the result. Adding a command from a forum beside a half-applied config produces a system nobody can explain. Rebuild the lab from the copy you kept.

When the checks pass, the next system waits until someone else can repeat the proof from the notes. detection engineering is done for this window when the proof is written, not when the tool printed a file.

This page is a planning guide. It is not legal advice, not an audit opinion, not a vendor manual, and not the text of a standard. If a lawyer, an auditor, or a regulator must see the decision, they see the ticket and the evidence, not this paragraph.

Hand the finished note to the neighbouring guide that owns the next step, and leave this system alone until that guide has its own window.

Detection checks before the rule is enabled for everyone

Confirm this before you call the change done: The story sentence is in the ticket. The log source is named. The lab event exists and is yours. The rule matched that event. A normal event did not page. The threshold is greater than one trivial failure. The draft has no match-everything clause. Disable was practised. The owner is named. No word list or spoofing was part of the test. A second person read the story and the threshold. The platform guide's syntax was the one you deployed. The hostname in the prompt matches the hostname in the ticket for detection engineering. The result line includes the time and the person, not only the command. You can point at the rollback value without searching a chat history. And done is a sentence a second person can repeat: the proof for detection engineering happened, and the next host is not started early. If one of those fails, stop.

Tools for this guide

These tools run in the browser on this site. They do not log into your machines.

Guides in this cluster

These supporting pages belong to this pillar.