Understanding FDA draft "Management of Cybersecurity in Medical Devices"

#1
Hi everyone, I'm trying to get an idea of what this new FDA draft - "Content of Premarket Submissions for Management of Cybersecurity in Medical Devices" (Document issued on October 18, 2018) implies for our company and our new designs.

The way I see it is that medical devices with complex User Interfaces tend to "look & feel" more and more like consumer products (mobile devices, tablets, etc.). This is generating a trend towards using advanced Graphic Frameworks (like QT or similar) running on top of "big" OS (Android, Linux-based OS, or other similar commercial OS) because the processor used is as well very complex (due to the need of high performance graphic engine, multi-core architecture, etc.).
My idea is to start a discussion and maybe suggest alternative solutions for this new trend (at least "new" for me).

a) Does anyone have any experience on using such complex environments?
b) Is it ok to use Linux?
c) Which one (Yocto, Armstrong, commercial, etc.)?
d) Won't we end up with a high work-load to validate SOUP, cybersecurity issue tracking, risk of cybersecurity mandatory updates (and possible recalls!!!)?

---

Let suppose we are using Linux-based OS to run a multi-core processor, and after the risk analysis we end up with a "Tier 1 - Higher Cybersecurity Risk" classification (for example, due to communication interface with the HIS or because we support Pendrive connection).

Here come several questions:

1) The draft states: "... protection mechanisms should prevent all unauthorized use (through all interfaces); ensure code, data, and execution integrity ...". What is the meaning of "interfaces" in this context? Are they only communication interfaces (like Ethernet, USB, serial, etc.) or they are refering to HMI aswell (like touch-screen entries, keys, etc.)?

2) What does it mean when the draft states: "Consider physical locks on devices and their communication ports to minimize tampering". Does this means to lock the access to the communication ports with a key? or maybe to activate the use of those ports using a kinf-of authentication dongle?
Anyone has an example of a device doing something like this?

3) In section B.1 it says "Design the Device to Detect Cybersecurity Events in a Timely Fashion", and in point (b) "Devices should be designed to permit routine security and antivirus scanning". Really?? Should we put an anti-virus inside the Device? Are there any alternatives?

(sorry if my post is messy, my understanding of the subject is also kind of messy at the moment)
Any comment you may have I will appreciate it!
 
Elsmar Forum Sponsor

yodon

Staff member
Super Moderator
#2
a) yes... but complexity is not necessarily a factor - a 'simple' interface can be vulnerable
b) I don't see why not
c) no specific experience
d) yes, but it should be commensurate with the risk. If someone hacking the device could lead to (potential) death or serious injury or breach of medical information as well, you should WANT to take appropriate measures. If you follow 62304, you still are expected to do a lot of that.

1) I think both.
2) I think both could be reasonable. I think you need to consider this on a case-by-case basis
3) Potentially, if it makes sense. An embedded application is treated much differently than a desktop application. Bear in mind they're trying to be general here, covering ALL types of software, including stand-alone software.

Yes, applying cybersecurity to medical devices is in its infancy and so there will be dirty diapers. :) Approach it all from a risk-based, common-sense perspective. What makes sense for your device? What's the potential harm (including access to protected info - you don't want to run afoul of GDPR!!) if hacked? What are the vulnerabilities and how have you mitigated likelihood of a breach?
 

pmg76

Registered
#3
Thanks Yodon for your answer!

I think one of the key questions here is:
"Are vulnerabilities only applicable when connecting the device using any communication port (ethernet, USB, serial, etc.) that is accessible without physically disassembling the device?"

This question has everything to do with the "Tier 1 Higher Cybersecurity Risk" definition:
"The device is capable of connecting (e.g., wired, wirelessly) to another medical or non-medical product, or to a network, or to the Internet"

Nowadays a lot of microcontroller/microprocessors can be updated using JTAG, USB, etc. interfaces with pre-loaded bootloader in an internal ROM. This means you could connect the device to another non-medical device and modify the firmware. However these interfaces would not be exposed to the outside world. Would this be considered as a Cybersecurity risk? What do you think?

Also, if Linux is considered as a very vulnerable operating system (using the rational mentioned at the beginning that the software is vulnerable to attackers that can only access through a communication port), then a possible "work around" would be to remove the communication capabilities from Linux and giving this responsibilities to another safer operating system running in a "separated" hardware.
Does this make any sense?
Would then be ok to use Linux without worrying about possible cyber-attacks?

[Just thinking out loud]
 

yodon

Staff member
Super Moderator
#4
Clearly, a big concern with a networked device is the potential for using the device as an entry point for attack of the larger (hospital) system. I think the first part there is trying to address all possible routes. So if you connect your device to a non-medical device (say a networked computer) to do the software update, you need to consider the possibility of opening doors on Pandora's box (and taking measures to prevent such).

For your second part, yes, certainly architecting a system to isolate vulnerabilities is very much a recommended approach.
 
