By Christopher Gates & Jason Smith
Gates & Smith hail from Velentium, a Texas-based medical device design and development firm specializing in end-to-end support for companies seeking to bring active implantables to market. Together with Axel Wirth of Medcrypt, they are the authors of Medical Device Cybersecurity for Engineers and Manufacturers, a comprehensive guide to secure development, available August 31, 2020.
While the need to assure the security of medical devices is long-standing, today, we are also facing new challenges, pressures, and opportunities accompanying the expansion of distributed healthcare delivery. Demand for distributed healthcare technologies has been rising for several years, but the dual need to minimize social contact and protect vulnerable populations because of the COVID-19 global pandemic is rapidly accelerating that demand.
However, with smarter devices that support greater remote functionality comes the potential for larger, more frequent, and more destructive cyberattacks — all of which helps explain the need for increased and better-clarified security regulations for medical devices.
Medical device developers are no strangers to pressure to decrease time-to-market for new devices: We swim those waters every day and we know the waves come from all sides. But to many developers, engineers, and manufacturers, embedded cybersecurity — the security domain applicable to everything from “Internet of Things”-capable coffeemakers to implantable pacemakers and neurostimulators — is unfamiliar.
Traditional approaches to secure development often look something like this:
When security problems with potentially high impacts are found, the results and responses are predictable:
We’ve seen it time and again: When rigorous security evaluations are held until the final stage before product launch, the effort needed to secure the product becomes a massive roadblock. Management is forced to decide between:
(A) Accepting significant delays and unanticipated expenses to accommodate rework; or
(B) Passing off on an insecure product and attempting to release it to market.
And with updated cybersecurity regulations going into effect on a regular cadence, the increasingly well-informed security expectations held by potential customers, and the unignorable moral and fiscal responsibilities to patients and business shareholders, Option (B) is no longer available.
Fortunately, we’re not doomed to face Option (A)! There’s a better way: The Cybersecure Development Lifecycle (CDLC).
Some of the benefits of adopting the CDLC include:
The Cybersecure Development Lifecycle approaches product development holistically. Instead of trying to shoehorn security in at the end, the CDLC integrates appropriate security activities into each step of development. With this approach, the results of security evaluations – scoped for each stage of the process – can immediately inform the next development sprint. The selection and assimilation of security solutions into the overall design take place concurrently with traditional development activities. Compliance artifacts (records and reports) are generated at designated intervals, which provides traceability to prove that security wasn’t a development “afterthought,” and that vulnerabilities were identified and addressed. This, in turn, assures regulators and purchasers – gatekeepers of medical device markets – that your device is secure, and therefore safe for deployment.
The essential elements of CDLC activities are:
One of our partners in evangelizing the software side of the Cybersecure Development Lifecycle is Parasoft, whose automated testing tool enables the efficient development of compliant, manageable, high-quality, secure code. We like to call this the “Shift-Left” approach to secure development:
Informed by resources and standards from organizations like NIST, OWASP, and CERT, the project’s security team defines a secure coding convention. Automated tools enable developers to apply that convention smoothly within their existing rhythms, and early-stage penetration testing and fuzzing collates the results and drives improvement both to the software under development and the conventions being applied to it. The result is early detection of code vulnerabilities and the elimination of potential conflicts of interest, which might otherwise pit security requirements, team morale, and the development schedule against one another.
This example is just one part of the total benefit of adopting the Cybersecure Development Lifecycle. To learn more about the CDLC, consider grabbing a copy of Medical Device Cybersecurity for Engineers and Manufacturers, a comprehensive guide to secure development coming soon from Artech House. Another option is to follow the Root of Trust series on our blog or reach out to Chris directly via LinkedIn with specific questions. We’re always thrilled to help medical device manufacturers secure their designs and bring new, life-changing medical devices to market.
One of the tools in our kit is Parasoft Solutions, which we and many of our customers use to eliminate potential exploitable vulnerabilities in code under development by applying secure coding standards such as CERT (an example of the CERT C dashboard from Parasoft is below):
For more details, check out Parasoft’s blog on securing applications using CERT C.
As healthcare applications and medical devices become increasingly interconnected, securing and testing communication APIs becomes critical.
Velentium will soon be offering Parasoft training courses specifically for embedded software in medical device development. As part of the training, you will learn that successful technical leaders start with having a clear vision of project compliance with both internal and external security standards. The sooner teams understand the technical depth, the better they can manage the effort, quality, and time-to-market tradeoffs.
Reach out to us to learn more about upcoming Parasoft training opportunities, or to schedule a consultation with our cybersecurity team for a current or upcoming embedded development project.