When I started building AEGIS, I figured the MITRE coverage question would take a week. It didn’t. It took months, and I’m still finding edges. This is the honest version of what I’ve learned.
The question that kicked all of this off was from a friend who runs an MSSP. He showed me a client QBR slide. One bullet read "Overall security posture: strong." I asked how he would defend that statement if the client’s board asked. He paused, then laughed, then said "I’d probably show them an ATT&CK heatmap from the vendor who sold us the EDR."
That’s when I decided AEGIS needed to actually answer "are we covered?" in a way that doesn’t come from a vendor’s marketing deck. What followed was a lot of humbling.
Thing one: vendor-published ATT&CK coverage is mostly lies
The first source I reached for was the vendor-by-vendor coverage claims you can find on every EDR/NDR/SIEM site. Those maps are aspirational. They mark a technique "covered" if the product has any rule that might fire on any subtechnique of that technique. That’s not coverage, that’s hand-waving.
I had to build a different model. For each tool in a stack, I ask: does this product have a default detection that would reasonably flag the common behavior tied to this technique? Not "could you write a rule?" — actual out-of-box behavior. It’s a stricter bar and the number of "covered" techniques dropped a lot compared to what vendors claim.
Thing two: coverage depends on what the attacker is actually doing
A healthcare provider is not worried about the same techniques a regional bank is worried about. I tried to build a generic "here’s your coverage across all of ATT&CK" view and it was useless — too much noise, nothing actionable. The version that actually helps is filtered: "here’s your coverage against the techniques threat groups that target your sector have used in the last 18 months."
That required me to maintain a sector-to-threat-group-to-technique mapping. It’s not a clean dataset anywhere public. I’ve stitched it together from MITRE’s Groups data, public breach post-mortems, CISA advisories, and a lot of reading. It needs updating every month. This is one of the less glamorous things AEGIS does behind the scenes.
Thing three: "covered" and "detected" and "prevented" are three different words
An EDR might detect a technique (log it) without preventing it (block it). A SIEM might have a rule for it but no one tuned the alert so it sits in a queue. A prevention control might exist but is running in monitor-only mode because it was breaking something in production last month.
I had to split the single "coverage" bit into three states: detected, prevented, and has-a-tool-that-theoretically-could-but-isn’t-tuned. The third state is where most real risk lives. It’s also where most vendor marketing lies.
Thing four: the MSSP problem is not the enterprise problem
If you run one environment, you can spend a couple of days doing this properly and keep it current by hand. If you run twelve client environments, the math breaks — you’re drowning in mappings. This is the scale problem AEGIS was actually built for, and it’s the reason a spreadsheet won’t solve it.
What I didn’t appreciate until beta users told me: they don’t want a tool that auto-maps. They want a tool that makes their expert judgment durable across clients. So AEGIS does a first-pass auto-mapping, and the MSSP analyst can override any cell and the override sticks. You tell me your EDR’s default rules actually catch T1078.004 in a cloud-heavy environment? Fine, your call, remembered.
Thing five: "what do I do about the gaps?" is a bigger product than "where are my gaps?"
This one surprised me the most. I thought identifying gaps was the hard problem. It’s not. The gap list is step one. Step two is "I have 47 gaps, which do I fix first, with what tool, at what cost, and how do I prove it to my CFO?" That’s the problem the next version of AEGIS’s recommender tries to solve. It’s half done.
What I still don’t have a good answer for
How do I handle coverage drift? When a vendor updates their product, does their coverage change? Probably yes, but I have no good signal for when. Right now, the analyst has to re-assess periodically. That’s not acceptable long-term but I haven’t cracked the automated version yet.
How do I measure quality of coverage? A tool can "cover" a technique poorly — high false positive rate, stale rules, slow response. I show binary covered/not-covered today. That’s a rough abstraction.
If you have an opinion on either of these, I would genuinely like to hear it. support@axivum.io goes straight to me.
What you can try today
If you run an MSSP or an internal security team and you want to see AEGIS work against your actual stack — no sales deck, no "let me set up a call next week" — request beta access. Tell me what sector you’re in and what tools you run, and I’ll come back within a business day with either a login or an honest "not yet, here’s why."
Written while building AEGIS. Subscribe below for the next one.