What Makes A Good Threat Model? Its More Than A Napkin, But It Begins There

When you are dealing with Operational Technology (OT) or connected products like a smart insulin pump or Internet of Things (IoT), the stakes are incredibly high. A poorly secured consumer app might leak a password, but a compromised medical device or industrial control system can cost lives or halt critical infrastructure.

Beginning with the land before time - if you have ever used Microsoft's Threat Modeling Tool (https://learn.microsoft.com/en-us/azure/security/develop/threat-modeling-tool), you know exactly where this journey usually begins.  And I’ll add another spicy bit - it often takes a knowledgeable analyst that understands the idiosyncrasies and nuance required to NOT make a mole hill out of an ant hill.  The skillset and mindset isn’t everywhere, so let’s try and get us all thinking about this - even if threat-modeling isn’t within your official role description - we can help get you there (sounds like another blog or webinar).

So the MSFT tool for those that don’t know - It’s a bit of a rough, Visio-type application that inevitably results in an absolute mountain of work. Now, I am not knocking it at all - in fact, that is exactly where my own journey started. One of my very first tasks back at Tofino Security was to sit down and read Microsoft's threat modeling book cover to cover. I even used that exact methodology extensively for my thesis.

But despite the solid foundational knowledge it provided, as I spent more time in the trenches, I always felt like there was something missing from that traditional approach. Building a truly effective threat model isn't just about drawing boxes and lines, and it definitely isn't about generating a massive, unactionable spreadsheet of doom. It has to be a deliberate, strategic process that aligns with the reality of engineering and business needs. 

Of course today, there are a myriad of tools to diagram applications and flows, various AIs to ask the wildest of questions, but still, you are the manager and analyst at the end of the day - any model needs context, whether tribal, document based, or inferred.  And of course - various bits of knowledge can be arcane and heavy, but here are some for reference:

• (Painful, and we can do it better) Microsoft - Threat Modeling Intro Training https://learn.microsoft.com/en-us/training/paths/tm-threat-modeling-fundamentals/

• MITRE - Threat Modeling with ATT&CK https://center-for-threat-informed-defense.github.io/threat-modeling-with-attack/

• (Legacy but still good) MITRE - Cyber Threat Modeling: Survey, Assessment, and Representative Framework https://www.mitre.org/sites/default/files/2021-11/prs-18-1174-ngci-cyber-threat-modeling.pdf

• NIST SP 800-154 (draft) Guide to Data-Centric System Threat Modeling https://csrc.nist.gov/pubs/sp/800/154/ipd

But to help demystify the process, mindset, and get you started using a Napkin. Here is a generic five-step approach (I admit - it is overly simplified, but more to come) on building a threat model that actually works for complex, connected systems.  It's honestly really about deciding scope, dividing and conquering, idealization, and scope… and more scope decisions.

I recognize this can be a complex topic so I am trying to illustrate through a series of article how Threat Modeling is a great engineering practice that any security or forward linking organization should be instilling; its always resulted in a better experience and product (for me). And Its so easy, you might be able to try it when thinking about your home's safety or security.

1. It Starts with Purpose and Scope

Before drawing a single diagram, I have to strictly define the System under Consideration (SuC) by working backwards from the real-world impacts.

• Define the Realm of Action: You simply can't model everything. Instead of asking what an attacker could do, I start with the most significant impacts - like the unauthorized alteration of an insulin pump's delivery logic - and draw a hard boundary around what affects that outcome. If the SuC relies on a third-party cloud analytics engine, I mark its internals as out of scope, treating it purely as an untrusted boundary.

• Tailor to the Job Role: Not all threat models are purely for the core security engineering team. If I am looking at the system through an IAM lens, I want to know all the authentication flows, OAuth tokens, and API gateways. If I am an electrical engineer, my scope is exposed pins, debug interfaces, and power rails.

• Establish the End Goal: What questions are we trying to answer? The goal is to either answer architectural questions through the model itself or identify the exact compensating controls needed to pass muster.

And before I do anything more - I establish not just scope, but instead our (pardon my Quebecois) Raison d'être. In other words - its a French phrase adopted into English that literally means "reason for being". It refers to the fundamental purpose, justification, or motive for the existence of a person, organization, or thing so - understand what it is you are modeling and why.

"E.g.,, I have a PLC from a Major OEM. This PLC has your typical accoutrements - EWS, HMI, Historian, Protocol X for the vendor to configure the PLC, and your forever-existing Modbus/TCP for controlling the process."

The problem is - your typical AI will come back with a complicated setup, based on all of the best hardening features that may/may not exist or be possible (or deployed in a brownfield), and you still don't know if this PLC is deadly to the right process, or is it effectively a paperweight. Instead beyond the above description - you would need to ask in addition:

"This device is used in a larger process - it is used as part of an HVAC called a Computer Room Air Handler (CRAH) and it is used in X facility. Our scope is limited to ONE CRAH, with the assumption that there is a larger scope with context on its operation, and that the facility depends on a series of CRAHs."

Knowing all of this cuts the chaff, and really makes the Threat Model realistic, accurate, complete, and valuable - it is tied to things that likely matter - which means - you can take it to do something.

2. Achieving My Goals: Inputs and Terminology

Once the boundaries are set, I need to figure out how to stack, rank, and sort the data. The industry is flooded with standards, so establishing a strict baseline is critical before looking at schematics or code.

• Get the Terminology Straight: We must distinguish our taxonomies. A critical distinction we make today is understanding the difference between a raw CVE (any of the thousands of vulnerabilities a scanner might find) and a known exploitable vulnerability under practical operational conditions.

• Gather Inputs and Track the Supply Chain: I figure out what documentation I have and what I need. This means gathering PCB layouts, firmware architecture docs, and Software/Hardware Bills of Materials (SBOMs/HBOMs). For general OT, leaning heavily into C-SCRM (Cybersecurity Supply Chain Risk Management) practices right here is vital to catch upstream vendor risks.

• Assess Feasibility: Can I create an initial working representation of the SuC with what I have? Perfection is the enemy of progress. An initial rough model based on high-level data flows is better than paralysis by analysis.

3. Building That Model: The CORE Representation

Now we get to what I really care about: building the core representation of the hardware and software stack.

• Focus on Interactions, Not Just Assets: I catalog the assets, but I don't get bogged down in creating a massive, static asset inventory. Cybersecurity is about interactions and data flow. In an OT/IoT context, this means documenting the physical I/O (exposed UART, SPI, or JTAG ports) and mapping out firmware modules and web management interfaces.

• Map the Flows and Boundaries: This is where the model comes alive. I establish the data flows, trust boundaries, and execution environments directly in the cybersecurity diagrams.

• Prioritize Interfaces: External interfaces get top priority. Then, we look closely at the "first touch" points on data. Where is the JavaScript sanitized to prevent XSS or SQL injection? Where do Remote Procedure Calls (RPCs) actually execute on the microcontroller?  You also need to imagine the technology too, what is true in X, is not always true in Y.  

• Doodle It Down: Whether physically on a whiteboard or plotted digitally, get the architecture out of your head so the electrical and software teams can look at the same picture.  Figure out fast what you don’t know, what you are unsure on, and how things generally look at work.

