Tire tracks in the grass around a security barrier, demonstrating bypassability of a poorly thought out security control. (Credit: unknown)

Strip Unintended Functionality. Related to least privilege, another technique is to remove unnecessary functionality. For example, a common software development approach is to include existing software libraries rather than develop new software from scratch. A developer can often acquire a library, write some wrapper code, and have new functionality prototyped after just a few hours. That library, however, is often that: a collection of many different functions. The developer might need only one function, but instead includes many functions when he or she uses that library. Those other functions may contain flaws that an attacker can exploit. Both developers and attackers can acquire automated tools that search these libraries for known vulnerabilities. Developers should either move to libraries that do not have those vulnerabilities or strip out the vulnerable functionality.

Non-bypassability. Attackers are like water: they will seep through the smallest crack. Non-bypassability prevents an attacker from easily working around security controls. Human and machine users of device interfaces should be authenticated, and specific actions the user is permitted to execute should be authorized based on the user. These authentication and authorization steps should not be bypassable, except for safety critical “break glass” functionality, which should be observable if used.

Controls. Responding to new attacks can require new or updated approaches. Yet again, industry comes to the rescue, with resources such as the Center for Internet Security’s Critical Security Controls. While these controls were developed for typical IT systems, each control can relate to medical devices. Developers might consider each control, and if the control is not selected for the medical device, document precisely why it is unnecessary. For example, version 6.1 has a control specifically around e-mail and Web browser protections. A connected infusion pump might not have e-mail, so that function can be documented as “Not Applicable.” If, however, the pump uses e-mail as a mechanism for reporting or file transfer, then those controls apply. Note, however, that while these controls are necessary, they should not be treated as a “sufficient checklist” for security.


To help the medical device industry support these architectural principles, the U.S. Department of Homeland Security (DHS) funded several programs to advance Cyber-Physical System (CPS) Security. One of these programs — Intrinsically Secure, Open, and Safe Cyber-physically Enabled, Life-critical Essential Services (ISOSCELES) — is developing a reference architecture to enable medical device products to be built from a secure foundation. ISOSCELES provides a separation layer and essential services for connected medical devices (see Figure 1). ISOSCELES will release as open source requirements model-based systems engineering tools for analysis and configuration and for example hardware and software implementations. Users adopting the ISOSCELES architecture will be able to select their hardware and build their own medical application on top of these services.

For example, with ISOSCELES, networking functions are wholly separate from the safety monitors. In an infusion pump, these safety monitors would limit the maximum rate at which a drug is delivered. ISOSCELES relies on model-based systems engineering tools to specify, analyze, and configure the separation architecture. The specification includes the allowed communications patterns between the partitions, which enables the tools to identify when safety-critical partitions are mistakenly connected to external networking interfaces. This will prevent errors caused by manual configuration, and it will also catch errors when developers create a connection “just for debugging.”


Developing a new medical device with security built in may reduce the time to market for products by addressing the new FDA guidelines for safe and secure devices. Once in the field, devices that adopt these principles will be better prepared to address newly discovered security vulnerabilities, while leaving the safety-critical components of the medical application untouched.


AppCheck, Commercial Tool – Searches Binaries for Known Vulnerabilities, www.codenomicon.com

CIS Controls, www.cisecurity.org

ISOSCELES, www.adventiumlabs.com

LynxSecure, Commercial Separation Kernel, www.lynx.com

SANS, Information Security Training ,www.sans.org

seL4, Open Source Separation Kernel, sel4.systems

AAMI, “AAMI TIR57: Principles for Medical Device Security — Risk Management,” www.aami.org

HIPAA, “Health Information Privacy,” www.hhs.gov

IEEE, “Most Top Computer Science Programs Skip Cybersecurity,” theinstitute.ieee.org

OWASP, “OWASP Top Ten Project,” www.owasp.org , capec.mitre.org , cwe.mitre.org , and cve.mitre.org

FDA, “Postmarket Management of Cybersecurity in Medical Devices,” www.fda.gov

FDA, “Public Workshop – Cybersecurity of Medical Devices: A Regulatory Science Gap Analysis,” May 18–19, 2017, www.fda.gov

Microsoft, “The STRIDE Threat Model,” msdn.microsoft.com

ASD, “Top 4 Strategies to Mitigate Targeted Cyber Intrusions: Mandatory Requirement Explained,” www.asd.gov.au

This article was written by Todd Carpenter, Chief Engineer and Co-owner of Adventium Labs, Minneapolis, MN. For more information, Click Here.


  1. “Security and Privacy for Implantable Medical Devices,” IEEE, http:// ieeexplore.ieee.org/abstract/document/ 4431854
  2. “MEDJACK: Hackers Hijacking Medical Devices to Create Backdoors in Hospital Networks,” Computerworld, www.computerworld.com/article/2932371/cybercrime-hacking/medjack-hackershijacking-medical-devices-to-createbackdoors-in-hospital-networks.html
  3. “Short Seller Muddy Waters Renews Claims of St. Jude Medical Cyber Vulnerabilities,” Marketwatch, http://www.marketwatch.com/story/short-seller-muddy-waters-renewsclaims-of-st-jude-medical-cybervulnerabilities-2016-10-19
  4. “FDA Should Expand Its Consideration of Information Security for Certain Types of Devices,” http://www.gao.gov/assets/650/647767.pdf
  5. “Content of Premarket Submissions for Management of Cybersecurity in Medical Devices,” FDA, https://www.fda.gov/downloads/medicaldevices/deviceregulationandguidance/ guidancedocuments/ucm356190.pdf
  6. “Managing Cybersecurity Risks in Connected Medical Devices,” Medical Design Briefs, http://www.medicaldesignbriefs.com/component/content/article/25210
  7. “Did the Mirai Botnet Really Take Liberia Offline?” Krebs on Security, November 4, 2016, https://krebsonsecurity.com/tag/mirai-botnet/