We may have hit a ‘data breach fatigue’ saturation point across the market as of late, but there were a few other security vulnerability stories swirling this past week that seemed to deviate from the standard reports.
One thing that comes to mind with respect medical devices with internet connectivity, is that devices, like any other technology, have evolved. Medical devices are now programmable, configurable and are more advanced to accommodate so many patient conditions, complete with automation, data collection and storage requirements.
I would characterize this evolution as part of the personalized medicine phenomenon within the Internet of Things.
The second thing however, is that if you take any device, regardless of whether its implanted inside a person, or if its external, wireless frequency doesn't all of a sudden concede. Anything that has a chip and is able to be interacted with on wifi or over BlueTooth perhaps, is able to be disrupted either via signal, transmission or some type of injection attack.
Securing devices appear to be a secondary concern to improving patient health when architecting these solutions. It looks like DHS is starting to investigate purported security flaws, and its likely that somewhere along the line, they may have conducted some vulnerability testing that have revealed some minimal vulnerabilities.
More testing will ultimately help them identify more bugs, like any product - but with something like a defibrillator, it is a matter of saving lives, not just protecting IP or sensitive data.
HIMSS (the Healthcare Information and Management Systems Society), which is the pseudo standards body for optimizing health engagements with IT globally, developed an interesting set of bullets that addresses security vulnerabilities associated with connected medical devices.
However, most of what HIMSS/NEMA is pushing out is really more about liability with respect to device manufacturers, and providers. The checklist within the MDS2 disclosure statement offers some insight into the types of security issues that should be considered, but its hardly prescriptive in nature.
In fact, its more of a risk exercise in advising how to specifically phrase the language in contracts if security issues arise. Here are a couple excerpts from the MDS2 that I found interesting relative to device security, and how they are characterizing ‘guidance’:
3-3: Can the device owner/operator obtain unrestricted administrative privileges (e.g., access operating system or application via local root or administrator account)?
GUIDANCE: Indicate in the notes if the device supports more than one privileged account (e.g., administrator, root). Indicate in the notes if the manufacturer imposes any restrictions on users regarding the use of administrator accounts.
5-1: Can relevant OS and device security patches be applied to the device as they become known/available?
GUIDANCE: If the manufacturer does not authorize users to apply OS and device security patches, or has any restrictions on this activity, then the existence of these restrictions should be mentioned in a note. The manufacturer may optionally choose to describe any restrictions directly in the note or reference external documents where a description of these restrictions can be found or simply write, “Information on manufacturer restrictions/limitations can be provided upon request,” for example.
So these exceprts reflect the risk management nature of security considerations that NEMA and HIMMS are recommending manufacturers look at when developing an RM plan. However, there's no order or categorization that makes sense with respect to building a real security model around potential security incidents or challenges.
The answer is we don't know what's possible - an episode of Homeland in Season 2 (SPOILER ALERT) showed the mapping between the Vice President's implant and a wireless exploit perpetrated by head terrorist character Abu Nazir, which ultimately caused a successful assassination attempt of the VP. It seemed pretty real.
Now, it might have been Hollywood, but this is an issue that merits keeping an eye on in the absence of a definitive set of prescriptive security guidance by bodies that manufacturers work with. As the IOT phenomenon continues gain momentum, I see this as an emerging security issue we haven’t really scratched the surface on yet - securing medical devices might need a closer look by the security industry.