A blog on medical devices, biotechnology, bioengineering, healthcare, etc. Join me on discussions about devices, regulations, the FDA, policies, law, and what not! Chaaraka is take on Charaka, an ancient Indian Physician of lore...
Thursday, June 15, 2017
No improvements in cyber-security for Pacemakers and Implantable Cardioverter Defibrillators (ICDs)
Cyber-security of medical devices is a critical issue, and surprisingly, one that still fails to gain appropriate attention, despite repeated publications and shocking revelations. The FDA has made some efforts, but as you will see from the report linked below, the efforts clearly fall short of what is actually needed. Through LinkedIn, I found an article and a report on ICD/Pacemaker security issues, that was revealing.
I will let you read the report, an easy read, and use this post to address some high level concerns based on what I learned. Here are a few concerns/thoughts:
1. It is clear that the FDA and other regulators don't fully understand cyber-security issues associated with medical devices. In fact, I would venture, most of us don't, at least not enough to pass robust regulations. Yes, it is a learning process and should happen in iterations, but the rate of progress and the quality of the outcomes are quite poor, when it comes to implementing cyber-security in devices. Even the basics appear to have fallen through the cracks - such as data encryption, hardware and code/firmware obfuscation, etc., which I had simply assumed were foregone conclusions, having seen a cyber-security upgrade to a product through to market that went well above the basics.
2. It is a bit surprising to learn that off-the-shelf hardware, and third party libraries are freely used. I thought, Class III devices would, by necessity see customization at every level. While this has been educational, it represents another layer of failure in security implementation. I have seen simple $20 - $30 prototype level sensors and such come with epoxy dipped circuits that were essentially impossible to reverse engineer. I can see how due to functionality concerns and medical device regulations, this is not the solution you'd see medical device manufacturers use, but clearly, some form of encryption and lock-out should be mandated.
3. Re-sale and re-use of devices is always an area of debate. Manufacturers would like to stop them altogether, first for financial reasons; reprocessors and resellers would love to be given unbridled access. Common ground is important, and it should be fundamentally unacceptable for un-encrypted (!), patient-data laden devices to show up online for sale (per the report, this has happened). Either data should be encrypted - how this is not mandated, still surprises me, or, at a minimum, anyone reselling any medical devices online should be required to "flash" devices/sub-systems that carry patient data.
4. From a business standpoint, having seen some companies, that were not necessarily visionary, but had learned through dealing with counterfeit capital goods and disposables, enforce encryption and obfuscation, I fail to see how all 4 manufacturers that make expensive and critical devices such as ICDs simply stand by and ignore fundamental security implementations. It further perplexes me that the FDA does not require stringent security features!
5. When it comes to physician programmers, I can see how, within the clinical setting, it would be dangerous to waste time entering user names and passwords when potentially dealing with critically ill patients, there should be a global lock on such devices the minute they are outside a clinical setting. The ability of random third parties (as the researchers at WhiteScope did, for example) to obtain these programmers and access the removable (!) hardware through unlocked (!) USB ports etc., is simply unacceptable. This shows that both the manufacturers and the regulatory agencies lack vision in implementing good, logical security systems. This is a very dangerous notion and immediate correction is essential. But, like the mice at the meeting, one has to sit and wonder, who will bell the cat?!
6. This is a bit of a repetition, but I see this as the core of the issue. Medical Device Manufacturers are not taking leadership on product and patient security. The FDA, veritably, the world's leading medical device regulatory agency is not. Therefore, no one is! We don't need obscure, soporific "guidance documents". I am sure the FDA has published a handful of these and will probably put out a handful more. What appears to be missing is a clear, forward looking visionary form of leadership, that doesn't just get bogged down on encrypting software code and locking down hard drives, but plans ahead to evolving paradigms and problems in cyber-security, such as the spread of ransomware for example. Given that off-the-shelf components, common architecture, readable code and data are used, as well as the fact that all components in the system/network can be purchased easily, all it will take is for an unscrupulous group of individuals to buy these devices, decode the overtly simple security features and then sell the mechanisms to nefarious groups, or decide to hold groups of patients, individuals or entire hospital systems hostage.
Conclusion
The problem of lax/absent cyber-security in medical devices of all kinds, is present and continues to evolve alongside the emergence of digital health and digitization in general. I can sit here and spin doom and gloom all day and all night, but what I am left to wonder about, instead is, given all we know, when and from where will we see this vision and leadership emerge from. Right now, I can only ask the question and have no answers to offer. If you can think of any, do let me know.
References:
1. The Healthcare IT News Article: http://www.healthcareitnews.com/news/pacemaker-device-security-audit-finds-8600-flaws-some-potentially-deadly
2. The WhiteScope Report: https://drive.google.com/file/d/0B_GspGER4QQTYkJfaVlBeGVCSW8/view
3. Image, Courtesy Pexels: https://www.pexels.com/photo/blur-bright-business-codes-207580/
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment