It’s a common situation. The SIEM went live, the log sources were onboarded one by one (domain controllers, firewalls, Microsoft 365, the VPN, some Linux servers, endpoint protection), and now the dashboards are full but the alert queue holds a few default rules. The team knows there should be more value in all that data, but not where to start.
You are not alone. CardinalOps found that the average enterprise SIEM ingests enough data to cover more than 90% of MITRE ATT&CK techniques, yet its rules cover just 21%. [1] Most organisations already have the logs. What’s missing is a method for turning them into use cases.
What a SIEM use case actually is
A use case is a specific thing you want to detect, written down with everything needed to detect it and act on it. A good one answers five questions:
- What behaviour? For example, “a user signs in successfully after many failed attempts from the same source”.
- Which logs show it? Entra ID sign-in logs, Windows Security events 4625 then 4624, VPN logs.
- Which fields and conditions? Result code, source IP, user name, a count and a time window.
- Why does it matter? It maps to a technique, here MITRE ATT&CK T1110 Brute Force, and to a risk the business cares about.
- What happens when it fires? Who triages it, what they check, and what they do, ideally written as a response playbook your SOAR can run.
Without the last two, a rule is just a query. With them, it is something the SOC can run, measure and improve.
Start from your log sources, not from a framework
It is tempting to start with the whole ATT&CK matrix and work down. With hundreds of techniques, that stalls quickly. Starting from the data you already collect is faster, because every use case you find is one you can build today.
For each source, ask what an attacker would have to do that this source would record. The table below is a starting point for the most common sources.
| Log source | What it can show | Example use cases |
|---|---|---|
| Windows Security on domain controllers | Logons, Kerberos tickets, account and group changes | Password spraying, Kerberoasting, a new member of Domain Admins, an account created and deleted within an hour |
| Process creation (Sysmon or 4688) | Every program started, with command line and parent | Encoded PowerShell, Office apps starting a shell, credential-dumping tools, shadow copies deleted |
| Entra ID or Okta sign-ins | Who signed in, from where, with which MFA result | Impossible travel, MFA push flooding, a sign-in from a new country followed by an MFA change |
| Microsoft 365 audit | Mailbox, file and sharing activity | New inbox forwarding rules, mass file downloads, a spike in external sharing |
| Firewall and proxy | Connections in and out, URLs, bytes sent | Port scans, connections to known C2 ports, large uploads to unusual destinations |
| DNS | Every domain looked up | DNS tunnelling, newly registered domains, lookups of AI and file-sharing services |
| AWS CloudTrail or Azure activity | Cloud control-plane actions | Logging disabled, access keys created for admin users, activity in unused regions |
| Web server and WAF | Requests to your applications | Vulnerability scanners, injection attempts, sudden bursts of 404 errors |
Notice how many use cases need more than one source. “A sign-in from a new country followed by an MFA change” needs identity logs and audit logs for the same user. These cross-source use cases are usually the most valuable, and they are the ones a single product’s built-in rules miss.
Map what you find to MITRE ATT&CK
Once you have a list, tag each use case with the ATT&CK technique it detects. For each technique, MITRE lists the data sources that can reveal it, which gives you a check on your list and a common language for reporting. [2] Plotting your use cases on the matrix shows coverage at a glance: where you are strong, where whole tactics such as Discovery or Exfiltration have nothing, and which gaps one new source would close.
Don’t write every rule from scratch
For most common techniques, someone has already written a good detection. The Sigma project maintains thousands of community detection rules in a vendor-neutral YAML format, each tagged with ATT&CK techniques and the log source it needs. [3] Sigma rules can be converted into Splunk SPL, Microsoft Sentinel KQL, Elastic queries and other SIEM languages. Start from a Sigma rule, test it against your own data, and tune it. That is much faster than a blank query, and you start from logic other teams have already tested.
See which use cases your logs can already run
LogLens reads your SIEM’s log sources and shows which of its 50+ best-practice use cases you can run today, which are partial, and which single source would unlock the most. The Sigma rule library and MITRE ATT&CK are built in.
See your coverage with LogLens →Check the fields, not just the source name
“We collect Windows logs” is not the same as “we can detect Kerberoasting”. That detection needs event 4769 from your domain controllers, with the ticket encryption type, which means Kerberos service-ticket auditing has to be switched on. Many use cases fail quietly because the source is present but the audit policy, the field or the parsing isn’t. CardinalOps found that 13% of existing SIEM rules are broken and will never fire, often for exactly this reason. [1]
So for each use case, check three things: the source is onboarded, the event type you need is actually arriving, and the fields the rule uses are parsed. A use case that depends on missing data isn’t a use case yet. It is a requirement for your next onboarding.
Decide what to build first
Rank your candidate use cases by three things: how often the technique is used in real attacks, how bad it is if you miss it, and how ready your data is. Identity attacks are a good place to start for most organisations, because the logs are usually already there and stolen credentials sit behind so many incidents. Mandiant found that stolen credentials were the second most common way attackers got in during 2024. [4] A sensible first batch for most estates:
- Password spraying and brute force against cloud and on-premises sign-in
- MFA fatigue, and new MFA methods registered after a risky sign-in
- New mailbox forwarding or inbox rules
- Changes to privileged groups and new admin accounts
- Suspicious PowerShell, and Office applications starting a shell
- Security tools or logging switched off
- Large uploads to unusual external destinations
Write it down, then measure it
Keep each use case in one place: the behaviour, the ATT&CK technique, the sources and fields, the rule, the expected alert volume and the triage steps. Then track two numbers for each one: how often it fires, and how often an alert turns out to matter. Rules that never fire need a data check. Rules that fire constantly and never matter need tuning or retiring. Over time this becomes a use-case library you can show auditors and leadership, mapped to ATT&CK and to frameworks such as ISO 27001 and NIST CSF.
Onboarding the log sources was the hard part, and you have already done it. Turning them into use cases is a repeatable process, one source and one technique at a time.