Mitigating NHS Cyber Risks

The UK National Health System is about to start connecting many of its medical devices to the healthcare network as part of its latest efficiency drive, but what does this mean for the cybersecurity of medical networks and to patient safety? Richard Staynings, examines medical devices, their expected lifespan, risks and support by manufacturers and explores what solutions are available to providers like the NHS to reduce cybersecurity risks.

 

 

Open the PDF in a separate page or view the full copy of Health Business Magazine and browse to Richard's article on pages 82 to 83.

Read More

Can Healthcare Tackle IoT, Medical Device Security Challenges?

Join SCMedia Editor Jessica Davis and Cylera's Chief Security Strategist Richard Staynings for a FireSide Chat at VIVE2022 -  the new CHIME / HLTH conference in Miami Beach FL, as they explore the challenges of medical device security.

Read More

Singapore eHealth - Innovative Technologies and Security

The Author addresses the Singapore eHealth Summit. Photo: Dean Koh

Singapore faces many of the same problems affecting patient care in Europe and North America; an aging population, rising demand and increasing costs. The need to implement more value-driven initiatives to increase efficiency and improve patient outcomes will become critical here in Singapore just as it is in other countries with declining populations or unsustainable rising healthcare costs. This includes the need for wider mainstream adoption of new and disruptive technologies like data analytics, machine learning and artificial intelligence, combined with highly innovative procedures to accurately identify, diagnose and treat patients.

The recent Singapore eHealth and Health 2.0 summit was unique in that it brought together some of the best minds and best ideas from all over the world under one roof, to showcase a plethora of quality treatment ideas and disruptive emerging technologies which promise to revolutionize the healthcare industry.

As with the adoption of any new technologies, there are risks which must first be evaluated before a technology can be introduced, and in healthcare, increasingly these risks focus upon cybersecurity.

In Singapore, which suffered its largest ever breach last year with the theft of 1.5m SingHealth patient identities along with the prescription records of its Prime Minister and other V.I.P.s, security is of particular concern. Several smaller healthcare breaches this year including publication of the personal details of over 800,000 blood donors, and the exposure of 14,200 HIV patient records has compounded the need for the industry to get security right.

Confidentiality, Integrity and Availability

The ASEAN region, according to CIO Magazine, with its dynamic position as one of the fastest growing digital economies in the world has become a prime target for cyber-attacks, accounting for 35.9% of all cyber attacks globally in 2017. The targeted attack against SingHealth is perhaps a wake-up call for the region to do a better job of securing Confidentiality, Integrity and Availability (CIA) its healthcare and other critical services.

But the risks impacting healthcare are way more nefarious than just the disclosure of confidential patient information. Far more worrying is the threat to the INTEGRITY of health records and other clinical data, and the AVAILABILITY of HIT systems needed to treat patients.

• What happens when a patient's blood type, allergies or past treatment records are altered by a hacker?
• What happens when a ransomware attack locks up all Health IT systems as it did to many hospitals in the British NHS with the WannaCry attack? 

Patient Care suffers and Patient Safety is placed at risk

The growth of medical devices and other Healthcare IoT (HIoT) is prolific and already outnumbers traditional computing systems. Compound growth in medical devices has reached 20% per year by some estimates. Furthermore, most are connected now to hospital networks and talk directly to core HIT systems like the Electronic Health Record. Hackers know this and have used the fact that HIoT systems are by and large unprotected against cyber-attack to launch their infiltration campaigns.

Many legacy medical devices can only connect to hospital WiFi using insure WEP encryption, which means any teenager with the right tools could gain access to core systems in most unsegmented healthcare networks with little more than a SmartPhone from a hospital waiting room.

Medical devices and other HIoT systems now pose the single greatest risk to patient safety according to many in the industry because of their lack of inherent security, inability to be patched or secured with AV or a host firewall as even a Windows PC can. What is more worrying is not that these devices are incredibly easy to hack or topple over, but the fact that they are most often connected to patients at the time providing critical life-sustaining care or telemetry.

On-stage demonstrations at security conferences like DefCon, Black Hat, and KiwiCon often feature the hacking of some sort of medical device that if connected to a real patient, would undoubtedly result in that patients death. Yet, the US FDA, Australia TGA, UK MHRA, and EU EMA, device manufacturers, and hospitals all downplay the risks, knowing that devices have a 15 to 20 year lifespan and few if any, are ever updated with security patches once sold.

The fact of the matter is that we have almost no idea if, and how many patients have died as a result of a medical device being hacked. No one currently is required to forensically investigate a failed medical device. Instead when is device is suspected of failing, all data is wiped to comply with HIPAA, GDPR, SPA, and other privacy rules and the device is shipped back to the manufacturer to be re-imaged, tested and put back into circulation. This is a subject I have written about in the past and one perhaps best demonstrated by Doctors Christian Dameff, MD and Jeff Tully, MD from the University of California Health System, in their realistic yet alarming presentation at the RSA Conference last year.

The need to better understand and evaluate risk in this growing sector of healthcare has reached a tipping point, as OCR in the United States and the TGA in Australia, starts to ask questions about risk analysis of these devices many of which are covered under the HIPAA Security Rule and the APA. However healthcare IT and Security teams face several daunting challenges before they can mitigate security risks and chase compliance.

1. In most hospitals, medical devices are owned and managed by Bio-Medical or Clinical Engineering, while other groups also outside of IT, manage building management and other hospital IoT systems. Consequently, there is limited security visibility, if any at all!

2. An accurate inventory of what HIoT assets are connected to the network is almost impossible to accomplish manually as devices change all the time and manual spreadsheets and traditional IT asset management systems have proven inaccurate.

3. Evaluating the risks of medical devices is difficult since most are connected to patients and cannot be scanned with normal security tools. Larger equipment like X-Ray machines, MRI, CT and PET scanners are in use 24/7 and cannot usually be taken out of service for regular security scans.

4. Inherent weaknesses in some HIoT protocols like DICOM allows a malicious actor to embed weaponized malware into a legitimate image file without detection, as researchers at Cylera Labs discovered recently.

5. Lack of internal network security allows a hacker to intercept and change a PACS image with false information during transmission between a CT scanner and its PACS workstation, adding a tumor to an image or removing one as security researchers at Ben Gurion University recently discovered.

Fortunately, new AI security tools from Cylera, created especially with healthcare in mind, are able to automate the entire risk management process to identify, profile, assess, remediate and manage HIoT assets in line with NIST SP800-30 standards. Just as healthcare delivery is moving towards disruptive innovative technologies, so are the security risk management tools being used to support the adoption of new technologies and new procedures.

Cylera’s 'MedCommand' solution, empowers healthcare providers to protect the safety of their patients, assets, and clinical workflows from cyber-attacks. 'MedCommand' provides clinical engineering and information security teams with a unified solution to manage and protect the entire connected HIoT environment including medical devices, enterprise IoT,
and operational technology.

The 'MedCommand' solution is built on Cylera’s 'CyberClinical' technology platform, which incorporates machine learning, behavioral analytics, data analysis, and virtualization techniques. Cylera has partnered with leading healthcare providers, experts, and peers to develop the most comprehensive and integrated HIoT security solution for healthcare.

Learn more about Cylera's innovative AI based approach to medical device and other HIoT endpoint management or contact us to schedule a conversation.

This blog was originally published here.

Read More

Medical Device Security and CIO Insomnia

During a conversation over drinks with a number of CIOs at a recent healthcare conference, I discovered that the number one concern that keeps most healthcare executives up at night is the security of their medical devices. That was somewhat unexpected, especially following press-grabbing headlines last year about ‘WannaCry’ and other ransomware attacks rendering a large part of the British NHS and other health systems useless for several weeks or months.

Reason 1: Management

Part of their concern is that medical devices are not typically managed by hospital IT (overseen in most cases by the CIO) but by clinical / biomedical engineering staff who power on and attach devices to hospital networks but have little understanding of the cybersecurity risks that are created by connecting an unprotected medical device to the hospital business clinical network. Connected medical devices can by-and-large be compromised easily, used as a foothold on hospital networks, or re-programed to execute patients or hold them to ransom.

