Cybersecurity, Risk and Assessment

Industries such as medical devices require that the companies developing products must develop a risk management plan to deal with Cybersecurity.

Cybersecurity Guidance

For medical devices, the U.S. FDA provides a guidance document for manufacturers to follow. If you’re not used to this then it can be quite daunting for a number of reasons. Firstly, it’s important to understand the risks that poor cybersecurity can place on product quality.

Secondly, from an engineering and management standpoint, the effort needed to implement good practices is not trivial. The aim in this post is to give an overview on thinking about risk management for pre-market for any device.

In all cases, a company will be under market pressure to deliver a product to a certain budget and timeframe. There’s a risk that cybersecurity will get lost pretty quickly, particularly if the focus is on developing a minimal viable product as soon as possible.

The FDA’s guidance for medical devices is very thorough for such a short document. It is based on the NIST guidelines. In short, the two main areas to address are:

• Identify and Protect – Limit access to trusted users only Ensure trusted content
• Detect, Respond, Recover

If you don’t know how to start then here are some tips to follow for the most common use cases.

How does the firmware or software for your device or product get updated or installed? This seems a like a very basic question, but it’s surprising that even well into a project a team has not fully grappled with it. If it’s a standalone device with firmware then the two approaches are likely to be:

• A PC based which connects to the device and installs a new version of firmware. This connection could be via USB or Ethernet.
• The device reaches out to an external server and performs an Over-The-Air (OTA) firmware update.

Therefore, from a risk management standpoint, it’s importance to start table the risk. For example, what would happen if:

1. An unauthorized person installed rogue firmware on the device. What’s the worst thing that could happen?
2. What could happen if the device fails to install the new firmware? Will it go back to known or previously valid version.

Hence, immediately we are able to ask the questions about who should be able to update/install software and how to respond or recover from failures.

How do I securely connect to my device? Again, it seems simple but there’s a number of possible ways to ensure a secure connection. If it’s password based then how do you ensure that passwords are not common for multiple devices? And how do you ensure the passwords are kept secret? In many cases, these requirements will lead down the case of certificates and Public Key Infrastructure (PKI). We’ll cover this in another post.

Cybersecurity Risks

Building a risk document is fairly straightforward and it’s a simply a matrix or table similar to the one below.

Id	Vulnerability	Threat	Risk	Score	Severity	Risk Priority Number (RPN)	Cybersecurity Control

Each of the rows should be a unique risk related to similar functions listed in the previous section. Starting from left to right, the id is simply a number starting from 1 and incremented for each row. The vulnerability is the weakness that exists. A good example is poor or limited design around software updates in a device.

The threat is something that can exploit the vulnerability. In the above example, if the vulnerability is a poor control on the software update process then the threat is that an actor can install an invalid version of software. The risk is answering the question regarding would happen if this threat were carried out.

The score column is a way to numerically measure the severe of this outcome. In the case, of cybersecurity, it’s best to use the Common Vulnerability Scoring System (CVSS). The severity column is optional but it’s useful if the vulnerability leads to a physical outcome, e.g. harm to a patient or a hardware impact. This should be related to a hazards analysis and match the worst possible outcome.

Combining the score and severity is possible using a product of the two numbers which computes a Risk Priority Number or (RPN). This can be used to decide based on a threshold which areas need to be addressed as controls.

The last control added is the Cybersecurity Control itself. In the case of secure communication, this might be to add an authentication scheme.

Finally, another round of assessment is performed after the controls to show that the score is reduced as a result of including the controls. For example, by adding an authentication scheme one would expect to see a reduction in the CVSS.