What's Your Country Song aka What's Your Cyber Reference List

Thomas Rhett helps us with medical device software this week. (Not to brag but my cousin in Thomas Rhett's band.)

When you're rolling down a two lane highway
And you turn your radio on
Tell me which one hits you baby
Yeah what's your country song

This is a coded message, of course, asking us to share our premarket medical device software cybersecurity references list. Below is mine.

If you have been thinking about cybersecurity for medical device software for a while the references I will be discussing this week are probably old "friends". For others that are new to this topic this list is a good place to start. I am organizing it based on my perceived hierarchy if you think of the documents like a pyramid. The first documents on the list are the base of the pyramid. The other documents tend to refer back to these.

“Framework for Improving Critical Infrastructure Cybersecurity.” NIST
“TIR57:2016/(R)2019 Principles for Medical Device Security—Risk Management.” AAMI
Shostack, Adam. Threat Modeling: Designing for Security
“Premarket Submissions: Management of Cybersecurity in Medical Devices.” U.S. Food and Drug Administration, FDA
“MDCG 2019-16 Guidance on Cybersecurity for Medical Devices.” European Commission
“Principles and Practices for Medical Device Cybersecurity.” IMDRF - International Medical Device Regulators Forum

NIST Framework

“Framework for Improving Critical Infrastructure Cybersecurity.” NIST, Apr. 2018, www.nist.gov/cyberframework/framework.

How many documents do you read that are the result of an executive order by the President of the United States? For me, not many. The NIST framework was the result of "Executive Order -- Improving Critical Infrastructure Cybersecurity" from February 2013. I won't be able to do the framework justice in a blog post. I did discuss it more in last week's blog post. Here I will summarize the basics. The core of the framework are 5 functions that I discussed last week; Identify, Protect, Detect, Respond and Recover. The framework also includes a implementation tiers to gauge progress within the framework. These are similar to other maturity models; Tier 1: Partial, Tier 2: Risk informed, Tier 3: Repeatable and Tier 4: Adaptive. Finally the framework recognizes that things are not one size fits all. Each company tailors things to their own situation through profiles. In the FDA premarket and postmarket guidances they help target the profiles to medical devices.

AAMI TIR57

“TIR57:2016/(R)2019 Principles for Medical Device Security—Risk Management.” AAMI, Sept. 2019. (Sadly, not a free download. $274 from AAMI.)

The NIST framework does not take into account the unique nature of security risks for medical devices and how security can affect patient safety. TIR57 bridges the gap from cybersecurity to patient safety and ISO 14971 "Medical devices — Application of risk management to medical devices". There are many 'right' ways to do security risk analysis. This document recommends analyzing threats, vulnerabilities, assets and adverse impacts. Personally, I don't really like breaking it down this way. I am more comfortable with the threat modeling approach which is next on the list. However, the rest of TIR57 is invaluable to explain how security risks are related to standard safety risks and how they are not the same. I have had folks in other departments want us to just do the security risk analysis within the regular software risk assessment/ FMEA but they are not always the same. For example, some cybersecurity attacks that disclose information or cause denial of service may not have any patient harm that would show up in a software FMEA.

Threat Modeling

Shostack, Adam. Threat Modeling: Designing for Security. Wiley, 2014.

Adam Shostack worked at Microsoft and helped develop the concepts of threat modeling. This book goes through all of the details of threat modeling. The basic steps are summed up in 4 questions: What are you building?, What can go wrong?, What should you do about the things that can go wrong? and Did you do a decent job of analysis? Rephrasing these are: model and diagram what you are building, find the threats in those models, find controls for those threats and then look back and make sure you did a good job. Testing can be a part of that last step. The book goes into good detail on these topics and specifics around them. Also included are other ways to think about your system like kill chains. This book is not medical device specific.

FDA Premarket Guidance

“Premarket Submissions: Management of Cybersecurity in Medical Devices.” U.S. Food and Drug Administration, FDA, Oct. 2018, www.fda.gov/regulatory-information/search-fda-guidance-documents/content-premarket-submissions-management-cybersecurity-medical-devices.

This is the key FDA "draft" guidance for premarket cybersecurity. I will do a whole post about this some day. In my experience when FDA issues a "draft" guidance it isn't optional while it is in draft state. You need to follow it or at least address its key points. This guidance combines the previous references in the context of medical devices. The emphasis as is appropriate is on a risk-based and TIR57 is referenced. Security by design is emphasized and this is tied to the NIST cybersecurity framework discussed above. Threat modeling is also expected as part of the design documentation. There are checklist type sections towards the end covering the NIST framework and cybersecurity labeling.

One important requirement that has yet to be finalized in practice is the use of a machine readable Cybersecurity Bill of Materials. It isn't clear what the format for this will be though. This CBOM includes off the shelf software and should be provided to health delivery organizations like hospitals.

EU Guidance

“MDCG 2019-16 Guidance on Cybersecurity for Medical Devices.” European Commission, Dec. 2019, ec.europa.eu/docsroom/documents/41863.

The European guidance covers many of the same points already discussed. These are secure by design, risk management/ assessment, and verification and validation. One key section that is not discussed as clearly elsewhere is to specify the minimum IT requirements. This reference says that we define the requirements of the IT environment for our medical devices. Please also pay special attention Annex II Examples, Device: "Implantable Sensor used to monitor Pulmonary Artery pressures in Heart Failure Patients". This is something that sounds very familiar to me somehow. /smile

This guidance does cover postmarket cybersecurity too. The FDA Postmarket guidance has been covered in a previous post although I did not discuss this section of the EU guidance. Perhaps I will do that in a later post.

IMDRF Guidance

“Principles and Practices for Medical Device Cybersecurity.” IMDRF - International Medical Device Regulators Forum, Mar. 2020, imdrf.org/consultations/cons-ppmdc.asp.

The most recent reference in this space is from the International Medical Device Regulators Forum. The point of the reference is to harmonize the international promote convergence in this space. It does cover many of the same points as the FDA and EU guidances. This is a risk-based approach across the total product life cycle that is a shared responsibility among all stakeholders. Threat modeling is emphasized. The guidance also covers the post market aspects. Perhaps a separate blog post on this is a good idea too.