Start with five alerts that point to something serious: failed logins followed by a success, a new administrator grant, logging being disabled, a new credential created, and a credential used from an unusual place. Tune each against a week of your own data before paging anyone.
This is a suggested starting set from our own judgment, not a standard. Adjust it to your threats.
1. Failures then success
Many failed logins for an account, or from one source across many accounts, followed by a success. It is the shape of password guessing and credential stuffing that worked. Needs authentication events with outcome and source.
Tuning: exclude known scanners and your own test accounts, and set the failure count from your normal rate.
2. New administrator or privilege grant
A role or permission change that adds administrative rights. Real grants happen, so route these to a human who can confirm in a message that it was expected. Needs admin action logs with actor and target.
3. Logging reduced or disabled
An audit trail turned off, a destination changed, a retention period shortened, an agent stopped. This is a classic step after compromise. It also catches honest mistakes. Pair with silent source detection.
4. New credential created
A new API key, access token or service account key, especially outside business hours or for a privileged identity. Stolen access is often turned into durable access this way. Needs credential lifecycle events.
5. Credential used from somewhere new
A user or service credential used from a new network, client or region compared with its history. Keep a rolling baseline per identity. Expect false positives from travel and VPNs, so start as a ticket, not a page.
How to write each rule
For every rule, write down in a single paragraph:
- the question it answers,
- the log sources and fields it needs,
- the threshold and time window,
- who receives it and the first three steps they take,
- known false positives.
If you cannot write the response steps, the rule is not ready. A good habit from detection engineering is to store rules in version control and test them, as in a detection as code pipeline for Sigma rules.
Test with a drill
Perform each action yourself in a test account. Confirm the event is logged, the rule fires, and the right person receives it. Record the time it took.
Avoiding alarm fog
OWASP warns against blind checklists that create alarm fog. Five tuned alerts beat fifty ignored ones. Review each alert's outcome monthly, and tune or retire any that never produce action. See tune or suppress a noisy alert.
Add a tripwire
A decoy credential from a canary token is a good sixth alert, since it has almost no false positives.
Quick check
Do I need a SIEM to run these?
No. Scheduled queries in a log platform with notifications can cover all five. A SIEM helps when you need to correlate across many sources.
How often should rules run?
As often as the response needs. Credential abuse rules should run every few minutes. Trend rules can run hourly.
Sources
Last reviewed: 19 October 2026.
