Читать книгу Do No Harm - Matthew Webster - Страница 29

We have all heard the phrase that history repeats itself. Unfortunately, that is true for the security of IoT/IoMT as well. While not true for all companies and there has been a great deal of recent innovation related to IoT/IoMT security, historically this has not been the case. Historically speaking, companies do not want to invest more into the product than they have to. It is an additional cost and hurts the overall bottom line. Since cost is a factor when making business decisions, going the extra mile is not always a wise business decision. Combine with that the slow approval rates by the FDA, and it is no wonder that security is not as high as it could be.

Those in the software development space or the security space may be familiar with something called the Open Source Web Application Security Project (OWASP). It helps developers and security practitioners with secure programming practices. In 2018 OWASP released the Top 10 internet of things (IoT) vulnerability list.⁴ It is one of the best aggregated lists of problems with IoT (and thus IoMT) devices. As we will explore, the IoT vulnerability list is an egregious list of challenges. From a security practitioner's perspective, it is appalling to design a system this way. The problems cited here are so severe, it is worth exploring all of them because they all apply to the historical challenges of IoMT. They also hint at the cultural challenges surrounding the IoT market, which, from a security standpoint, is very different from other IT markets such as Microsoft, which takes security very seriously.

Number one on the list is “Weak, Guessable, or Hardcoded Passwords.”⁵ Security practitioners have known for more than 20 years the importance of good password hygiene. Leaving the default password in place means that almost anyone with access to the network can own the device. Weak or easily guessable passwords are also just as unforgivable. Every year the top passwords used are published and they do not vary a great deal. Unsurprisingly, weak passwords tend to be the most hacked. This means a hacker can gain control of that data in many instances.

Second on the list is “Insecure Network Services.”⁶ This refers to vulnerabilities that could be exploited over a network that allow the system to be compromised. Not surprisingly, in some cases this refers to components that are not required for functionality of the device.

Third on the list is “Insecure Ecosystem Interfaces.”⁷ The ecosystem refers to all of the interconnections that device may have to other devices that could allow the device to be compromised. This includes various wireless communication, cloud connections, no authentication (no username/password), no encryption in the communication, and lack of input and/or output filtering. Lack of authentication means that anyone with access to the interface 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.”⁸ 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.”⁹ 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,”¹⁰ 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”¹¹ 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.”¹² 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.¹³ 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.”¹⁴ 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.¹⁵ 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.¹⁶ 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.