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
Part 1: Ready for Red Teaming? Intelligence-Driven Planning for Effective Scenarios
Take time for dedicated planning and evaluation ahead of red team testing to prepare your organisation for effective red team exercises.
The Strategic Value of Platformization for Proactive Security
Read about NetSPI’s latest Platform milestone, enabling continuous threat exposure management (CTEM) with consolidated proactive security solutions.
Backdooring Azure Automation Account Packages and Runtime Environments
Azure Automation Accounts can allow an attacker to persist in the associated packages that support runbooks. Learn how attackers can maintain access to an Automation Account.