Your first detection

A detection is a hypothesis with an alert attached: this pattern means that attack. The rule in this lab says five or more failed logins from one host within ten minutes deserves a wake-up. That shape — count, entity, window — covers most threshold detections you will ever write.

Anatomy of a threshold rule

title: Possible brute force
pattern: 5 or more failed logins from one host within 10 minutes
action: alert the on-call

Three parts: the selector (failed logins — what counts), the grouping (from one host — the entity), the window and threshold (5+ in 10 minutes — how much of it, how fast). Change any one and you change what pages at 3am. Too loose and the rule fires on users with sticky keys; too tight and the spray from the credentials lesson walks under it.

The shipping standard: test first

Run the rule against a known sample before it ships: it must fire on the attack and stay quiet on the benign lines. A rule you cannot test is a guess, and guesses page people at 3am. In the lab, match rule.yml sample.log fires on the six-event burst and ignores the legitimate deploy logins — read the alert line and confirm both halves (fires + quiet) before you call it done.

Tuning without breaking it

Every shipped rule needs three numbers written down: the threshold you chose and why, the false-positive rate you accept, and the review date. Start from the lab's 5-in-10, then tune from production data: exclude known scanners and CI hosts via allowlists (never by raising the threshold for everyone), and add a second rule for the slow spray (few-per-account across many accounts) that this rule structurally cannot see.

Key takeaways

• Threshold rules are selector + entity + window/threshold. Name all three.
• A rule ships only after firing on attack samples and staying quiet on benign ones.
• Tune with allowlists and review dates, not by silently raising thresholds.