January 30, 2019 By Brian Russell

VDOO Comments on the FDA DRAFT Guidance

Content of Premarket Submissions for Management of Cybersecurity in Medical Devices

VDOO is pleased to provide these comments on the FDA DRAFT Content of Premarket Submissions for Management of Cybersecurity in Medical Devices. This is an important effort and we applaud the FDA for proactively updating the existing guidance to keep pace with the rapid technological change associated with medical devices. As a cybersecurity company focused on enabling the secure design of IoT devices, our overall view of this guidance is very positive. We have provided these comments with the hope of sharing our experience to bolster an already well formed set of recommendations.

General Recommendations & Comments

1. This pre-market guidance is highly useful in identifying a set of baseline controls that should be applied to the design of a device. What seems to be missing however is a discussion on the need to adopt a secure development lifecycle (SDL). From experience, the adoption of a SDL is a critical aspect of ensuring that a device is actually developed securely. We recommend adding in a section describing the controls that should be put in place as part of any SDL adopted by device manufacturers. This would include the generation and tracking of security requirements derived from controls such as the ones documented here, from applicable Security Technical Implementation Guides (STIGs), from best practice industry guidance and from other sources. Additionally, we recommend including process requirements such as establishing secure coding practices and conducting peer reviews on code. We also recommend the addition of controls specifying the need for security analysis of developed code, ideally using automated firmware analysis which can be integrated directly into the developers’ Continuous Integration (CI) environment. Tools such as our firmware analysis scanner can play a critical role in the secure design process through feedback loops that identify design flaws and then create appropriate requirements/user stories that then impact the security design of the device.

Recommendations and evaluations for secure development processes within the context of secure design are commonplace within government. Common Criteria for example includes a focus on the process itself used to design and develop technology.

2. From a process perspective, consider borrowing from the defense industry. For development of “high assurance” devices, there is highly collaborative process that developers and the Government conduct at the onset and during the development of new products. This process involves the tailoring of a “Security Requirements Traceability Matrix (SRTM). The SRTM is pre-loaded with technical security controls that can be applied to any development. The vendor team tailors these controls to their specific device based on the unique characteristics and operating environment of that device. This allows a master set of controls (the baseline) to be used as the starting point for any device development, providing vendors that may not have a good understanding of where to start with the low-level details they need to design security in from the beginning. The controls listed in this draft guidance would make a good starting point to expand into a medical device SRTM that could then be used and tailored by all vendors. The process of tailoring is a negotiation between the government and vendor where the government ensures the vendor is not removing controls that should actually apply to the stated environment and device characteristics.

Detailed (by line) Recommendations

Line 83: Recommend adding secure digital memory cards in the example list (e.g., USB, CD, SDCards) as they are often used in new devices.

Line 231: "As part of the software validation and risk analysis required by 21 CFR 820.30(g), software 231 device manufacturers may need to establish a cybersecurity vulnerability and management 232 approach, where appropriate.”

This language seems to imply that there are scenarios where a medical device manufacturer does not need to establish a cybersecurity vulnerability management approach. The message this sends seems at odds with the need to ensure that all medical devices are developed and fielded securely. We recommend modification of the phrase "may need" to reflect this.

Line 233: Which design controls specifically? Perhaps pointing to a recognized set (e.g., industry best practice) of design controls would be beneficial, or pointing to the controls contained within this document.

Line 257: What is described in the following lines is a standard threat modeling approach. We recommend calling this out as such "FDA recommends that medical device manufacturers follow a standardized threat management approach that includes: ...

Also, recommend adding some additional information on the various steps of the threat model. E.g., Line 261: Identify assets: assets can include data, web services, etc contained within an IoT device or the ecosystem that supports the device.

It might also be useful to recommend some well-known threat modeling approaches (e.g., Microsoft's or OCTAVE Allegro).

Line 271: Recommend defining what "resilience" means in the context of medical devices. i.e., are they expected to operate through an attack?

Line 284: Understand that privacy of Patient Health Information (PHI) is not within the scope of this guidance, but may consider adding in-scope. Currently the two tiers do not differentiate devices whose compromise might result in leakage of sensitive information, but medical device manufacturers do need to concern themselves with this. Having a single guidance document that takes this into account would be beneficial.

Line 386: Add in "certificates" in the examples given. Certificates are very often used as authentication mechanisms especially for device-to-device interaction.

Line 387: Recommend added term "complex" to password.

Line 390: Recommend using term "privilege management model"

Line 402: Recommend explaining/rewording "limit public access to passwords used for privileged device access".

Line 404: There are additional types of tamper protections that can be implemented so best not to limit to only locks. Recommend re-word: "Consider tamper protections on devices and their communication ports to minimize and detect tamper events (e.g., physical locks, piezoelectric circuits, etc).

Line 405: Recommend adding a control to disable all test ports (JTAG, UART) before fielding to customers.

Line 414: This is a great opportunity to recommend the use of hardware-protected storage for cryptographic primitives/keys whenever possible.

Line 467: This is a good opportunity to recommend that all keys be generated on the devices themselves instead of centrally generated and then provisioned manually or over the network.

Line 512: The recommendation is to log the sending of information to unknown entities. This is interesting and perhaps deserves a corresponding control to white list all "known" entities within the device itself. Otherwise not sure the device itself would know this as usually this is caught at a SIEM.

Line 538: What is the FDA recommended guidance related to device behavior during a failure. Should devices fail-safe by shutting down, should they continue to operate? Is this device-specific? At a minimum, FDA should recommend that medical device manufacturers take failure modes into account and proactively determine how a specific device should behave during a failure. There may be scenarios where a device should shut down in case there is a detected compromise.

About VDOO

VDOO is a mission-driven company established to change the face of IoT security, and aims to become the Security Authority (SA) for connected-devices. Having created a device-focused security framework, VDOO enables the cyber-security implementation and certification of IoT devices. By providing an end-to-end platform that can examine the device’s components and attributes, as well as identify the device's existing and missing security measures, we enable a smoother, easier pre-release security implementation process for IoT makers, based on the gap analysis results. Upon successful implementation of security measures, we certify the device, providing users and makers with peace of mind, and supporting the global move to IoT. Together with the establishment of a complete framework that includes not only the technologies themselves, but also a community that can alert, guide and offer solutions, this will set the tone for the entire industry.


Brian Russell

Brian Russell is a security advisor at VDOO. He is the Chair of the Cloud Security Alliance (CSA) IoT Working Group, author of the book Practical IoT Security and an adjunct professor at the University of San Diego (USD). Brian has 20 years of experience providing information security engineering and leadership. He has provided technical leadership for the creation of cryptographic key management systems for the Department of Defense and the modernization of cryptographic systems for the U.S. Navy.

You may also like