the internet on the Eastern seaboard of the United States. A DDOS attack is caused when hundreds or thousands of IoT devices are compromised and then used to point internet traffic at one or more sources. In this case the hackers used the malware that, once it took over devices, then removed other pieces of malware that may be infecting the device so they could claim the device for themselves. All it took was to look for internet-exposed IoT devices to pull off the attack, along with a little ingenuity. In this case, the code had 61 usernames and passwords, which allowed the attackers to compromise devices such as cameras, home routers, and baby monitors. All of the devices were using a stripped-down version of the Linux operating systems, which the malware was looking for.15 These were just a few kids who had no intention of causing the extreme problems they did.
While this story is not directly related to IoMT, it is indirectly related and serves as a strong cautionary tale. The security of these random internet-connected devices is very important. Lack of security can cause severe problems. The reality is governments and organized crime took note of what was going on. IoT was hitting center stage, and variants of Mirai were created after the fact—just looking for vulnerable devices to compromise.
Whether the devices had hardcoded passwords or it was just poor management on the part of the individual IoT device owners is more than an immaterial distinction. If the manufacturers had hardcoded passwords, it means that if the system is on the open internet, it can be compromised by looking up the default password. The two most obvious ways to protect the device is to not have it directly exposed on the open internet or to limit the inbound traffic on the internet that can reach the device. While there are a few other options, it does illustrate the challenge of trying to protect devices with known vulnerabilities.
Let us take a look at a more recent case to validate this point. On January 9, 2017, the FDA released a statement saying that patients with a St. Jude Medical implantable cardiac device (along with the corresponding transmitter) were vulnerable, which could affect how the medical devices work.16 The FDA went on to say that the Merlin@home Transmitter could ultimately be used to provide inappropriate shocks, cause rapid battery depletion, and so on. A device without battery life at a critical time could have potentially deadly consequences.
It may seem that 2017 was not that long ago, but from a technology perspective it was. Since then, the FDA has enacted new rules to help protect medical devices. Understanding that challenge, though, requires an understanding of the technology—the subject of the next section.
IoMT Technology
Security and technology go hand in hand. To understand the security risks within the IoMT, it really helps to understand the technology. Because this book is aimed at a general audience and not a technical one, we are only going to go deep enough to explain what the general issues are from a security standpoint. Please keep in mind much of what is discussed here is not true across the entire spectrum of medical devices. Each piece of technology has its own specific applicability.
Part of the reason it is so important to define what medical devices are is that it helps to determine what kinds of technology are built into the devices. Just as there is no one-size-fits-all in the medical device world, that is true for IoMT as well. Any generalizations made here are not meant to be applicable across the whole spectrum of IoMTs.
Electronic Boards
In a traditional computer there exists something called a motherboard. Without going into too many details, it is the central circuitry that connects different aspects of the system such as memory, the processor(s), input and output functions, the hard drive, monitor, and so on. What is important to consider from an IoMT perspective is that for some medical devices, many of the aspects of a traditional computer are baked into the motherboard. The end result is that memory, processing power, communications, and so on are severely limited. Often the “operating system” (firmware for the technophiles) is extremely limited and in some cases is not possible to upgrade or patch.
Operating Systems
Operating systems are another aspect of many connected medical devices. In many cases these are the same operating systems you may have at home. The first chapter covered medical imaging devices running on Windows XP. Another report from 802secure stated that 83% of the systems are running on outdated operating systems—a 56% jump from the previous year as a result of Windows 7 not being supported any longer.17 In some cases these systems can be and are updated, but in other cases, the manufacturer will not support upgrades, making things a bit more challenging in hospitals.
Sometimes the issues of old operating systems are beyond the control of the manufacturers. The FDA can take as much as 5 to 6 years to approve a particular device.18 Many companies are on a 3-year cycle for upgrading hardware. Imagine the quandary device manufacturers are in. Quite often the devices are released to the public with known vulnerabilities. The manufacturers can't change operating systems mid-stream. To make matters worse, many medical devices have a 15- to 20-year life span.19 As of this writing, Windows XP has 741 known vulnerabilities20—many of which cannot be patched because it is not supported. This is a huge challenge because sometimes the hardware cannot support new operating systems. The fact that many IoMT systems are kept for 15 to 20 years creates other challenges. It is simply impossible for manufacturers, developers, and operating systems to keep patching systems for 15 plus years. Inadvertently, it becomes an intersection where all of these problems create an environment that is essentially a hacker's paradise.
Software Development
Secure software development is arguably one of the more important controls in information security—especially if data is accessed through that software. If you have a poorly written application, it can mean the difference between securing the data and not securing the data. The challenge with software development is that there can be ten ways, all legitimate, of accomplishing the same control. In many other parts of information technology, there is a button to press and you are done. From a historical perspective, there are some cultural challenges.
Typically, developers use something called the software development lifecycle (SDLC). The SDLC includes methods of eliminating the various problems. These include peer review, unit testing, line testing, and a host of other techniques. What is missing from the SDLC processes of less mature organizations (from a security standpoint) is security. Depending on when and where you went to school, security may or may not have been a consideration. Oftentimes, it is up to organizations to train developers about security.
Training developers on security can be a little like herding cats. Doing it right means you have to have several things in place. First, you need a set of guidelines and security standards for the team to follow. Just right-sizing the amount of information to provide the developers can be a daunting task for organizations. Providing too much information means it will not be retained right away. Not providing enough means other challenges for the organizations.
Another aspect of a good coding environment is tooling. There are fantastic tools on the market that can detect problems before the product goes into production, and using them in the right way is one way to reduce the risks to the organization. However, the tools do have blind spots when it comes to human logic flaws. It is not something these kinds of applications are good at, and thus penetration tests are critical to the final product being secure. A penetration