• Think in Functionality: Key items can be grouped together, and threats/negative activities often manifest themself in “heat map” like function - e.g., if you have a webserver, chances are these types of active attacks will occur.  A watchdog or OOM attack may be less likely, or not even possible - that would be a different class of CAPEC (https://capec.mitre.org/data/definitions/3000.html) or something like resource starvation.

4. Nailing Down the Threats: Evolving the Core Model

With a core model in hand, we break it. We need to understand system-level architectural flaws and complex scenario-based threats. Remember I mentioned scope and context at the beginning - here is where you circle back, and please recall that in the industrial world, there are a number of engineering considerations and not everything you read about in "cyber land" is true:

• Idealize REALISTIC Scenarios: I build out the how, what, and why. What if an attacker targets the provisioning server that handles cryptographic key material for our entire fleet of devices? What if a local attacker gets physical access to the device - like the kinds of hardware manipulation we routinely see demonstrated at the S4x26 PoC Pavilion?

• Attack Paths over Attack Trees: We build attack paths. Traditional attack trees are academically fascinating because they map every theoretically possible route, but they are terrible for real-world decision-making. We need the likelihood and impact of specific, realistic attack paths to define precise requirements, and of course add in - those groups of functionality.  (Even if its not entirely scientific, and is biased - it just helps folks understand via buckets)

• Keep Risk Math Practical: We tie these threats back to the core model. I actively avoid overthinking the exact quantitative risk math. Evaluating impact and likelihood is simply a tool to prioritize countermeasures and cut through the FUD. We balance engineering realism with budgets, microcontroller constraints, and End-of-Life (EoL) timelines.

5. Putting the Model to the Pavement

A model is completely useless if it sits in a drawer. Now that we have it, we put it to work.

• Beyond the Checkbox: We integrate the model deeply into the engineering lifecycle. It becomes a prioritization engine for the engineering backlog and a vital artifact for systems-of-systems architectural decisions.

• Make It Live for Incident Response: The model must be a living document within the broader risk management system. When the PSIRT gets an alert about a new zero-day in a network stack, this threat model is the very first thing they pull up to determine the blast radius and actual exploitability within our specific architecture.

• Drive Root Cause Fixes: As the product evolves, the documentation and the threat model must evolve continuously. Every new incident should force the cybersecurity of the involved products to improve, finally addressing problems at their root cause rather than just passing recommendations down to the asset owners.

Getting to why a great model matters, well it happens to matter today with the CRA legislation - this is definitely a reality check, and if you own a major portfolio, I suspect you are trying to find the budget for a serious amount of time spent threat modeling and figuring out compliance.

Now with the EU Cyber Resilience Act (CRA) https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act, transforming secure-by-design from an aspiration into a strict legal obligation has made threat modeling no longer optional - it is the engine for compliance. Considering a "product with digital elements" like a connected insulin pump or an industrial edge gateway. Under the CRA, manufacturers must perform a documented cybersecurity risk assessment to earn their CE mark. Here is how a robust threat model directly answers the legislation's demands:

• a) Communicating what issues affect the product: The CRA dictates that you cannot sell products with known exploitable vulnerabilities. When a scanner flags 500 CVEs in your software stack, the regulation doesn't expect you to blindly patch all of them. Your threat model serves as the technical proof of whether a specific vulnerability can actually be reached and effectively exploited by an adversary under your product's practical operational conditions.

• b) Determining scope and providing fixes: If an issue affects a third-party module within your device, your threat model determines your response strategy. If the model proves that the attacker cannot effectively cause an impact because of downstream data sanitization or disabled features, you can justify why an immediate, disruptive firmware patch isn't required, and why a configuration change or a compensating control is the official mitigation.

• c) Fulfilling broader compliance wishes: Article 13 of the CRA requires you to document risks and chosen mitigations based on the product's intended purpose and "reasonably foreseeable misuse." Your threat modeling artifacts - the data flows, identified attack paths, and documented security decisions - collectively form the exact technical documentation required by regulators. It proves that you didn't just react to threats, but actively engineered resilience into the product from day one.

Ultimately, the goal of a great threat model isn't to create a compliance headache, but to transform security from a cost center into a core quality metric. By adopting this type of focused approach, threat modeling ceases to be a massive, unactionable effort; it becomes the clearest proof that you genuinely know your product's architecture and its real-world risks. 

I hate seeing products that show a gazillion CVEs, that makes everyone throw their hands up.  But I want to help empower decision-makers by distilling mountains of potential vulnerabilities into a prioritized, actionable roadmap, cutting through the noise of constant security alerts; Models can help do that - or at least help the folks communicating issues to the people that sign the decisions. Solutions like ArgusEye (https://www.arguseye.ai/), by leveraging AI to automate the tedious documentation, asset cataloging, and flow mapping, further simplify this transition, allowing analysts to focus on what truly matters: breaking the model and engineering resilience.

Give us a ping - https://www.arguseye.ai/contact