The Medical Device Safety and Cybersecurity Overlap Challenge

Many people are familiar with the safety and cybersecurity Venn diagram, indicating the section in the middle where the two risk areas overlap.

There will always be potential areas where a cybersecurity breach could impact safety related functionality. For example, access to registers or RAM in a microcontroller through a cybersecurity vulnerability could disable a safety mechanism. Likewise, safety-related functionality could impact cybersecurity, e.g., by adding a new attack surface through the additional hardware for the safety mechanism. This is easy to show in a Venn diagram, but how do we analyze the potential risks in these two diverse technical areas?

In the medical device world, where risk analysis is generally carried out in a simpler fashion than in sectors such as aviation or automotive, there is often less focus on the types and interfaces between analysis techniques. Using island solutions can result in vulnerabilities or malfunctions at the interfaces between the analyses being missed.

A key part of ensuring comprehensive risk management is considering both safety and cybersecurity in tandem. One important approach is integrating cybersecurity into the design from the start. As outlined in our partner blog by Firefinch, Cybersecurity – Secure by Design, building software with security in mind at every step can significantly reduce risks before they occur.

In this blog we look at how a common strategy for the analysis can be realized.

Marrying up analysis

One of the general problems in the medical device sector is the expectation in risk analysis that there will be a severity–versus–occurrence–probability figure for every risk. Documents such as ISO TIR24971, among other sources, are good at highlighting that risk acceptability criteria should be defined, including the case where the probability of harm cannot be estimated.

This concept aligns well with software analysis where, e.g., a Hazard and Operability Study (HAZOP) may be utilized, removing any attempt to add a probability score. In the hardware world, Failure Mode and Effects Analyses (FMEAs) are very widely used, which include an estimate of probability of occurrence. This is then often the crux of the problem: how do you represent both safety and cybersecurity in the same analysis, and more importantly, how do you bring the individuals responsible for cybersecurity and safety analysis together?

Industries generally suffer from island solutions. Software engineers, hardware engineers, usability teams, etc. all work on their own individual analysis, and this is often where the cracks appear. Many great sources, such as Alessandro Birolini’s ‘Reliability Engineering’, highlight the importance of analyzing interfaces. We are not just referring to interfaces between software classes or hardware components, but wherever technologies or disciplines meet.

Knowing the threat

One important aspect that is identical in both safety and cybersecurity is the activity of identifying threats (cybersecurity) and hazards (safety). Ultimately, this yields product requirements, based on which the architecture can then be defined.

Once the requirements definition has started (this will generally be an iterative process), the risk analysis should commence. This is the activity of defining the mitigations for any identified threats and hazards. One of the best approaches to analyzing risks in different technical areas is the HAZOP. The severity of the threat or hazard is passed down from the hazard or threat analysis, hence this establishes the priority of the threat or hazard we are trying to protect against. The principle of the HAZOP is using a set of guide words to ask the same questions of each block in the architecture. In this manner, the architecture is analyzed systematically using these guide words.