 So our next speaker is part of the health care security and privacy expert. He is an active member in the security community. He is also an author of such books as visual basic and visual basic dot net for scientists and engineers as well as pro-prol parsing. And he is the project lead for OWASP's anti ransomware guide and OWASP's secure medical device deployment standard projects. Now here to present his talk, standardizing the secure deployment of medical devices, ladies and gentlemen, Chris Frentz. It should come as no surprise to anyone in this room but hospitals are routinely pretty insecure. Going back the last few years, there's been a number of health care data breaches. We see it in 2015. MIT announced it was going to be the year of the hospital hack. We had a bunch of major breaches throughout 2016. And a lot of the security risks in hospitals were further emphasized with all of the ransomware attacks that were predominant last year within health care. The first being Hollywood hospital, roughly March of last year. They were brought down for several days and paying $17,000 to recover all their data. And that was the first of many, many hospitals. We saw a similar trend with MedStar following shortly afterwards as well as many other hospitals throughout the U.S. Now there's several reasons why hospitals like these and all other hospitals make prime targets for attackers. Number one being is medical record data is actually worth quite a bit, much more so than a credit card. You steal a credit card number. You might get a few thousand dollars out of the account before the bank notices the fraud and cuts you off. A medical record has a lot more useful data. It could be used for much more comprehensive identity theft because it contains social security numbers, all kinds of other stuff in it. You could establish false identities, open lines of credit with it. You could use it for insurance fraud. You could even use it to buy pharmaceuticals and medical devices that you could then resell for profit. So there's lots of things you can do with medical data that make it quite, quite valuable. And a lot of it too, it can be valuable in ways that you wouldn't normally expect. Like for example, to get a visa to the U.S. from a lot of different countries, they require a clean lung x-ray. And countries where tuberculosis is prominent like China and stuff like that, there's actually a huge black market for clean lung x-rays right now. So medical data can often be used in a lot of ways that you wouldn't typically expect. So that's one thing that makes hospitals a fairly ideal target for attackers to go after. The other and more concerning thing that makes hospitals an ideal target is within healthcare, there are still a ton of legacy systems. If we think about it, a lot of medical equipment is quite expensive. It's hard to replace. And it was designed with doing whatever clinical function it had in mind. It might do that clinical function well. It might have a 10-15 year lifespan in which it still does that clinical function very well. But a lot of that equipment was not built with security in mind. We see that in a lot of medical devices now, we're seeing reports almost daily of medical devices being vulnerable to hacking. There's been a number of demonstrations even at this conference here of various medical devices that were easily exploited. In the news recently, we saw both Hasbira, they made the news for the FDA recall for their infusion pumps. And we're probably all familiar with the issue with some of the St. Jude pacemakers that were also all over the media. Going back for some other examples, some medical devices because of the usage of Windows XP and other stuff, it was found to have over 1,400 vulnerabilities in just one system alone. This raises a lot of interest in questions because a lot of the previous attacks they focused on patient data, but what would occur if attackers targeted medical devices instead? And this was largely theoretical until about two months ago when WannaCry broke out. We're pretty familiar with it. It was pretty much a pandemic ransomware attack. Could have actually been much worse than it actually was if the kill switch wasn't found in time. But even so, many, many companies throughout the entire world, you can see the map there showing where they were struck. It was quite widespread, brought a lot of companies down. And most telling in healthcare actually occurred in Britain. Their national health service pretty much was brought to its knees by the WannaCry virus. But the malware and stuff outbreak wasn't unique to healthcare there. Hospitals throughout the world were affected, including in the U.S. But one of the distinct things that's different about WannaCry than a lot of past ransomware outbreaks is past ransomware outbreaks targeted the computer systems that housed patient data. Which, while that still has an impact on patient care, one of the interesting things about WannaCry is WannaCry actually spread to the medical devices themselves. Very, very different. A lot of radiology equipment in this particular case was actually brought down by WannaCry. Those systems had the same vulnerabilities that a lot of the computer systems affected by WannaCry actually had. Because if we think about it, all of these medical devices basically under the hood, they are computers. They're either running some form of Linux or some form of embedded windows. But those same vulnerabilities we find in our PCs, they're going to be present in these medical devices as well. And this is pretty scary because it really can give a whole new meaning to the term denial of service in a way that really could cause somebody to die depending on what the device actually is. You know, if you have a stroke patient coming in and they can't get the cat's gun down in time to determine if you need surgery, something else like that. Could have fatal consequences. If a heart monitor misses a defect, the patient goes, starts to have a heart attack, the nurse doesn't notice because the monitor was shut off or brought down by some kind of virus. There's many indications like that where you could have potentially lethal outcomes. Now the question is is what to do about it? There's a lot of organizations thankfully that are starting to look at it. One is I am the cavalry but two years ago they released their Hippocratic oath for connected medical devices and basically it covers things that manufacturers can do to help make devices more and more secure. Through a lot of their efforts to improve medical device security, I know they've been working with the FDA and the FDA also has released a lot of guidance within the last couple of years. Some things about the FDA guidance, they released both pre-market and post-market guidance. Basically that makes security recommendations for medical devices. The pre-market guidance is mostly in terms of how the devices are manufactured. The post-market guidance mostly deals with things like keeping devices up to date and other stuff companies should ideally do once the device is put on the market. Now this is a huge, huge step in the right direction. Very essential. But one of the downsides right now is the guidance is currently non-binding. So it's a recommendation to manufacturers but not something they legally have to follow yet. And my other concern with this type of stuff is if we think about it, even if manufacturers comply with all this guidance tomorrow they make the theoretically perfectly secure device starting tomorrow. There's still a lot of medical devices that are going to exist for a long time in hospital and healthcare institutions that are not going to be replaced overnight. In many cases these systems cost hundreds of thousands, millions of dollars depending on the systems are going to be replaced. And no hospital has the budget to go about and replace all their devices because a new, more secure model came on the market. So even in the perfect world where everything became secure tomorrow, which is not going to happen, it's still going to be years and years before all of the older insecure devices are removed from our healthcare institutions. So the real question is what can we do now to help make medical devices more secure? What can we do in our current environments? So how do healthcare institutions that have current deployments, we're replacing them tomorrow is not going to be a possibility. What can they do to make devices more secure? And on top of that is even if we assume these perfectly secure devices will one day come to market. You could have a device with all the security features in the world in your environment but if you don't take the time to configure and deploy it properly it's still going to be highly insecure. So one of the things that was heavily lacking was a standard for how hospitals should go about and securely deploy medical devices. And that's one of the things a lot of my work is focused on. I did release the standard through OWASP but basically what the goal of this project is, is it's designed to complement the work done by the FDA, complement the work done by IMD-Calvary and not focus on the manufacturing side but focus on the hospital side. On the actual people who will be deploying these devices. Now some of the things within the guidance, I'm not going to go through every control in depth. There was the Google link in the preceding slide and I'll make the slides available to anybody who wants them. But one of the first things I think should be touched upon by hospitals is purchasing controls. This is one of the most effective ways to get organizations to change over the long term to get manufacturers to increasingly adopt security and put security into their products. So in my opinion any hospital is going to be acquiring new medical devices. One of the first things they should do is they should audit the devices that they're going to buy for both security and privacy. Which devices, before they purchase them, are going to best meet the needs in terms of keeping the data secure and keeping the patients secure. And when doing this, organizations should remind doctors and stuff that that is a big part of patient safety nowadays. Because if the device is not secure and it goes down, that really can put patients at risk. So that needs to be considered as well. In terms of evaluating the patient, the privacy and the security controls, some of the other things to consider is also this long term support for the device. Which vendors are willing to provide patches and other stuff over the long term for those devices? Because the reality is these devices do have 10 to 15 year life span sometimes. So which vendors are going to continue to keep those platforms under support? And another recommendation, not quite in the guide yet, but what I'm going to add in the next version of the guide is, I think when people do buy these devices, they should request a list of all the software components that are contained in the device. Because it's not uncommon to find that even if they have an up to date version of Windows or Linux or something else in the device, that they're using an ancient version of Apache or some other old library and stuff like that. And having a list of all the components can help you in your security auditing. So my number one thing and I think more and more hospital should do it is put with their wallet and only bring devices into the environment that do meet some semblance of security and privacy principles. Additionally, one of the scary things, particularly exposed by WannaCry, but exposed in other sources as well, is a lot of the medical devices that were brought down by WannaCry were brought down because they were publicly accessible over the internet. Now, that's pretty scary because in 99% of the cases there's probably no need for those devices to be accessible over the internet. So, I mean, I could really go through in depth with the firewall, that kind of stuff is, but taking basic mechanisms to ensure that your medical devices are not publicly reachable, pretty simple, straightforward security control, missing in an awful lot of hospitals. So one section of the guide does go through different perimeter protections you can put in place to ensure that these devices are not publicly available and if they do need access to the internet and other stuff like that, things you can do to actually control and restrict access to just what is needed. Additionally, just like you should have defense at the perimeter, a lot of organizations fail in this area as well, is these devices do not need to talk to every other device on your network. Yes, all modern medical equipment, it's pretty much network-enabled, often for perfectly valid reasons to improve patient care because, you know, let's say you have a heart monitor sitting on a patient and, you know, the heart rate could automatically be sent to a nursing station where the nurse is monitoring it and having that kind of stuff networked, it can improve response times, much better for patient care. There's a lot of valid reasons for having this equipment networked. But the output of that heart monitor does not need to go to every device in your organization. Likewise, every device in your organization does not need to connect to that particular heart monitor. So a lot of the controls here focus on, you know, very basic network security, but stuff you often find lacking in a lot of hospitals, basic things like network segmentation, taking time to do vulnerability scanning of devices you have inside, making sure they're secure and making sure patches are applied, things like that. Very basic controls we commonly reply to regular desktop endpoints or servers in our environment or oftentimes missing from medical device deployments. So this section here basically advocates putting those types of controls inside. And even things like internal firewalls and stuff like that, you know, if you're going to spend three quarters of a million dollars on a MRI machine, spending extra 300 dollars on a small sonic wall to put in front of it and protect it is really not, you know, too much to ask. So, now device security controls. What are the security controls that should be configured on the devices themselves? And yes, once again, a lot of these things are very, very basic. Changing the default credentials on the device. It should be common sense to do, but if you look at a recent outbreak like MRI, it was a list of pretty much 61 passwords that were used to compromise hundreds of thousands of devices. So, in a lot of cases, just having basic mechanisms like this in place can be a huge improvement. So, you know, there are basic controls to prevent attacks similar to what we saw at MRI, like changing default credentials, account lockouts, things like that. But there's a lot of other things that hospitals don't think of to do. Like, let's say you have something like WannaCry, hit your environment. Do you actually have this for a copy of your firmware? How are you going to restore that device to a functional state if it's taken down? Much better to prepare for that kind of stuff ahead of time, be ready for it, then to go, uh-oh, I have no way to recover this device once an attack hits. You're having a backup of your configuration. Okay, maybe you applied the new firmware. You got it back in place, but that device probably had special settings to make it work in your environment. Do you have those backed up as well? Things like that that can help you recover from an attack. Uh, baseline configurations, make sure things are, um, deployed securely, having the ability to encrypt data, things like that, having update mechanisms in place, making sure that you do go around, have the latest firmware in each device, um, compliance monitoring to make sure the device stays secure, physical security, make sure the device can't be tampered with, and also things like asset management as well. You'll find in most hospitals, if biomedical devices were to come under attack, it probably wouldn't be IT or security that was notified right away. It probably be the group that handles the medical devices. And what they'd probably do to start is they'd probably swap the device out for a new one, wouldn't even think to troubleshoot it. So having proper asset management in place, if you were to come under attack would be good, because it would help you track what devices were compromised, what were not, and help you from putting an affected device back into production. Okay. Another thing you'll find in a lot of medical device deployments is they're either what they call interface or central stations that the device is connected to. So basically how I'm going to find that the central station is, let's say you have a series of heart monitors, there's going to be a computer that all that data is going to. Okay. So it's used to collect and analyze a lot of the data collected by these devices, and that may function as an interface, even if you have an isolated network for your medical devices, where that particular computer is then used to send data off to your medical record system or something else. So you might have proper network segmentation, everything else, but this particular interface device is going to be a potential weak point, because that's going to be what links the rest of your production network from your isolated medical device network. So you want to make sure that there's proper steps here as well in order to secure the devices. Things like standard OS hardening, making sure the data is encrypted as you transport it, basically have message security in place, and that once again you keep these devices and all of the software that runs on them is up to date as possible. Now this is an area I particularly like, is there's a lot of recommendations that we have so far, but I don't think you can consider anything secure until you actually go ahead and test it and prove it secure. Yes, you might have put a great firewall in, you might have put a bunch of rules in your firewall, but how do you know those rules actually do what you think they're doing, unless you actually go ahead and actually go ahead and test it. So I'm a big advocate of once you actually do these deployments, once you put the controls in place, that you actually go ahead and run a penetration test. See, does my security actually keep this device secure? I'm also big in having instant response plans done ahead of time, and I'm very, very big on doing mock incidents, to actually run through scenarios where you will actually simulate the device being under attack. How would you respond to it? You don't want a situation where the first time you're dealing with an incident is when the incident actually happens and people are lost in what to do because they've never run through the drill before. You can actually see a screenshot here. It wasn't done for medical devices, it was done for desktop PCs, but it's an incident that we actually did at Hospital I Work at. We actually did take over some desktops. I changed out Explorer EXE for another EXE that popped up this ransomware screen, and we actually saw how IT and the staff actually dealt with a simulated ransomware outbreak like that. So I'm very big on actually testing stuff ahead of time. Now some things about the standard is it is starting to gain some attention. So there is some growing adoption. It's been covered in magazines such as CSO Magazine, the IAPP Privacy Perspectives, help net security, health system CIO, a few other things. Also pretty interesting is it was recently translated into Turkish, because the Turkish Ministry of Health is actually considering adopting some of the recommendations as part of their own internal policies. So that's pretty interesting, and hopefully the adoption of something like this continues to develop and continues to grow, because I think it's a heavily unaddressed area of security right now. Just as a side note, if anybody's interested, it doesn't directly deal with the talk, but I'm also the author of the OASP Anti-Ransomware Guide, and that's another guide that has a set of 45 different controls in the categories there designed to protect the organization against ransomware using a defense in depth approach. At this point, I'll take any questions. Sure. Most of the framework I've laid out so far. Some devices, the patients take them home. They connect to implantable medical devices. In fact, some software may be like on iPhones. So you can't have this level of perimeter security with it. They may have to talk back to the medical provider. Could you give some advice on that? Thank you. Sure. That's definitely true. Most of the guide I did focus on was for hospital and healthcare institutions. So I was focusing more on, I guess, the institutions themselves, but implantable devices are definitely a risk. That's part of what we saw at the St. Jude pacemakers was it was their Merlin at home transmitter that was used to communicate with the device was found to be insecure. And yes, home users are not going to follow the same kind of security recommendations and things like that. I think that much more falls to the manufacturing standards the FDA is putting out to basically put security in place that way because you have much less control over what you can do with a person at home. I guess my standard was more focused on things hospital IT security staff can do to secure their deployments. But that's definitely a real valid concern. And I think that's better addressed though by the FDA guidelines rather than the budget I was working on. So jumping on the kind of the last question there, I know it's not exactly the topic of this conversation, but for blood glucose meters, insulin pumps, things that are embedded or worn on the actual patient, what is the FDA even trying to address these sorts of security concerns on those devices, things that are connecting to their iPhones and androids? They did release some guidance. It's non binding right now, but there is some FDA both pre and post market guidance that has recently been released. But like I said, it's currently non binding, so there's recommendation