This is not fiction! It has been demonstrated numerous times at security conferences most recently by McAfee at BlackHat and Defcon in Las Vegas last month. New Zealand ethical hacker Barnaby Jack started the trend of exposing medical devices vulnerabilities, when in 2011 at the MacAfee Focus Conference he demonstrated a hack of a wireless insulin pump causing the pump to deliver its entire reservoir of insulin into a mock patient. In 2012 he followed this performance up with a hack of a Pacemaker causing the device to administer an 815volt shock directly to the heart of the mock patient. Both demonstrations would have been fatal to a real patient and that might explain why in 2007 Vice President Dick Cheney had the wireless interface disabled to his own pacemaker at the insistence of Doctors and the US Secret Service. Jack demonstrated the ease at which a patient could be harmed or executed once their Implantable Medical Device or IMD had been hacked. Others followed at subsequent security conferences with hacks of network-attached infusion pumps, reprogramming the device to give a continuous maximum dose of Morphine till the reservoir was empty and the patient likely dead.

Reason 2: Lack of Security

The CIOs second concern is that medical devices have almost no built-in security found on a typical workstation or laptop and cannot readily be patched or upgraded. Nor can security tools and supplicants like anti-malware or a host firewall be installed as the limited capacity of devices will not support the additional memory or processing requirements needed.

To compound these issues, medical device manufacturers are notoriously reluctant and slow to release patches for their devices even when known security vulnerabilities have been discovered. This has resulted in some high profile shaming of manufactures as in the case of Muddy Waters Capital, an Options Trader, against St Jude Medical and the first ever FDA recall of a medical device as a result of the public disclosure. Would the Food and Drug Administration (FDA) have acted if it weren’t for the very public disclosure? It’s hard to tell. Would St Jude Medical have spent any time fixing known security vulnerabilities in some of its pumps? Based upon past performance, it’s highly unlikely. In fact, that was the reason for Muddy Waters penetration test in the first place, thus driving down the share price of St Jude Medical stock, allowing Muddy Waters to profit from its options trades.

The fact of the matter is that most medical devices unless afforded extra layers of protection and defense-in-depth security, are extremely vulnerable to cyberattack. Especially if connected to the main hospital network, let alone allowed to talk to the Internet.

Why are Medical Devices so Vulnerable to Attack and Compromise?

Medical devices take 5 to 6 years to go through testing and clinical trials before they receive FDA approval. The same is true in most other countries. That means that brand new devices arriving in hospitals today were designed at least 5 or 6 years ago using technology that was available at the time. Anyone connecting their 2012 era Windows computer to the Internet tomorrow without any security software or updates would more than likely be compromised inside 10 minutes, yet that’s what we do with medical devices. Only with medical devices, we use them not to surf the web or check email, but to monitor and treat patients - and in some cases keep them alive. That’s where unmitigated risks surface that results in CIO insomnia.

