MIT course "Computer Systems Security". Lecture 15: "Medical software", part 1

Massachusetts Institute of Technology. Lecture course # 6.858. "Security of computer systems". Nikolai Zeldovich, James Mykens. year 2014

Computer Systems Security is a course on the development and implementation of secure computer systems. Lectures cover threat models, attacks that compromise security, and security methods based on the latest scientific work. Topics include operating system (OS) security, capabilities, information flow control, language security, network protocols, hardware protection and security in web applications.

Lecture 1: “Introduction: threat models” Part 1 / Part 2 / Part 3
Lecture 2: “Controlling hacker attacks” Part 1 / Part 2 / Part 3
Lecture 3: “Buffer overflow: exploits and protection” Part 1 /Part 2 / Part 3
Lecture 4: “Privilege Separation” Part 1 / Part 2 / Part 3
Lecture 5: “Where Security System Errors Come From” Part 1 / Part 2
Lecture 6: “Capabilities” Part 1 / Part 2 / Part 3
Lecture 7: “Native Client Sandbox” Part 1 / Part 2 / Part 3
Lecture 8: “Network Security Model” Part 1 / Part 2 / Part 3
Lecture 9: “Web Application Security” Part 1 / Part 2/ Part 3
Lecture 10: “Symbolic execution” Part 1 / Part 2 / Part 3
Lecture 11: “Ur / Web programming language” Part 1 / Part 2 / Part 3
Lecture 12: “Network security” Part 1 / Part 2 / Part 3
Lecture 13: “Network Protocols” Part 1 / Part 2 / Part 3
Lecture 14: “SSL and HTTPS” Part 1 / Part 2 / Part 3
Lecture 15: “Medical Software” Part 1 / Part 2/ Part 3

Greetings to all, I also studied at MIT in the 90s and am glad to return here again. Today we will talk about a slightly different kind of security, leave the technical part aside and discuss what far-reaching consequences this security leads to. So that you know, I am from the Midnight Coffeehouse club area, and our University of Massachusetts Amherst, which you see on the screen, is located in Michigan, but we are not as big as your campus.



Today we will talk about some of our research and discuss everything: from exploding defibrillators to confidentiality issues in medical devices. Basically it will be connected with only one direction of research of my former graduate student, who in the photo presented here will disinfect implantable defibrillators. Today we will mainly talk about the safety of medical devices.

The next slide shows a list of many people who participated in these studies, and I will try to summarize some of the current provisions on the safety of a medical device from different points of view. I am also obliged to include in my lecture this sample slide on possible conflicts of interest, so now you can learn about any potential biases in my thinking. But I would like to think that I am less biased than an ordinary person.

About a year ago an interesting event occurred. The FDA, the Food and Drug Administration, issued a draft document that said that they would now check manufacturers for cybersecurity, or, as we call it, security and privacy, not only in terms of implementing software. providing a medical device, but also regarding the development of this software before the first line of the program is written.



Therefore, we will talk about how this affected the thinking of the medical device industry. The latest tutorial on developing medical software design appeared just a couple of weeks ago, and we recently participated in a video conference organized by the FDA about this. In total, more than 650 people joined this meeting. There have been many interesting things for medical device manufacturers about how to apply some of the concepts that you learn here in your class.

However, it is really difficult. I noticed that one of the questions on the site was how to change the culture of the medical community so that it understands how important security is. This slide illustrates this.



The slide shows one of the founders of the asepsis, Dr. Ignaz Semmelweis, who says that the doctor must wash his hands. He is objected to by American obstetrician Charles Meigs, who says the words: “Since doctors are gentlemen, they always have clean hands!”

Who washed their hands this morning? Great, I don't recognize the Massachusetts Institute! So, 165 years ago, there lived a famous obstetrician Ignaz Semmelweis, who investigated the disease called “postpartum sepsis”. And he discovered that if his medical students who worked in the morgue in the morning, then went to the patients, then these patients, as a rule, died more often. He came to the conclusion that if the doctors washed their hands after they worked with the corpses, then the mortality after the birth, during which they assisted, would be much less. So he recommended that doctors wash their hands. However, the reaction of the community of doctors to this proposal was mainly expressed by the opinion of obstetrician Charles Meigs, who asserted that all doctors are gentlemen, therefore they always have clean hands.

