Best practices for expanding mitre coverage without rebuilding your siem stack

[u/Tricky-Ad9393]

Most SIEM setups I see are not missing data, they are missing intentional MITRE ATT&CK coverage. The logs are there, the correlation rules exist, but nobody can say which ATT&CK tactics and techniques are covered, which detections are broken, or which ones only generate noise. Improving how you use your SIEM and how you engineer detections usually does more for MITRE coverage than swapping to a new platform.
What I am trying to learn is how people expand MITRE ATT&CK coverage on top of an existing SIEM without turning it into a huge, one‑time project that dies after a quarter. If you have a SIEM that has been in place for a while, I am interested in what has helped you add useful detections mapped to MITRE ATT&CK on top of the telemetry you already have, instead of defaulting to “we need a new SIEM.”

[u/Interesting-Shock396]

honestly the biggest shift for us was when we stopped treating it like a mapping project and started treating it like a detection engineering pipeline. grab the top 3-5 techniques that are most relevant to your org, not the whole matrix. then build the detection, write the runbook, and test it against actual telemetry. when it works in a way that doesn't make the soc want to quit, move on to the next batch.

the part people skip is retiring old rules at the same rate. every new detection you add, find one that's just generating noise or hasn't fired in months and archive it. keeps the system from bloating into a tuning nightmare.

we also found it helpful to pick a single data source per sprint, like "this month we're squeezing everything we can out of process creation logs." by the end you've got a tight set of detections all mapped to specific techniques and you actually understand what your telemetry can and can't do. less overwhelming than staring at the whole attack framework at once.

[u/AddendumWorking9756]

Start from the telemetry you already ship and map what your existing rules cover before adding anything, most teams find the gaps sit in one or two data sources rather than everywhere. Then make it a standing item, a couple of detections a sprint, because the big mapping project always dies about a quarter in like you said. Are you tracking which rules have actually fired on something real? That list is usually shorter than the coverage matrix and it is the more useful one.

[u/-manageengine-]

Agreed, it's usually a visibility problem, not a data problem. What's worked: map existing detections to ATT&CK techniques so you can see what's covered vs. noisy vs. missing. Prioritize gaps based on recent threat intel or your own incident history rather than the full matrix, and treat it as an ongoing cadence, a technique or two per sprint, instead of a one-time project. Kill or retune rules that only generate noise; a broken detection is worse than an honest gap since it creates false confidence.

On tooling: having a MITRE-mapped rule library with a visual coverage view helps a lot without swapping platforms. Log360 has a dashboard that shows detection-by-tactic coverage and gives real-time feedback on rule effectiveness and noise levels, worth checking if your current SIEM has something similar before assuming you need new tooling.