*Published: 06/30/2025* > For a quick bottom line up front, I am not against using MITRE. I find it incredibly useful, and it is a beautiful categorical system. I have also participated in both managed service evaluations on the vendor side. That said, its core purpose is often misinterpreted. ### Intro MITRE is not a roadmap nor an atlas. It's a categorical system from which to record different methods of attacks under various killchain phases. This opinion tethers me to the "Unpleasant Truths" booth, where veritas shines in spite of the missing audience. ![[comforting_lies.png]] ### Misconceptions at the Forefront There's a common misnomer around MITRE, and unfortunately it allows those lacking knowledge of the threat landscape, such as senior leadership and salesman, to use it to derive a plan. External contractors will often parade the intelligently-built categorical system as a shield. MITRE is an after-the-fact categorization and an interesting archive of malicious behavior.  What it was not designed for: - A roadmap for rule deployments - A method to accurately prove out your coverage - A goal to strive for with 100% coverage If you're a conscientious objector who can't stand idly by while people peddle the sweet lies, you will invariably end up in conflict with various groups. Coverage overall will always be a moving target. It's hard to encourage the "point to me on MITRE where this hurts" mentality because it is security theater. - Covering all MITRE techniques is like trying to block every possible move in a chess game—it’s endless and impractical.  - Nobody will ever achieve 100% MITRE coverage, and that is far from the aim.  - Visualizations from external contractors will derail attempts at an "intel-driven" approach, as the rule stack will disproportionately show coverage of different tactics. Examples of MITRE misuse: - External contractors using MITRE coverage to drive priority over the detection stack - Red team trying to drive priority to create a rule over individual MITRE sub-techniques - Telling threat hunters that they need to review MITRE to help detection engineering determine coverage gaps You'll notice the common theme from each example is placing MITRE in a position to drive priority. From a mathematical perspective, VanVleet's [blog](https://medium.com/@vanvleet/threat-detection-strategy-a-visual-model-b8f4fa5184410) concisely explains why the mission of MITRE as a roadmap becomes impractical: - A detection that comprehensively covers one procedure covers 1/500th of the total attack surface. - A detection that covers 4 procedures (like our ideal detection in the LSASS Memory example) covers 4/500th of the attack surface. - A detection that can only reliably cover half of a procedure is still covering 1/1000th of the attack surface. - A detection that covers 1 2-tuple is covering 1/124,750th of the attack surface (remember that 500 items allows for 124,750 possible 2-tuples). - A detection that covers one tangential element is effectively covering 1 of nearly infinite options, but for the sake of our math let’s generously assume there are only 1,000 different tangential elements an attacker could introduce. Thus, it covers 1/1,000th of 1 of 500 procedures, so that’s 1/500,000th of our attack surface. ### Wrap Up My intent was not for this writeup to appear as overtly negative, but rather to dispel the misnomers surrounding priority, and hopefully provide more backing for those who are trying to keep firm on their intel-driven priority.