The security of connected medical devices in the healthcare and home setting is being jeopardized by the growing threat of security breaches. One of the most recent vulnerabilities that have emerged came when St. Jude Medical recalled certain defibrillators as a result of a transmitter that FDA found to be vulnerable to attack.

MedTech Intelligence recently spoke with Laura Elan, engineering manager at UL, LLC about how device companies should be addressing the cybersecurity issue. Elan will be speaking at the Medical Device Cybersecurity conference in Washington, D.C. later this month.

MedTech Intelligence: What are the biggest areas of concern related to cybersecurity and medical devices?

Laura Elan: Now that we’re beginning to see security requirements emerge for both pre-market submissions as well as for products already in the market, many companies understand that they need to have a managed process for addressing cybersecurity now.  We find that questions still exist around how to approach cybersecurity. The world of cybersecurity standards and frameworks is very broad. The good news is that there’s a lot of good material out there, including standards and guidances that have been written and publications by many different agencies, including IEC, ISO and UL. However, because it’s such a large body of knowledge and there isn’t a lot of framing of, let’s call it sufficiency, it can be pretty exhausting to determine “what is enough?”

MTI: What are device companies doing right when it comes to addressing cybersecurity?

Elan: Companies are starting to ask good questions and examine and understand the environment of risk.  We are also seeing regulators respond with guidance documents to help manufacturers. We’re beginning to see the evolution of standards that take into consideration very specific requirements around security. Last year we [UL] published a set of standards that collects what we feel is a very specific, relevant, practical baseline set of requirements for security. We couldn’t do that alone—we engaged stakeholders from both government, and the private and public sector in developing the requirements set. This collective thinking is a very positive thing.

We ask our customers [device manufacturers] to apply a risk-based approach to security: What assets or data are you using in the product? How attractive is the data? How is the medical device being connected into larger systems? What’s the vulnerability there?

Medical Device Cybersecurity: Design, Oversight, Risk Mitigation & Containment | March 23–24, 2017 | Learn moreMTI: Can you share any best practices in cybersecurity?

Elan: There are a lot of standards out there. When we engage device designers who may have a different lens on software development, [it’s important] to reach out to folks who have been doing IT security for a while, because many of the methodologies (encryption, authentication and authorization) are similar. These are techniques that are well established in the IT security world that can be easily adopted into product development or software system development.

Build security into the design early and use test-based verification tools. These tools include software quality tools that can analyze vulnerabilities and weaknesses in the code that are potentially exploitable and can be remediated early in the design process. It’s a lot harder to fix issues when the design reaches maturity. Security verification can be done through third-party testing or in house, but either way, it’s important to make that a regular part of the entire software development lifecycle process.

Include in software verification planning how security is to be addressed and affirmed.  It’s also critical to understand what it means for a company to be able to demonstrate to their own customers, such as healthcare IT organizations, that they have addressed security in their connectable products. Companies should also think about that early in the design process as they do software verification—and security should become part their overall SDLC. It’s important to consider the entire software supply chain. If a company is designing with contractors in different parts of the world, or if software is replicated or hosted with a third party, it’s important to qualify each part of your software supply chain security controls. How are they contributing and helping you protect the product? What are their potential vulnerabilities, and do you have quality management systems that are addressing these issues as well as all of the other supply quality attributes that medical device manufacturers need to have in place? Those are just beginning questions, and the good news is that many of these processes—such as software lifecycle processes and supply chain processes, are already in place at companies.  It’s not an unknown territory. It’s just adding security and extending it to the data being hosted that can help manufacturers move into that next step.