
Medical Device Security
At the 2011 Black Hat Conference, Security Researcher Jay Radcliffe demonstrated what many healthcare security professionals have been concerned with; hacking a medical device. Medical devices have developed from isolated islands into systems with embedded operating systems that communicate with other applications. As such, a new threat window opened. Apart from the obvious benefits that such advancements have brought to healthcare, it also brings some responsibilities. Since Mr. Radcliffe’s presentation there has been lots of discussion about the security of insulin pumps and what the manufacturer should do. However I’d like to discuss the broader topic and maybe from a slightly different angle. Speaking generally about medical device security there is a lot of confusion about what can be done to ensure that privacy and security is maintained on, for all intents and purposes let’s call them “smart” devices. Many individuals will say that FDA regulated devices cannot be altered in any way. However; the FDA itself has published articles going back a couple of years now indicating that this is incorrect. Aware of such misinterpretation a November 2009 post clearly reminds readers that “cybersecurity for medical devices and their associated communication networks is a shared responsibility between medical device manufacturers and medical device user facilities.” That’s a powerful statement and what some may think upon first read, unfair. This doesn’t just say it is solely the responsibility of the device manufacturer but also to the organization that uses, distributes, and maintains them. If a pump or other medical device that transmits information and/or receives instructions remotely (such as heart pumps) fails, the patient will most likely go back to the covered entity for a reason. It doesn’t matter if it’s because the pump was damaged, altered maliciously, or just had a design flaw, both organizations will take a public relations hit. So what does this mean for covered entities? Devices used and distributed by covered entities should have had security as part of the design process and allow for updates if necessary. For example, if the device uses a Windows operating system, how will it receive updates and what department will be responsible for that? If you’d like to get more involved in this type of discussion check out the HIMSS Medical Device Security Work Group or the FDA Draft Guidance which is out for comments now.
Explore More Blog Posts

Extracting Sensitive Information from Azure Load Testing
Learn how Azure Load Testing's JMeter JMX and Locust support enables code execution, metadata queries, reverse shells, and Key Vault secret extraction vulnerabilities.

3 Key Takeaways from Continuous Threat Exposure Management (CTEM) For Dummies, NetSPI Special Edition
Discover continuous threat exposure management (CTEM) to learn how to bring a proactive approach to cybersecurity and prioritize the most important risks to your business.

How Often Should Organizations Conduct Penetration Tests?
Learn how often organizations should conduct penetration tests. Discover industry best practices, key factors influencing testing frequency, and why regular pentesting is essential for business security.