MedTech: Good Cyber Practices are Good for R&D
By Shannon Lantzy, MedCrypt Vice President of Consulting
Proactive product security can increase the chances of market success, and be done affordably as part of the design phase.
Dilemma: How much product security is “enough” in the design phase?
When developing a new medical device, it is critical to balance time to market and cybersecurity features. The goal is to find “enough” proactive security, while avoiding both over-investment or risking under-investment. Too little security can lead to costly reengineering or regulatory rejection. Too much may crush the chances of getting to market quickly. Ideally, security requirements would be prescriptive; either investors, customers, or regulators would define exactly what is needed. Unfortunately, medical device security is harder than that; each connected medical device is somewhat unique and therefore requires tailored security architectures.
There are many free resources to help figure out what is needed. Regulators publish guidance (e.g., FDA, IMDRF, MDR). In addition to regulatory bodies, there are plenty of standards, industry consensus frameworks, and playbooks that outline what a medical device manufacturer should do. There are free resources for threat modeling, and guides for deployment. Some of the largest manufacturers publish their frameworks and participate in hacker communities, and startups can learn from what the big manufacturers provide. For example, BD (Becton, Dickinson and Company) publishes its product security framework and several templates for policy and procedures. (Not to mention, following a large manufacturer’s lead may be useful for later acquisition negotiation.) There are amazing community resources, like the Biohacking Village, where you can essentially get help for free.
Unfortunately, these resources don’t specifically prescribe how to engineer controls (e.g., authentication, encryption, locking down unused ports, vulnerability management over a device lifetime). You’ll need security expertise at some point. There are plenty of vendors (like MedCrypt) who offer products and services for a range of budgets. However, R&D leadership can take tangible steps within your organization before needing to hire or invest.
Immediate steps toward proactive product security
While knowing exactly how to design and engineer security into a medical device requires experience and expertise, leaders can make a material impact on how their products are secured. Here are some prescriptive, zero-budget, low-labor initial steps for R&D leaders to foster product security from within their own groups.
- Be vocal about security. Talk out loud about security with your team. Tell them that security is important for patient safety. Have at least a one-sentence security strategy (e.g., “Don’t harm patients, be proactive about our business risk.”) and live by it.
- Start threat modeling with every design iteration, even if you don’t know much about security. The FDA has recognized the process of threat modeling as a systematic, evidence-driven approach to securing medical devices, and expects threat modeling documentation to be included in regulatory submissions. You don’t have to have cybersecurity expertise to start threat modeling.
- “Read the Rules and Follow the Directions” of your regulators. There is a lot of leeway within regulations and guidance but if you miss something completely, your regulator will catch it. For example, FDA requires not just security controls in the product, but also security maintenance over the total product lifecycle, such as vulnerability monitoring, coordinated disclosure, and participation in an ISAO. The regulatory guidances (linked in the paragraphs above) should give you a good sense of what you’ll need programmatically. The Joint Security Plan has a good industry-driven framework and maturity model to use as a checklist.
All of the steps above can be started with your current resources and team. More importantly, taking these steps will lead to better design, a better understanding of risks, more collaborative thinking around design choices, and a better product overall. You are already “doing security” implicitly if you’re building a product that is effective for patients. These steps will not only be good for securing your product, but they’ll also help you build a robust team and help you toward a more profitable and successful launch.
