Security Vulnerabilities in Medical Devices
Medical devices, fully self-sufficient appliances in their own right, aim to revolutionize the healthcare industry. They educate and empower patients to keep a check on their health, aid doctors and patients detect disease(s), assist in medical processes, let patients control and manage their health and make personal fitness more exciting.Modern medical devices are often categorized into:
Healthcare information systems, on the other hand, are designed to comprehend, store, manage and communicate information related to patient health or activities of healthcare service providers and assist them in delivery of healthcare services. To comply with various federal stipulations and regulations and to ensure seamless, automated healthcare service delivery, it is imperative that any medical device not only functions as intended by its manufacturer, but also stays secured from system malfunctions largely driven by system design failure or forced manipulation by "man in the middle" attack, especially during interconnect phases, from malicious actors.
A state-of-the-art clinic is a complex system. It consists of sophisticated medical equipment that operate through fully functional computers with an operating system and required applications installed on them. Connecting medical devices to EHR systems has considerably brought down the time it takes to keep a check on the vital patient data. Not only do physicians depend on digital information stored in the computers, but also most of the healthcare technologies are connected to the Internet. Ranging from monitors, infusion pumps, CT scanners to ventilators, each device contains critical patient information.
A typical hospital network consists of VLANs (virtual network segments) based on their type, function or profile. These segments are setup to plug onto the LAN of the hospital network, either directly or via tunnelling. Usually, most modern hospitals use the Computerized Maintenance Management Systems (CMMS) to manage their medical device inventory. Many of these systems are connected to the network and allow communication with the medical devices for maintenance purposes. Often these systems are complemented or integrated with Real-Time Location Systems (RTLS) to support locating and managing devices. Other sections of the network such as Clinical, Business and Administrative sections also feed on to the same LAN.
One of the most important components of this network is the security module which plugs onto both the LAN setup as well as WAN setup. These VLAN configurations provide an additional degree of protection from network-based attacks and most importantly, should an attack occur, they help to contain an outbreak.
Wireless technologies are significantly improving the quality of healthcare by offering exceptional mobility to patients while providing healthcare professionals an easy and real-time access to patient data. Most medical devices attached to hospital networks are remotely accessible from other points on the network, or even the public Internet.
A hacker may get an unauthorized access to the hospital network because of weak access control measures, thereby resulting in compromised confidentiality. The generic method by which a hacker seeks to attack can broadly be placed under any one of the following:
According to guidelines from FDA, the manufacturers must try and limit unauthorized access to medical devices and implement policies and practices for adequate data security. They must limit network access to trusted users only and must maintain a device's critical functionality. Apart from restricting unauthorized access to the network and networked medical devices, health care centres must ensure use of antivirus software and firewalls, and should conduct periodic evaluation to keep track of individual network components.
A year ago, the researchers at the University of Washington conducted an experiment on tele-surgery, where a surgeon in one location controlled a robot in another location and let the robot perform a surgery on the patient. The results of this experiment highlighted that using the Interoperable Telesurgery Protocol, which is publicly available, hackers can easily interrupt the commands sent by the surgeon to the robot by deleting or changing the commands, modify the intention of signals from the operator to the robotic arm by changing the robotic arm movements and take complete control over the robot and therefore the surgery procedure.
This explains how in an endeavour to improve interoperability of health care networks and devices, medical device security becomes a secondary priority for most manufacturers, whereas technological innovation holds maximum importance. As a result, patient care gets compromised as medical devices connected to the Internet pose substantial risks in being hacked by unauthorized users. In fact, according to a recent report from SANS Institute, 94% of health care centres have faced the perils of a cyber attack.
Of late, a number of medical device manufacturers are migrating their data processing activities to the cloud, thereby unknowingly adding another security threat vector. Manufacturers are also often indifferent to ensuring adequate security on networked medical devices, primarily because of a conflict of interest. They work with a profit objective in mind and compromise on the security of medical devices.
Manufacturers are progressively using Commercial off-the-shelf Software (COTS). As systems are becoming more multifaceted and feature-rich, COTS becomes a preferred design choice for a number of software architects. However, the major shortcoming of this approach is that the device automatically takes over the vulnerabilities of COTS. Additionally manufacturers use chipsets, applications and code libraries that are outdated and inexpensive so that they are able to maintain a higher profit margin. As such, these pose increased number of vulnerabilities and are incompatible to the modern day gadgets.
Any commercial software application makes a device vulnerable to malware or attack vectors and it is of key prominence that manufacturers strengthen the device using security best practices such as disabling unnecessary ports or components of the commercial software, which are not in use and including the component in the device's security notification and patching process.
Vulnerabilities in networked medical devices may include, but is not restricted to, device flaws in terms of hardware, software or technical security controls and physical security controls. Some of the most common vulnerabilities present in wired and wireless networked medical devices include the following:
Addressing network security threats and preventing information security risks is a big challenge. Since it is practically impossible to eliminate cyber security threats completely, manufacturers and health care centres must put in efforts to minimise them. It is very important to maintain a proper balance between safeguarding patient information and supporting the use of innovative technologies for enhanced device performance.
Currently, in most cases, under pre-meditated cyberattacks, health care centres face complete breakdown in regular operations as they lack the ability to detect such an attack. IT, risk and compliance staff in hospitals and clinics should anticipate future medical device security risks and address them along with the existing risks to provide patient safety and protected health information. Moreover, it is extremely important that manufacturers and companies dealing with medical devices begin to implement security strategies right from the inception of a device up to its commercialisation.
It is vital to reduce the risk of exploitation of vulnerabilities by limiting access to networked medical devices to specific user groups and implementing layered network protections, including endpoint and network activity monitoring, firewall and antivirus software.Typical risk mitigation approaches include isolating medical devices that do not meet security standards, sampling devices randomly to gauge compliance and constantly monitoring and taking appropriate measures to maintain device security. Some recommended security standards to address the risks intrinsic to networked devices include the following:
Given the numerous ways programmers can make mistakes, looking for security vulnerabilities in a piece of software should be an integral part of the development process. Strangely, that is not always the case as testing the security of a particular product can be an expensive proposition and developers often weigh expense against cost of other factors involved in releasing the product to its customers. Also their knowledge about security threats is restricted. As such, when it comes to ensuring device security, it loses priority over the delivery of the product. Because of this, even software developed in an environment stringently cognizant of security risks is most likely released without full testing.
Naturally when the application is released, hackers will bash away at it with every possible corrupted form of the protocol to create an error in the application. By pushing at the edges of the envelope of the protocol, they may find a way to trip up the application and create a buffer overflow, the most frequently leveraged design error.
How are hackers finding buffer overflow opportunities missed during development and standard pre-release QA? A wide range of tools have been developed by the hacker community to enable the rank and file to find new exploits. These tools, fuzzers, work by creating and feeding a wide range of unexpected or corrupted inputs looking for a combination that will break the application. The production of these tools has become a small industry of its own. The QA world has attempted to adapt these rough and ready hacker tools into their test processes with some success, but also with many headaches. Most of these hacker-developed fuzzers are focused on a single type of code weakness or just on a single protocol or even on a single application.
Even after all the QA testing being done, buffer overflow error tests, protocol breach tests, and black-box testing should be done to further reduce the scope of adding vulnerabilities to the devices. How? We'll look at that now!
Translation of requirements during application development is the first cause of most programming errors. For instance, during the development of an application for a pacemaker, a project manager translates the requirements from the desired end to the programming team, which members translate to individual programming assignments. The programmers then translate the assignment into a proper syntax for the programming language. All these translations are sources of potential programming errors during the design stage.
Off-by-one errors, programming language use errors, integer overflows are all examples of errors generated by a programmer while translating a concept to a proper algorithm. For example, to hold 'n' items that are each 'm' bytes long, the programmer may tell the program to allocate n*m bytes. If m*n is larger than the biggest number that can be represented, less memory will be allocated than intended. This may lead to a buffer overflow.
However, not all programming errors are created equally. Some allow attackers to gain something or to get an ability they didn't already have. They may be able to deny other users' access to the program by crashing it, or access information they shouldn't be able to. In some cases, they may be able to cause the program to execute any command they tell it. These errors are vulnerabilities. Other errors, while they may have the same causes, won't give attackers any access they didn't already have. So, the first task for a vulnerability researcher is to determine if the programming error is merely a bug or if it can lead to exploitation. If a bug can lead to exploitation, either by itself or when used in concert with other bugs, it is indeed vulnerability
Also insecure coding practices occur when software developers do not take into account the introduction of logical security vulnerabilities. Software defects (software errors) and logic flaws can be exploited to compromise medical devices. Insecure coding practices are very dangerous because it may enable an attacker to take over the device's functionality, acquire its data, or prevent the device's software from working at all.
Multi-protocol, environment-variable 'Smart' fuzzers like beSTORM, which has been formally approved by the ISA Security Compliance Institute (ISCI) as a communication robustness testing (CRT) tool for use in ISASecure® Industrial Automation and Control System (IACS) certification, are vital for finding buffer overflow weaknesses, not only because they automate and document the process of delivering corrupted input, but also because they closely watch for unexpected response from the application. For example, beSTORM will try packets with malformed headers, by manipulating packet content and providing the kind of data that the application may be looking for, using &, <, >, full stops and commas within email applications, or typical URL symbols for HTTP servers. This is simply unviable if done manually.
Device protocol APIs allow applications to talk to a device over industry standard protocols. Developers need to simply identify the device and then open a communication channel to it. Opening a channel prompts for access authorization. This is a critical step to help prevent programs from accidentally or maliciously communicate with one or more devices without the user's awareness. Once access is granted, the program can communicate with a device, including starting long data transfers.
Being able to attack the actual implementation of the protocol by generating attack vectors that target basic coding errors such as mishandling of input validation orboundary checking (defensive programming errors), design flaws (logical, design specification, and similar), and the implementation of the protocol itself, is how hackers achieve better results.
The use of more advanced manipulations based on the basic two types (value manipulation and protocol manipulation) also considerably impacts the capability of today's fuzzers to provide results. For example, trying to exploit a logical flaw in the program by sending a login request twice and then combining it into the melting pot of attacks increases the numberof combinations required, and the success rate. Being able to work with more advanced protocols, requiring the fuzzer to wait for a response before sending the next request (basically establishing sessions with the attacked application-session-based fuzzing) is another step in fuzzing.
beSTORM, perhaps the only multi-protocol, environment-variable 'Smart' fuzzer, officially recognised by the ISA Security Compliance Institute (ISCI) as a communication robustness testing (CRT) tool for use in ISASecure® Industrial Automation and Control System (IACS) certification, addresses protocol breaches by testing over 50 protocols and 'auto learns' new or proprietary protocols while providing automated binary and textual analysis, advanced debugging and stack tracing.
This is a technique that works by automatically feeding a program multiple input iterations that are specially constructed in a way to trigger an internal error indicative of a bug, and potentially crash it. Commonly referred to as "fault injection" technique, blackbox testing can be applied to a network service as much as to a CPU, a cell phone, program parameters, an API, a Web browser, or a file type.
Testers with no knowledge of the internal working of the application being tested go about their work by first sniffing traffic at target protocols, generate input iterations from what they observe, and then drive 'Random' or 'Garbled' messages or 'Legal' mouse and keyboard events at the application until vulnerabilities emerge. Application monitoring can vary from a watchdog that sees if the program is still running to a remote check to see if the service is still available and responding or all the way to more advanced techniques like watching with a debugger for an anticipated exception. By value manipulation, only a specific data set is tested for specific value changes and through protocol manipulation, the entire protocol structure implementation can be tested or both.
The solution is to catch application flaws during development using the best fuzzer you can get - when correction is relatively easy and far less expensive.
By applying automated protocol based fuzzing techniques, beSTORM, a powerful automated black-box auditing tool, tries virtually every attack combination, intelligently starting with the most likely scenarios and detects application anomalies, which indicate a successful attack. This way security holes can be found in the application far faster, without brute force testing and almost without any user intervention. Easily scalable, beSTORM is equipped with the ability to use multiple processors or multiple machines to parallelize the audit and substantially reduce the testing duration.
Beyond Security's beSTORM is an exhaustive fuzzer. A powerful blackbox auditing tool, it is designed to find security weaknesses in protocol implementations and uses formal RFC definitions to create an attack language which in turn is used to identify vulnerabilities in the tested application. Although it supports testing for predetermined test cases and tries to exploit more likely vulnerabilities before continuing with the full test, its main objective is to allow for the most complete testing that will cover as much of the protocol space as possible. With beSTORM, it is also possible to write custom modules for proprietary protocols using XML.
For more information, visit www.beyondsecurity.comMore Information and Free Trial