SBN

Treating security like safety: What the FDA’s recognition of UL 2900-2-1:2018 means for developers

UL 2900-2-1 calls for the secure design and security testing of medical devices. What does the FDA’s adoption of the standard mean for your development team?

What UL 2900-2-1 means for developers

By Dan Lyon and Garrett Sipple

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

The cyber security of connected medical devices—notoriously poor for decades—could finally start to improve as global regulatory bodies increase their focus on their security stance. While the 6th June announcement by the federal FDA on a change in the pre-market certification process of devices was low-key (11 pages of dense bureaucratese buried within tens of thousands of pages in the Federal Register), the implications of the FDA’s adoption of UL 2900-2-1 as a ‘consensus standard’ are enormous, both for device manufacturers and for patients.

UL 2900-2-1 is part of a series of documents that were developed over a number of years with input from multiple stakeholders, including Synopsys, and approved by the American National Standards Institute (ANSI). The standard calls for ‘structured penetration testing, evaluation of product source code, and analysis of software bill of materials’, as well as documentation of security controls, lifecycle security processes, and intended use.

While the new standard does not spell out exactly how design or testing must be done, the clear message is that failing to do it adequately could keep your product off the shelves. And the FDA-focused US market is not alone; other geographies such as the EU, China, and Japan are also incorporating security into their pre-market approval considerations.

Threats and future-proofing

Address threats by creating a development process that aligns with standards such as UL 2900-2-1.

One question that we commonly discuss with medical device manufacturers is how to keep up with the changing threat landscape. Security issues are constantly in the news and new vulnerabilities are regularly disclosed. Regulatory agencies are in a position where they need to respond to the changing landscape and they expect manufacturers to also respond, which means that manufacturers need to future-proof their development processes against the constant evolution of security vulnerabilities. How can manufacturers address security’s rapid rate of change in a manner that makes sense, given that development of new medical devices is often measured in years?

The answer is to create and mature a security program that can ensure alignment between the accepted standards like UL 2900 and the manufacturers’ development processes, while also providing security subject matter expertise to project teams.

In order to future-proof a development process, there needs to be a dedicated security group responsible for creating and maturing a security program. The UL 2900 standards provide one framework for an organisation to create a security program and take a more holistic approach to security. A holistic approach is needed since the various security activities within UL 2900 complement each other and find different security gaps in a system.

UL 2900 recommends specific analysis and testing techniques to help discover security risks at various stages of the lifecycle. Some of the recommended techniques include:

  • Security-specific static analysis: Detects problems in source code like buffer overflows.
  • Software composition analysis (SCA): Detects problems with third-party and open source software usage.
  • Fuzz testing: Detects problems with handling unexpected inputs.
  • Dynamic application security testing (DAST): Detects problems related to application execution, such as with authentication.
  • Interactive application security testing (IAST): Detects and verifies vulnerabilities in web applications.

Merely incorporating testing techniques is not enough to ensure security of a medical device submission or lifespan. There are specific skills and expertise required in the design stage to adequately consider security. For example, domains like cryptography must be well understood to be applied effectively.

The complexities of security

While a fully capable security program may take years to build, the most important step is the step to initiate the process.

It is often useful to understand security by looking at how manufacturers build safety into their systems. Just like safety, security is an emergent property of complex systems. Thus, security requires the same kind of focus at every stage in the lifecycle.

A manufacturer would never be able to demonstrate a product as safe and effective through a single test at the end of the lifecycle because they haven’t done the work to find and address the failure modes. Similarly, a single security-focused penetration test at the end is incapable of demonstrating whether or not a product is secure.

Building security risk identification and reduction processes into all of the development activities and stages, just like safety risk, is essential to achieving an acceptable result. And therein lies the answer to future-proofing the development of secure products that take years to get to market.

If any organization around the globe applies the same mindset to building security in as they do to building safety in, it becomes normal to generate the necessary artifacts that are required for successful regulatory approvals. Doing security risk-management right means having evidence of looking for risks using industry accepted tools and techniques, and then applying appropriate controls to reduce the risks.

Establishing a holistic approach to security as a new design input does not happen overnight. It is a journey of organizational change and maturity which will require time, resources, and budget to accomplish. While a fully capable security program may take years to build, the most important step is the step to initiate the process.

Secure my connected medical devices


*** 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/ul-2900-2-1/