Threat Modeling
Manual for documenting threat models in Ketryx using custom item types
1. Introduction
Threat modeling is a foundational practice used to identify security objectives, risks, and system vulnerabilities across the entire medical device system. It supports the definition of countermeasures to prevent, mitigate, monitor, or respond to potential threats throughout the product lifecycle. This manual provides guidance on how to document your threat model using Ketryx.
As part of our cybersecurity risk management approach, we will:
Perform threat modeling throughout the design process
Ensure it encompasses all elements of the medical device system
Use threat modeling to guide risk analysis and the selection of appropriate security controls
Apply it at the system, product, network, application, and connection levels to ensure robust and comprehensive protection
This approach ensures proactive risk identification and mitigation from early design through post-market activities.
The threat model should:
Identify medical device system risks and mitigations as well as inform the pre- and post-mitigation risks considered as part of the cybersecurity risk assessment;
State any assumptions about the medical device system or environment of use (e.g., hospital networks are inherently hostile, therefore manufacturers are recommended to assume that an adversary controls the network with the ability to alter, drop, and replay packets); and
Capture cybersecurity risks introduced through the supply chain, manufacturing, deployment, interoperation with other devices, maintenance/update activities, and decommission activities that might otherwise be overlooked in a traditional safety risk assessment process.
Rationale for the methodology(ies) selected should be provided with the threat modeling documentation.
An effective security risk assessment requires identifying and documenting threats, vulnerabilities, assets, and potential adverse impacts. These elements may be analyzed in any sequence and typically involve cross-functional collaboration:
Clinical experts contribute insight into adverse impacts related to the device's intended use
Security professionals assess threats and vulnerabilities across the system
This is an iterative process that evolves through ongoing discussion and brainstorming, progressively uncovering new threat vectors and system elements that may be at risk.
The outcome of this process is a comprehensive and well-considered list of threats, vulnerabilities, and potential impacts, which directly informs the subsequent step of risk estimation and control selection.
The first step in creating this threat model is establishing the necessary item types. The item types required for this threat model and its definition per TIR57:2016/(R)2019, are as follows:
Asset: person, structure, facility, information and records, information technology systems and resources, material, process, relationships, or reputation that has value
Risk: a combination of the probability of occurrence of harm and the severity of that harm
Risk Control (Mitigation): a process in which decisions are made and measures are implemented by which risks are reduced to, or maintained within, specified levels
Threat: any circumstance or event with the potential to adversely impact organizational operations (including mission, functions, image, or reputation), organizational assets, individuals, or other organizations through an information system via unauthorized access, destruction, disclosure, modification of information, and/or denial of service
1.1. Purpose
The purpose of this manual is to instruct users on how to utilize Ketryx for documenting threat models, with a focus on the STRIDE methodology.
1.2. Scope
This manual describes how to use Ketryx to document threat models in a system. It is intended for users who are responsible for identifying and mitigating threats to a system.
1.3. Regulatory Context
AAMI TIR57: 2016/(R)2019: Principles for medical device security – Risk management
2. Terms and definitions
AAMI
Association for the Advancement of Medical Instrumentation
STRIDE
A threat modeling framework that categorizes threats into six types: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege
TIR
Technical Information Report
3. Rethinking Threat Modeling
Ketryx supports a more streamlined and practical approach to threat modeling while maintaining alignment with established regulatory definitions and standards. Rather than redefining core terminology, this section describes how existing concepts are applied in practice when using Ketryx.
3.1. Threats as Cyber Risks
Within Ketryx, Threats are treated operationally as cyber risks.
A Threat item captures:
The potential adversarial action
The exploitable condition within the system
Quantitative CVSS base scoring to assess the exploitability and technical impact
Qualitative classification using the STRIDE methodology (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege)
3.2. Risks as Safety Risks
In this model, Risks continue to represent safety risks.
A Threat may exist without resulting in patient harm. However, when the exploitation of a Threat could impact device safety, it introduces or contributes to a safety risk, which is documented using the default Risk item type.
This distinction ensures:
Cybersecurity risks are assessed independently
Relations to safety risks are only introduced when there is a credible pathway to harm
Clear traceability exists between cybersecurity concerns and patient safety outcomes
3.3. Linking Threats to Safety Risks
Ketryx supports direct traceability between Threats and Risks, allowing organizations to document how cybersecurity risks translate into safety risks when applicable.
This linkage provides:
Transparency between cybersecurity analysis and safety risk management
Documentation of cyber-to-safety causality
A unified risk view that supports both engineering and regulatory needs
The Risk Management Dashboard allows organizations to view and manage safety risks alongside their related Threats, with customizable fields and filters to support organization-specific workflows.
3.4. Streamlined Workflow
When applying this approach in Ketryx, the threat modeling workflow follows this structure:
Asset – Identify valuable system components or resources that require protection
Threat (Cyber Risk) – Document the cybersecurity threat using STRIDE classification and CVSS scoring
Risk (Safety Risk) – Capture any safety risk introduced by the threat, if applicable
Mitigation – Implement security and/or safety risk controls
Validation – Verify security and/or safety risk controls through appropriate test cases and test execution
This workflow supports iterative threat modeling throughout the product lifecycle, from early design through post-market activities, without requiring changes to formal terminology or regulatory definitions.
4. Project setup
Although this guide does not cover incorporating vulnerability advisories into the threat-modeling workflow, you can access vulnerability advisory data by first configuring your software dependencies. This requires a project within the Ketryx Software Supply Chain Management module. If you don't have a project set up, follow the instructions in MAN-03, section 3.
Once you have a project set up, you can start using threat modeling. The following sections describe how to set up the custom item types.
4.1. Advanced Configuration in Ketryx
For now, Threat Model management is only fully supported within Ketryx. There may be unintended behavior when mapped to connected source systems, such as Jira.
For this guide, we will be following an Asset-First Approach. This method emphasizes identifying and managing assets before mapping associated threats. However, it can be adapted to fit your specific workflow or requirements (e.g., Threat-First).
Once ready, navigate to your Ketryx organization to start configuring these item types along with additional advanced settings.
Note: Please contact your client operations representative or contact support to enable the new risk table UI feature before continuing.
First, go to the Advanced Settings in your organization, and copy the configuration below and paste it into the corresponding fields:
Note: Please refer to Custom Item Types for more information on how to configure custom item types in Ketryx. To enable editing of such items, make sure to configure isEditableInKetryx for the type and corresponding fields.
Organization Level Advanced settings
Custom Item types
Custom item fields configuration
Custom relations
Project Level Advanced settings
Then, go to the Advanced Settings in your project, and copy the configuration below and paste it into the corresponding fields:
Dynamic records table configuration
Additional Traceability Configuration
4.2. Approval rules
By default, custom item types come with no approval rules configured. To do this, go to Settings > Approval rules in the project you are setting up and add the necessary rules for the item types you have created.
5. Item Types and Relationships
The diagram below illustrates the relationships among key elements in the threat modeling and risk management process, including the interaction between cybersecurity and safety risks. Adopting an Asset-First Approach—a methodology Ketryx favors, though other approaches exist—the process begins by defining the Asset.
An Asset represents a resource or valuable element within the system that could be compromised. This approach ensures all subsequent analysis is centered on what is most critical.
Creation of Asset
The Asset is the starting point for identifying a Threat. This Threat represents the potential negative impact on the Asset should it be compromised. In the case that a Threat's realization may lead to potential patient harm, then the appropriate safety risk is traced accordingly. For more information on how to perform risk assessment for both safety and cybersecurity risks, please see MAN-08 Risk Management.
After an Asset is defined, relevant Threats are identified.
Creation of Threat
A Threat represents a potential cybersecurity event that could compromise the Asset by exploiting a weakness in the system as implemented.
Relation to an Asset
Only Threats that are realistically exploitable—meaning the affected functionality is reachable, enabled, and exposed through a threat surface—are included in the threat model.
To address identified Threats, Security Risk Controls are implemented.
Relation to Risk Controls
These controls are measures intended to prevent, detect, or limit the impact of a cybersecurity threat. The effectiveness of Security Risk Controls is verified through Security Validation Test Cases, which confirm that the controls function as intended within the system.
Following the implementation and validation of Security Risk Controls, the Residual Cybersecurity Risk is evaluated.
Scoring a Threat
If the residual risk has the potential to affect system behavior in a way that could lead to harm, it is then analyzed as a Safety Risk.
Threat to Safety Risk Relation
A Safety Risk represents the potential for harm to patients, users, or the environment resulting from a Threat. Identified Safety Risks are addressed through Safety Risk Controls, which are measures designed to reduce the likelihood or severity of harm. The effectiveness of Safety Risk Controls is validated through Safety Validation Test Cases, ensuring that safety mitigations adequately protect against the consequences of cybersecurity-related failures. For more information on safety risk management and validation, please refer to MAN-08 Risk Management and MAN-06 Test Management.
The above graphic does not depict all possible relationships between the item types, for example the relationship between vulnerabilities and risks, and risk controls. It is intended to provide a high-level overview of the key elements in the threat modeling process, not a comprehensive representation of all possible connections.
6. Traceability Between Dependencies and Threats (Optional)
In this guide, SBOM-based vulnerability analysis is performed separately from the threat-modeling process. However, the results of that analysis can still inform and strengthen your threat model. Traceability between these two processes can be achieved by introducing a custom relation between a Vulnerability Impact Assessment (VIA) and the Threat item. If desired, incorporate the following configuration changes in the Advanced Settings at the Organization Level, in addition to the configuration established above.
Custom relations
Custom item types
Last updated
Was this helpful?