SBN

Complex but helpful: Negotiating FDA guidance to build a cybersecurity program

FDA cybersecurity guidance is informed by a long list of standards and recommendations. How can manufacturers translate these documents into practices?

Using FDA cybersecurity guidance to build a security program

By Dan Lyon and Garrett Sipple

The original version of this post was published on MedTech Engine.

In October 2018, the US Food and Drug Administration (FDA) released an updated draft of security recommendations for medical device manufacturers. The recommendations advise manufacturers that security should become a design input in the development process, alongside safety. Because security and safety are similar, the FDA guidance recommends a risk-management approach for cybersecurity—just like safety risk management.

This guidance contains notable additions that signal a move toward transparency and information sharing. Since the risks associated with medical devices stem from shared responsibilities between manufacturers, healthcare delivery organisations and patients, it is important that manufacturers share information to help all parties reduce risks in their areas of responsibility. For example, manufacturers communicating a product’s bill of materials and using security-specific labeling are positive steps toward helping healthcare delivery organisations manage their risks.

New divisions

One new concept presented in the FDA guidance is establishing a two-tier system for medical devices. Tier 1 devices present a higher risk, and tier 2 devices present a lower risk. The difference between the tiers is that tier 2 notes that associated controls can be justified through a risk analysis. This seems to imply that tier 1 requires all controls mentioned in the document; however, in practice, all controls should be identified and evaluated through risk assessments.

To ensure safe and effective operation, medical devices often have limitations for security controls. The justification and rationale for tier 1 and tier 2 should be applied evenly. This is because organisations need to understand the safety risk and the risks that security controls can present, such as automatic lockouts or password authentication controls.

FDA cybersecurity guidance is missing an essential concept that is fundamental to assessing risk adequately.

But one essential concept that is fundamental to assessing risk adequately is missing in the FDA guidance. That concept is top management’s responsibility to ensure that appropriate subject matter expertise is brought to bear when evaluating a medical device system’s risk exposure. AAMI TIR 57 discusses this concept, which is derived from ISO 14971.

The ISO 14971 standard focuses on safety risk management for medical devices. It requires that top management ensure appropriate expertise be used for safety risk management. Without this expertise, an accurate understanding of the safety risk isn’t possible. Security subject matter expertise, and top management’s responsibility to support it, is mirrored in AAMI TIR 57. Without this expertise, an organisation will not be able to adequately identify security risks. While this seems intuitive, companies need to understand what it means to build or buy subject matter expertise.

Responsibility at the top

One common scenario in which organisations frequently struggle involves top management failing to recognise the investment necessary for security expertise. Security is like any other domain in that true expertise takes time to build and requires different skill sets across all areas of development. Many manufacturers have multiple job roles in software architecture, software engineering and test engineering. Security must be present in these areas, and someone who is skilled in security testing or penetration testing might not have architecture or coding skills.

Let’s look at an example. Say that you’re designing a device for a new domain, like an implanted device rather than an external device. To do so, you need to bring a whole host of new design inputs to the process. For one, you need an expert in biocompatibility to help identify potential safety risks. Security works in the same way: experts in system security architecture, secure software engineering and security testing need to provide input throughout the development processes.

Experts in system security architecture, secure software engineering and security testing need to provide input throughout the development processes.

The FDA has also recognized UL 2900-1 and UL 2900-2-1 as a means to facilitate submission reviews for medical device security. The UL 2900 series documents, the FDA’s recommendations, and AAMI TIR 57 all recommend a risk-based approach. The risk-based approach is the same, and adherence to UL 2900 helps manufacturers provide evidence of the risk identification and control that the FDA is looking for. But is it enough simply to adopt one of these standards over the other?

Necessary complexity

We’re not the first to admit that all these standards can get confusing—we had to brush up on the contents of all three for this article. So how can manufacturers address the discrepancies? How can they find out about new advances in the state of secure development outside these standards? One solution is to derive a common set of requirements from different standards and requirements. The manufacturer can provide this common set of requirements for the development process or product under design to the teams that are building the product or process.

The activity would review the various standards and generate a single output that has been interpreted by the organisation to meet the compliance needs. This is an activity we see many organisations perform, as evidenced by activity SR1.3, ‘Translate Compliance Constraints to Requirements’, in the Building Security In Maturity Model (BSIMM), a study examining the current state of software security in a variety of industry verticals. Note that SR1.3 is just one of 116 distinct activities measured by the BSIMM, intended to help organisations to build more secure software.

The BSIMM also includes other required activities. Take the examples of subject matter expertise and top management’s responsibilities. Those concepts are addressed in BSIMM activities T1.5 ‘Deliver Role-specific Training’ and CP2.5 ‘Ensure Executive Awareness of Compliance Obligations’.

Developing a comprehensive, proactive approach to building security into systems is the best way for manufacturers not only to build more secure products but also to demonstrate compliance with medical device standards issued by multiple bodies.

Developing a comprehensive, proactive approach to building security into systems is the best way for manufacturers not only to build more secure products but also to demonstrate compliance with medical device standards issued by multiple bodies. The BSIMM is a great resource to help you begin wading through the noise and bring focus to your security and safety processes—thus ensuring that the products you send to market are as safe and secure as possible.

Find out more about the BSIMM


*** This is a Security Bloggers Network syndicated blog from Software Integrity Blog authored by Synopsys Editorial Team. Read the original post at: https://www.synopsys.com/blogs/software-security/fda-cybersecurity-guidance/