To some extent, we see a similar attitude to security today, so this is not too surprising. Throughout our conversation, I will try to draw some parallels with this.
I have too much material on the subject, so I will skip over some things. But the first thing I want to ask is - are any of you going to become a doctor? Not? Well, well, in this case, you will have something to talk about over a cocktail with your friends, doctors.

We will talk a little about implantable medical devices. I'll let you hold this thing in your hands, it's safe, just don't lick it. This is the former patient's implantable defibrillator. In fact, these devices are already about 50 years old, it was then that the first cardioventer defibrillators began to appear. At that time, they were external, and patients had to push a cart with this device in front of them and have a strong nurse next to them.



Decades passed, and the defibrillators were small enough to be fully implanted in the body. On the slide, you see an image of what is called a “rod” that uses inductive coupling. Technically, it is wireless, there are no wires here. The device is programmed to provide a heart rate of 60 beats per minute.

As a security researcher, I became interested in the appearance of defibrillators around 2003, such as the one that I transmitted to you using wireless technologies and networks. We are used to the fact that networks serve more for global computing, so I wondered what could go wrong here?

Fortunately, there are many engineers who are also concerned with this issue in medical companies, but here security requires a completely different mindset. And I'm going to tell you about how this thinking has changed.

If you disassemble one of these devices, you will find in it a huge amount of things that limit exploitation. So if you need a complex engineering problem, just disassemble one of these devices. More than half the volume of a defibrillator is a very large capacity battery that costs $ 40,000. It also uses silver metal - vanadium oxide.

Microcontrollers are located in the upper part of the stimulator, and usually there are antennas for communicating with the defibrillator control device. All this is hermetically sealed and implanted into your body.



We are talking about one of the harshest operating conditions of an electronic device. If you want to recharge the battery in your body, you can only wish good luck. Did you know that charging batteries generate heat and gas? Therefore, when designing such devices, there are serious limitations, and it is quite difficult to add security there.

However, there is a very good reason for wirelessly managing a medical device. There are good reasons, but there are serious risks. To illustrate this, I want you to see how the first implantable defibrillators looked.



This is a defibrillator from the Medtronic Museum in Minneapolis. Can anyone guess what kind of small metal cylinder is on the right side? What is its function? Antenna? Control? Management is a very close guess! Any more suggestions?

This "protrusion" was used before the advent of wireless to control the defibrillator. Previously, to change the device settings, the doctor said: “Patient, please raise your hand. I'm going to insert a needle through the armpit and twist the heart rate change disk. ”

Thus, one of the main advantages of wireless communication is that it actually reduces the number of foreign objects entering the body, because the more foreign objects enter the body, the greater the likelihood of infection. This is a serious risk. In fact, 1% of implants give serious complications, and about 1% of them are fatal. So control of the infection is one of the most important things you need to ensure when you implant and replace the device.

Of course, if you go to the other extreme and just say that you want to establish a wireless connection everywhere, you will get other types of risks. I called this the theory of “bacon for wireless”. My mom from the middle West said that bacon makes everything better around.
I noticed that there are some device manufacturers who seem to use wireless communication everywhere, without even thinking about the danger of such a decision. It has its advantages, but you need to think strategically before adding this feature to a fairly unsafe device. For example, think about what risks may arise over time.

I'm not going to talk a lot about Internet networks, but I think this quote deserves a mention. Does anyone remember the ship Costa Concordia off the coast of Italy? His captain said: "Today, everything is much safer thanks to modern tools and the Internet." This is a frame from space, in which you can see his overturned ship.



So when you add internet and wireless to your medical device, you take a new risk. But you should not be afraid of this, you just need to provide for the control of possible negative consequences.

I want to show you in pictures how the typical operation of a medical device goes, how it is used in clinical care, how it can change your thinking, if it comes from a safety point of view, and what you need to think about risk. First, let's talk about a world in which there are no real threats, but only unsafe methods, dangerous accidents and some carelessness without any conscious sabotage.



