MITRE ATT&CK - Not Just a Checklist
During my first week at Rilevera, I read a blog post from our CEO, Ethan Smart, about GitHub and its place in the Detection Engineering lifecycle. Ethan wrote something that resonated with me:
GitHub was never the outcome I needed - it was a means to an end, and I'd confused the two.
That line got me thinking about my experience in the security industry and how this idea applies to many things - but perhaps nowhere more surprisingly than the MITRE ATT&CK Framework.
When a framework isn't a framework
MITRE ATT&CK is, at its core, a foundation - MITRE says so themselves. So why isn't it always treated that way? In my career I've worked with more than 100 companies across all industries - as clients and, at times, as a consultant to security product vendors. Almost all of them treated ATT&CK the same way: as an end goal.
Security product vendors are the biggest culprits. Whether I was working with a customer or embedded with a SIEM developer, there was always pressure to have a detection rule covering every tactic and sub-technique in ATT&CK. After all, if you can detect every step an attacker might take, you're secure right? Not quite.
One size does not fit all
The problem with treating ATT&CK coverage as an end goal is that it misrepresents what ATT&CK is - a foundation. Every environment is unique, shaped by its endpoints, its underlying infrastructure, and the business functions those systems support. All of these factors should inform how Detection Engineers build their rules.
Financial institutions are a good example. Early in my career, a senior engineer told me that mainframes were a dying technology, so I assumed I'd never need to secure one. Five years later, I worked with one of the largest financial institutions on the planet and their mainframe was by far their most critical asset.
Another example: traditional Windows infrastructure. Early in my career, every customer I worked with had Windows endpoints and domain controllers. Then, about two and a half years in, I came across a customer running their entire operation on AWS-native services and MacBooks. It raised an uncomfortable question: "How could we claim the same level of detection coverage for an environment our rules weren't built for?"
Those experiences upended my early assumptions and led me to a revelation: in security, one size does not fit all.
To be fair, most SIEM vendors give customers a solid starting point with built-in rules mapped to ATT&CK. Detection Engineers are then tasked with filling the gaps. The shortfall comes when they do so without applying the context of their environment - chasing coverage for its own sake rather than relevance.
What Detection Engineers Need
The solution isn't to abandon ATT&CK, it's to use it as the foundation it was designed to be. Effective Detection Engineering requires layering your organization's unique context on top of that foundation.
That means understanding which data sources are actually flowing into your SIEM, mapping the tactics and techniques that are relevant to the specific services and infrastructure in your environment, and honestly assessing how well your current detection rules hold up against those threats rather than against an arbitrary checklist.
Done right, ATT&CK coverage stops being a scoreboard and becomes a living, environment-aware picture of your detection coverage. The goal isn't to check every box; it's to make sure the boxes you're checking actually matter for the environment you're defending.
How Rilevera Solves This
My technical interview with Rilevera's CTO, Andrew Ingalls, was what really sold me on joining the company. We shared a core belief - the thesis of this post: ATT&CK coverage can and should look different for every customer.
Rilevera addresses this problem by applying the context of the data sources flowing into your SIEM, informing you of the tactics and techniques that could target the services and infrastructure behind those sources, and measuring how well your detection rules map to ATT&CK with full context for how your environment can actually be attacked.
