Do No Harm. Matthew Webster
can gain access to the information. Lack of encryption means that the system is vulnerable to a man-in-the-middle attack. This is someone who hasn't authenticated to the device, but may be inline from the communication. Essentially the information is in plain text and can be pulled. If it isn't clear, poor interface security can lead to data breaches, stolen passwords, etc.
The fourth item on the list is “Lack of Secure Update Mechanism.”8 Many IoT devices simply cannot be updated. In some cases this ties into hardcoded passwords, while in others it is the operating system or firmware that cannot be updated. This means that any vulnerabilities found cannot be remediated. Alternative methods must be used to protect the device.
If there was one item that causes a cascade of other items, it would be the fifth item, the “Use of Insecure or Outdated Components.”9 Having up-to-date components is critical as those components are foundational for everything else. Think of it this way: a percentage of you have thought about upgrading your computer, but were prevented from doing so because the hardware could not handle the upgraded operating system. Without the proper hardware, the operating system may get to a point where patching the system is simply not possible. Even worse, outdated components may have known vulnerabilities in it that can be compromised by an attacker.
We will get into some of the intricacies of privacy in Chapter 6, but “Insufficient Privacy Protection,”10 the sixth item on the list, is almost an epidemic of its own. Based on everything identified so far, not only are there privacy gaps, but in many cases, there are compliance gaps. This particular deficit also points to the data being used improperly, such as storing on devices or with poor encryption or even no encryption in many cases.
“Insecure Data Transfer and Storage”11 is also a serious problem with IoT devices. The range of issues on this seventh item include lack of encryption of the data at rest, in transit, or in use. Almost all of the compliance regulations require encrypting the data. Of course, that depends on the type of information. Not all information is regulated, so the type and amount of information collected will influence the importance and the risks related to the data.
The eighth item on the list may not as intuitable as some of the others for the less technically inclined. It details the “Lack of Device Management.”12 What this means is that there is no centralized oversight of the IoT devices. This is important as the only way to discover a problem is to be at the specific IoT device. You have no way of knowing in a centralized fashion if data is leaving the device or not (at least through the existing technology). Also, if there is an issue on a thousand devices (for example), instead of making a change centrally and then pushing that change throughout the organization, each device must be connected to individually. Simple tasks can become monumental efforts. An extra console can make all the difference in the world.
“Insecure Default Settings” is number nine on the list.13 In many cases this is much worse than it sounds. If an operating system can change the settings on the device, the risks can be reduced with due care. What they are also talking about is locking operators out from the system so they cannot make changes. In many cases, this is very prudent because an operator could prevent key functionality on the system thus rendering the device nonfunctional. Most manufacturers do not want to support a device if changes are made. This is even true for some software, so it is not just an IoT issue. This is often tied to outdated components or the ability to update the core operating system.
The final item on the list may also not be immediately intuitable as a problem for some of you. Number 10 is “Lack of Physical Hardening.”14 There is an old expression in security, “If you have physical access to a device, you own it.” Not providing physical security for the devices is particularly concerning—especially if brought over to the medical world where outsiders have access to some of the medical devices when seeing patients.
It is important to keep in mind that not all of these items will be applicable to connected medical devices, but given the roots of medical devices within IoT, many of these items are quite common. In 2018, the FDA put out new regulation regarding the security of IoMT. While that was a large step forward, hospitals can hold onto devices for many years—often longer than they were intended to. This means that many of the previously approved devices may have one or more of these problems.
But let us take a practical example of how these weaknesses in IoT can have disastrous and unforeseen consequences. In 2016, Paras Jha, an undergraduate at Rutgers University, wanted to see how DDOS attacks could be used for profit, so he attacked Rutgers so that the University would hire him. Eventually the DDOS tools used by Jha were enhanced and augmented by himself and a few friends. That code was posted online. Someone else decided to use the code against Dyn, an infrastructure company. This was on October 12, 2016. The resultant attack was a massive distributed denial of service (DDOS) attack that took out a large portion of 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