The FDA maintains a database of blunders, malfunctions, damages and deaths. This is open information, you can see for yourself. This sample is called MAUDE - “Experience of using devices by manufacturers and consumers”.

This slide describes a case of using a device called a “volumetric infusion pump,” a device that mechanically injects drugs into your body through a vein. In this case, the patient died, and if you look at this text carefully, you will see that one of the reasons for the tragedy was a buffer overflow. I think you know all about buffer overflows from your first lecture. So this happens in real life in every area that uses computer technology.



In this particular case, a buffer overflow was detected during software error checking, but the reaction to such an error was to turn off the pump, that is, to put it into safe mode. But the creators of the software did not take into account the fact that for some patients the disconnection of the pump is a death sentence. So this patient died after an increase in intracranial pressure, followed by brain death, and all this happened because of a buffer overflow.

So there is nothing complicated, right? You all know that you do not want to get a buffer overflow in the software, and in this case there is no external influence. This simply illustrates the status of the software, at least for this particular device. This is a very difficult task.

Another complication of security is the need to consider the human factor. There are several universities that focus on this side of the issue, but, in my opinion, not enough. Therefore, I rely on my own life experience.

My wife requested anonymity, so I will not reveal her name. On the slide you see me, my wife, there is an infusion pump at the back, and our child is still inside his wife. Fortunately, the pump worked just fine. In general, pumps are great for providing medical care, but they still caused more than 500 deaths due to various types of malfunctions.



Therefore, I will tell you about one more fault. The next slide shows the implantable type of pump. It has a semi-permeable membrane, through which you can replenish stocks of medicines, and a user interface that a nurse or doctor uses to change the dosage.

Does anyone see where you are taking the amount of medication? You have to squint, right? You need to look at this figure very well.
.


Here at number six it says that we are going to dose a bolus. A bolus is a time for the gradual administration of a daily dose of medication for more than 20 minutes and 12 seconds, and all this is implanted, so that the patient does not feel the process of drug administration.

This user interface came into effect after the FDA withdrew the previous version of the interface and required further work. Prior to the recall in paragraph 6 of the control interface of this pump, there were eight key elements missing: HH: MM: SS, these are hours, minutes, and seconds.



What do you think would happen when this designation was missing? In this case, it is very easy to make a mistake in the units of measurement and make an error in the order of magnitude.

Unfortunately for this patient, his pump was incorrectly programmed, so the medicine was administered in 24 minutes instead of 24 hours. The error was caused by the lack of designation of input numbers: hours, minutes, seconds. This was discovered only after the patient died - after leaving the hospital, he was in a severe car accident and later died due to the fact that his family agreed to disconnect the medical life support system.



If you look at it from a technical point of view, the problem is pretty simple, right? Just in the interface there was no "label". But here the human factor is very easy to trace, although it is not always in sight, the focus of engineering processes. But this is a very important element in improving the reliability of devices that rely on software. Therefore, I urge you to take the human factor into account when developing your software, even if it does not have a critical impact.

I also want to talk about the exciting world of program management. I put together on this slide all these little dialog boxes that appear whenever my computer gets a software update, but all this happens in the background. Like my iPhone, which is constantly getting updates and becoming “stronger”. Medical devices also receive software updates, in principle they do not differ from traditional computing devices. They simply control the vital functions of your body.

There is one interesting case that happened about 4 years ago. There are companies that produce antivirus software that is used by hospitals, in particular, McAfee. So, during the next critical update, this antivirus Windows considered it malicious, placed in quarantine, and then decided to isolate the system. This caused an emergency restart of computers and the appearance of BSOD on the screens.

As a result, the hospital stopped accepting patients, except in severe cases, such as gunshot wounds, because their registry systems did not work properly.

So, clinical care is highly dependent on the functions of the software, and we sometimes forget about the role of security.

Microsoft has a huge impact on many users as the largest developer of operating systems. Believe it or not, there are still a lot of medical devices running Windows XP, whose support was discontinued six months ago. Thus, you should not use this OS, because no more security updates and feature updates are released for it. This is outdated software. But until now, new computer equipment with preinstalled OS Windows XP continues to be delivered to medical institutions.

