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: "Control of hacker attacks" Part 1 / Part 2 / Part 3
Lecture 3: "Buffer overflow: exploits and protection" Part 1 / Part 2 / Part 3
Lecture 4: "Separation of privileges" Part 1 / Part 2 / Part 3
Lecture 5: "Where Security Errors Come From" Part 1 / Part 2
Lecture 6: "Opportunities" Part 1 / Part 2 / Part 3
Lecture 7: "Sandbox Native Client" Part 1 / Part 2 / Part 3
Lecture 8: "Model of network security" 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 turning off 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. ( : , , , ).



, , , . , , , , . , , . , , , .

, , , , . ? , . , . , , -, , . . , . , , .

, , , . , Wand, . , , , 802.11.

90 . , , . , , . — , .



, , . , , . . - – , , . , USB-, ?



, , . , , « ». .



, , «», , . , , , : « , , ».

, – , .

, , , « » . , : «, »!

. , , , , , , .

, , , , , , , , . . , 10 , . , , .



, , , . ? ? , « ». , , . 10 USRP GNU. , .



, , . . , 500. . 32 , .

, . , , , , , . , , ? , , . « ». , , , , . , , .

, , . , .

. , , .

. , , .

, – . , , , .

, Beth Israel Deaconess. . . , , , .

, :

«, Windows XP SP1, SP2 SP3, 0+15+1 600, 16, »! : „, , , 600 Windows XP“.

, , . , , , Windows XP 15 .



, . , , , , .
, 12 , . 1 , .

25:00

MIT course "Computer Systems Security". 15: « », 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 we have 2 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?