In the healthcare sector, where the stakes are even higher, cybersecurity is paramount in the development of medical software. A single failure can endanger patients’ lives and expose their confidential data.
For this reason, regulatory authorities place particular importance on the safety of medical devices. This is the case with the Food & Drug Administration (FDA) in the United States, whose mission includes ensuring that software is designed to protect patients and users against malicious use.
What is the STRIDE Threat Model?
Spoofing
To avoid this, measures must be implemented to ensure that the person logging in is the expected user, thereby guaranteeing authenticity in the system.
Tampering
To prevent such actions and ensure system integrity, these modifications must be detectable.
Repudiation
To prevent such scenarios, measures must be implemented to ensure non-repudiation in the system.
Information Disclosure
To ensure system confidentiality, the use of encryption mechanisms is recommended.
Denial of Service
In such cases, alternative access methods must be established to ensure system availability.
Elevation of Privileges
To prevent this, measures must be implemented to ensure proper system authorizations are maintained.
6 Steps to Ensure Medical Software Safety With the STRIDE Threat Model
Now that we have a detailed understanding of the STRIDE threat model, let’s explore how it can be used to identify potential cybersecurity threats during the design phase of medical software development.
1
Identifying Information Assets
An information asset is a resource within an organization’s infrastructure that must be protected due to its value. These assets include digital data, physical documents, intellectual property, and the knowledge and skills of employees.
2
Identifying Attack Surfaces
An attack surface is all the potential entry points through which an attacker can exploit vulnerabilities to gain unauthorized access to a system and cause damage.
3
Applying the STRIDE Threat Model to Each of the Assets and Surfaces Identified
To effectively apply the STRIDE threat model to each identified asset and surface, we recommend creating a cybersecurity analysis matrix.
| informational assets | Attack Surface | STRIDE | Scenario | Sequence of Events | Hazardous Situation |
|---|---|---|---|---|---|
| Patient temperature | Thermometer → BLE | Tampering | [...] | [...] | [...] |
| Patient temperature | Thermometer → BLE | Spoofing | [...] | [...] | [...] |
| Patient temperature | Thermometer → BLE | Elevation of Privileges | [...] | [...] | [...] |
| Patient temperature | Thermometer → BLE | Denial of Service | [...] | [...] | [...] |
The “Scenario” column shows the type of attack that applies to a threat type. There may be several possible attack scenarios, each with different impacts, for the same threat category. In this case, each scenario should have its own line in the matrix.
The “Sequence of Events” column provides a high-level description of how the attack unfolds.
Finally, the “Hazardous Situation” column offers a tangible description of the impact the attack will have on the concerned asset or attack surface.
4
Identifying the Plausible Consequences of the Various Scenarios Formulated
For each consequence, we need to define its impact, assess the damage caused, and determine both the probability and severity levels.
Impact
Harm
Physical injury or damage to a person’s health, or damage to property or the environment.
Probability
-
Improbable
(1:100,000 < P < 1:10,000) -
Unlikely
(1:10,000 < P < 1:1000) -
Occasional
(1:1,000 < P < 1:100) -
Frequent
(P > 1:100)
Severity
- Negligible (user inconvenience)
- Minor (injury without requiring medical intervention)
- Major (injury requiring medical intervention)
- Severe (risk of death or permanent injury)
5
Assessing The Level of Risk of The Identified Consequences
Once the probability and severity of a potential scenario have been defined, it is possible to assess the associated risk. The level of risk can be determined using a matrix that evaluates both the severity and probability of an incident.
6
Defining Risk Mitigation Measures
Knowing all these elements allows us to define necessary mitigation measures, i.e., actions to prevent the occurrence of an incident.
- Modifying the basic design if the risk is unacceptable, to reduce the likelihood of occurrence.
- Adding preventive measures to eliminate or reduce the risk, such as data encryption and multi-factor authentication.
- Providing precautionary information to users if other measures are not feasible (e.g., advising against entering personal information).
Cybersecurity is a crucial element to consider in the development of medical software. The STRIDE threat model provides a systematic risk analysis methodology, helping us identify necessary measures to mitigate risks.
However, relying solely on this model is insufficient for risk mitigation. Additional actions during development are essential. Rigorous software testing is required to prevent incidents that could harm patients and potentially lead to product recalls, litigation, and damage to the manufacturer’s reputation.
