A Step-by-Step Guide to Cybersecurity Threat Modeling

Medical Device manufacturers are generally familiar with device risk management, using ISO 14971 as their guide to identify and quantify safety risks of their devices. Now, cybersecurity risks need to be managed as well. But the 14971 processes do not translate directly into this space, and the FDA draft guidance for premarket cybersecurity suggests that the manufacturer create a threat model. While threat modeling is somewhat common in the IT space, this is a new concept for medical device manufacturers. In this paper, we will provide the methodology we use at Promenade Software for Cybersecurity Threat Modeling.

THE THREAT MODEL

Threat modeling provides a systematic way to identify cybersecurity threats. It is an essential part of the Cybersecurity Risk Management Process.

Figure 1: Threat modeling as part of the Cybersecurity Risk Management Process

There are different methodologies for performing a threat model, and AAMI TIR57 is a great resource for describing different approaches. It covers Threat-oriented, Asset/impact-oriented, and Vulnerability-oriented security risk assessments.

At Promenade, we like to use a hybrid Asset and Vulnerability approach, as we feel it most closely parallels the concepts of the familiar FMEA (Failure Mode Effect Analysis). In an FMEA analysis, system components are evaluated for their probability of failure and the subsequent potential severity of harm. Asset-based threat modeling looks at system assets (resources with security value) and the potential impact of that asset losing its confidentiality, integrity, or availability. In this way, impact parallels severity. Likewise, by looking at system vulnerabilities and the associated difficulty of exploitation, we can establish a likelihood, much like determining probability of component failure.

Figure 2: Asset and Vulnerability Approach

A STEP-BY-STEP GUIDE

Step 1

We start by identifying the assets we need to protect. Assets include everything that is needed to keep the device operating effectively and safely, with appropriate patient privacy. For example, patient data, device treatment parameters, and user display are assets. Components that store and protect assets are also assets, such as RAM, hard drives, and security key storage. However, not all electronic components are considered assets, even if they are essential to the system performance. We draw the line at requiring access to system internals – i.e. physically opening the system. For example, a resistor change could alter performance, but we consider that beyond the scope of Cybersecurity threat modeling. The internal system, accessible only by taking the system apart with screwdrivers is considered a trust boundary.

Step 2

Once the assets are identified, each asset is evaluated for the potential impact to safety or privacy should that asset get compromised. Some impacts to consider include:

  • Impact to operation – loss of device effectiveness, loss of device therapy, loss of availability
  • Impact to the physical device, information, or communications
  • Impact to individuals – physical injury or loss of life, inappropriate or suboptimal therapy, loss of PHI, and patient concern
  • Impact to other organizations or the environment, including damage to property, damage to the environment, or to network connected systems

In our threat model approach, we create a table that lists each asset and the associated impact due to loss of confidentiality, integrity, or availability. Below are examples for an infusion pump:

Figure 3: Assets and associated impacts
Step 3

Identify potential vulnerabilities and attack vectors. First establish the trust boundaries. Trust boundaries are the boundary assumptions you can make in your system about the internal trustworthiness of interactions. The interfaces between trust boundaries are potential points of vulnerabilities or attack vectors. For example, a database can have trusted internal interactions. But the SQL interface to the database is an attack vector.

Below are some examples of common attack vectors.

Figure 4: Attack Vectors
Step 4

For adversarial threat sources, consider the skill required to exploit the vulnerability. The threat source can be placed in one of 6 tiers (based on TIR57):

  • Tier I: Attackers that use available code and tools to exploit known vulnerabilities
  • Tier II: Attackers that can create tools to target known vulnerabilities
  • Tier III: Attackers who are technologically savvy and are adept at finding and exploiting vulnerabilities
  • Tier IV: Organized, highly technical, well-funded professionals working in teams
  • Tier V: State actors who perhaps create vulnerabilities in products to enable exploitation of networks and systems
  • Tier VI: States that use their military, intelligence, and vast resources to achieve a specific outcome

The above list is inversely correlated to the likelihood of attack. The effort and sophistication required can help determine the likelihood. For example, if a vulnerability requires only Tier I sophistication, the likelihood is high. On the other hand, if Tier V or VI are required, exploitation is not likely to happen for your medical device, as there are probably easier ways to achieve the desired outcome.

However, threat sources do not have to be adversarial. Consider also sources such as incompatible software caused by mistaken update, or error in setup. These non-adversarial threats can be direct, or they can inadvertently lower the tier required of adversaries.

Final Step

Now that we have the assets, impact, vulnerabilities, and threat sources, we are ready to assess the threats. The STRIDE (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege) methodology helps to consider the types of threats we should consider.

Below is an example of STRIDE elements from the MITRE Playbook for Threat Modeling Medical Devices.

Figure 5: STRIDE elements

Below is an example threat to an asset, indicating attack vector, impact, and source. There could be multiple threats to each asset.

Figure 6: Threats

These threat entries will provide input into the Cybersecurity Risk Analysis spreadsheet, which will calculate the risk using this information. Calculation of risk can be performed with a function of likelihood (inverse of threat source tier) and impact. Other factors can also be applied to the likelihood formula, such as ease of discovery or perceived gain.

After applying mitigating controls to risks, it is important to note that they must be evaluated for introduction of new system safety risks. Cybersecurity and usability are sometimes at odds, and the balance should be evaluated and documented.
Below is the workflow:

Figure 7: Interaction between Cybersecurity Risk Management and Safety Risk Management

Threat modeling should be iterative, allowing for new considerations, and system changes to be incorporated. This process should be in the Security Risk Management Plan.

SUMMARY

Threat modeling provides an effective, systematic methodology for identifying the security threats to your system. It should begin at the start of product development, and continue throughout the product lifecycle. In this paper, we share our approach that has proven successful for our clients at Promenade. We hope you found this helpful as well.

CEO of Promenade Software Frances Cohen
Frances is President of Promenade Software and a leading expert on Software for Medical Devices.
frances@promenadesoftware.com
https://www.linkedin.com/in/francescohen
SUBSCRIBE TO
NEWSLETTER
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
ABOUT
PROMENADE SOFTWARE

Promenade Software, Inc. specializes in software development for medical devices and other safety-critical applications.
Promenade is ISO 13485, and CypherMed Cloud is SOC2 Type II certified.

© 2022 Promenade Software, Inc.
Text Link