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
Clarifying CAASM vs EASM and Related Security Solutions
Unscramble common cybersecurity acronyms with our guide to CAASM vs EASM and more to enhance attack surface visibility and risk prioritization.
Filling up the DagBag: Privilege Escalation in Google Cloud Composer
Learn how attackers can escalate privileges in Cloud Composer by exploiting the dedicated Cloud Storage Bucket and the risks of default configurations.
Bytes, Books, and Blockbusters: The NetSPI Agents’ Top Cybersecurity Fiction Picks
Craving a cybersecurity movie marathon? Get recommendations from The NetSPI Agents on their favorite media to get inspired for ethical hacking.