Build SIEM use cases around attacker behavior you can see in logs you already collect. Good first ones are repeated failed sign-ins followed by a success, new privileged accounts, cleared or stopped logging, and risky cloud or code changes. Each use case needs a log source, a rule, an owner and a response step.
What makes a good use case?
A use case is a question, a data source, a rule and an action. "Is someone guessing passwords?" needs authentication logs, a threshold over time, and a named person who will look. If any of the four is missing, the alert will sit unread.
MITRE ATT&CK gives you a library of behaviors to choose from. Its entry for brute force lists four sub-techniques: password guessing, password cracking, password spraying and credential stuffing. It also publishes detection analytics, which makes it a good model for what a use case should say.
Which five should come first?
1. Failed sign-ins followed by success. ATT&CK's analytics for brute force describe a high volume of failed logon attempts followed by a successful one from a suspicious user, host or timeframe, and multiple failures for valid or invalid users followed by success from the same IP or user. A separate pattern is spraying across many users in a short interval. Logs needed: identity provider, VPN, SSH and key SaaS applications. Response: reset the credential, revoke sessions, check for further activity.
2. New privileged accounts or role grants. Attackers who get a foothold often create or elevate accounts. Logs needed: directory and cloud audit logs. Rule: any addition to an administrator group or role outside a change window or by someone who is not an administrator. Response: confirm with the change record, or treat as an incident.
3. Logging gaps and tampering. If an attacker can switch off logging, you lose visibility. NIST's log management guide includes an example of a Windows event noting that the audit log was cleared, and its guidance on log security covers protecting stored logs. Rule: alert on cleared logs, stopped agents and sources that go silent for longer than their normal interval. Response: investigate the host first.
4. Sensitive data access outside normal patterns. Logs needed: database audit, file access or storage logs. Rule: a user reading far more records than their baseline, or a service account used from a new location. This needs a baseline period, so start by logging and reviewing before alerting.
5. Risky changes to the software path. Logs needed: source control and CI audit logs. Rule: a force push to a protected branch, a new deploy key, or a change to pipeline files without review. Response: contact the committer and review the change.
What do these use cases depend on?
Two things that are not detections. First, time. NIST recommends time synchronization technologies such as NTP so the clocks of log sources agree, because correlation fails when they do not. Second, normalization: converting fields to a consistent representation so a rule written once works across sources.
What should you leave for later?
Anything you cannot respond to. A rule for detecting a rare technique is worthless if nobody has a playbook for it. Also postpone use cases that need data you do not collect, until you have started collecting it.
A constructed example
A company with an identity provider, a cloud account and a code host starts with use cases 1, 2 and 5 because those logs already flow in. For use case 1, it sets a rule: five failed sign-ins for one user within ten minutes followed by a success from a new country. The first week produces eleven alerts, nine from staff traveling. The team adds a condition for the new country plus a failed MFA prompt, which cuts the noise to two alerts a week. Both are reviewed within a day, because an on-call engineer owns them.
How to check or apply this
- Choose three to five behaviors from a catalog such as MITRE ATT&CK that fit your environment.
- For each, name the exact log source and field, and confirm it is collected and parsed.
- Write the rule, test it on past data, and record the false positive rate.
- Assign an owner and a response step, and write both in the alert text.
- Tune for two weeks, then set a review date.
- Add a use case that detects the failure of your logging itself.
Quick check
How many SIEM use cases is enough?
There is no standard number. A handful that are tested, owned and acted on are worth more than a long list that nobody reviews.
Should we alert on everything ATT&CK lists?
No. Pick techniques that match your assets and for which you have logs and a response. Treat the catalog as a menu, not a checklist.
Sources
Last reviewed: 18 October 2026.