The HIPAA Security Rule (45 CFR (§164.308(a)(1)(ii)(A)&(B) requires a Risk Analysis and ongoing Risk Management be conducted of any and all devices that create, maintain, transmit, or receive ePHI or other sensitive data. Yet most hospitals don’t even have an accurate inventory of their medical device assets so how can they possibly assess their risks? The identification and profiling of medical devices has not been easy for hospitals, most of which have had to rely upon labor-intensive ad-hoc manual discovery processes. New tools and services from IoMT / HIoT vendors in the space that can identify and profile medical devices is beginning to change this however. A full asset inventory and medical device profile can now be exported from these tools and entered into enterprise risk analysis tools to perform compressive risk analysis to meet the very strict requirements of OCR and HIPAA.

The concern however is a lot deeper than mere HIPAA Compliance and the protection of PHI. Patient safety has become a major worry for healthcare providers where changes to the integrity and programming of medical devices can have far reaching effects. Hackers have already demonstrated the removal of safety limits and have over-written calibration data and dosages and changed drug libraries. Not only is the integrity of medical devices a growing concern but also their resiliency. Most devices will crash or blue screen when a simple virus or multi-cast traffic appears on the subnet. In particular, device availability for patient telemetry systems is critical to alert care staff to patient Codes or other conditions where speedy action on their behalf is required to save a life. Integrity and availability attacks are far more concerning than confidentiality attacks against PHI, and is where the real damage can be done.

To date, the OCR has only issued written guidance on the risk analysis of medical devices containing PHI, although audits show that OCR is beginning to take a broader look at all medical devices regardless of whether they create, receive, store or transmit PHI. The FDA continues to issue guidance, NCCoE and NIST have written a guide to secure medical infusion pumps resulting in NIST Special Publication 1800-8, and the Cloud Security Alliance (CSA) and Open Web Application Security Project (OWASP) recently joined forces to publish a revised Medical Device Deployment Guide. The fact remains however, that numerous medical devices are extremely vulnerable and are not being adequately managed from a risk perspective.

The average cost of a data breach according to Ponemon is $3.8 million. The damage and impact to a hospital’s reputation following a medical device attack resulting in patient death is pretty much unlimited. This may sound a little far-fetched but a recent study by the University of California Cyber Team found that several hospitals had self-reported adverse events from compromised healthcare infrastructure cybersecurity events, like ransomware, malware, or compromised EHRs. The study found that adverse events impacted between 100 and 1,000 patients. Furthermore, the 80 percent of survey respondents that reported risks in medical devices, is way higher than what the FDA reports.

Risk Management

Once identified, risks to critical systems should be addressed immediately. When remediation or retirement of a medical device is not possible, effective compensating security controls should be implemented to isolate and protect the device from attack and compromise. Many of the larger hospital systems are turning to micro-segmentation of their medical device network assets using Cisco TrustSec or other tools to essentially white-list network communications to and from each medical device and drop all other traffic. GE Health and Unisys do this by routing all medical device traffic through proxy servers. Others have segmented their medical device VLANs by use of internal firewalls. These solutions all increase the complexity of networks and leave many smaller hospital systems with tight budgets and limited capabilities out in the cold.

What’s being done to harden medical devices and prevent them from being hacked?

Guidance (and its only guidance to date) has been published by the FDA, NIST, NCCoE, CSA/OWASP and others to improve the deployment and security of medical devices. The onus however is squarely being placed upon healthcare providers to secure the medical devices they procure and utilize. At the same time manufacturers are being pressured to improve the security design of their devices and now have to perform a risk analysis of medical devices before FDA approval. But with a 5 to 6-year development cycle, the results of ‘improved security by design’ may take many years to reach hospitals and patients. With a 15 to 20-year lifespan for many medical devices, the security problem is not about to go away any time soon. That means hospitals need to implement compensating security controls immediately and keep them there for the foreseeable future.

Somewhat alarmingly however, a recent Ponemon Report on Medical Device Security showed that despite known vulnerabilities “roughly one third of device makers and healthcare delivery organizations (HDOs) are aware of potential adverse effects to patients due to an insecure medical device, but despite the risk only 17 percent of device makers and 15 percent of HDOs are taking significant steps to prevent such attacks.”

Healthcare IoT and the Internet of Medical Things currently presents perhaps the single biggest open back door to securing healthcare the world over. 

Read More

Understanding Medical Device Security

The FDA recall of a medical device last week has caused a bit of a media storm as the general public scrambles to find out more. The fact that a medical device meant to help sustain life is insecure and could be hacked to kill a patient is alarming to all of us. More worrying is that the medical device subject to the recall, a cardiac rhythm management product, or “pacemaker” to the rest of us, is probably not an anomaly. Many other medical devices more than likely also lack adequate security.

To understand the risks, we first need to understand the problem. To be honest, this could require an extensive series of blog posts over weeks to fully examine and explain this properly, but here’s the 50,000-foot version.

Different types of medical devices and the risks they pose

First, there are the implantable medical devices (IMDs) like the medical pacemaker at the center of this story. This group of medical devices includes the implanted insulin pump that security researcher Barnaby Jack hacked live on stage at the Miami Hacker Halted Conference in 2011, reconfiguring the device to deliver a lethal drug dose. It also includes a pacemaker that was hacked, again by Jack, at the Melbourne BreakPoint Security Conference in 2012 to deliver a lethal 830 volt electric shock to a patient.

Second are the much wider range of network-attached medical devices used in healthcare delivery. These include:

• Diagnostic imaging systems: ultrasound, MRI, PET, CT scanners, and X ray machines 
• Treatment equipment: infusion pumps, medical lasers, and surgical machinery 
• Life support: ventilators, anesthetic and dialysis machines 
• Medical monitors for oxygen saturation, blood pressure, ECG and EEG, and many, many more. 

The greatest data-security risks for medical devices

Network-attached devices far outnumber implantable ones, but both have one thing in common—a very long life span! No one wants a pacemaker that needs to be replaced every couple of years, and hospitals simply can’t afford to rip and replace their multi-million-dollar investment in x-ray machines, and PET and CT scanners if they still work perfectly. Many current medical devices are 15 or 20 years old already, placed into service when the rest of us were deploying Windows 95 and dial-up modems.

The greatest risk to medical devices, however, is that many lack even the basic security protections that a $200 home PC has - things like antivirus software and a host firewall. The danger is that when a malware worm gets into a hospital and spreads its way laterally across the network to reach highly vulnerable medical devices, it either quickly infects them (many of the newer models run a form of Windows XP), or the malware multicast traffic storm causes the medical device to crash or just stop working. It’s not that someone hacked and changed a parameter - although that is a distinct possibility, but it’s more likely that its battery becomes quickly drained and powers off, or the system blue screens and ceases to provide life-sustaining care.

Understanding the Problem

You can't protect what you don't know about and most hospital systems have very little idea just how many medical devices they have on premise and how many attach to their wired or wireless network and therefore pose the highest risk. Or more importantly, how many of those devices contain PHI and are therefore subject to annual HIPAA Risk Assessment and OCR validation that a risk assessment has been conducted annually.

To manage a problem you first need to understand the problem. Performing an accurate and periodic or ongoing asset inventory is a first step. The difficulty is twofold however: medical devices do not just simply show up in a Windows Explorer or Finder view of the network, nor can they be actively scanned in many cases. Secondly, many devices are powered on as needed for patient care and powered off when not and returned to storage. So understanding exactly how many you have, what each does, and what versions of OS and software each is running, while at the same time trying to avoid double counting is not exactly easy.

What is needed is a way to passively monitor the network to identify typical medical device network traffic along with endpoint IP addresses, VLAN and physical location, and to perform some sort of profiling of devices including the identification and recording of unique device characteristics. Fortunately, there are tools and companies that do this now, so you don't need to reinvent the wheel.

Once an inventory is obtained you can identify potential weaknesses, known threats and vulnerabilities and evaluate probability and likelihood as you would for other IT devices subject to HIPAA Risk Analysis. Once you have identified your highest risk devices, you can set about patching or otherwise remediating risks, or implement compensating security controls till such time as a longer term solution can be implemented or the vulnerable assets retired and replaced. Unfortunately, most medical devices today exhibit some level of risk and older devices may prove to be more secure than newer ones thanks to obscure operating systems or firmware compared to today's COTS (commercial off the shelf) embedded OS versions.

How to reduce risk and protect devices

It’s going to take years to patch or replace the arsenal of insecure medical devices and billions of dollars that healthcare providers simply don’t have. So, we need to look at alternatives to secure them for the rest of their life-spans. This is best accomplished by the use compensating security controls, which doubles as an acceptable audit of risks as far as HIPAA and OCR are concerned.

By far the most effective approach is use of network access control (NAC) using microsegmentation, where medical devices are locked down and secured by the software defined network (SDN) they are attached to. (Attempting to manage 350,000 individual medical devices otherwise in a hospital is near impossible.)

Modern network infrastructure supports security technologies like Cisco TrustSec©, where each network port acts as a virtual firewall. Using security group tags (SGTs), and identity services engine (ISE), network traffic is controlled so that only specifically authorized users - biomedical equipment technicians (or BMETs, as they are known) - have access to reprogram devices, and these systems are only able to communicate with designated internal IP addresses using predetermined ports and protocols. The network will drop everything else, like malware traffic and any connection attempts from unauthorized users. Many of the more advanced healthcare providers have already adopted such an approach, and by employing compensating security controls like ISE and TrustSec have been able to secure their networked medical devices from attack at the click of a button.

This blog was originally published here. To view comments or join the discussion on this article or the questions it raises, please follow the link above. 

Read More

Securing Medical Devices - The Need for a Different Approach - Part 2

This is a two-part story. The first part can be read here.

I recently met with the CIO and CISO of a large US healthcare system to chat about how the system was going about securing its 350,000 network attached medical devices. They were busy assessing and profiling all of the disparate devices from a multitude of different vendors that the pre-merger, independent hospitals had purchased over the past twenty years or so. The Health System had multiple teams of third party vendors from many of the big names in bio-engineering, working with its own IT team to review configurations, firmware and OS/ application versions, and to make updates where necessary in order to improve the security posture of these devices.

The CIO however was greatly concerned by the number and churn in these devices – given warranty replacement units and new devices arriving at hospitals seemingly on a weekly basis. He was concerned whether they would ever be able to get in front of their hardening project, and whether reconfiguration and lock-down would ever really secure these network attached systems at the end of the day.

After listening carefully to his plan and all the activities he and his CISO had sanctioned, I suggested cautiously, that perhaps the health system was on the wrong path. My argument was that they would never be able to keep up with and manage 350,000 disparate biomedical devices, growing by twenty percent per annum, using a strategy essentially designed to manage PCs and workstations. One where domain level tools could be used to patch and configure the vast majority of endpoints. The manpower requirements alone I suggested, would consume his entire IT team’s bandwidth and budget at some point, if not very soon.

I suggested that he abandon entirely all thoughts of securing individual endpoints by locally hardening devices, and by disabling services like TFTP, FTP, TelNet and SSH, that many of his medical devices had left the factory with enabled, and instead look at other control points to secure those devices (compensating security controls) that would enable much higher levels of automation, and reduce the margin for human error that a manual process would inevitably lead to.

I suggested that he use his network as the control point rather than attempt to manage so many individual endpoints. By enabling TrustSec - a built-in access system in his newer Cisco switches and routers, he could lock down each endpoint device whether wired or wirelessly attached to the network, and control in a uniformed manner, which ports and protocols each device could communicate on, which users could administer each device, and which other devices each medical device could communicate with, i.e. specifically authorized canister, gateway or clinical information systems only…. and nothing else!

By employing ISE (Cisco Identity Services Engine) to set access policy, which would then be enforced by TrustSec, (something that was already being used to manage guest wireless access), the health system could create uniform enterprise policy implementation across all sites and locations, and avoid the need for possibly hundreds of firewall engineers to write and update access control lists in switches, routers, and firewalls. What’s more, rules written in ISE could be written in easy-to-understand business language, rather than complex access control syntax for direct entry into infrastructure devices by firewall and network engineers.

Furthermore ISE could be used to profile each of model of medical device, such that a profile could be developed and assigned once for each model, and applied globally across the entire enterprise of 350,000+ medical devices, thus automating security for the almost un-securable!

I continued, “What’s more, the same profile you assign to a medical device in one hospital, is used for a similar device in another hospital so long as its all part of the same ISE domain. Thus you can more effectively manage your medical device asset inventory across hospitals, by assigning medical devices when and where needed rather than to tie up money in unused assets in each location.”

“In other words” I explained, “Using ISE and TrustSec, you can provide your users with dynamic segmentation capabilities such that you can take a medical device (or truck load of medical devices) from one site to another site in need of those devices, (for perhaps local disaster management), and have those devices immediately recognized by the network and assigned the right access permissions as soon as they are plugged in or otherwise connected to the network. No need to engage a firewall or network engineer to add MAC addresses to an ACL (access control list) at 2am in the morning – just plug it in and it will work!”

Essentially you will have an enterprise-wide dynamic automated user and device access system, that is enterprise policy-driven in easy to understand language (versus firewall and switch syntax), that will actually save your biomed team money because they can run a minimal asset inventory across the entire health system. What’s more, in so doing, you are actually securing the un-securable and protecting medical devices from attack, as well as protecting the main hospital business network from being attacked from an easily compromised medical device.

A large number of leading US healthcare delivery organizations are already using ISE and TrustSec to secure their medical devices, research and intellectual property, PHI, PII and other confidential information, by security segmentation of their networks and IT systems. Many are working towards micro-segmentation at the individual device level. Many more are using the same segmentation approach and technology to isolate their PCI payment systems, their guest and contractor network access, and for network access quarantine to perform posture assessments on laptops and mobile devices re-attaching to the network after being used to treat patients in the community.

For more information on this approach, read Cisco’s Segmentation Framework and the Software-Defined Segmentation Design Guide.

For information about how Cisco’s Security Advisory Services can to assist you to design secure segmentation in your environment, please review Cisco's Security Segmentation Service or contact your Cisco sales team.


This blog was originally published here. To view comments or join the discussion on this article or the questions it raises, please follow the link above.

Read More

Securing Medical Devices - The Need for a Different Approach - Part 1

It’s hard not to notice a growing collection of medical devices whenever you visit a hospital or clinic. They surround today’s medical bed, almost like a warm scarf around a bare neck on a cold winter’s day. If they weren’t there you would wonder why. They provide all kinds of patient telemetry back to the nurses station: O2 sat levels, pulse rate, blood pressure, etc. They provide automatic and regular administration of medication via pumps and drips and oxygen dispensers. The medical bed itself tracks patient location across the hospital as the patient is wheeled to and from the OR, imaging or other specialties.

What is not recognized however, is that the number of medical devices employed in the delivery of care to patients is currently growing at almost twenty percent per annum globally. What's more, this growth rate is increasing. For the BioMed staff that has historically been responsible for managing them, it’s an almost impossible task. One that gets more difficult by the day as more and more devices are plugged in or wirelessly connected to the network.

The problem as far as risk is concerned, is not just the growth of these standalone devices and the difficulty managing so many, but the fact that these systems, many of which are critical to patient well-being, by and large have ALMOST NO BUILT-IN SECURITY CAPABILITY. Nor can they be secured by standard compute endpoint tools like anti-virus / anti-malware. They are a huge vulnerability, not only to themselves, but also to everything else attached to the network on one side of the device, and the patient on the other side.

Standalone medical devices are designed, built and FDA approved to perform a very narrow and specific function, and to do so reliably for long continuous periods of operation - unlike a Windows PC, which sometimes appears to have been designed to work for a month more than its manufacture warranty! Medical devices tend to stop working when subjected to things outside of their design parameters. Things like multicast network traffic caused by worms, viruses and other malware. Things like ICMP, NMAP and other network traffic used to illuminate, query, or profile devices perhaps by attackers. What’s more, medical devices are rarely retired and withdrawn from service, which means many hospitals are still using devices designed and built twenty years ago – at a time when Windows 95 had just been released and most of us weren’t even on the ‘World Wide Web’ as we called it then! How could they POSSIBLY be secured and prepared to defend against the types of cyber attack we see today?

Many standalone medical devices leave the manufacturing plant with all kinds of security vulnerabilities – many open TCP/UDP ports, and numerous enabled protocols by default like TFTP, FTP, Telnet. Most of these are highly vulnerable to attack. In June 2013 DHS tested 300 medical devices and all of them failed basic security checks. In 2015 we had 'white-hats' demonstrating hacks of implantable medical devices (IMDs) live on stage at security conferences. Since this time several popular medical pumps have been very publicly exposed for the ease at which they could be compromised by an attacker. (Some manufactures have issued recalls and firmware upgrades but not all.) If one of these pumps were employed to administer at a gradual and regular level, for example, pain medication such as morphine or perhaps insulin to a patient, what damage would be inflicted upon that patient if the pump was hacked and told to administer its entire medication all at once?

While older standalone medical devices were built to run on obscure, custom, often hardened UNIX operating systems, or even eProm, many of today’s mass-produced, quick-to-market commercial devices run on Windows 9 Embedded – nothing more than a cut-down version of the hugely vulnerable and highly insecure Windows XP operating system.

Windows Embedded is subject to many of the same vulnerabilities and freely available exploits as the regular Windows XP operating system. A targeted attack against modern medical devices is thus relatively easy given a mass of known and proven exploits. Yet we continue to attach insecure, unprotected pumps and all kinds of other devices with the potential to do damage to patients, knowing that at any time a nefarious hacker or almost innocent intruder could turn the device into an execution tool.

Just because it hasn’t happened yet, doesn’t mean to say that it won’t happen today… or perhaps tomorrow!

Read Part 2 of this blog.


This blog was originally published here. To view comments or join the discussion on this article or the questions it raises, please follow the link above.

Read More

New Guidelines for Securing Medical Devices and Networks

Medical Device Security

The increased use of technology in healthcare over the past decade has resulted in greatly improved patient outcomes. However, the addition of IP-enabled devices has elevated concerns about security. The U.S. Food and Drug Administration recently published an advisory on Cybersecurity for Medical Devices and Hospital Networks and a new draft guidance document, Content of Premarket Submissions for Management of Cybersecurity in Medical Devices.

It’s likely that the FDA’s guidance responds to a presidential Executive Order and Policy Directive aimed at reducing critical infrastructure risk and a Department of Homeland Security bulletin about the vulnerability of health system LANs due to unsecured medical devices connected to them.

As things stand, medical devices, which include everything from intravenous pumps and pharmacy robots to implanted pacemakers, can represent a huge vulnerability to the security of networks used to deliver healthcare. Many networks connect to hospital LANs via older, insecure wireless technology. Furthermore, many still retain their default security settings, making them easy targets for hackers. Medical devices have become, therefore, a potentially unsecured backdoor to vast amounts of highly valuable, personally identifiable health information stored on healthcare networks.

Not all providers have firewalled and segmented their networks to isolate these insecure medical devices, or implemented “bent-pipe” application security to encapsulate all communications to and from endpoints. As the black market price of a medical record continues to soar, cybercriminals are directed increasingly to the easy pickings of poorly secured healthcare networks, making the risks all the more apparent.

While the FDA’s guidance to medical device manufacturers has been a long time coming, in its current form it directs manufacturers to evaluate and address cybersecurity risks and vulnerabilities for current and planned devices. It does not necessarily address the millions of devices that may no longer be supported by manufacturers, but that still dominate hospitals and healthcare systems.

Despite an increased awareness about the vulnerability of these older devices, financial pressure on healthcare delivery makes it challenging for health providers to rip and replace them. Alternative security controls need to be considered to protect these devices and the networks to which they are attached.

While the new FDA guidelines and DHS bulletin stress the risks that medical devices pose to hospital networks, we also need to take into account the reverse situation. If hospital networks can be compromised via wireless medical devices, it stands to reason that life-sustaining medical devices can be compromised through poorly secured hospital networks. While some healthcare providers have state-of-the-art networks with high levels of performance, reliability and security, others have yet to make this investment in people, process and technology.

With ever-growing numbers of medical devices used in critical patient care, the risks that one or more will be compromised should be a huge concern to all of us. As they stand currently, these life-sustaining devices could be targets for cyberassassins or cyberterrorists seeking to extort or hold for ransom patients, medical device manufacturers and healthcare providers.

While attacks of this sort are not yet common, some have already occurred. A real possibility exists that more attacks of this type will take place in the not-too-distant future unless better security controls are used to protect these devices and the networks to which they are connected.

This post was co-authored with Sam Visner, who leads CSC’s global company‐wide cyber strategy.

Read More