In this situation, the software life cycles are slightly shifted. It’s good if you’re used to downloading updates to open source software daily, but think about medical devices. You can not refuse it in a year, it can be used for 20 years. Therefore, it is very difficult to find software suitable for 20 years of operation, it is almost like a flight into space.

A month ago, the FDA released a guide about what they expect to see from manufacturers. Think of it as a project for software developers.



When you state all the requirements for your medical device, they ask the manufacturers how they have thought through the safety issues, all the risks, and how they are going to mitigate them. What are the residual risks, that is, what are the problems that they cannot solve? Ideally, they expect the manufacturer or developer to provide all possible risks and ways to reduce them.

From the point of view of software management, none of the medical staff is a responsible, authorized user, so anything can happen. But now there are recommendations that are designed to help manufacturers better integrate safety into their products. So I think that we are having a good time discussing such issues.

Now we can go on to discuss security issues, leaving out of the context of the lecture things not related to it. So let's put on our gray and black hats (a hint of hacker ethics: a hacker in a gray hat is testing the vulnerability of computers, but can use his knowledge for personal gain, hackers in black hats are more hackers than researchers).



Before I begin, I want to say that this is a very difficult area of ​​research, because there are patients in it. And if today they gave me a medical device that has security problems, I would still take it, because it would be much better for the patient with this device than without it. But, of course, I would prefer to have safer medical devices. Now there are more and more safe devices, but if you have to choose between the device and its absence, I would strongly recommend that you still use the device to be in a much better position.

But, nevertheless, let's consider a case of sabotage in which we have an adversary who wants to create problems when using a medical device. Who is the defibrillator? Great, he is here. I would like to tell you a little about how these defibrillators are implanted. This is a very specific device, because, firstly, it is implanted inside a living organism, therefore the risk is very high. It supports your life. If it beats in your heart and suddenly fails, the results can be disastrous. So this is very interesting from an engineering point of view, because a defibrillator has to work around the clock, seven days a week for many years.

So this is a programmer, not a person, but a device. This is mainly a durable computer with a small device called Wand or a rod attached to it. This is not a computer mouse, but a transmitter and receiver using its own wireless communication in a dedicated frequency range; this is not a regular 802.11 connection.

The operation takes about 90 minutes. The patient is awake, he remains calm, but the operation is performed under local anesthesia. A small incision is made in front of the clavicle, and then a team of six people will guide the electrode through a blood vessel ending inside the heart. I have such a probe here - an electrode that has not been previously used.



You see small notches at its end, some devices have two sensors, so that it can sense your heart rate and influence it. You can create small or large heartbeats, in time with the heart rhythm or to restart the heart if the rhythm is chaotic. This is a very advanced device. The beveled tip at the end of the probe electrode is a steroid-type metal, it does not cling to the tissues, so the electrode passes freely through the vessel. In principle, this is a regular USB cable, right?



After this thing is implanted in the heart, the patient is sutured and the stimulator is tested. Usually, after this, the patient receives what looks like a small base station, like a small access point and is called a “home monitor”. This greatly limits freedom.



On the radio channel operating on a dedicated frequency, you can collect all the telemetry and send it to the "cloud", usually this confidential cloud storage for private use, so that medical workers can monitor their patients. For example, if you notice that the patient's device, Mary, is transmitting unusual readings, you can call her and say: “You need to make an appointment and come to me, because I would like to understand what happens to your defibrillator.”

Thus, one of the beneficial properties of wireless communication is the ability to continuously monitor the work of a patient's defibrillator, rather than doing it only once a year.

We had a team of students that we gathered from several universities, I gave them a defibrillator and an oscilloscope, and they “retired to the cave” for about nine months. Returning from there, they said: "look what we found"!

The next slide shows a screenshot of the communication session between the device and the programmer. All that you see is completely understandable, no cryptography, at least no encryption to be noticed.

Here you will find the name of the doctor who has placed the implant, the diagnosis, the name of the hospital, the condition of the device, the name of the patient, date of birth, model and manufacturer of the defibrillator, serial number of the device. In general, it is a complete electronic medical record. This is a rather old device that was used about 10 years ago, but at the time it was perceived as a work of art. It did not use encryption, at least to ensure the confidentiality of medical information.



