Topic

Threat Modeling

STRIDE, attack trees, and risk-driven threat models that satisfy ISO 14971, IEC 62304, and FDA reviewers.

A good threat model is the spine of every credible cybersecurity submission. These episodes go deep on STRIDE, PASTA, attack trees, data flow diagrams, and how to map cybersecurity risk into ISO 14971 risk management. Learn how Blue Goat Cyber and the broader community build threat models that scale across product portfolios and stand up to FDA scrutiny.

threat modelingSTRIDEattack treesISO 14971IEC 62304data flow diagramcybersecurity risk

Why the threat model is the spine of the submission

Every other cybersecurity artifact derives from the threat model. Security requirements come from the threats you identified. Test cases come from the controls you claimed. Residual risk statements come from the threats you decided not to eliminate. When a submission is incoherent, it is almost always because the threat model was written last, retrofitted to justify decisions already made.

A threat model is not a list of scary scenarios. It is a structured analysis of a specific system architecture: what the components are, where the trust boundaries sit, what data crosses them, who the plausible adversaries are, and what each of them could do.

Methods that work for medical devices

STRIDE - spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege - remains the most practical starting framework because it is systematic and teachable. Applied per element against a data flow diagram, it forces coverage rather than intuition. Attack trees complement it by working backwards from a harmful outcome, which maps naturally onto how medical device risk is already reasoned about.

The data flow diagram matters more than the method. Most weak threat models fail because the underlying architecture view is wrong or missing: undocumented debug interfaces, a cloud companion nobody diagrammed, a service laptop that connects directly to the device. You cannot analyse what you have not drawn.

Connecting security risk to ISO 14971

Medical device threat modeling differs from enterprise threat modeling in one decisive way: the consequence of interest is patient harm, not data loss. A vulnerability that leaks non-clinical telemetry may be a low-severity finding; one that lets an attacker alter a therapy parameter is a safety issue regardless of exploit difficulty.

That means cybersecurity risk has to flow into the ISO 14971 risk management file rather than living in a parallel security document. Exploitability replaces probability, harm severity is assessed the same way as any other hazard, and risk controls are verified like any other control. IEC 62304 then governs how the resulting software requirements are developed and maintained. Teams that keep two separate risk registers end up defending contradictions in review.