Healthcare delivery organizations (HDOs) have been busy increasing their network and systems security in the last year, though there is still much room for improvement, according to Forescout researchers.
This is the good news: the percentage of devices running Windows unsupported operating systems fell from 71% in 2019 to 32% in 2020 and there have been improvements when it comes to timely patching and network segmentation.
The bad news? Some network segmentation issues still crop up and HDOs still use insecure protocols for both medical and non-medical network communications, as well as for external communications.
Based on two data sources – an analysis of network traffic from five large hospitals and clinics and the Forescout Device Cloud (containing data for some 3.3 million devices in hundreds of healthcare networks) – the researchers found that, between April 2019 and April 2020:
- The percentage of devices running versions of Windows OS that will be supported for more than a year jumped from 29% to 68% and the percentage of devices running Windows OS versions supported via ESU fell from 71% to 32%. Unfortunately, the percentage of devices running Windows OSes like Windows XP and Windows Server 2003 remained constant (though small)
- There was a decided increase in network segmentation
Unfortunately, most network segments (VLANs) still have a mix of healthcare devices and IT devices or healthcare equipment, personal, and OT devices, or mix sensitive and vulnerable devices.
As far as communication protocols are concerned, they found that:
- 4 out of the 5 HDOs were communicating between public and private IP addresses using a medical protocol, HL7, that transports medical information in clear text
- 2 out of the 5 HDOs allowed medical devices to communicate over IT protocols with external servers reachable from outside the HDO’s perimeter
- All HDOs used obsolete versions of communication protocols, internally and externally (e.g., SSLv3, TLSv1.0, and TLSv1.1, SNMP v1 and 2, NTP v1 and 2, Telnet)
- Many of the medical and proprietary protocols used by medical equipment lack encryption and authentication, or don’t enforce its usage (e.g., HL7, DICOM, POCT01, LIS02). OT and IoT devices in use also have a similar problem
That’s all a big deal, because attacks exploiting these security vulnerabilities could do a lot of damage, including stealing patients’ information, altering it, disrupting the normal behavior of medical devices, disrupting the normal functioning of the entire organization (e.g., via a ransomware attack), etc.
Defense strategies for better healthcare network security
The researchers advised HDOs’ cyber defenders to:
- Find a way to “see” all the devices on the network, whether they comply with company policies, and detect malicious network behavior they may exhibit
- Identify and remediate weak and default passwords
- Map the network flow of existing communications to help identify unintended external communications, prevent medical data from being exposed publicly, and to detect the use of insecure protocols
- Improve segmentation of devices (e.g., isolate fragile legacy applications and operating systems, segment groups of devices according to their purpose, etc.)
“Whenever possible, switch to using encrypted versions of protocols and eliminate the usage of insecure, clear-text protocols such as Telnet. When this is not possible, use segmentation for zoning and risk mitigation,” they noted.
They also warned about the danger of over-segmentation.
“Segmentation requires well-defined trust zones based on device identity, risk profiles and compliance requirements for it to be effective in reducing the attack surface and minimizing blast radius. Over-segmentation with poorly defined zones simply increases complexity without tangible security benefits,” they concluded.
Manufacturing medical devices with cybersecurity firmly in mind is an endeavor that, according to Christopher Gates, an increasing number of manufacturers is trying to get right.
Healthcare delivery organizations have started demanding better security from medical device manufacturers (MDMs), he says, and many have have implemented secure procurement processes and contract language for MDMs that address the cybersecurity of the device itself, secure installation, cybersecurity support for the life of the product in the field, liability for breaches caused by a device not following current best practice, ongoing support for events in the field, and so on.
“For someone like myself who has been focused on cybersecurity at MDMs for over 12 years, this is excellent progress as it will force MDMs to take security seriously or be pushed out of the market by competitors who do take it seriously. Positive pressure from MDMs is driving cybersecurity forward more than any other activity,” he told Help Net Security.
Gates is a principal security architect at Velentium and one of the authors of the recently released Medical Device Cybersecurity for Engineers and Manufacturers, a comprehensive guide to medical device secure lifecycle management, aimed at engineers, managers, and regulatory specialists.
In this interview, he shares his knowledge regarding the cybersecurity mistakes most often made by manufacturers, on who is targeting medical devices (and why), his view on medical device cybersecurity standards and initiatives, and more.
[Answers have been edited for clarity.]
Are attackers targeting medical devices with a purpose other than to use them as a way into a healthcare organization’s network?
The easy answer to this is “yes,” since many MDMs in the medical device industry perform “competitive analysis” on their competitors’ products. It is much easier and cheaper for them to have a security researcher spend a few hours extracting an algorithm from a device for analysis than to spend months or even years of R&D work to pioneer a new algorithm from scratch.
Also, there is a large, hundreds-of-millions-of-dollars industry of companies who “re-enable” consumed medical disposables. This usually requires some fairly sophisticated reverse-engineering to return the device to its factory default condition.
Lastly, the medical device industry, when grouped together with the healthcare delivery organizations, constitutes part of critical national infrastructure. Other industries in that class (such as nuclear power plants) have experienced very directed and sophisticated attacks targeting safety backups in their facilities. These attacks seem to be initial testing of a cyber weapon that may be used later.
While these are clearly nation-state level attacks, you have to wonder if these same actors have been exploring medical devices as a way to inhibit our medical response in an emergency. I’m speculating: we have no evidence that this has happened. But then again, if it has happened there likely wouldn’t be any evidence, as we haven’t been designing medical devices and infrastructure with the ability to detect potential cybersecurity events until very recently.
What are the most often exploited vulnerabilities in medical devices?
It won’t come as a surprise to anyone in security when I say “the easiest vulnerabilities to exploit.” An attacker is going to start with the obvious ones, and then increasingly get more sophisticated. Mistakes made by developers include:
Unsecured firmware updating
I personally always start with software updates in the field, as they are so frequently implemented incorrectly. An attacker’s goal here is to gain access to the firmware with the intent of reverse-engineering it back into easily-readable source code that will yield more widely exploitable vulnerabilities (e.g., one impacting every device in the world). All firmware update methods have at least three very common potential design vulnerabilities. They are:
- Exposure of the binary executable (i.e., it isn’t encrypted)
- Corrupting the binary executable with added code (i.e., there isn’t an integrity check)
- A rollback attack which downgrades the version of firmware to a version with known exploitable vulnerabilities (there isn’t metadata conveying the version information).
Overlooking physical attacks
Physical attack can be mounted:
- Through an unsecured JTAG/SWD debugging port
- Via side-channel (power monitoring, timing, etc.) exploits to expose the values of cryptographic keys
- By sniffing internal busses, such as SPI and I2C
- Exploiting flash memory external to the microcontroller (a $20 cable can get it to dump all of its contents)
Manufacturing support left enabled
Almost every medical device needs certain functions to be available during manufacturing. These are usually for testing and calibration, and none of them should be functional once the device is fully deployed. Manufacturing commands are frequently documented in PDF files used for maintenance, and often only have minor changes across product/model lines inside the same manufacturer, so a little experimentation goes a long way in letting an attacker get access to all kinds of unintended functionality.
No communication authentication
Just because a communications medium connects two devices doesn’t mean that the device being connected to is the device that the manufacturer or end-user expects it to be. No communications medium is inherently secure; it’s what you do at the application level that makes it secure.
Bluetooth Low Energy (BLE) is an excellent example of this. Immediately following a pairing (or re-pairing), a device should always, always perform a challenge-response process (which utilizes cryptographic primitives) to confirm it has paired with the correct device.
I remember attending an on-stage presentation of a new class II medical device with a BLE interface. From the audience, I immediately started to explore the device with my smartphone. This device had no authentication (or authorization), so I was able to perform all operations exposed on the BLE connection. I was engrossed in this interface when I suddenly realized there was some commotion on stage as they couldn’t get their demonstration to work: I had accidentally taken over the only connection the device supported. (I then quickly terminated the connection to let them continue with the presentation.)
What things must medical device manufacturers keep in mind if they want to produce secure products?
There are many aspects to incorporating security into your development culture. These can be broadly lumped into activities that promote security in your products, versus activities that convey a false sense of security and are actually a waste of time.
Probably the most important thing that a majority of MDMs need to understand and accept is that their developers have probably never been trained in cybersecurity. Most developers have limited knowledge of how to incorporate cybersecurity into the development lifecycle, where to invest time and effort into securing a device, what artifacts are needed for premarket submission, and how to proper utilize cryptography. Without knowing the details, many managers assume that security is being adequately included somewhere in their company’s development lifecycle; most are wrong.
To produce secure products, MDMs must follow a secure “total product life cycle,” which starts on the first day of development and ends years after the product’s end of life or end of support.
They need to:
- Know the three areas where vulnerabilities are frequently introduced during development (design, implementation, and through third-party software components), and how to identify, prevent, or mitigate them
- Know how to securely transfer a device to production and securely manage it once in production
- Recognize an MDM’s place in the device’s supply chain: not at the end, but in the middle. An MDMs cybersecurity responsibilities extend up and down the chain. They have to contractually enforce cybersecurity controls on their suppliers, and they have to provide postmarket support for their devices in the field, up through and after end-of-life
- Ccreate and maintain Software Bills of Materials (SBOMs) for all products, including legacy products. Doing this work now will help them stay ahead of regulation and save them money in the long run.
They must avoid mistakes like:
- Not thinking that a medical device needs to be secured
- Assuming their development team ‘can’ and ‘is’ securing their product
- Not designing-in the ability to update the device in the field
- Assuming that all vulnerabilities can be mitigated by a field update
- Only considering the security of one aspect of your design (e.g., its wireless communication protocol). Security is a chain: for the device to be secure, all the links of the chain need to be secure. Attackers are not going to consider certain parts of the target device ‘out of bounds’ for exploiting.
Ultimately, security is about protecting the business model of an MDM. This includes the device’s safety and efficacy for the patient, which is what the regulations address, but it also includes public opinion, loss of business, counterfeit accessories, theft of intellectual property, and so forth. One mistake I see companies frequently make is doing the minimum on security to gain regulatory approval, but neglecting to protect their other business interests along the way – and those can be very expensive to overlook.
What about the developers? Any advice on skills they should acquire or brush up on?
First, I’d like to take some pressure off developers by saying that it’s unreasonable to expect that they have some intrinsic knowledge of how to implement cybersecurity in a product. Until very recently, cybersecurity was not part of traditional engineering or software development curriculum. Most developers need additional training in cybersecurity.
And it’s not only the developers. More than likely, project management has done them a huge disservice by creating a system-level security requirement that says something like, “Prevent ransomware attacks.” What is the development team supposed to do with that requirement? How is it actionable?
At the same time, involving the company’s network or IT cybersecurity team is not going to be an automatic fix either. IT Cybersecurity diverges from Embedded Cybersecurity in many respects, from detection to implementation of mitigations. No MDM is going to be putting a firewall on a device that is powered by a CR2032 battery anytime soon; yet there are ways to secure such a low-resource device.
In addition to the how-to book we wrote, Velentium will soon offer training available specifically for the embedded device domain, geared toward creating a culture of cybersecurity in development teams. My audacious goal is that within 5 years every medical device developer I talk to will be able to converse intelligently on all aspects of securing a medical device.
What cybersecurity legislation/regulation must companies manufacturing medical devices abide by?
It depends on the markets you intend to sell into. While the US has had the Food and Drug Administration (FDA) refining its medical device cybersecurity position since 2005, others are more recent entrants into this type of regulation, including Japan, China, Germany, Singapore, South Korea, Australia, Canada, France, Saudi Arabia, and the greater EU.
While all of these regulations have the same goal of securing medical devices, how they get there is anything but harmonized among them. Even the level of abstraction varies, with some focused on processes while others on technical activities.
But there are some common concepts represented in all these regulations, such as:
- Risk management
- Software bill of materials (SBOM)
- “Total Product Lifecycle”
But if you plan on marketing in the US, the two most important document should be FDA’s:
- 2018 – Draft Guidance: Content of Premarket Submissions for Management of Cybersecurity in Medical Devices
- 2016 – Final Guidance: Postmarket Management of Cybersecurity in Medical Devices (The 2014 version of the guidance on premarket submissions can be largely ignored, as it no longer represents the FDA’s current expectations for cybersecurity in new medical devices).
What are some good standards for manufacturers to follow if they want to get cybersecurity right?
The Association for the Advancement of Medical Instrumentation’s standards are excellent. I recommend AAMI TIR57: 2016 and AAMI TIR97: 2019.
Also very good is the Healthcare & Public Health Sector Coordinating Council’s (HPH SCC) Joint Security Plan. And, to a lesser extent, the NIST Cyber Security Framework.
The work being done at the US Department of Commerce / NTIA on SBOM definition for vulnerability management and postmarket surveillance is very good as well, and worth following.
What initiatives exist to promote medical device cybersecurity?
Notable initiatives I’m familiar with include, first, the aforementioned NTIA work on SBOMs, now in its second year. There are also several excellent working groups at HSCC, including the Legacy Medical Device group and the Security Contract Language for Healthcare Delivery Organizations group. I’d also point to numerous working groups in the H-ISAC Information Sharing and Analysis Organization (ISAO), including the Securing the Medical Device Lifecycle group.
And I have to include the FDA itself here, which is in the process of revising its 2018 premarket draft guidance; we hope to see the results of that effort in early 2021.
What changes do you expect to see in the medical devices cybersecurity field in the next 3-5 years?
So much is happening at high and low levels. For instance, I hope to see the FDA get more of a direct mandate from Congress to enforce security in medical devices.
Also, many working groups of highly talented people are working on ways to improve the security posture of devices, such as the NTIA SBOM effort to improve the transparency of software “ingredients” in a medical device, allowing end-users to quickly assess their risk level when new vulnerabilities are discovered.
Semiconductor manufacturers continue to give us great mitigation tools in hardware, such as side-channel protections, cryptographic accelerators, virtualized security cores. Trustzone is a great example.
And at the application level, we’ll continue to see more and better packaged tools, such as cryptographic libraries and processes, to help developers avoid cryptography mistakes. Also, we’ll see more and better process tools to automate the application of security controls to a design.
HDOs and other medical device purchasers are better informed than ever before about embedded cybersecurity features and best practices. That trend will continue, and will further accelerate demand for better-secured products.
I hope to see some effort at harmonization between all the federal, state, and foreign regulations that have been recently released with those currently under consideration.
One thing is certain: legacy medical devices that can’t be secured will only go away when we can replace them with new medical devices that are secure by design. Bringing new devices to market takes a long time. There’s lots of great innovation underway, but really, we’re just getting started!
Securing medical devices is not a new challenge. Former Vice President Cheney, for example, had the wireless capabilities of a defibrillator disabled when implanted near his heart in 2007, and hospital IT departments and health providers have for years secured medical devices to protect patient data and meet HIPAA requirements.
With the expansion of security perimeters, the surge in telehealth usage (particularly during COVID-19), and proliferation in the number and types of connected technologies, healthcare cybersecurity has evolved into a more complex and urgent effort.
Today, larger hospital systems have approximately 350,000+ medical devices running simultaneously. On top of this, millions of additional connected devices are maintained by the patients themselves. Over the next 10 years, it’s estimated the number of connected medical devices could increase to roughly 50 billion, driven by innovations such as 5G, edge computing, and more. This rise in connectivity has increased the threat of cyberattacks not just to patient data, but also patient safety. Vulnerabilities in healthcare technology (e.g., an MRI machine or pacemaker) can lead to patient harm if diagnoses are delayed or the right treatments don’t get to the right people.
What can the healthcare industry do to strengthen their defenses today? How can they lay the groundwork for more secure devices and networks tomorrow?
The challenges are interconnected. The solutions cannot be siloed, and collaboration between manufacturers, doctors, healthcare delivery organizations and regulators is more critical now than ever before.
Device manufacturers: Integrating security into product design
Many organizations view medical device cybersecurity as protecting technology while it is deployed as part of a local network. Yet medical devices also need to be designed and developed with mobile and cloud security in mind, with thoughtful consideration about the patient experience. It is especially important we take this step as medical technology moves beyond the four walls of the hospital and into the homes of patients. The connected device itself needs to be secure, as opposed to the network surrounding the device.
We also need greater visibility and transparency across the medical device supply chain—a “software bill of materials.” The multicomponent nature of many medical products, such as insulin pumps or pacemakers, make the final product feel like a black box: hospitals and users know what it’s intended to do, but they don’t have much understanding about the individual components that make everything work. That makes it difficult to solve cybersecurity problems as they arise.
According to the 2019 HIMSS Cybersecurity Survey, just over 15% of significant security issues were initially started through either medical device problems in hospitals or vendor medical devices. As a result, some of these issues led to ransomware attacks exposing vulnerabilities, as healthcare providers and device makers scrambled to figure out just which of the products were at risk, while their systems were under threat. A software bill of materials would have helped them respond quickly to security, license, and operational risks.
Healthcare delivery organizations: Prioritizing preparedness and patient education
Healthcare providers, for their part, need to strengthen their threat awareness and preparedness, thinking about security from device procurement all the way to the sunsetting of legacy devices, which can extend over years and decades.
It’s currently not uncommon for healthcare facilities to use legacy technology that is 15 to 20 years old. Many of these devices are no longer supported and their security doesn’t meet the baseline of today’s evolving threats. However, as there is no replacement technology that serves the same functions, we need to provide heightened monitoring of these devices.
Threat modeling can help hospitals and providers understand their risks and increase resilience. Training and preparedness exercises are imperative in another critical area of cybersecurity: the humans operating the devices. Such exercises can put doctors, for instance, in an emergency treatment scenario with a malfunctioning device, and the discussions that follow provide valuable opportunities to educate, build awareness of, and proactively prepare for cyber threats.
Providers might consider “cybersecurity informed consent” to educate patients. When a patient signs a form before a procedure that acknowledges potential risks like infection or side effects, cyber-informed consent could include risks related to data breaches, denial of service attacks, ransomware, and more. It’s an opportunity to both manage risk and engage patients in conversations about cybersecurity, increasing trust in the technology that is essential for their health.
Regulators: Connecting a complex marketplace
The healthcare industry in the US is tremendously complex, comprised of hundreds of large healthcare systems, thousands of groups of physician practices, public and private payers, medical device manufacturers, software companies, and so on.
This expanding healthcare ecosystem can make it difficult to coordinate. Groups like the Food & Drug Administration (FDA) and the Healthcare Sector Coordinating Council have been rising to the challenge.
They’ve assembled subgroups and task forces in areas like device development and the treatment of legacy technologies. They’ve been reaching out to hospitals, patients, medical device manufacturers, and others to strengthen information-sharing and preparedness, to move toward a more open, collaborative cybersecurity environment.
Last year, the FDA issued a safety communication to alert health care providers and patients about cybersecurity vulnerabilities identified in a wireless telemetry technology used for communication that impacted more than 20 types of implantable cardiac devices, programmers, and home monitors. Later in 2019, the same device maker recalled thousands of insulin pumps due to unpatchable cyber vulnerabilities.
These are but two examples of many that demonstrate not only the impact of cybersecurity to patient health but to device makers and the healthcare system at large. Connected health should give patients access to approved technologies that can save lives without introducing risks to patient safety.
As the world continues to realize the promise of connected technologies, we must monitor threats, manage risks, and increase our network resilience. Working together to incorporate cybersecurity into device design, industry regulations, provider resilience, and patient education are where we should start.
Contributing author: Shannon Lantzy, Chief Scientist, Booz Allen Hamilton.
Researchers at Ben-Gurion University of the Negev have developed a new AI technique that will protect medical devices from malicious operating instructions in a cyberattack as well as other human and system errors.
Abnormal or anomalous instructions introduce many potentially harmful threats to patients, such as radiation overexposure, manipulation of device components or functional manipulation of medical images. Threats can occur due to cyberattacks, human errors such as a technician’s configuration mistake or host PC software bugs.
Dual-layer architecture: AI technique to protect medical devices
As part of his Ph.D. research, BGU researcher Tom Mahler has developed a technique using artificial intelligence that analyzes the instructions sent from the PC to the physical components using a new architecture for the detection of anomalous instructions.
“We developed a dual-layer architecture for the protection of medical devices from anomalous instructions,” Mahler says.
“The architecture focuses on detecting two types of anomalous instructions: (1) context-free (CF) anomalous instructions which are unlikely values or instructions such as giving 100x more radiation than typical, and (2) context-sensitive (CS) anomalous instructions, which are normal values or combinations of values, of instruction parameters, but are considered anomalous relative to a particular context, such as mismatching the intended scan type, or mismatching the patient’s age, weight, or potential diagnosis.
“For example, a normal instruction intended for an adult might be dangerous [anomalous] if applied to an infant. Such instructions may be misclassified when using only the first, CF, layer; however, by adding the second, CS, layer, they can now be detected.”
Improving anomaly detection performance
The research team evaluated the new architecture in the CT domain, using 8,277 recorded CT instructions and evaluated the CF layer using 14 different unsupervised anomaly detection algorithms. Then they evaluated the CS layer for four different types of clinical objective contexts, using five supervised classification algorithms for each context.
Adding the second CS layer to the architecture improved the overall anomaly detection performance from an F1 score of 71.6%, using only the CF layer, to between 82% and 99%, depending on the clinical objective or the body part.
Furthermore, the CS layer enables the detection of CS anomalies, using the semantics of the device’s procedure, an anomaly type that cannot be detected using only the CF layer.
19 vulnerabilities – some of them allowing remote code execution – have been discovered in a TCP/IP stack/library used in hundreds of millions of IoT and OT devices deployed by organizations in a wide variety of industries and sectors.
“Affected vendors range from one-person boutique shops to Fortune 500 multinational corporations, including HP, Schneider Electric, Intel, Rockwell Automation, Caterpillar, Baxter, as well as many other major international vendors,” say the researchers who discovered the flaws.
About the vulnerable TCP/IP software library
The vulnerable library was developed by US-based Treck and a Japanese company named Elmic Systems (now Zuken Elmic) in the 1990s. At one point in time, the two companies parted ways and each continued developing a separate branch of the stack/library.
The one developed by Treck – Treck TCP/IP – is marketed in the U.S. and the other one, dubbed Kasago TCP/IP, is marketed by Zuken Elmic in Asia.
The library’s high reliability, performance, and configurability is what made it so popular and widely deployed.
“The [Treck TCP/IP] library could be used as-is, configured for a wide range of uses, or incorporated into a larger library. The user could buy the library in source code format and edit it extensively. It can be incorporated into the code and implanted into a wide range of device types,” the researchers explained.
“The original purchaser could decide to rebrand, or could be acquired by a different corporation, with the original library history lost in company archives. Over time, the original library component could become virtually unrecognizable. This is why, long after the original vulnerability was identified and patched, vulnerabilities may still remain in the field, since tracing the supply chain trail may be practically impossible.”
The vulnerabilities were discovered by Moshe Kol and Shlomi Oberman from JSOF in the Treck TCP/IP library, and Zuken Elmic confirmed that some of them affect the Kasago library.
About the vulnerabilities
Collectively dubbed Ripple20, the vulnerabilities (numbered CVE-2020-11896 through CVE-2020-11914) range from critical to low-risk. Four enable remote code execution. Others could be used to achieve sensitive information disclosure, (persistent) denial of service, and more.
“One of the critical vulnerabilities is in the DNS protocol and may potentially be exploitable by a sophisticated attacker over the internet, from outside the network boundaries, even on devices that are not connected to the internet,” the researchers noted.
“Most of the vulnerabilities are true zero-days, with 4 of them having been closed over the years as part of routine code changes, but remained open in some of the affected devices (3 lower severity, 1 higher). Many of the vulnerabilities have several variants due to the stack configurability and code changes over the years.”
The researchers plan to release technical reports on some of them and are scheduled to demonstrate exploitation of the DNS vulnerability on a Schneider Electric APC UPS device at Black Hat USA in August.
The Treck TCP/IP library did not receive much attention from security researchers in the past. After JSOF researchers decided to probe it and discovered the flaws, they also discovered that contacting the many, many vendors who implement it was going to be a time-consuming task.
Treck was made aware of the vulnerabilities and fixed them, but insisted on contacting clients and users of the code library themselves and to provide the appropriate patches directly.
But, since some of the vulnerabilities affect also the Kasago library, JSOF involved multiple national computer emergency response team (CERT) organizations and regulators in the disclosure process.
“CERT groups focus on ways to identify and mitigate security risks. For example, they can reach a much larger target group of potential users with blast announcements, ‘mass-mailings’ that they broadcast to a long list of participating companies to notify them of the potential vulnerability. Once users are identified, mitigation comes into play,” the researchers explained.
“While the best response might be to install the original Treck patch, there are many situations in which installing the original patch is not possible. CERTs work to develop alternative approaches that can be used to minimize or effectively eliminate the risk, even if patching is not an option.”
The Ripple20 vulnerabilities have been dubbed thusly because of extent of its impact.
“The wide-spread dissemination of the software library (and its internal vulnerabilities) was a natural consequence of the supply chain ‘ripple-effect’. A single vulnerable component, though it may be relatively small in and of itself, can ripple outward to impact a wide range of industries, applications, companies, and people,” they noted.
“The inclusion of the number ’20’ denotes our disclosure process beginning in 2020, while additionally symbolizing and giving deference to our belief in the potential for additional vulnerabilities to be found from the original 19,” they told Help Net Security.
The researchers have pointed out that the vulnerability disclosure process, their own efforts to identify users of the Treck library, and the patch/mitigation dissemination process have been immensely aided by Treck, various CERTs, the CISA, and several security vendors (Forescout, CyberMDX).
A number of vendors have confirmed that their offerings are affected by the Ripple20 flaws. JSOF has compiled a list of affected and non affected vendors, which will be constantly updated as additional information becomes available.
Device vendors should update the Treck library to a fixed version (220.127.116.11 or higher), while organizations should check their network for affected devices and contact the vendors for more information on how to mitigate the exploitation risk. The researchers will make available, upon request, a script to help companies identify Treck products on their networks.
“Fixing these vulnerabilities presents its own set of challenges, even once they’ve been identified on the network. Some already have patches available. But there are also complicating factors,” Forescout CEO and President Michael DeCesare noted.
“With these types of supply chain vulnerabilities and embedded components, the vendor that is creating the patch isn’t necessarily the one that will release it. That can delay the issuance of a patch. There are also no guarantees that the device vendor is still in business, or that they still support the device. The complex nature of the supply chain may also mean the device is not patchable at all, even if it needs to remain on the network. In such cases, mitigating controls such as segmentation will be needed to limit its risk.”
The various CERTs and agencies like CISA will surely offer mitigation advice via security advisories.
The EU Agency for Cybersecurity (ENISA) published a cybersecurity procurement guide for hospitals.
The hospital is a vast ecosystem comprised of an entire network of devices, equipment and systems that often require connection to external systems, making monitoring and control a very hard task to do. This is due to the high sensitivity of medical data and the potential vulnerability the sector is faced with, cybersecurity has to be applied every step of the way to ensure patient data privacy and the availability and resilience of healthcare services at the same time.
A cybersecurity procurement guide for hospitals
The Procurement Guidelines for Cybersecurity in Hospitals published by the Agency is designed to support the healthcare sector in taking informative decisions on cybersecurity when purchasing new hospital assets. It provides the information to be included in the procurement requests that hospitals publish in order to obtain IT equipment.
This new report outlines good practices and recommendations for including cybersecurity as a provision in the procurement process in hospitals. Initially the report presents the set of hospital assets and the most prominent cybersecurity threats linked to them.
After categorising the procurement process in three steps, namely “Plan, Source and Manage”, it identifies the cybersecurity requirements associated with each step. To make this even easier, the guide provides suggestions for evidence on how the requirements can be fulfilled by the provider.
The EU Agency for Cybersecurity, Executive Director, Juhan Lepassaar, stated:
“Protecting patients and ensuring the resilience of our hospitals are a key part of the Agency’s work to make Europe’s health sector cyber secure”
Who can use the guide?
This report is addressed to healthcare professionals occupying technical positions in hospitals, i.e. Chief-level executives: CIO , CISO, CTO, IT teams as well as procurement officers in healthcare organisations.
It may be of interest to manufacturers of medical devices that provide products to hospitals (medical devices, clinical information systems, networking equipment, cloud services, etc.). When these manufacturers offer services or products, they will know the security requirements that the hospital expects them to fulfil and they can provide evidence to prove it.
As Head of Research at CyberMDX, Elad Luz gathers and analyzes information on a variety of connected healthcare devices in order to improve the techniques used to protect them and/or report about their security issues to vendors. The research includes analyzing protocols, reverse engineering software, and conducting vulnerability tests.
Healthcare organizations are increasingly experiencing IoT-focused cyberattacks. What is the realistic worst-case scenario when it comes to such attacks?
The first and most important risk to bear in mind and protect against in our space is always patient risk. In a place like hospital, this may happen on different levels. Care critical devices that are directly connected to patients like infusion pumps, ventilation, anesthesia, patient monitoring and such obviously represent the most critical endpoints from a security perspective. Compromises to those devices can cause serious immediate effects.
After care critical devices, the next most critical line of defense should be drawn around diagnostic machines like radiology devices, or lab devices that can also result in situations of serious short term negative impact. Beyond that, you have to account for care adjacent devices that pose near term risk, such as connected sterilization machines and medication dispensers. Even devices that have only little to do with the medical flow but are still necessary for the hospital to operate — like wireless tags, access controls, connected washers may affect the responsiveness of the medical staff which may later affect patient health.
It’s been cited ad nauseam and for good reason — but the WannaCry attacks immediately come to mind as a really poignant example of how even administrative devices being compromised can result in patient harm. And that threat hasn’t gone away in the last 3 years since WannaCry. Just in 2019, a truly astonishing 759 ransomware attacks were launched against healthcare organizations. Of those, at least 10 forced hospitals to turn away patients due to an impaired ability to deliver care. In fact, there’s a very serious impact on care even when hospitals don’t need to turn away patients.
When researchers measured the effects of cyber attacks on patient safety they found an operational ripple effect that added — on average — 2.7 minutes to medical response times. In a health emergency like a heart attack, minutes are often the difference between life and death. To wit, the same report noted a 3.6% increase in cardiac event fatalities at hospitals that had recently suffered cyberattacks. In other words, all other things being equal, for every 30 cardiac event patients admitted to a cyber-exploited hospital, statistically, one patient who would have survived elsewhere will be lost.
How do the complex medical device supply and value chains ultimately impact the security of connected devices in the healthcare industry?
Because of the complex medical device supply and value chains, it’s not always clear who should take responsibility for security best practices. While hospital administrators tend to think device manufacturers should be responsible for the security of their devices — which if not designed securely can hardly be operated securely — device manufacturers think the responsibility lies with the hospitals who create the network conditions that largely define the attack surface. This gap in expectations makes effective medical device security all the more difficult.
It’s important that security be considered at the earliest stages and built into medical technology research, development, procurement, deployment, and management processes. This means not only thinking about security, but also testing for it so that potential issues can be identified and addressed before they graduate into real-world problems. That applies equally to medical device stakeholders in the pre-market and post-market — manufacturers and hospitals.
Today, the type of testing required is woefully neglected by both sides of the market, with only 9% of manufacturers and 5% of users say they test medical devices at least annually.
What are the main challenges when it comes to vulnerability research of medical devices?
From a purely research perspective, there are challenges to do with access. For example, device procurement costs that can be prohibitively expensive, laws and policies that prevent vendors from selling to non-hospitals, sometimes difficult-to-accommodate spatial prerequisites, as well as installation, configuration, and calibration complexities, or even networking codependencies.
From a slightly less tactical perspective, looking more at strategy and the bigger picture, the research is only valuable insofar as it manages to improve the industry’s security. To that point, challenges can sometimes come in how vendors relate to researchers — if the relationship becomes adversarial, it will be difficult for both sides to work together to actually improve security. Of course, we need to also think about the facts on the ground in hospitals. Even if the researchers and vendors do everything right on their end, it doesn’t guarantee a positive outcome if hospitals continue using vulnerable devices without implementing patches or other mitigations.
So, there are definitely challenges in trilaterally coordinating positive real-world impact. And with the worst-case scenario for our industry always revolving around cases of cyber-physical harm, a severity scoring system (CVSS) that fundamentally ignores physical impact, the system itself may do a disservice in misrepresenting and poorly prioritizing the risks.
It’s imperative that all the stakeholders be able to come together, share a clearly understood frame of reference and common objectives in dialing down the real-world risk exposure.
What does this type of research entail? Were you surprised by some of the findings?
Our research methodology involves some proprietary technology and tactics that I can’t discuss, but the parts that I can talk about normally begin with data collection and good old fashioned detective work.
We break down and reverse-engineer the communication protocols used by medical devices, we analyze device network behavior, we crawl the internet and scraping device references, we dig into MDS² files, we use a good amount of inductive reasoning, trial & error, and “poking around” in the lab to follow the breadcrumbs and build the investigation.
When we “crack” a case open and discover a previously undocumented security issue, we’re often surprised by things like lack of authentication, hard-coded credentials, and other vulnerabilities that are caused less by human error and more by bad or lazy design decisions taken.
What’s your take on responsible disclosure? What can be done to safeguard users in case a vendor is not responsive to vulnerability reports?
Cybersecurity is still fairly new and somewhat unfamiliar territory to most healthcare organizations. In fact, the whole industry is still working on getting its arms around it, and that goes to national oversight bodies and institutionalized safeguards as well. The process is still not perfectly standardized or very granularly governed. There may not be official rules dictating who is informed of what, what controls are applied to whom, who has influence over bottom line determinations, and what can be said to whom for every stage in the process.
Similarly, the factors governing the timeline for disclosure can be somewhat opaque and, from an institutional perspective, the guiding logic for disclosure is not always clear. So, if you’re dealing with a cooperative vendor you might expect that CISA — the division of homeland security responsible for overseeing the disclosure process for matters of public infrastructure — would withhold disclosure until patches can be developed and issued for the vulnerability in question. Yet, that’s not always the case. I think it’s important that we not lose sight of the forest for the trees or reduce the task of vulnerability management to items on a static checklist. We need to maintain a view of the mission: making healthcare safer and more secure.
That said, the fact is that more often than not, the process works as designed; and improvements are being introduced all the time. So I think, all in all, responsible disclosure is very important to the long-term security health of the industry. I also think it will only get better as lessons are learned and CISA collaborates more closely with other bodies like the FDA.
To your second question, I think we should concern ourselves less with how users can protect themselves from an unresponsive vendor, and more with how the public, the demand side of the market, researchers, and national oversight bodies can work together to apply pressure as needed to make sure that vendors are always responsive to matters of cybersecurity.
What advice would you give to a healthcare CISO that wants to make sure the connected devices in use in the organization are as secure as possible?
There is obviously a need for an automated tool to do that. Otherwise we are talking about nonstop work of securing thousands of devices, tens of different models and deployments, each requiring its own permissions and rules, in an ever-changing environment both inside the hospital (new assets get connected, old ones disconnected) and outside (new threats and vulnerabilities are published).
The best option would be using a solution that is tailor-made for medical centers, which is what we do at CyberMDX. Our solution is already familiar with a huge collection of medical devices and their unique protocols and our researchers are always working to lock down vulnerabilities you don’t even know you have. We are THE experts when it comes to cybersecurity and clinical connectivity.
How do you expect the security of IoT medical devices to evolve in the near future?
As IoT continues to connect everyday devices, I think we’ll find, especially in the medical field, that the most basic and relied upon devices will quickly become our biggest liabilities from a security perspective. Some evidence of this trend can we seen in the recent MDhex vulnerabilities that revealed a number of products in the popular CARESCAPE family of patient monitoring devices to be extremely vulnerable to cyber sabotage.
The problem is that all of a sudden manufacturers are expected to be experts in something — cybersecurity — that they’ve barely had to consider until now. It’s challenging for the manufacturers because the largest variety and best quality of agent-based security solutions reside on Windows and Linux-based devices, and require frequent updates to be relevant. Meeting those requirements is usually challenging in IoT embedded devices. Therefore I expect organizations to rely more and more on centralized, third-party provided agentless solutions that monitor the network traffic and introduce security features.
The developments in the area of cybersecurity are alarming. As the number of smart devices in private households increases, so do the opportunities for cyber criminals to attack, TÜV Rheinland reveals.
Uncontrolled access to personal data undermines confidence in the digital society. The logistics industry and private vehicles are increasingly being targeted by hackers.
“From our point of view, it is particularly serious that cybercrime is increasingly affecting our personal security and the stability of society as a whole,” explains Petr Láhner, Business Executive Vice President for the business stream Industry Service & Cybersecurity at TÜV Rheinland.
“One of the reasons for this is that digital systems are finding their way into more and more areas of our daily lives. Digitalization offers many advantages – but it is important that these systems and thus the people are safe from attacks.”
Uncontrolled access to personal data could destabilize the digital society
In 2017, Frenchwoman Judith Duportail asked a dating app company to send her any personal information they had about her. In response, she received an 800-page document containing her Facebook likes and dislikes, the age of the men she had expressed interest in, and every single online conversation she had had with all 870 matching contacts since 2013.
The fact that Judith Duportail received so much personal data after several years of using a single app underscores the fact that data protection is now very challenging. In addition, this example shows how little transparency there is about securing and processing data that can be used to gain an accurate picture of an individual’s interests and behavior.
Smart consumer devices are spreading faster than they can be secured
Smart speakers, fitness trackers, smart watches, thermostats, energy meters, smart home security cameras, smart locks and lights are the best-known examples of the seemingly unstoppable democratization of the “Internet of many Things”.
Smart devices are no longer just toys or technological innovations. The number and performance of individual “smart” devices is increasing every year, as these types of devices are quickly becoming an integral part of everyday life.
It is easy to see a future in which the economy and society will become dependent on them, making them a very attractive target for cyber criminals. Until now, the challenge for cybersecurity has been to protect one billion servers and PCs. With the proliferation of smart devices, the attack surface could quickly increase hundreds or thousands of times.
The trend towards owning a medical device increases the risk of an internet health crisis
Over the past ten years, personal medical devices such as insulin pumps, heart and glucose monitors, defibrillators and pacemakers have been connected to the internet as part of the Internet of Medical Things (IoMT). At the same time, researchers have identified a growing number of software vulnerabilities and demonstrated the feasibility of attacks on these products. This can lead to targeted attacks on both individuals and entire product classes.
In some cases, the health information generated by the devices can also be intercepted. So far, the healthcare industry has struggled to respond to the problem – especially when the official life of the equipment has expired.
As with so many IoT devices of this generation, networking was more important than the need for cybersecurity. The complex task of maintaining and repairing equipment is badly organized, inadequate or completely absent.
Vehicles and transport infrastructure are new targets for cyberattacks
Through the development of software and hardware platforms, vehicles and transport infrastructure are increasingly connected. These applications offer drivers more flexibility and functionality, potentially more road safety, and seem inevitable given the development of self-propelled vehicles.
The disadvantage is the increasing number of vulnerabilities that attackers could exploit – some with direct security implications. Broad cyberattacks targeting transport could affect not only the safety of individual road users, but could also lead to widespread disruption of traffic and urban safety.
Hackers target smart supply chains and make them “dumb”
With the goal of greater efficiency and lower costs, smart supply chains leverage IoT automation, robotics and big data management – those within a company and with their suppliers.
Smart supply chains increasingly represent virtual warehousing, where the warehouse is no longer just a physical building, but any place where a product or its components can be located at any time. Nevertheless, there is a growing realization that this business model considerably increases the financial risks, even with only relatively minor disruptions.
Smart supply chains are dynamic and efficient, but are also prone to disruptions in processes. Cyberattacks can manipulate information about deposits. Thus, components would not be where they are supposed to be.
Threats to shipping are no longer just a theoretical threat but a reality
In 2017, goods with an estimated weight of around 10.7 billion tons were transported by sea. Despite current geopolitical and trade tensions, trade is generally expected to continue to grow. There is ample evidence that states are experimenting with direct attacks on ship navigation systems.
At the same time, attacks on the computer networks of ships used to extort ransom have been reported. Port logistics offers a second, overlapping area of vulnerability.
Many aspects to shipping that can be vulnerable to attack such as ship navigation, port logistics and ship computer network. Attacks can originate from states and activist groups. This makes monitoring and understanding a key factor in modern maritime cybersecurity.
Vulnerabilities in real-time operating systems could herald the end of the patch age
It is estimated that by 2025 there will be over 75 billion networked devices on the IoT, each using its own software package. This, in turn, contains many outsourced and potentially endangered components.
In 2019, Armis Labs discovered eleven serious vulnerabilities (called Urgent/11) in the real-time operating system (RTOS) Wind River VxWorks. Six of these flaws exposed an estimated 200 million IoT devices to the risk of remote code execution (RCE) attacks.
This level of weakness is a major challenge as it is often deeply hidden in a large number of products. Organizations may not even notice that these vulnerabilities exist. In view of this, the procedure of always installing the latest security updates will no longer be effective.
Researchers have discovered six critical and high-risk vulnerabilities – collectively dubbed MDhex – affecting a number of patient monitoring devices manufactured by GE Healthcare.
The flaws may, according to GE Healthcare, allow an attacker to make changes at the device’s OS level that may render the device unusable or interfere with its function, make changes to alarm settings on connected patient monitors, and utilize services used for remote viewing and control of multiple devices on the network to access the clinical user interface and make changes to device settings and alarm limits, which could lead to missed, unnecessary, or silenced alarms.
In short, they may lead to patient harm or even death. Also, unfortunately, patches are yet to be issued.
About the MDhex vulnerabilities
Researcher Elad Luz of CyberMDX unearthed the flaws in September 2019 and notified GE Healthcare about them.
- CVE-2020-6961 – Unprotected storage of credentials (SSH private key exposed and is universally shared across an entire line of devices in the CARESCAPE and GE Healthcare family of products)
- CVE-2020-6962 – Improper input validation (the versions of the web-based system configuration tool in use is deprecated and opens the devices up to a number of vulnerabilities with known exploits in the wild)
- CVE-2020-6963 – Use of hardcoded credentials (SMB with hard-coded credentials allows remote file access)
- CVE-2020-6964 – Missing authentication for a critical function (MultiMouse / Kavoom KM software can be run to allow remote keyboard/mouse and clipboard control of a machine)
- CVE-2020-6965 – Unrestricted upload of dangerous file types (software update manager allows remote file upload)
- CVE-2020-6966 – Inadequate encryption strength (credentials for VNC remote desktop access are stored in an insecure manner AND can be found in publicly available product documentation)
Some of the affected devices present only some of these issues, others all. The list is as follows:
- ApexPro Telemetry Server, Versions 4.2 and prior
- Clinical Information Center (CIC), Versions 4.X and 5.X
- CARESCAPE Telemetry Server, Versions 4.3 and prior
- CARESCAPE Central Station (CSCS), Versions 1.X and 2.X
- Patient monitors B450, B650 and B850, Versions 1.X and 2.X
Mitigations and patches
“GE is developing software updates/patches including additional security enhancements that will be made available,” the manufacturer noted, but didn’t say when.
In the meantime, to mitigate the risk of exploitation, they advise users to properly configure the Mission Critical (MC) and Information Exchange (IX) networks to ensure the isolation of the vulnerable devices – instructions on how to do it can be found in the product configuration guides and technical and service manuals.
“Properly configured MC and IX networks greatly reduce but do not eliminate the ability to gain access to the networks. As a result, if the networks are properly isolated, for this issue to occur, the unauthorized person would need to gain physical access to the listed monitoring devices themselves individually or acquire direct access to the isolated MC or IX networks on-site at the hospital,” the company noted.
GE healthcare told ZDNet that they’ve been notifying customers about the issues and mitigations since November 2019 and that they are not aware “of any incidents where these vulnerabilities have been exploited in a clinical situation.”
“Finding vulnerabilities in medical devices is like hitting snooze on your alarm in the morning. This isn’t your drop-dead to get out of bed and it’s not a breach, but it’s your warning that attackers, who are sometimes closer on our tail than we’d like to admit, have a new pathway in,” commented Nadir Izrael, CTO and co-founder of Armis.
“Medical data and patient data is valuable, as is the life giving operation of the medical devices themselves, and it’s what attackers are looking to steal or disrupt. It’s why I’ve seen MRI machines talking to servers in Russia, a medical crash cart being used to access Facebook or phishing websites, and even an infusion pump infected by malware that was still connected to a patient. MDHex is a reminder that trust in the security of patient care devices can’t be given implicitly any more. Hospitals need to know that many medical devices are inherently insecure, built without security in mind and without an agent, and extremely difficult to patch, if at all.”