Therefore, when we saw this, we thought that we definitely need to pay attention to the safety of managing this device. How does it provide authenticity control? Inviolability of information? We decided to conduct the next experiment and began to learn how to use what is called "program radio." Perhaps some of you have played with this, now there are a whole bunch of them. About 10 years ago, radio software for the USRP and GNU was popular. Our goal was to make the defibrillator think that the patient’s heart was producing a fatal heart rhythm.



We took an unnecessary antenna from a pacemaker, created a small antenna, and recorded a radio frequency signal that caused a fatal heart rhythm. And then we sent it back to the defibrillator wirelessly. After that, the device emitted a signal corresponding to the shock of a shock of 500V. That is, an electrical defibrillation of a non-existent patient stopping the heart was performed. This is about 32 joules per millisecond, something similar can be experienced when hitting the chest with a horse hoof.

It was interesting how we found it. So, I was in the operating room, and if you remember, I said that after implantation, the surgical team checks whether the defibrillator is working properly. How can you tell if a defibrillator is working normally, if the patient's heart beats normally? Therefore, a team is built into the defibrillator that causes a deadly heart rate, which the defibrillator is intended to restore. This is called "command shock." Therefore, when I asked the doctors about this, it turned out that they do not understand what the concept of authentication is for such devices. After that, we decided that we really need to study more deeply how to solve these problems.

In this particular case, we were able to send a command to the device, but we could not verify the authenticity of this command, so that we can artificially cause a shock. The good news is that these devices could solve this problem by updating the software.

That's about the implant itself. A huge number of innovative solutions are applied to them; this is no longer science fiction, real people and patients stand behind it.

Most people are deeply concerned about the provision of quality medical care. But sometimes they just don’t understand how to fit security into the design process, so culturally it’s a challenge.

Another interested party is people who provide medical care in the first place - these are hospital staff or small clinics. If you want to find malware, go to the hospital, there you will find many interesting virus programs, and here's why.

The next slide is a screenshot from my colleague who worked at the Beth Israel Deaconess Medical Center in Boston. He made a screenshot of his network architecture. There is nothing amazing in it. Interestingly, he listed the operating systems installed on what was considered medical devices.

I like to add numbers and check everything, so I recalculated his data and said:

“Well, you have Windows XP SP1, SP2 and SP3, but 0 + 15 + 1 does not equal 600, it is 16, you have the wrong addition”! He looked at me and said: “No, Kevin, all right, we have 600 more computers in the hospital with the zero Windows XP service pack.”

Thus, these are the medical devices for which they were unable to update the manufacturer’s software and install security patches. This means that they have used old software in the hospital, which has been vulnerable to all old malware that has been affecting Windows XP for 15 years.



In a clinic, it is very difficult to protect equipment, because the service life of equipment and software are not synchronized. In healthcare, they think in terms of decades, but in the fast world of the hockey stick from Silicon Valley, we think of days, weeks, or months in relation to software innovations.
At the bottom of the slide you see information that the average time of infection of medical equipment with viruses is 12 days, during which they have no protection against malware. With the presence of antivirus programs, the safe operation time of devices without the threat of virus infection increases to almost 1 year, but this is not enough.

25:00 min

MIT course "Computer Systems Security". Lecture 15: "Medical software", part 2


Full version of the course is available here .

Thank you for staying with us. Do you like our articles? Want to see more interesting materials? Support us by placing an order or recommending to friends, 30% discount for Habr users on a unique analogue of the entry-level servers that we invented for you: The whole truth about VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps from $ 20 or how to share the server? (Options are available with RAID1 and RAID10, up to 24 cores and up to 40GB DDR4).

VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps until December for free if you pay for a period of six months, you can order here .

Dell R730xd 2 times cheaper? Only here2 x Intel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD 1Gbps 100 TV from $ 249 in the Netherlands and the USA! Read about How to build an infrastructure building. class c using servers Dell R730xd E5-2650 v4 worth 9000 euros for a penny?