Threat ModelingProcess, Methods, and a Worked Example
Threat modeling is the discipline of finding security problems in a design before an attacker finds them in production. This guide explains what threat modeling is, compares STRIDE, PASTA, LINDDUN, attack trees, and the other methodologies you will encounter, walks through a seven-step process, and works a complete example for a defense subcontractor portal that handles controlled unclassified information. It also covers threat modeling for AI and LLM applications, the tools available, and how a threat model satisfies the risk analysis requirements in CMMC, NIST SP 800-171, HIPAA, and PCI DSS.
What Is Threat Modeling?
Threat modeling is a structured process for understanding what you are building, identifying what can go wrong with it, deciding what you are going to do about each problem, and checking whether you did a good enough job. Those four questions, popularized by Adam Shostack and adopted by the Threat Modeling Manifesto, are the whole discipline in one sentence. Everything else on this page, including STRIDE, PASTA, data flow diagrams, and rating schemes, is a technique for answering one of the four questions well.
- Threat modeling is design-time security analysis. It finds flaws in architecture, trust boundaries, and data flows while they are still cheap to fix, which a scanner or a penetration test of a finished system cannot do.
- Every method answers the same four questions. What are we working on? What can go wrong? What are we going to do about it? Did we do a good enough job? Pick the method that fits your team, not the one with the longest acronym.
- STRIDE is the default starting point. Its six categories, applied to each element of a data flow diagram, give a small team a complete and repeatable way to enumerate threats without specialist training.
- The diagram matters more than the tool. A whiteboard drawing with honest trust boundaries produces a better model than an expensive platform fed an incomplete architecture.
- Compliance frameworks require the result, not the name. NIST SP 800-171, HIPAA, PCI DSS, SOC 2, and ISO/IEC 27001 all require risk analysis of systems. A threat model is a defensible way to perform it and feeds the System Security Plan and POA&M directly.
- A threat model is a living document. It is re-run on every architectural change, including the addition of an AI component, and validated by penetration testing or red teaming where the rating warrants it.
The word "threat" in threat modeling has a specific meaning. A threat is something that could go wrong: an attacker impersonates a user, a file is altered in transit, a backup is read by someone who should not see it. A threat is not a vulnerability, which is a specific weakness that makes a threat possible, and it is not a risk, which is a threat weighed by its likelihood and impact. Keeping those three words separate is the first discipline of threat modeling, because a model that lists vulnerabilities ("the server is missing a patch") instead of threats ("an attacker on the internet executes code on the application server") goes stale the moment the patch is applied, while the threat remains true for the life of the system.
Threat modeling applies to more than software. The same process works for a network segment, a cloud tenant, a business process such as wire approvals, a medical device, a manufacturing line, or an AI agent that can call tools on your behalf. At Petronella Technology Group, Inc., founded in Raleigh in 2002, we run threat models for defense subcontractors preparing for CMMC assessments, medical practices performing HIPAA risk analysis, and firms deploying private AI, and the shape of the exercise is the same each time: draw it, break it, fix it, check it. The methodology comparison, the step-by-step process, and the worked example below are the same material we use with clients in the Triangle and nationwide, written so a technical lead can run a first model with nothing more than a whiteboard.
The Four Questions Every Threat Model Answers
The four questions are method-agnostic. STRIDE, PASTA, attack trees, and every tool on the market are different ways of answering one or more of them. Teams that keep the questions in front of them avoid the most common failure, which is producing an impressive artifact that never reaches a decision.
1. What are we working on? Scope and the data flow diagram
The first question produces a scoped diagram. Scope means a clear boundary: this application, this network segment, this business process, and nothing else for now. The diagram of choice is the data flow diagram, which uses only five kinds of element. External entities are people and systems outside your control, such as users, partners, and third-party APIs. Processes are the code and services that act on data. Data stores hold data at rest: databases, file shares, object storage, backups, logs. Data flows are the arrows between them. Trust boundaries are the dashed lines where the level of trust changes: the internet edge, the line between a user's browser and your server, the boundary between an application and its database, the line between a standard user and an administrator. If a diagram has no trust boundaries, it is a network drawing, not a threat model input. Write down the security objectives at the same time: what data must stay confidential, which actions must be attributable, what must stay available during business hours.
2. What can go wrong? Threat enumeration
The second question produces a list of threats, and the challenge is completeness rather than imagination. Unstructured brainstorming finds the threats the room has seen before and misses the rest. A method such as STRIDE gives the team a checklist to walk per element, so that for every process, data store, flow, and external entity, someone asks whether it can be spoofed, tampered with, repudiated, disclosed, denied, or escalated. Attack trees serve the same purpose from the other direction, starting from an attacker's goal and working back to the steps that reach it. Threat intelligence about your industry, which we draw from our threat intelligence services, sharpens the list by showing which threats are being exercised against organizations like yours this year. Each threat should be a sentence with an actor, an action, and a target, and should be recorded against the diagram element where it occurs.
3. What are we going to do about it? Mitigations and acceptance
The third question turns each threat into a decision. There are four legitimate responses. Mitigate: add or strengthen a control so the threat is harder to realize or less damaging. Eliminate: remove the feature, the data flow, or the stored data so the threat no longer applies, which is often the cheapest fix of all. Transfer: move the responsibility to a party better placed to carry it, such as an identity provider handling authentication or a cyber insurance policy handling residual financial loss. Accept: record that the threat is understood and that the organization will live with it, with a name and a date on the acceptance. Every threat in the model gets exactly one of these, an owner, and, for mitigations, a place where the control will be documented, which for regulated clients is the System Security Plan and, for anything not yet implemented, the Plan of Action and Milestones.
4. Did we do a good enough job? Validation
The fourth question is the one most teams skip. Validation has three parts. First, does the diagram still match the system as built? Engineers add integrations, enable features, and open firewall rules, and each change can invalidate a boundary. Second, were the mitigations actually implemented, and do they work? A control written in a plan is not a control until someone has configured it and someone else has tried to get past it. Third, did the model find the threats that matter? The honest test is whether a penetration test, a red team engagement, or a real incident surfaced a threat the model did not contain. When that happens, the model is updated, and the gap is treated as a lesson about the method, not a failure of the people who ran it.
Threat Modeling Methodologies Compared
Several named methodologies exist, and they are not interchangeable. Some are categorization schemes for enumerating threats, some are full processes that run from business objectives to residual risk, and one is a rating scheme that is often mistaken for a methodology. The table describes each in plain language so you can choose, or combine, with confidence.
| Methodology | Focus | Best for | Output | Effort |
|---|---|---|---|---|
| STRIDE | Threat categorization. Six categories (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) applied to each element of a data flow diagram. Developed at Microsoft. | Application and system teams of any size that want a complete, repeatable enumeration without specialist training. The default starting point for most organizations. | A list of threats per diagram element, each tagged with a category and the security property it violates. | Low to moderate. A small system can be enumerated in a single session. |
| PASTA | Risk-centric process. The Process for Attack Simulation and Threat Analysis runs seven stages: define business objectives, define technical scope, decompose the application, analyze threats, analyze vulnerabilities and weaknesses, model attacks, and analyze risk and impact. | Organizations that need the threat model tied directly to business impact and executive reporting, or that are modeling a high-value application with a mature security team. | A risk-ranked set of attack scenarios with business impact, plus countermeasures aligned to objectives. | High. Each stage produces its own artifacts and the method expects input from business owners as well as engineers. |
| LINDDUN | Privacy threat categorization. Seven categories: Linking, Identifying, Non-repudiation, Detecting, Data Disclosure, Unawareness, and Non-compliance. Developed by researchers at KU Leuven. | Systems that process personal data, where privacy harms (profiling, re-identification, tracking) matter as much as security harms. Pairs naturally with STRIDE on the same diagram. | Privacy threats per data flow with suggested privacy-enhancing mitigations. | Moderate. Similar mechanics to STRIDE, with a different checklist. |
| Attack Trees | Goal-oriented decomposition. The attacker's objective is the root node, and each branch is a way to reach it, broken into AND and OR sub-steps down to concrete actions. Popularized by Bruce Schneier. | Analyzing a specific high-value objective in depth, such as "obtain the CUI drawings," or explaining an attack path to leadership. Complements STRIDE rather than replacing it. | A tree diagram per goal with the cheapest or most likely paths identified, which can be annotated with cost, skill, or detection difficulty. | Moderate per tree; grows quickly if every asset gets its own tree. |
| OCTAVE | Operational and organizational risk. The Operationally Critical Threat, Asset, and Vulnerability Evaluation, from the Software Engineering Institute at Carnegie Mellon, focuses on critical assets, the organizational practices around them, and operational risk rather than software design. | Organization-wide risk assessment led by the business rather than by developers, and programs that need a risk register more than a design review. | Asset-based risk profiles, threat scenarios, and a protection strategy and mitigation plan at the organizational level. | High. Designed as a multi-phase program involving business and IT staff. |
| Trike | Requirements-driven risk management. Builds a requirements model of actors, assets, and permitted actions (create, read, update, delete), then derives threats as deviations from the intended permissions. | Teams that already maintain detailed requirements and access models and want threats derived from them systematically. Less common in practice than STRIDE or PASTA. | An actor-asset-action matrix, derived threats, and a risk model scored against acceptable risk per asset. | Moderate to high; the requirements model must be built and maintained. |
| VAST | Scalable enterprise modeling. Visual, Agile, and Simple Threat modeling separates application threat models (built from process flow diagrams by developers) from operational threat models (built from infrastructure views by operations teams) so modeling can run inside agile sprints across many teams. | Large organizations with many development teams that need consistent, automated modeling integrated with their delivery pipeline. Associated with the ThreatModeler platform. | Per-application and per-environment threat models with threats drawn from a maintained library, and enterprise roll-up views. | Moderate per model once tooling is in place; the method assumes a platform. |
| DREAD (rating scheme) | Not a methodology. A scoring scheme that rates each identified threat on Damage, Reproducibility, Exploitability, Affected users, and Discoverability to produce a priority. Microsoft, where it originated, moved away from it because scores proved subjective and inconsistent between raters. | Teams that want a simple, visible way to argue about priority once the threats exist. Use it, if at all, after STRIDE or another enumeration method, and expect to calibrate scores as a group. | A numeric or High/Medium/Low priority per threat. | Low, but prone to disagreement. A simple likelihood-and-impact matrix is often clearer. |
In practice, most organizations we work with in Raleigh, Durham, and Cary land on STRIDE-per-element for enumeration, a likelihood-and-impact matrix for rating, and an attack tree for the one or two objectives leadership cares most about. PASTA and OCTAVE are the right choice when the deliverable must stand on its own as an organizational risk assessment, which is how we structure the work when a client's compliance risk assessment and threat model are a single engagement. LINDDUN is added whenever the system processes personal data under HIPAA, state privacy law, or a customer's contractual requirements.
STRIDE in Depth
STRIDE works because each of its six categories is the negation of a security property that a well-designed system should provide. If you know what property each element of your diagram needs, you know which STRIDE threats to look for. The examples below are written for the kind of system a small or mid-sized business actually runs: a web application with a database, an identity provider, backups, and administrators.
| STRIDE category | Property violated | What it means | Example threat | Example mitigation |
|---|---|---|---|---|
| Spoofing | Authentication | Pretending to be a user, a device, or a service that you are not. | An attacker uses a password harvested by phishing to sign in to the customer portal as a staff member from an unfamiliar location. | Phishing-resistant multi-factor authentication at the identity provider, conditional access tied to managed devices, and alerting on impossible-travel sign-ins through Managed XDR. |
| Tampering | Integrity | Changing data or code without authorization, at rest or in transit. | An invoice record in the accounting database is altered to redirect a vendor payment to an attacker-controlled bank account. | TLS on every data flow, database permissions that allow writes only through the application service account, and change logging with a separate approval step for bank detail changes. |
| Repudiation | Non-repudiation | Performing an action and then being able to deny it, because nothing reliable recorded who did what. | A user deletes a shared project folder and claims the deletion was a system error; the application only logs "folder deleted" with no account or timestamp. | Per-user accounts with no shared logins, audit logs that record actor, action, object, and time, forwarded to a managed SIEM where they cannot be edited by the application administrators. |
| Information Disclosure | Confidentiality | Exposing data to someone not authorized to see it. | A nightly database backup is written to cloud storage with a permissive access policy and is read by an unauthenticated internet user. | Encryption at rest with keys held separately from the storage, deny-by-default storage policies verified by cloud security posture management, and access logging on the backup location. |
| Denial of Service | Availability | Making a system or data unavailable to the people who need it. | Ransomware encrypts the file server and the connected backup share during the week a bid is due. | Backups that are offline or immutable with routine restore tests, endpoint detection and response, network segmentation between workstations and servers, and a tested incident response plan. |
| Elevation of Privilege | Authorization | Gaining capabilities beyond what the account was granted. | A standard user exploits a flaw in the web application to reach the administrative settings page, or a help desk account is used to add itself to a domain administrators group. | Server-side authorization checks on every request, least-privilege role design, separate administrative accounts used only from a hardened jump host, and web application penetration testing to confirm the checks hold. |
STRIDE-per-element is the practical refinement. Not every category applies to every kind of element: external entities are subject to spoofing and repudiation, data stores to tampering, information disclosure, and denial of service, data flows to tampering, information disclosure, and denial of service, and processes to all six. Walking the diagram element by element with that short list in hand keeps the session moving and keeps the output complete. STRIDE does not rate threats, which is why it is paired with a rating step, and it does not tell you about privacy harms, which is why LINDDUN exists.
The Threat Modeling Process, Step by Step
The seven steps below are the threat modeling process we run in workshops, and they are the same steps a technical lead can run internally. Each step produces an artifact that the next step consumes, so the model can be picked up by someone who was not in the room.
Define scope and security objectivesName the system, state what is in and out of scope, and write the objectives in plain language: which data must remain confidential, which actions must be attributable to a person, what must stay available and for whom. For regulated systems, record which data categories are present, such as CUI, protected health information, or cardholder data, because the objectives follow from the data.
Build the data flow diagramDraw external entities, processes, data stores, and data flows, then add trust boundaries wherever the level of trust changes: internet to perimeter, browser to server, application to database, user to administrator, your tenant to a vendor's. Keep it to one page. A diagram that needs a legend to read is too detailed for a first model; decompose a process into its own diagram later if needed.
Identify assets and trust boundariesList what an attacker would want: the data stores holding regulated data, the credentials that unlock them, the administrative paths, the backups, the signing keys. Confirm that each asset sits inside at least one trust boundary on the diagram and that every flow crossing a boundary is drawn. Missing boundaries around identity, backups, and administration are the most common gaps, and they are where incidents actually begin.
Enumerate threats per elementWalk each element with STRIDE-per-element and write each threat as a sentence with an actor, an action, and a target, tied to the element where it occurs. Add LINDDUN categories if personal data is present. For the one or two assets leadership cares most about, draw an attack tree from the attacker's goal back to concrete steps to catch multi-stage paths that a per-element walk can miss.
Rate and prioritizeRate each threat by likelihood and impact. Where the threat corresponds to a known, published vulnerability, use its CVSS score for the technical severity. For everything else, a simple High/Medium/Low matrix agreed by the group is clearer and more defensible than a numeric scheme that invites false precision. Record the reasoning next to the rating so an assessor can follow it.
Decide mitigations and record themGive every threat one of four decisions: mitigate, eliminate, transfer, or accept. Assign an owner and a target date. Write implemented mitigations into the System Security Plan as the control that addresses the threat, and write unimplemented ones into the POA&M. Acceptances are signed by someone with the authority to accept the risk, not by the engineer who found it.
Validate and keep the model aliveVerify that the diagram matches the system as built, test the mitigations rated High through penetration testing or red teaming, and compare any incident against the model to find threats it missed. Re-run the model on each architectural change, including new integrations, cloud migrations, and AI components, and refresh it at least annually alongside your risk assessment.
The two steps most often rushed are the first and the last. Scoping too broadly produces a diagram no one can finish; skipping validation produces a document that describes a system that no longer exists. If your team has time for only one improvement to an existing model, put trust boundaries on the diagram and re-walk the elements that touch them.
Model Your System With Engineers Who Have Investigated the Threats That Materialize
Petronella Technology Group facilitates threat modeling workshops for defense subcontractors, medical practices, financial firms, and AI deployments in Raleigh, Durham, Chapel Hill, Cary, and nationwide. A scoping call reviews your architecture and compliance obligations and ends with a written plan for the workshop, the deliverables, and how the results will be recorded in your System Security Plan and POA&M.
Worked Example: Threat Model of a Defense Subcontractor File-Sharing Portal Handling CUI
The example below is an illustrative model, not a client engagement. It describes a system that is typical of the machine shops, engineering firms, and component suppliers in the Triangle and across North Carolina that receive technical drawings from a prime contractor and must protect them as controlled unclassified information under DFARS 252.204-7012 and NIST SP 800-171.
Step 1 and 2: Scope, objectives, and the data flow diagram
Scope: the file-sharing portal and everything that touches CUI drawings, from receipt to backup. Security objectives: CUI must be readable only by authorized engineers and the prime; every access and change to a drawing must be attributable to a named person; the portal must be available during the working week; the organization must be able to show an assessor evidence of all three. The diagram, described in text, has the following elements. External entities: engineers working at the Raleigh office, engineers working remotely from home networks, a prime contractor's document control staff uploading drawings, and a portal administrator. Processes: an identity provider enforcing multi-factor authentication, the web portal that users see, and an application server that handles file storage, permissions, and audit logging. Data stores: the document database holding drawings and metadata, the audit log store, and the backup repository. Data flows: engineer to identity provider (sign-in), engineer to web portal (browse, download, upload), prime to web portal (upload), web portal to application server (API calls), application server to database (read and write), application server to audit log store (append), database to backup repository (nightly copy), and administrator to application server (configuration and user management). Trust boundaries: the internet edge between all external entities and the portal; the boundary between the web portal and the application server; the boundary around the database and backup repository; and a separate boundary around the administrative path, since an administrator can change permissions for everyone.
Step 3: Assets
The assets an attacker would want, in rough order of value: the drawings themselves in the database and the backups; the credentials of any engineer with project access; the administrator's credentials and the administrative path; the audit logs, which an attacker would want to alter to hide activity; and the availability of the portal in the days before a delivery milestone. Each asset sits inside a drawn boundary, and the flows that cross those boundaries are the places where threats concentrate.
Steps 4 to 6: Threats, ratings, and mitigations
| Threat | STRIDE | Affected element | Rating | Decision and mitigation |
|---|---|---|---|---|
| An attacker phishes an engineer's password and signs in to the portal from the internet | Spoofing | Engineer to identity provider flow | High | Mitigate: phishing-resistant MFA enforced at the identity provider for every account, conditional access limiting sign-in to managed devices, sign-in anomaly alerting. |
| A drawing is intercepted while the prime uploads it over an untrusted network | Information Disclosure | Prime to web portal flow across the internet boundary | High | Mitigate: TLS enforced on every external flow with current protocol versions and cipher suites, HTTP Strict Transport Security, certificate monitoring. |
| An engineer alters a drawing revision and later denies doing so | Repudiation | Application server and audit log store | Medium | Mitigate: individual accounts only, audit records with actor, object, action, and time, logs cryptographically signed and forwarded to a SIEM the application administrators cannot edit. |
| Files are modified in transit between the application server and the database | Tampering | Application server to database flow | Medium | Mitigate: TLS on the internal flow, database reachable only from the application server's network segment, integrity hashes stored with each file and checked on retrieval. |
| The backup repository is exposed through a storage misconfiguration and read by an outsider | Information Disclosure | Backup repository | High | Mitigate: encryption at rest using FIPS 140 validated cryptographic modules with keys held outside the storage service, deny-by-default access policies, configuration monitoring, access logging. |
| Automated password guessing against the portal sign-in page | Spoofing | Web portal process | Medium | Mitigate: rate limiting per account and per source, lockout with alerting, MFA so a guessed password alone is insufficient. |
| Ransomware encrypts the database and reaches the connected backups | Denial of Service and Tampering | Database and backup repository | High | Mitigate: immutable or offline backup copies on a separate credential, routine backup integrity checks and restore tests, endpoint detection and response on servers, segmentation between workstations and servers. |
| A compromised administrator workstation is used to reach the administrative path | Elevation of Privilege | Administrator to application server flow | High | Mitigate: administration permitted only from a dedicated jump host with its own MFA, separate administrative accounts never used for email or browsing, session logging, approval for permission changes. |
| An engineer emails a CUI drawing to a personal account or an unapproved vendor | Information Disclosure | Engineer external entity | Medium | Mitigate: data loss prevention on email and endpoints keyed to CUI classification labels, a written data classification policy, and role-based security awareness training. |
| An authorization flaw lets an authenticated engineer browse another project's folders | Elevation of Privilege | Web portal process | High | Mitigate: server-side authorization checks on every object request, least-privilege roles scoped per project, web application penetration testing before go-live and after major releases. |
| The prime contractor's account is compromised and used to upload a malicious file | Tampering | Prime to web portal flow | Medium | Mitigate: MFA required for external partner accounts, malware scanning on upload, file type allowlist, uploaded files served from storage that cannot execute content. |
| The portal is flooded with requests in the week before a delivery deadline | Denial of Service | Web portal process | Medium | Mitigate: rate limiting, upstream denial-of-service protection, capacity limits that fail safely, availability monitoring with an on-call path. Transfer: part of the residual risk to the hosting provider's protections and the cyber insurance policy. |
Step 7: Validation and recording
The implemented mitigations are written into the System Security Plan as the controls that satisfy the relevant NIST SP 800-171 requirements, with the threat model cited as the risk assessment evidence for requirement 3.11.1. Mitigations not yet in place, such as the jump host or the immutable backup copy, become line items in the POA&M with owners and dates. The High-rated threats around authentication, authorization, and the administrative path are the scope of a penetration test, and the model is re-run when the organization adds a second prime, moves the portal to a new cloud region, or introduces an AI assistant that can read drawings. For a subcontractor working toward a CMMC Level 2 assessment, this single model answers several assessor questions at once and gives the gap assessment a concrete architecture to test against.
Threat Modeling for AI and LLM Applications
An application that includes a large language model is still an application, and the data flow diagram still works. What changes is the set of elements and the fact that the model reads natural language from places you do not control and may be allowed to act on what it reads. Threat modeling AI and LLM applications means adding those elements to the diagram, treating every input the model sees as untrusted, and enumerating a set of threats that do not appear in a conventional web application. The OWASP Top 10 for LLM Applications is the reference list we use as a completeness check; the categories below are the ones that come up in nearly every model we run, mapped to STRIDE where the mapping is clean.
New diagram elements for an AI application: the model itself (hosted by a vendor or running on your own hardware), the system prompt and any instructions that shape the model's behavior, retrieval sources such as document stores and vector databases, the tools or functions the model is permitted to call, the orchestration layer that routes between them, and the training or fine-tuning pipeline with its data sources. Draw a trust boundary between the model and every source of text it reads, including documents retrieved from your own systems, because a document can carry instructions as easily as a user can type them.
| AI-specific threat | What it looks like | STRIDE mapping | Typical mitigations |
|---|---|---|---|
| Direct prompt injection | A user types instructions that override the system prompt, causing the model to ignore its rules, reveal its instructions, or take an action the user is not authorized to take. | Tampering with the instruction flow; Elevation of Privilege when the result is an unauthorized action | Separate system and user content, constrain the model's capabilities to the user's own authorization, input and output filtering, and adversarial testing. See our guide to prompt injection. |
| Indirect prompt injection | Instructions hidden in a web page, email, PDF, or retrieved document are read by the model and executed as if they came from the user or operator. | Spoofing of the instruction source; Tampering | Treat all retrieved content as data, not instructions; sanitize and label retrieved text; require confirmation for consequential actions; limit which sources the model may read. |
| Training data poisoning | An attacker influences the data used to train or fine-tune a model, or the documents in a retrieval store, so the model behaves incorrectly on chosen inputs. | Tampering with the data store | Provenance and integrity controls on training and retrieval data, access control on the document store, review of fine-tuning datasets, monitoring for behavioral drift. |
| Model and prompt theft | Extraction of proprietary system prompts through conversation, or exfiltration of model weights or fine-tuned models from storage or through excessive API querying. | Information Disclosure | Do not place secrets in prompts; rate limiting and anomaly detection on the model API; encryption and access control on model artifacts; consider private LLM hosting so weights never leave your environment. |
| Insecure output handling | Model output is passed to a browser, a shell, a database, or another system without validation, enabling cross-site scripting, command injection, or SQL injection through the model. | Tampering; Elevation of Privilege | Treat model output as untrusted input to every downstream component, encode and validate it, and never execute generated code or queries without constraints. |
| Excessive agency | An agent is given tools, permissions, or autonomy beyond what its task requires, so a manipulated or mistaken model can send email, move money, delete records, or change configurations. | Elevation of Privilege; Repudiation when actions are not attributable | Least privilege for every tool, human approval for irreversible actions, scoped credentials per task, full logging of tool calls attributed to the initiating user. |
| Model and plugin supply chain | A third-party model, plugin, connector, or dataset contains malicious behavior or vulnerabilities, or a vendor changes a hosted model's behavior without notice. | Tampering; Spoofing of a trusted component | Inventory of models and plugins, vendor assessment through third-party risk management, pinned model versions, testing on upgrade, and governance under an AI governance framework. |
| Sensitive data disclosure through the model | The model reveals personal, regulated, or confidential data from its training set, its retrieval store, or earlier conversation turns to a user not entitled to see it. | Information Disclosure | Enforce the user's authorization at retrieval time, not just at the prompt; minimize what is placed in context; redact regulated data; monitor outputs. |
Two further points are specific to AI. First, the model you are threat modeling may not be the one you think you have: unsanctioned tools adopted by staff carry the same threats with none of the controls, which is why shadow AI detection is part of scoping. Second, validation of an AI threat model needs a different kind of test. Conventional penetration testing confirms that authentication and authorization hold; AI red teaming confirms that the model resists injection, refuses to exceed its agency, and does not leak what it should not. Both belong in the validation step. Our enterprise AI security practice builds these models for organizations deploying private and vendor-hosted AI in the Triangle and nationwide, and Craig Petronella discusses the design decisions behind them with founders and security leaders on the Encrypted Ambition podcast.
Threat Modeling vs Risk Assessment vs Penetration Testing vs Red Teaming
These four activities are often confused, and buyers sometimes purchase one when they need another. They differ in what they examine, when they happen, and what they produce, and a mature program uses all four in sequence.
| Activity | What it is | When | Who performs it | Output |
|---|---|---|---|---|
| Threat modeling | Design-time analysis of a system's architecture to enumerate what could go wrong and decide what to do about it. | During design, before build, and again on every architectural change; also as a first analysis of an existing system that has never been modeled. | The system's architects and engineers, facilitated by a security practitioner who knows the methods and the threats. | A diagram with trust boundaries, a threat list with ratings, and a mitigation plan with owners, feeding the SSP and POA&M. |
| Risk assessment | Organization-level evaluation of threats, vulnerabilities, likelihood, and impact across systems and business processes, following a method such as NIST SP 800-30. | Periodically, typically annually, and when the business or threat environment changes materially. | Risk and compliance staff with input from system owners; often an external assessor for independence. See our cybersecurity risk assessment service. | A risk register with rated risks, treatment decisions, and a report leadership and assessors can read. Threat models are its system-level inputs. |
| Penetration testing | Authorized, time-boxed attack against a built system to find and exploit vulnerabilities within a defined scope. | After build and before release, after significant changes, and on a regular schedule required by frameworks such as PCI DSS. | Independent offensive security testers. See penetration testing. | Findings with proof of exploitation, severity ratings, and remediation steps. Confirms or refutes the threat model's mitigations. |
| Red teaming | Covert, objective-based emulation of a realistic adversary against the whole organization, including people, process, and detection. | Once detection and response capabilities exist and have been tested individually; periodically thereafter. | Experienced operators under rules of engagement with a small white cell. See red teaming and purple teaming for the collaborative variant. | Attack narrative, detection timeline, root-cause findings, and a detection-engineering backlog. Validates whether the threats the model rated highest are detectable in practice. |
The sequence matters. A threat model without a penetration test is an untested hypothesis. A penetration test without a threat model tests whatever the tester happened to look at, which is why so many test reports are long on medium-severity findings and silent on the design flaw that would actually lose the data. Attack surface management and vulnerability management run continuously between these events and keep the "what are we working on" answer current, since the external attack surface changes faster than any annual review. For a plain-language comparison of the testing side, see vulnerability scanning vs penetration testing.
Where Threat Modeling Fits in Compliance Frameworks
No major framework uses the words "threat modeling" as a requirement, with the notable exception of the Secure Software Development Framework, which names it among design practices. Every major framework, however, requires a risk analysis of systems, and a threat model is the most defensible way to perform one for a specific system. The table lists the identifiers an assessor will recognize. We keep each citation to the identifier and its subject and do not paraphrase control text, because the exact wording belongs to the framework.
| Framework | Reference | Subject | How a threat model supports it |
|---|---|---|---|
| CMMC Level 2 and NIST SP 800-171 Rev 2 | 3.11.1; 3.12.1 | Periodically assess risk; periodically assess security controls | The threat model is the system-level risk assessment for 3.11.1, and its validation step, in which mitigations are tested, is evidence toward 3.12.1. Vulnerability scanning under 3.11.2 supplies the known-vulnerability input to the rating step. See our CMMC compliance guide and the changes in NIST SP 800-171 Rev 3. |
| NIST SP 800-53 | RA-3 | Risk Assessment | For organizations assessed against NIST SP 800-53, including FedRAMP environments, the threat model documents the threats, likelihoods, and impacts considered for each system and the resulting control decisions. |
| NIST SP 800-30 | Guide for Conducting Risk Assessments | Risk assessment method | Provides the risk assessment process that the threat model plugs into: threat sources and events, vulnerabilities and predisposing conditions, likelihood, impact, and risk determination. Threat modeling supplies the system-specific threat events. |
| NIST SP 800-218 | Secure Software Development Framework | Design practices in the Produce Well-Secured Software group | Threat modeling is named in the design practices. Software suppliers to the federal government and their customers use the SSDF as the reference for secure development, and a documented threat model per release is direct evidence. |
| HIPAA Security Rule | 45 CFR 164.308(a)(1)(ii)(A) | Risk analysis | A threat model of each system that creates, receives, maintains, or transmits electronic protected health information is a structured, thorough risk analysis in a form regulators and auditors can follow. See HIPAA Security Rule compliance and our HIPAA risk assessment service. |
| PCI DSS v4.0 | Requirement 12.3.1; Requirement 6 | Targeted risk analysis; secure software development | A threat model of the cardholder data environment and the payment application supports the targeted risk analyses that 12.3.1 calls for and the secure development practices under Requirement 6. See PCI DSS compliance. |
| SOC 2 Trust Services Criteria | CC3.2 | Identify and analyze risk | System-level threat models are evidence that the entity identifies and analyzes risks to its objectives, and the mitigation decisions tie to the controls an auditor tests. See SOC 2 controls. |
| ISO/IEC 27001:2022 | Annex A 8.25; Annex A 8.27 | Secure development life cycle; secure system architecture and engineering principles | Threat modeling is a recognized practice under both controls: it operationalizes secure design principles and produces the design-stage security analysis a secure development life cycle expects. See ISO 27001. |
| NIST CSF 2.0 | Identify function, ID.RA | Risk assessment | Threat models are the system-level inputs to the Risk Assessment category, and the four-question structure maps cleanly onto Identify (what are we working on, what can go wrong) and Protect (what are we doing about it). See NIST CSF 2.0 implementation. |
For defense subcontractors, the practical payoff is that one threat model answers the risk assessment questions in a CMMC Level 2 assessment, populates the SSP, and gives the POA&M a defensible origin for each open item. As Craig Petronella details in the CMMC 2.0 Certification Guide, the risk assessment family is where assessors most often find that an organization has a scanner report but no analysis; a threat model closes exactly that gap. As a CMMC consultant and CyberAB Registered Provider Organization, we record the model and its mitigations in ComplianceArmor® so the evidence is in the same place as the rest of the assessment package.
Threat Modeling Tools
Tools help with diagramming, consistency, and keeping the model in a form that can be versioned and reviewed. None of them does the thinking. The right choice depends on who will maintain the model and whether it needs to live alongside code.
| Tool | Type | Approach | Best for |
|---|---|---|---|
| Microsoft Threat Modeling Tool | Free desktop application for Windows | Draw a data flow diagram with trust boundaries; the tool generates candidate threats per element using STRIDE and a configurable template, and tracks their status. | Teams new to threat modeling that want STRIDE-per-element enforced by the tool, and Windows-centric organizations. |
| OWASP Threat Dragon | Open source, web and desktop | Diagram-based modeling with support for STRIDE, LINDDUN, and other category sets; models are stored as JSON and can be kept in a source repository. | Development teams that want an open, lightweight tool with models under version control, and cross-platform shops. |
| IriusRisk | Commercial platform | Questionnaire-driven and diagram-driven modeling against a rules library that proposes threats and countermeasures; integrates with issue trackers so mitigations become tickets. | Organizations with many applications that need consistent models, countermeasure tracking, and reporting across teams. |
| ThreatModeler | Commercial platform | Automated modeling following the VAST methodology, with separate application and operational models, a threat library, and cloud environment import. | Large enterprises and cloud-heavy organizations standardizing threat modeling across many teams and environments. |
| pytm | Open source Python framework (OWASP) | Threat modeling as code: the system is described in Python, and the framework generates the data flow diagram, applies a threat library, and produces a report. | Engineering teams that want the model in the repository, reviewed in pull requests, and regenerated in the build pipeline. |
| Threagile | Open source agile threat modeling toolkit | Architecture described in a YAML file; the tool runs risk rules against it and generates diagrams, a risk report, and tracking output. | Teams practicing infrastructure as code who want the threat model to live and evolve beside their configuration. |
| Whiteboard or general diagramming tool | No specialized software | Draw the data flow diagram by hand or in any diagramming application, walk STRIDE-per-element as a group, and record threats in a spreadsheet or document. | A first model, a workshop with mixed technical and business participants, and any team that has not yet adopted a tool. Still the most common approach and often the most honest. |
Our workshops begin at the whiteboard regardless of what tool the client will use afterward, because the discussion about where trust boundaries belong is the most valuable hour of the engagement and tooling tends to shorten it. The finished model is then transcribed into whatever the client's engineers will maintain, and the mitigation decisions are recorded as evidence in ComplianceArmor® alongside the SSP, so the model and the compliance documentation never drift apart. Good IT documentation practices apply to the model as much as to anything else: version it, date it, and name its owner.
Common Threat Modeling Mistakes
Most threat models that fail to earn their keep fail in the same eight ways. Each is avoidable, and most are visible in the first ten minutes of reviewing the artifact.
Modeling once and never updating
A model dated three years ago describes a system that no longer exists. Tie the refresh to architectural change tickets and to the annual risk assessment, and put the model's owner and date on its first page.
No trust boundaries on the diagram
A diagram without dashed lines is a network drawing. Trust boundaries are where threats concentrate; without them the enumeration step has nothing to grip, and the internet edge, the admin path, and the database boundary all go unexamined.
Listing vulnerabilities instead of threats
"Server missing patch" expires when the patch is applied. "Internet attacker executes code on the application server" is true for the life of the system and leads to mitigations that outlast any single finding. Scanner output is input to rating, not a substitute for threats.
Skipping "did we do a good job"
Without validation, the model is a hypothesis. Check the diagram against the built system, test the High-rated mitigations, and compare every incident and penetration test finding against the model to see what it missed.
No owner for each mitigation
A mitigation with no name beside it is a wish. Every threat gets a decision, every mitigation gets an owner and a date, and every acceptance is signed by someone with authority to accept the risk.
Modeling only the application
Identity providers, backups, administrative paths, and the build pipeline are where real intrusions begin and end. If the diagram stops at the application's edge, the model protects the part of the system attackers go around.
Ignoring insider and supply-chain threats
Not every actor is an outsider. Include the disgruntled engineer, the compromised vendor account, and the malicious software update as external entities with their own flows. An insider threat program and third-party risk management supply the inputs.
Treating a tool's auto-generated list as the model
Tools propose candidate threats from a template. Accepting all of them produces a long list of generic items no one reads; the team's job is to prune, add the system-specific threats the template cannot know, and rate what remains.
Not Ready for a Workshop? Start With the Threats Your Industry Faces This Year
Our free 2026 SMB Cybersecurity Survival Guide covers the attack patterns we see against small and mid-sized businesses and is a useful input to the "what can go wrong" step. If you are a defense subcontractor, the free SPRS score calculator shows where your NIST SP 800-171 self-assessment stands before the threat model begins. When you are ready to model, call us or email and we will scope the workshop.
Three Ways to Threat Model: An Honest Comparison
Organizations that decide to threat model have three realistic paths, and each is the right answer for someone. The comparison is candid about the strengths of doing it yourself and of software platforms, because a facilitated workshop is not always the right call.
| Factor | Do It Yourself With This Guide and Free Tools | Software Vendor Platform | Petronella Technology Group Facilitated Workshop |
|---|---|---|---|
| What you need to start | A technical lead willing to learn STRIDE, a whiteboard, and the engineers who built the system | A subscription, time to configure templates and integrations, and someone to own the platform | A scoping call and a few hours of your engineers' time for the workshop |
| Quality of the first model | Depends on the facilitator's experience; teams commonly miss trust boundaries and the identity, backup, and admin paths on the first attempt | Consistent and thorough against the template, with a risk of long generic threat lists that need pruning | Facilitated by practitioners who have modeled similar systems and investigated real incidents, so the system-specific threats get found |
| Compliance mapping | Yours to do; this page's framework table is a starting point | Varies by product; some map countermeasures to frameworks, few produce SSP-ready language | Mitigations written directly into the SSP and POA&M, mapped to the identifiers an assessor expects, with evidence stored in ComplianceArmor® |
| Keeping the model alive | Depends on discipline; easy to let lapse after the first release | Strong, if the platform is integrated with the delivery pipeline and someone maintains it | Annual or per-release refresh as a scheduled engagement, with the model handed over in your tool of choice |
| Validation | Separate purchase or internal effort | Not included; the platform models, it does not test | Penetration testing, red teaming, or AI red teaming scoped from the model's High-rated threats where warranted |
| Best for | Teams with a capable security-minded engineer and time to learn; a good first step for any organization | Organizations with many applications and teams that need scale and consistency | Regulated organizations preparing for a CMMC, HIPAA, PCI DSS, or SOC 2 assessment, AI deployments, and teams that want an expert in the room for the first model |
Many clients combine paths: a facilitated workshop for the first model and the compliance mapping, then internal maintenance with a free tool, and a scheduled refresh with us before each assessment. That is a sensible pattern, and we will say so on the scoping call if it fits.
How Petronella Technology Group Runs a Threat Modeling Engagement
Petronella Technology Group, Inc. was founded in Raleigh, North Carolina in April 2002 and has spent 24+ years securing regulated small and mid-sized businesses and defense contractors. The company is a CyberAB Registered Provider Organization (RPO #1449) and has held a BBB A+ rating since 2003. Threat modeling engagements are led by Craig Petronella, an MIT-certified cybersecurity professional, CMMC Registered Practitioner, North Carolina Licensed Digital Forensics Examiner (License 604180-DFE), and cybersecurity expert witness. His forensic casework informs the enumeration step directly: incident investigations show which threats actually materialize, and that experience shapes which paths we insist on drawing. As Craig Petronella details in How Hackers Can Crush Your Business, the defender's most useful habit is thinking like the attacker, and a threat modeling workshop is that habit made into a repeatable process.
Scoping call and architecture intakeWe review your system, the regulated data it holds, your compliance obligations, and any prior assessments or incidents, and agree on scope, participants, and deliverables in writing.
Data flow diagram workshop with your engineersA facilitated session with the people who built and run the system. We draw the diagram together, argue about where the trust boundaries belong, and leave with a one-page model everyone recognizes as accurate.
STRIDE-per-element enumerationWe walk every element and boundary with STRIDE, add LINDDUN for personal data and the AI threat categories for LLM components, and build attack trees for the assets leadership cares about most.
Rating and mitigation plan written into your SSP and POA&MEach threat is rated and given a decision and an owner. Implemented controls are written into the System Security Plan; open items go into the POA&M with dates. Where detection is the mitigation, the Managed XDR Suite provides the control and the evidence.
Validation through testing where warrantedHigh-rated threats become the scope of a penetration test, a red team engagement, or AI red teaming, so the model's mitigations are confirmed rather than assumed.
Annual or per-release refreshThe model is revisited on each architectural change and at least annually alongside your risk assessment, with the refreshed evidence recorded in ComplianceArmor®.
ComplianceArmor® is our proprietary compliance documentation platform, with an SSP generator, gap analysis, evidence collection, and continuous monitoring, and it is where the threat model's mitigations are recorded as evidence so the model and the assessment package stay in step. When a threat does materialize, our data breach forensics team handles the investigation, and what it learns feeds the next refresh. Engagements are scoped to clear deliverables with no long-term contract required. We serve Raleigh, Durham, Chapel Hill, Cary, and the Research Triangle, and run workshops nationwide, in person or remotely. We promise a candid model: if the diagram shows a path to your data that your current controls do not address, the report will say so plainly, with a mitigation and an owner next to it.
"Petronella Cybersecurity provides outstanding service! Their team is extremely knowledgeable, responsive, and truly cares about protecting their clients. They take the time to explain complex issues in simple terms and deliver real solutions, not just promises."
GB Entraînement, TrustIndex verified review
Petronella Technology Group is rated 4.7 across 92 verified TrustIndex reviews and 5.0 across 15 Google reviews.
Threat Modeling: Frequently Asked Questions
What is threat modeling in simple terms?
What are the four questions of threat modeling?
What is the difference between STRIDE and PASTA?
When should threat modeling happen in the development lifecycle?
Is threat modeling required for CMMC or HIPAA?
How long does a threat modeling workshop take?
How is threat modeling different from a penetration test?
How do you threat model an AI application?
Explore Related Security and Compliance Services
Cybersecurity Risk Assessment
Organization-level risk assessment that threat models feed, following NIST SP 800-30.
Penetration Testing
Testing scoped from the threat model's High-rated threats to confirm mitigations hold.
AI Security Assessment
Architecture review and threat modeling for private and vendor-hosted AI deployments.
Zero Trust Security
Architecture built around the trust boundaries a threat model identifies.
Virtual CISO
Leadership that keeps the model, the risk assessment, and the testing on the calendar.
Incident Response Guide
What to do when a threat materializes, and how the lessons return to the model.
Threat modeling sits inside a larger program. A security risk assessment places each system's model in organizational context, and NIST SP 800-207 zero trust architecture is the natural design response to the trust boundaries the model exposes. Security awareness training addresses the human external entities on the diagram, and a free phishing security test shows how the spoofing threats in your model fare today. The NIST SP 800-61 incident response process returns real-world threats to the model after an event. Our broader cybersecurity services and compliance services, including healthcare cybersecurity for HIPAA-regulated practices, are described elsewhere on this site, as is our company history since 2002.
Find the Flaws in Your Design Before an Attacker Finds Them in Production
Since 2002, Petronella Technology Group has helped regulated businesses in Raleigh and across the country design, test, and document secure systems. A facilitated threat modeling workshop gives you a diagram your engineers recognize, a threat list your leadership can act on, and evidence your assessor can use. Call 919-348-4912 or book a workshop to begin scoping.
Written by Craig Petronella, MIT-certified cybersecurity professional, CMMC Registered Practitioner, and NC Licensed Digital Forensics Examiner (License 604180-DFE), founder of Petronella Technology Group, Inc. in Raleigh, North Carolina. As Craig Petronella details in How Hackers Can Crush Your Business, the first step in defending a system is learning to think like the person attacking it. As Craig Petronella details in the CMMC 2.0 Certification Guide, the risk assessment family is where threat modeling earns its place in a defense contractor's assessment. As Craig Petronella details in How HIPAA Can Crush Your Medical Practice, the HIPAA risk analysis is a system-by-system exercise, which is exactly what a threat model provides. His 15 published books cover these topics in depth. Framework references on this page are to NIST SP 800-171 Rev 2 requirements 3.11.1 and 3.12.1; NIST SP 800-53 RA-3; NIST SP 800-30; NIST SP 800-218; HIPAA Security Rule 45 CFR 164.308(a)(1)(ii)(A); PCI DSS v4.0 Requirement 12.3.1 and Requirement 6; SOC 2 Trust Services Criteria CC3.2; ISO/IEC 27001:2022 Annex A 8.25 and 8.27; and NIST CSF 2.0 ID.RA. The worked example is illustrative and does not describe any client.
Last Updated: October 30, 2026 | Petronella Technology Group, Inc. | 5540 Centerview Dr., Suite 200, Raleigh, NC 27606 | 919-348-4912 | info@petronellatech.com