Safety testing

Safety testing

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



Categories:

What are the global implications of the FDA’s recognition of UL 2900-2-1:2018?

Dan Lyon, Senior principal security consultant and Garrett Sipple, Managing security consultant both at Synopsys explain

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

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.

Dan Lyon

Garrett Sipple

The complexities of security

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.

About the author

With well over 100 years experience between us, we've been around the editorial and medical blocks a few times. But we're still as keen as any young pup to root out what's new and inspiring.

Contribute

You're the expert! Write for The Engine or share your articles, papers and research

Add your content

Add your content

Keep informed

Sign up for Ignition, our regular, ideas-packed newsletter

Sign in with social media

or with a username