Thread starter Similar threads Forum Replies Date
S Understanding FDA rules regarding MDDS Status and Clinical Trials 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 2
L Understanding FDA requirements for Software Validation Qualification and Validation (including 21 CFR Part 11) 7
D Surface Roughness understanding Inspection, Prints (Drawings), Testing, Sampling and Related Topics 1
P Understanding DFMEA and PFMEA - Supplier Related IATF 16949 - Automotive Quality Systems Standard 21
DuncanGibbons Understanding the applicability of Design of Experiments to the IQ OQ PQ qualification approach Reliability Analysis - Predictions, Testing and Standards 0
B Measuring and monitoring equipment - Understanding which procedures to be compliant with ISO 13485 ISO 13485:2016 - Medical Device Quality Management Systems 6
M Informational Health Canada has launched an e-Learning tool to aid in understanding the premarket regulatory requirements for medical devices in Canada Medical Device and FDA Regulations and Standards News 0
S Understanding UDI requirements - Class 2 medical device (hearing aids) 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 3
M Informational Understanding Costs And Risks For HFE Usability Studies — Part 1: Testing In-House Medical Device and FDA Regulations and Standards News 0
J Properly understanding SPC - Newbie SPC questions Statistical Analysis Tools, Techniques and SPC 29
S Understanding control chart and measurement capability Statistical Analysis Tools, Techniques and SPC 2
P Minitab Data Analysis - Understanding if a Process is in Control or Not Using Minitab Software 2
R Understanding a few points on ISO 9001's Design and Development Planning ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 1
Z Understanding Cycle Time - Why the time of the other activities are left out Lean in Manufacturing and Service Industries 11
J Understanding ISO 9001:2015 - 10.3 Continual Improvement ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 10
J Understanding ISO9001:2015 - 8.3: Design and Development of Products and Services ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 3
E Root Cause Analysis - Is Insufficient Understanding an acceptable Root Cause? General Auditing Discussions 9
E Understanding of TS 16949 Clause 7.6.2 IATF 16949 - Automotive Quality Systems Standard 5
K Understanding IEC 60601-2-68 requirements ISO 13485:2016 - Medical Device Quality Management Systems 1
A Training material for interpretation & understanding Part 11 requirements 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 2
N Understanding the absolute uncertainty specification for a Fluke 5500A Measurement Uncertainty (MU) 3
N Understanding, Challenging & Approving Supplier Control Plans FMEA and Control Plans 7
M Definition Recommendations - Understanding "recommendations" and "recommended corrective action" Definitions, Acronyms, Abbreviations and Interpretations Listed Alphabetically 8
S Understanding UDI (Unique Device Identification) Other US Medical Device Regulations 10
T Understanding USP <1112> Water Activity as applicable to Medical Devices Other Medical Device and Orthopedic Related Topics 4
K Understanding Risk Management Requirements according to AS9100 AS9100, IAQG, NADCAP and Aerospace related Standards and Requirements 11
S MIL-HDBK-217 - Understanding the various Environmental Conditions Reliability Analysis - Predictions, Testing and Standards 1
D What is your understanding or interpretation of TS16949 7.4.1.2 IATF 16949 - Automotive Quality Systems Standard 6
C Understanding the relationship between 62304 and the MDD ER IEC 62304 - Medical Device Software Life Cycle Processes 7
S Understanding Subgroup Size - Multi Cavity (Minitab) Statistical Analysis Tools, Techniques and SPC 4
R Understanding clause 15.4.2.1 d) of amendment 1:2012? IEC 60601 - Medical Electrical Equipment Safety Standards Series 7
M Understanding accreditation, MoUs, certifications Other ISO and International Standards and European Regulations 28
L Mobile Medical App - Understanding 21 CFR Part 820 Requirements 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 3
D Understanding and implementing ISO 17025 ISO 17025 related Discussions 9
M Understanding Versions of Collateral and Particular Standards IEC 60601 - Medical Electrical Equipment Safety Standards Series 7
S Understanding, Analysis and Monitoring Quality Defects on Composite Components Statistical Analysis Tools, Techniques and SPC 3
S Understanding PMS (Post Market Surveillance) and PMCF (Vigilance and PMCF) Quality Manager and Management Related Issues 1
B Understanding why my CpK and PpK are low, and LCL Statistical Analysis Tools, Techniques and SPC 20
S Understanding Quality Objectives, Metrics and KPI ISO 13485:2016 - Medical Device Quality Management Systems 15
Q Beginner's Understanding - The Purpose and Applications of QMS/ISO Standards Philosophy, Gurus, Innovation and Evolution 12
Q Understanding Configuration Management AS9100, IAQG, NADCAP and Aerospace related Standards and Requirements 16
W Understanding PPAP Appearance Approval APQP and PPAP 22
V Understanding Automotive Coating for Seating Mechanism Components Manufacturing and Related Processes 1
M Understanding of Regression and ANOVA in Minitab Statistical Analysis Tools, Techniques and SPC 8
4 Understanding ILAC policy P14:12/2010 6.3 part a) General Measurement Device and Calibration Topics 28
H Understanding 8.2.3 M&M of Processes for our Internal Audit ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 6
P Understanding ISO 26262 Road Vehicle Functional Safety Other ISO and International Standards and European Regulations 2
arios Understanding adoption of a product to an existing Sterilization Cycle Other US Medical Device Regulations 1
M Learning ISO 13485 - Getting a better understanding of the requirements ISO 13485:2016 - Medical Device Quality Management Systems 6
G Understanding Identification of Design in QSR 21 CRF Part 820.30 Design Control (f) 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 2

Similar threads

Top Bottom