I Am The Cavalry - Day Two: Uncomfortable Truths

The theme for today is Uncomfortable Truths, yes. This is Bo and Josh, and they're gonna get started with, I guess, just a 30 minute hello, talk about the cavalry for a bit, and then we're gonna get to more open discussion, right? Cool. All right, thanks. So,

who was in here for at least part of the day yesterday? Okay, and who is new? to the track today, just coming in. Okay, good. So yesterday, it was a very one-to-many kind of interaction. We were standing up here talking and bringing other folks on stage to go through some of the things that they care about, that they've seen, their wants, needs, desires, fears, hopes, dreams. Today, we're gonna be a lot more collaborative. So yesterday, just to recap, we started out and just did an overview of I am the Cavalry. So if you're not familiar with I am the Cavalry, we're a grassroots initiative that started three years ago here on August 1st. So we're two days past our third birthday. And the idea was

that as we looked around the InfoSec community, we saw a lot of the types of failures that we typically have, servers crashing, laptops not coming up when they're supposed to, such as our AV fail over here. mobile phones, getting malware on them, all of these types of things, we really hadn't seen a consequential failure. We hadn't seen loss of life. We hadn't seen a massive scale where people started to distrust the technology that underlies some of these societal systems. But as we're connecting software to more and more of the things around us, the consequences of those failures will increase. So it won't be as much about credit card data, PII, and it will be a lot more about loss of life, loss

of trust. And as we started looking around and talking to government people, corporate folks, others who might be looking at these types of problem spaces so that we could fix them, we found that there really weren't, there wasn't anybody in charge, right? We got as high and deep as we could and found that we were the adults in the room and that scared the hell out of us and made us empowered to be able to take action and to decide our own fate. So that's how the name came about. We said if the cavalry isn't coming, then the responsibility falls to us. And so I am the cavalry is all of us saying, I will

be part of the solution. I will not go quietly into that night.

That was our introduction yesterday, just basically briefing the people who haven't yet heard about us. Then we started talking about hacker heroes. We had Karen El-Lazari do a great talk. If you didn't get to see it yesterday, it's recorded and it'll be posted in two or three weeks. Calling out all of the protectors in the crowd, the people who want to solve hard problems because they know that it's a global good. We had a panel where we tried to talk through some of the hard problems that we see every day as well as the things that we've done to overcome them, right? To show the progression of things over the past five years, where five years ago, if we got a bunch of us together in a room,

we know what would happen. We would get drunk and talk about the problems and admire them. Today, we've started talking about what the solutions might be so that we can solve them and move towards something better and work on raising the waterline for everybody. In the afternoon we came back and we heard from Jen Ellis and Amanda Craig about what's going on in public policy in cyber safety. They went through a lot of different pieces of legislation, of regulation, state, federal, international, talking about how whether we want to or not, cyber security is now a part of the public policy zeitgeist and we can't ignore it anymore. as well as talk about some of the successes we've had with the

MCA exemptions for security research in medical devices and voting machines and in cars in getting a Michigan car hacking bill fixed. So where it was terrible before, it's now much, much better because of this community, right? Sticking their hand up and saying, wait a minute, something's wrong here. and then going and engaging in a positive, productive manner with those lawmakers. Then we moved on to health care cyber safety panel, our discussion. And it was magical. It was magical, as Josh says. So that was a lot about what's going on in the industry, some trends, looking back three to five years, and then coming to today, what's happening, and then projecting out another year or so and see what's going to happen. We had four really, really good talks that

were just five minute lightning talks from different perspectives. We had a US regulator, the US FDA, Suzanne Schwartz, talking about how they've been working to bring the entire community together in health care. So not just medical device makers, HDOs, health care delivery organizations, and the government, but bringing in security researchers as a part of a healthy ecosystem and how important we are to them. Colin Morgan from Johnson & Johnson gave a very good talk about, and you've got to go see it if you didn't see it yesterday. We had a video of his kid saying that his dad is a superhero because he works on these things that help people and he keeps the bad guys from hurting them with the medicine machines.

He also told a personal story about the path from Johnson & Johnson's perspective. and how they've gone from what security and medical devices to a very clueful organization that has a lot of good things coming and has done a lot of things already. We then heard from Jay Radcliffe, a security researcher, talking about the maturity of the entire ecosystem and some of the baby steps that he's seen in the past five years, where we've come, and how not only have the companies matured and gotten better about responding to us, Also, the FDA and ICS cert and other government agencies have gotten better about dealing with security research, security researchers. But the researchers themselves have also stepped up and they've been more willing to work

collaboratively rather than just dropping out of a black hat. And it's not because any one group stood up, it's because all of them collectively started standing up and going around in a virtuous circle. Then we had Khwadi, who is here, gave a talk from a physician's perspective. And he basically said, look, guys, this isn't about you. This isn't about manufacturers. It's not about the FDA. It's about the patients. Patient safety is the number one concern. And then after that talk, we had a car talk, which I wasn't here for because I had to run upstairs. So why don't you debrief on that? Yeah, we've had the most progress, I think, in automotive and medical. So

that's why we really highlighted them yesterday. I basically showed the five-star cyber safety framework we published two years ago and then gave kind of a progress report for how many and which parts of the automotive ecosystem have embraced it. So instead of showing a highly technical presentation, if you want to go look at this, I showed the kind of slides that are appropriate for being ambassadors into that community. We also glossed over who was on the midday panel with Nickerson. That was basically the head of cybersecurity for Philips Medical, the One of the guys from NHTSA, which is the National Highway Transportation Safety Administration, the regulator equivalent of an FDA for cars. We had Sasha from Exxon with an oil and gas

perspective. And the goal there was to kind of show these are areas that are working, why they're working, and where the passion plus personal responsibility and ownership has really made a dent. So some of those examples came up again in the car place because we were able to show where NHTSA was essentially not involved or where some of the automakers were in an adversarial relationship with researchers for some good reasons. And now how you have Tesla, Ford, excuse me, not Ford, Tesla, GM, and FCA, Chrysler of America, Fiat Chrysler of America have published coordinated vulnerability disclosure programs with a few others coming soon. So that was really a progress report of what's succeeded to date against the five-star cyber safety framework and the overall ecosystem.

And then we adjourned abruptly. So Beau's overview yesterday is not bad. I see some new faces, so I'm going to show a few little framing things. The purpose of today is if yesterday emotionally was where we've won and where we're winning in the first three years, today is really frickin' hard problems that we don't know how to fix. Really hard ones. And we want to have the candor and the trust with each of you to speak very aggressively about some of these. In the morning, we want to really tackle uncomfortable truths. And one of the things we've experienced is, this is a great line, I think it was from one of the presidents, but the opposite of a profound truth is

not a profound lie. It's another profound truth. And most of our hard, untractable problems are where you have competing profound truths that come into tension. And we can't be so polarizing as to say, well, my truth is more important than your truth, because that perpetuates a stalemate. So one of the things we want to do is surface some profound truths that make this really, really hard. In fact, one of the things I alluded to in the cyber safety framework for auto is star number three, which I'll show briefly in a minute, is evidence capture. We don't have any security logging or evidence capture in automobiles at all. And one of the reasons we don't is actually friends of ours that are privacy advocates have been so harsh on

the automotive industry historically and on the government historically for good reasons that none of them are willing to get in that fight again. So there's really intractable problem where really good privacy goals are coming at attention with really important forensic and NTSB and accident investigation goals. Rather than us admiring the problem or being stuck for years, the goal of the cavalry is to be safer sooner. And we can only do that if we work together. And that means we really want to hear some of these. So I have some horror stories I'm going to share from the Health and Human Services Cybersecurity Task Force of how dangerous modern health care delivery organizations are. And we don't know how to solve some of those problems. We're hoping

to surface some on agricultural technology, which threatens parts of the global food supply. We hope to talk about some of the oil and gas issues, if people are willing. And we're also going to shut the cameras off so that we can have it, at the moment someone wants to, so that we can have really important revelation in surfacing a ground truth. And the idea is later this afternoon, we'll take some of those ground truths. And if we have uncomfortable truths, they necessitate uncomfortable solutions. So even though we kind of hate regulation, we kind of hate laws, and we kind of hate lots of parts of society. When we have cars that can kill people or airlines that can fall out of

the sky or oil and gas pipelines that can explode, we have mandatory safety things. And now that bits and bytes are meeting flesh and blood, even if it's un-able, we want to surface maybe some possible solutions to rise to these challenges. So with that, I think I'm gonna show a few framing things. Especially because there's some new faces. And then I'd like to get into some uncomfortable truths, if that's OK. And if you have one, we want to hear it. So I'm terrified right now by clinical medical environments, agricultural technology, and some of the oil and gas stuff. But maybe you've got an even worse one that we haven't heard of yet. So this is where we want to surface some of that stuff. Anything else? Go for

it. OK. So real fast. I don't think all white hats or all of our tribe here in Vegas this week, even if you don't identify as a white hat, have the same motivations. So one thing that's been very useful in talking to policymakers. We should also, yeah. Beau and I recently left the private sector to go to a nonprofit policy think tank. So he literally went to Washington. So Mr. Geek goes to Washington. I'm just traveling off into Washington. But we're trying to more directly influence public policymakers. We were doing a lot on top of our day jobs. but we saw that we weren't getting better fast enough. So we want to be a platform and a conduit for

any of your concerns. And we built trust relationships with executive branch, with legislative branch, with justice. We built some of those trust relationships. We're still building some more. But look at this as not what we're doing, because we can't do it. But look at us as a platform and a conduit for your deepest concerns. But one of the things that's been very helpful is they don't know why hackers would hack anything. They're like, why would you do this to us? Why would anybody hack our vehicles? What are you, crazy? You're endangering everybody. You must be trying to extort us, things like that. So one thing that was very useful is I kind of broke it down into five motivations of White Hats. And no one is just one thing.

I have two of these. I major in one, and I minor in another. And each of you may carry a different one. I find the B-Sides crowd tends to be a little more similar than maybe the DEF CON crowd at large. But there's protectors that want to make the world a safer place. There's puzzlers who do it for challenge, for curiosity. It's probably what started the hacker culture was the curiosity. There's prestige that want to win the white jacket or be a rock star or be on stage in keynote Def Con or Black Hat. There's profit, which is to make a living or personal gain. And then there's protest. You're for or against something, but

lawfully. Think like protecting dissidents or outing corruption or things like that.

This becomes really important as we acclimate 100-year-old car manufacturers and very long-standing device manufacturers and medical to realize you don't have to, depending on how you engage and what your coordinated vulnerability disclosure looks like, you're going to attract or repel subsets of these. And how you interact with them will differ. So if you're working with someone who's primarily motivated for prestige, they're not going to negotiate with you to give you more time before their DEF CON talk. They're going to do their DEF CON talk because their primary motivation is to do the DEF CON talk. Whereas if it's a protector, they're not really out to get noticed. And some of the best car hackers we've met, for example, you've never even heard of them. Because they're

just doing it to make the world a safer place, or they're doing it because it's fun and it's a hard problem. So for me, I'm a protector first. I want to make the world safer. And it doesn't hurt if it's a really, really hard problem. So I'm a puzzler second. I'm not sure what yours is, but I'd be very eager to find out. Typically, the people at B-Sides are a little more consistent. Obviously, there's other motivations, but that's the simplest way to do it. And people in policy like short lists, and they like them to have the same letter at the beginning of each of them. So we went through some of the what's working, what's not. And I'm not going to go

through in great detail what the five stars are, but let's just pick one. On our first birthday, we published this one. for the automakers and it started a pretty robust multi-stakeholder collaboration process where people said they were doing security but no one could actually describe what they were doing or which parts they were doing. So without reading all these, we basically said all systems fail, so you need five ready postures for failure. We're not going to prevent car hacking, we're just going to make it less damaging. So the first one is do you tell your customers how you avoid failure? Second one is do you put on a welcome mat to take help avoiding failure from researchers trying to help you? Do you have a way to capture, study,

and learn from failure? Do you have a way to promptly respond to failure? And do you have a way to contain and isolate failure? It's a way oversimplified version of much more elegant language. But we're just assuming cars will be hacked. We want to make sure a hack of the stereo can't shut off the brakes. We want to make sure that you're taking help from researchers instead of sending them cease and desist letters, those kind of things. And even though this stuff won't make the cars much, much safer, it starts a culture within these organizations to prioritize cyber safety issues.

The evidence capture is the one that's really freaking hard because of some competing ground troops. But what I'm going to walk through and what I promised I'd walk through is this one. And I'll do a short version, but my hunch is we're going to dive deeper into each of these later throughout the day. We haven't published this, but I've been using it for all three years of the cavalry stuff. When I go to like a big industrial controls manufacturer and they say, well, how is this different than IT security? We already have a security team. How's IoT different? The easiest thing to do, and I've done this in one hour, I've done this in one

and a half day, I've done it in a full day, is to walk through six ways it's different. And this is where things start to get uncomfortable with our friends, because we have longstanding beliefs about when a device manufacturer doesn't fix something, the only way to catalyze a fix is to do a disclosure. And that's true for websites, but what happens when it's an unpatchable industrial controls device that can cause cyber physical damage. So it can't be fixed. The act of us disclosing that, even though that's our conventionalism for 15 years, may actually be the thing that puts people apart. Sometimes we're all we have. And I feel very conflicted about that. For a long time, we've seen evidence that if you want someone to fix something, and they

won't fix it, you go public. Or some of these forever days that can be really dangerous. One of the ways that help people understand this in the cyber safety or cyber physical industry and this framework. So really quickly, I say that we have different adversaries that are used to dealing with these non-scrap kitties or card scammers for some of these cyber physical systems. Different adversaries with different motivations and different capabilities. Number two, there'll be different consequences of failure. I'd like to get into some of those. But really briefly, we won't measure these in number of records lost or number of credit cards lost. That's how we currently measure breaches. We're going to measure them as the number of lives lost, in impacted GDP, or gross domestic product, or in

crisis of confidence in key markets and national security. I mean, after- What does that mean for geeks? For what? For geeks. For geeks? So break that down. Because that works for policy makers. Yeah, you're right. So we're in this ingenuous role where we're translators and ambassadors. So sometimes we have to use words like cyber, and people are going to have to get used to that. Don't worry, we'll do plenty of drinking this week. What it means is the fact that something, and we were just talking about this, the fact that there's cross-site scripting in something doesn't mean it's a business impact. So we focus on what's broken, but maybe not why it matters to the business. But when you're talking about

some of these things, if my mother-in-law no longer trusts her Jeep because there's enough hacks or someone gets killed in a Jeep, Jeep will probably go out of business. It'll probably be a hostile takeover. I mean, if you hit the stock price enough, if you damage brand enough, And when we were talking to some congressional folks, they said the automotive industry, when they decided to bail out Detroit, for example, the math was pretty simple. They saw that one in nine Americans were employed directly or indirectly by the auto industry. Because they're either an automaker, a tier one supplier, a service technician, a parts manufacturer, a dealer association. So any loss of a single OEM was calculable to be a potentially double digit impact to the US economy.

So maybe all they care about is money, but that gets their attention. Whereas maybe a single person dying from an accident doesn't matter to them, because we have about 100 fatalities a day in the US for car accidents. That's just kind of acceptable loss. I don't think it's acceptable, and NHTSA doesn't think it's acceptable. But it's not the fact that there will be a death. It's the fact that an exotic death might scare someone so bad that it hurts the economy. It makes people not trust these safer modern vehicles. And more importantly, as we saw post 9-11, or we saw in what's happening in Paris and other parts of the world, is when you have

a catastrophic failure from an exotic adversary, we tend to compromise our values. We tend to send blood and treasure overseas. We tend to introduce secret FISA courts and programs that were leaked by Snowden. So we want to make sure that we preserve trust and confidence. Because a breach, or even having someone like a target go out of business, would be an acceptable loss for the country. But having a crisis of faith in the government's ability to protect you is not good. Really not good. And if you're trying to provide cutting edge medical treatment to improve life and sustain life and prolong life, and people and chief medical officers stop trusting some of these hyper-connected devices, that will negatively and adversely affect all the benefits we could have from

modern technology. So the consequences of failure are not going to be breach records. It's going to be measured in different units and more consequential units. The context and environment changes. So these are not operating behind layered security perimeters. If it's a medical device that's attached to your body, it's a migratory device. There is no perimeter. And there never will be. The device is going to be its perimeter. And in combination with some of these other things, you can't just assume you're gonna have a UTM in your home that somehow shields you from all of the things that might attack the growing number of IoT devices in your home. You know, people call a car a computer on wheels. It's more like a data center on wheels with several cloud

components, right? So the operational context and environment we cannot assume is identical to normal traditional security. The composition is different. So the hardware, firmware, software stacks are going to be very different depending on which type of IoT we're talking about. And one of the reasons I do this with manufacturers is if you're a small device manufacturer on Indiegogo Kickstarter project, versus a Siemens industrial controller that's going to live for 30 years and cost millions of dollars to buy, this framework becomes increasingly important to understand the physics and dynamics of how to do this stuff. So in the composition of goods, you're seeing a lot more ODMs bought by the pallet. You're seeing really cheap stuff where the margins matter. You're seeing a

lot more Android OS, which is super secure, right? So we should put it in all sorts of embedded cyber physical systems. But it's because it's The XWorks is great, right? Yeah. So the kind of things that people gravitate to for either price reasons or developer talent force reasons are fairly different. They're not going to be Windows in all cases. They're not going to be familiar, which is both a blessing and a curse for adversaries. But different economics. So sometimes if it's a really small device manufacturer or like a Nest that used to be small, they don't have a CISO. They don't have a security staff. They might only have three employees. In fact, I heard from the FDA the average number of employees at a device manufacturer is

seven. I don't know if that's accurate still, but I heard seven, I've heard 11. But what's the probability that one of those seven or 11 is a cybersecurity expert threat modeler and secure coding expert? I mean, Bo and I, usually when we talk to a manufacturer, one of the first questions we used to ask, we don't even ask anymore, is which threat modeling method do you use? After everyone said, what's a threat model? We stopped asking for a bit. We get them there, but we don't ask them on the first call anymore. Sadly though, Brian Knopf, DUQA, he gave a flash talk at the IoT village last DEF CON a year ago, and he asked the room which threat modeling they use.

And none of the hackers knew what a threat modeling tool was either. So that's not good either. But we've got to work on that, because if these things haven't been threat modeled at the design stage, they stand very little chance of being resilient to attack in operational environments. But the economics is incredibly important. Depending on what you're talking about, the margins may be negative. There might not be a budget. The price point, even if you spend 10% of your cost of goods on security, if your cost of goods is $20, it doesn't work out so well. So we've had some uncomfortable conversations about certain device types under a certain price point. will never be secure and will never be securable. And therefore, maybe if they had

the ability to affect public safety, they shouldn't exist. Maybe. And these are uncomfortable conversations. And then the time scales is really important too. So the time to live for my phone, right? How long do you keep a phone? Now, they can live longer, but how long do you keep a phone? Two years? Three years? How long do you keep? should you, the average durable good of a car is seven to 11 years. So if the body of the car is durable and useful for seven to 11 years, but we're increasingly buying the car based on the technical features of a cell phone, there's a mismatch between really legacy outdated software and the physical durable goods. If it's a Siemens industrial controller, the ROI might be

30 years. Like to buy that thing, it better work for 30 years. Can we anticipate all the new threat models three years out from now, let alone 30 years out from now. So there's really poor future proofing on these things. So on the scale here, what we basically do is we make a grid, depending on which things they're looking at. And we try to factor in what's the time scales, what's the margins, what's the regulatory, implicit in the economics is what's the regulatory pressure for your sector. And they look very, very different when you're talking about a Fitbit versus a nuclear centrifuge device. Anybody have questions or objections or major omissions on this little framework? Because this will help us

when we talk about some of the uncomfortable truths. Let me make it concrete. Hospitals, we're going to get into a lot. But hospital medical environment, it's composed of lots of medical devices. And we have some medical device manufacturers in the room. Even if they made a magic wand and make really, really good secure devices right now, they come to the market a year from now, the economics of a health care delivery organization is they don't have a lot of budget. So we talked to a bunch of, I'm on the Health and Human Services Cybersecurity Task Force that Congress asked for in December. And Michael McNeil from Phillips, who was here yesterday, he's also on it. It's very overwhelming. We have some health care delivery

organizations, small ones and large ones, on this task force. And their statistics show that most health care delivery organizations, even large ones, don't have a CISO. And many of them don't even have a single IT person on staff. So how do you network segmentation and isolation, and system hardening, and patching, and basic hygiene, when you don't even have a single IT person on staff? So the economics are such that one of them said, we can either hire a CISO or a surgeon. We can either buy a firewall or an ambulance. And they went up through medical school, so they're leaning towards Now, some of that might not be true. It might not be zero sum. And if the regulatory environment

changed, if the incentives changed, if the culture changed, they would realize that they shouldn't buy a house they can't afford and get upside down on their mortgage on the IT and security debt in some of their purchases. But at the moment, they're incredibly prone because in their culture, in their economics, and in their incentive structure, that money is fairly zero sum. And it goes to more health delivery professionals.

So in the adversary model, I don't think Russian criminals that do card scamming would take down patient care in hospitals. I don't think that's likely to happen. I think it's more likely to be some adversaries that are ideological, the kind of people that shoot up a nightclub, the kind of people that blew up the finish line at the Boston Marathon, the kind of people who like Trick, which I have a slide for him. But Trick was a member of Team Poison Anonymous. And he radicalized. And he moved from the UK to Raqqa. And shortly after DEF CON last year, he was killed in a drone strike because he started the cyber caliphate, was recruiting people

to come hack for ISIS, was training them how to use Shodan to find our hard-coded default passwords in our hospital equipment and in our power plants that nobody bothers to keep off the internet, that nobody bothers to change the passwords. Some of them, they can't change the passwords. So what you have is someone with the means, motive, and opportunity to negatively and adversely affect patient care. And we typically dismiss this stuff at FUD as FUD, but it happens to also be true. And it's very easy to make new versions of Janiyad Hussain. So when we run through these kinds of things, who has the means, motive, and opportunity to hurt a hospital clinical environment? What are the consequences of failure? Well, you'll

probably have loss of life. You'll certainly have shattered confidence. You might have chief medical officers less likely to attach more and more critical systems to the internet, which hurts things like meaningful use and all sorts of other electronic health record initiatives. We don't want that, because as we can start to share electronic health records more accurately and more interoperably, there's a belief that things like machine learning might actually cure diseases we haven't cured yet. The context and environment, they can't do segmentation isolation because they're forced to be hyper-connected. The composition of goods is unfortunately in this particular case way too familiar. It's a lot of Windows XP. In fact, even when you give them new devices, one of the comments they made was, you're going to have to

pry our XP out of our cold, dead hands. Because when they have a system that works, they have very good necessary reasons to not mess with it. It's just we have not impressed upon them that using something like, in fact, I had a really good analogy the other day. It's expensive for surgeons to wash their hands really rigorously and methodically before surgery. And it takes a lot of time to do that when they could be doing surgery. And they do it. Because after analysis of post-op fatalities and post-op infections, things like the checklist manifesto justified that's necessary hygiene to come out to the outcomes and the survival rates you want to see. But we haven't figured out that a failure to cleanse your XP from your operating

environment in your clinical delivery environment may be the equivalent of failing to wash your hands before surgery. Just don't say cyber pathogens. I will not say cyber pathogens.

But the economics are really important here, and the time scales are also really important. Because if you go to make a purchase of a really expensive piece of big iron, something like an MRI machine, the capital justification is that thing has to be functional for a minimum of this many years to be cost justified. So the timescales are much more protracted. And even if you could demonstrate a clear, unpatchable, unmitigated pathway to harm in a clinical environment, the hospital will still have to use that device for a long period of time, knowing full well that it may be vulnerable, because the business is there to provide health care. They'll have to come up with some creative way to do some sort

of mitigation or segmentation, if they can.

I'm going to touch on that. I might as well do some right now then.

Yeah. Let me pull up one little slide. This is Hollywood Presbyterian Hospital in Southern California. Most of you heard that ransomware is hitting hospitals. Ransomware wasn't trying to hit hospitals. It just landed in certain hospitals initially. So the Sam Sam attack was leveraging a known vulnerability in JBoss and lots of medical devices that happened to be exposed to it. And people didn't know they were vulnerable, so they didn't know to patch it. This is a great argument for why we need software supply chain transparency and software bill of materials and all these things, so we can actually tell what we're using, where we're affected. So that if we hear that somebody has a hospital ransomware infection, you should be able

to ask, are we affected? And where are we affected? And which systems do we need to isolate or patch? And you can't really do that at all right now, except for a few exceptions like Phillips is voluntarily publishing a software bill of materials lately. But this particular hospital didn't pay the ransom. They happened to accidentally get hit by it. The ransom was very low. I think if they knew they were in a hospital, they could have charged a lot more. But the effect was the lack of flow of electronic records essentially prevented them from delivering patient care for a sustained amount of time. And they diverted ambulances. They tried to move certain patients at one point. And depending on the severity of the victim in the

ambulance or the severity of the patient you need to move, that's a really high risk maneuver. And it takes a lot of staff to do it safely while they should be focusing on the delivery of patient care that people need and deserve. So when I saw this this spring, this is one of the reasons Bo and I left the private sector. Because I said, this is not good. If an accident can cause a denial of patient care, If random network bouncing traffic, just normal cesspool of the internet can cause this, what could someone who wanted to do it do? And more importantly, what's our response time? Could we even shut it off if we wanted

to? Sure, you could try to patch that one device. But I don't know if you guys heard this. It came up on a panel last night at Codenomicon. Billy Rios took a look at one device that had over 1,400 known CVEs in the one device. And someone said, oh, that's exotic. It's an old one. And we looked. I'm like, yeah, it's a little old. Let's look at a new one. About 1,000 known vulnerabilities in a typical clinical device. Now, the smaller ones have less codes. They have less vulnerabilities. But there's lots of old JREs. There's lots of old operating systems. There's lots of things like Bash. There's lots of just poor supply chain hygiene, people using older versions of OpenSSL or HTTP client. One of the big irons

he looked at is still using DOS. So the kind of hygiene you see in a typical environment, if there's 1,000 of those vulnerabilities in the average device, and one of them was able to shut down patient care, it shows that we're in an incredibly fragile state. So to your point, though, after this was revealed, you saw some more deliberated targets of the next versions of ransomware towards hospitals. So there is ways to make money. And I hope to show a slide, just not for too long. that I use in my CMU course, where we kind of map out which adversaries are you likely to face for your industry and in which priority. So you don't want to fix every vulnerability, as we were discussing earlier. You want

to fix the ones that could be a consequential failure to your organization's mission. And that way, we're not looking at fixing every little thing on our website. We're looking at what's the cost of wrong for certain types of failure conditions. So on this one, yeah, there's plenty of money in doing this. But the thing is, I've been studying adversary classes and motivations for a very long time. And one thing that criminals are really, really good at is not provoking a law enforcement response. And if you stay under their threshold, and if you haven't paid attention to this, every time the FBI talks to your local InfraGuard chapter, they'll tell you what it is. As long as you stay below their threshold, they can never chase their caseload.

So really good criminals, of which most of them are really good now, They know the safe zone in which is acceptable losses in behavior. And many of them would not deliberately hit hospitals, because as soon as they start killing people, they will provoke a law enforcement response, an international one. So it's not really good math to try to target health delivery organizations. So there's a little bit of a spike. And if you get somebody drunk from one of the antivirus labs, they'll tell you there has been a bit of a spike in the targeting of medical. But they're not going to breach a threshold where they provoke a response. But yes, they are a threat actor. In fact, one of the reports I just saw shows that PHI,

the street price, is going way up. So there's a lot more deliberate targeting of health care information. The thing is, though, we're not the cyber privacy movement. We're the cyber safety movement. So we're trying to make sure that there's plenty of consciousness in the community to focus on privacy. There's HIPAA. There's high tech. There's a lot of focus there. There's almost no focus until we got on the scene on cyber safety. But to the government's credit, I mean, the one representative, they only have 20 people in this task force and they picked us to be kind of a voice of the white hat. I mean, the fact that they asked for white hats at all

is freaking amazing. And they picked this group to try to be that voice. I think because we've proven we can be more collaborative. But they're not ready yet for this. They're trying to initially grapple with that fact. So yeah, you could do it. I'm not saying they would always honor it, but you know, Chinese could do this, the Russians could do this, the Israelis could do this, the French could do this. They all have the capability to do it. But it's means, motive, and opportunity. And we have conventions and treaties like not hurting non-combatants and things like that. And people violate them all the time, but we also have a mutually assured destruction thing. So I'm not saying we're safe from those actors. I'm saying

that the one that concerns me most about triggering that crisis of confidence is accidents and ideological adversaries. the accidents point. If you have something that's meant to steal banking credentials and it gets onto a medical device and it's so poorly written that it crashes the medical device, you don't have to imagine that someone's going after that medical device. And what I say is malice is not a prerequisite for harm. Great line. So I can definitely see where cyber criminals trying to steal PHI, for instance, could inadvertently kill people. But it doesn't mean that they have to try. Yeah, and we're kind of hoping someone cries BS here. But the thing is, most of my career, I've been looking

at new adversary classes and motives and what they do and how they're thinking. And it sounds like someone's about to cry BS. All right.

The question for the camera is, have we seen? And by the way, anybody at any time can ask us to shut this off. And I won't reveal who asked it if you want. I have no knowledge as to if there's any difference in propagation by country for China or Russian hospitals. We do know that one of the reasons the US is particularly vulnerable is we have private medicine. So some of the more centralized local ones, they're still vulnerable, but they have more span of control. can make more consistent reactions. So in some cases, it's to our disadvantage because we have a very fragmented

population of... When you go back to DC, you might want to check on that. I definitely think it's a great question. We know that some of the penalties for hacking in different countries do affect the prominence of attacks. This particular one was an accident. No one was targeting the hospital. They were targeting JBoss. which is in a lot of places. Male Speaker 2 001 001 001 001 001 001 001 001 001 001 001 001 001 001 001 001 001 001 001 001 001 001 001 001 001 001 001 001 001 001 001 001 001 001 001 001 001 001 001 001 001 001 001 001 001 001 001 001 001 001 001 001 001 001 001 001 001 001

001 001 001 001 001 001 001 001 001 001 001 001 001 001 001 001 001 001 001 001 001 001 001 001 001 001 001 001 001 001 001 001 001 001 001 001 001 001 001 001 001 001 001 001 001 001 001 001 00 understand those organizations are behind where US is. They're looking to us to understand what to implement in systems. And so they're further behind. And so they don't have a lot of other, they're still working on paper, they're in those kinds of conditions. You know, I know someone I can ask your very question of, I just can't do it in real time. But maybe after lunch I'll know the answer. I know someone I could

ask. And you're very right about other countries being somewhat behind in terms of technology. And that's one of the things that, in talking with policymakers and others in DC, when you start to ask them, what do other countries have to lose versus what we have to lose, it's pretty clear that we are the most highly exposed, the most highly dependent, and the most highly prone to this. And other countries have less repercussions. So when certain military people say, well, it's like mutually assured destruction. We can take out their systems, they can take out ours, that's how we know we won't. The math doesn't work quite that way. This is an incredibly key point and if

you haven't been following us for a while, let me just remind our organizational problem statement from day one was this, our dependence on connected technology is growing faster than our ability to secure it in areas affecting public safety and human life. And I chose that word very carefully after spending enough time with Dan Geer. One measure of security is how dependent you are on something. And if it's not dependable, you can either make it more dependable, which is incredibly costly and will take a lot of time, or you can depend upon it less. So what we really want is to never place more dependence on something than it is worthy of. And the US is asymmetrically more dependent on IoT and modern technology than others are.

I think health care is a good example of that. But we're not the only ones. There's much more modern medicine in other places for certain types of things. But we are more heavily dependent. There's a great graphic novel that I bring up. It hasn't clicked for anybody why. It's called Why? The Last Man. And it does a thought experiment where every man on Earth except for one guy just dies. And it shows what happens, like the domino, the branches and sequels and the cascading effects. And it shows. Like, the next person in line to be president is like the Department of Secretary of Agriculture, because they're so far down the line at the time this was written for women in government. And it

shows how many pilots died, how many surgeons died, how many of this. So it kind of amplified inequalities in different places. And one of the more stunning things it revealed was the most dominant fighting force on Earth's remaining. Can you guess where it was? Israel. Why? Compulsory service for men and women. So it wasn't, I'm not trying to make a feminist point. I'm trying to show that the variations in how dependent we are on connected technology will mean that even though we're all equally vulnerable globally, we're not equally dependent. And we are one of the most dependent countries. And this isn't a US-centric movement, but the US is one of the most dependent countries on very fragile IT. I

just wanted to make a comment about, you know, I've certainly traveled a lot around the world and I've unfortunately gotten sick in a lot of places around the world and have had to just kind of get local healthcare. And I can tell you while there are certainly plenty of places that have more advanced medicine than us, that is not the norm. And the devices that I was put under to verify, you know, pulse and EKG and whatever, I promise you none of those had an IP address. So I think there's also a little bit of a lag, right? I think there's a little bit of a lag of how big of a problem this is

in many other parts of the world, as well as the sensitivity to how big of a problem that would be perceived even if something were to go wrong. So would a response to a compromised medical device in Sub-Saharan Africa be the same as the response to that sort of thing in the US from a public perspective? And I suspect the answer is not yet, and we'll probably get there. And another analogy is if you take a look at what happened with SWIFT, the global banking network for money movement, it's also not by accident that they targeted Bangladesh, Vietnam, and places around the world where there are much, much more lax standards around the IT environment where those systems would be operating. So again, I think it's also

opportunistic. They go after the areas where there's gonna be less law enforcement, it's gonna be easier to execute the attack, you can get plenty rich without like Josh mentioned, alerting the big boys and getting their attention. A lot of it is just opportunistic. We still have all the old adversaries. We're just trying to say that we have some newer ones too. I have to go upstairs briefly for a few minutes, in a few minutes. Let me just try to make one more point before we take more audiences. I've been skipping this. When Jericho and I spent two and a half years researching these guys, everyone that had researched them prior got attacked. But we did

it kind of in a humble way. We wrote this Building a Better Anonymous series, and we kind of engaged them in a dialectic. And now the public knows tons more. But one of the things we said on the very first slide that we had Mar do from the 303 group was we said we're less concerned about anonymous and more concerned about the blueprint that can be picked up and perfected by others. So what comes next? If they're like an emergent property of hyper-connectivity, if it's showing how much power the individual has to use for any motivation in the human condition, what will come next? And if you've been watching the news, the people basically are,

darn it. Basically, it's kind of undeniable that ISIS has perfected the blueprint of social media and asymmetric use of the internet. They're doing a much better job with it than Anonymous was, because what Anonymous lacked was a consistent ideology. So the US intelligence apparatus is dumbfounded at how a Silicon Valley innovation has been perfected by one of our more unpredictable enemies. And we tend to dismiss this stuff as FUD, but I think you guys are adults, so we can talk about the reality here. And let's just make it really grounded. There were only like four or five pockets of actual hackers in Anonymous. There was cabin crew, there was lul-sec, anti-sec, there was team poison. And one of

the better hackers in team poison was Janiyad Hussein, a UK citizen. He's the one that defaced all the stuff for Tony Blair. Very well educated. CNN's doing a documentary on him right now. He went to like a really genius prodigy kind of undergrad, I mean primary school. He radicalized some point after our research was done. He moved from the UK to Raqqa. He was paying, he's being paid dollar for dollar, the same as they pay their military leaders. Dollar for dollar. I'm less concerned that they're starting to use more IT and more concerned that they value them equal to combatants in their pay structure. And he was recruiting and training people. And you all know the kind of stuff you can find on

Shodan. You all know the hard-coded passwords you can Google search and Google DERF for. You all know If we can see it on the internet, we can probably do it. And one of the things that the ICS hackers tell you is, you don't need to hack these things. You just do a Nessus scan and you'll crash them. And if you're not trying to have stealth and persistence and exfiltration and lateral movement like we've all conditioned ourselves to think about for the confidentiality of data, if your goal is to deny service of a medical service or to denial service, to kill switch an ambulance, if your goal is an availability attack, that's all you have to do. So the barrier to entry is incredibly low

to cause harm. So if you look at the relative talent of someone like Junaid Hussain, it's down here versus a Russian criminal or a nation state attacker with a nation state budget. The difference is these guys lack the motivation or will to do it for a bunch of reasons. And they can. But these guys, while not talented, are much more willing to assert themselves. And this, again, is your invitation to cry BS on this. But what we have between Hollywood and Presbyterian is an existence proof that an accident can cause a denial of patient care. And what you have in TRICK, which is handled, T-R-I-C-K, what you have in TRICK is an existence proof of someone who is willing and able to do it. So when you think about

the means, motive, and opportunity, the motivations are as varied as they are in the human condition. So out of 7 billion people, maybe Bo will talk about his Drake equation later, out of 7 billion people on the planet, and we know about somewhere between 1% and 4% are sociopaths, we're hoping that none of those people ever notice that they can use Shodan and Metasploit to take down a hospital. I don't like those odds. You have to have a lot of faith in humanity.

Do we even know of any sociopath hackers? You probably drank with one at the bar last night. Think about a few high profile hackers that we know are sociopaths. Just here this week.

And I don't think it's going to require malice. Some of our friends that are trying to embarrass some of these things, they'll just post stuff on Shodan and hope no bad guy is going to say, oh, look, I can do that. It might be an accident. We might be the very thing that causes this first loss of life. We wrote a position on disclosure on the cavalry site. And if you have even three minutes, please read it. I started off by stealing from Nietzsche. I said, he's got this line, whoever fights monsters should see to it, he himself does not become one. I said, those concerned with public safety and human life should take great

care not to inadvertently put them at risk. And it kind of messes with all my training. I've been doing this a very long time, as many of you have.

of had certain entrenched beliefs about disclosure. And now that we're looking at forever days in safety critical industries, it gets more complicated. So this bothers me. The other thing about health delivery, which we should pick up on later, is it's not that it'll happen. It's that the response time is really, really ugly. And I do not have time to tell you why yet, but we will today. It's really, really ugly. And it's not my opinion. The task force has been talking about it every meeting. about how many years. So first of all, it's measured in years. But it's more like 15 years from when we have our big catastrophic moment until we have something slightly more defensible. And

one of the reasons for that, I'll just get this jab in. One of the reasons the US has a self-inflicted problem is with the HITECH Act, we attach reimbursement to something called meaningful use, which had lots of good reasons to do it. But what it did is it took a bunch of devices that were never threat modeled or designed to be connected to anything. And it forced them to slap on connectivity to be connected to everything. So none of them were really ready for this level of connectivity. So we kind of forced ourselves to be more exposed than maybe other countries. And if you think the US is prone for those reasons, they are. But

what's even worse is when we finally let go of those Windows XP systems that we're clutching from our cold, dead hands, they have very long secondary lifespans in other parts of the world like BRIC countries, like Brazil, Russia, India, China, and other places, who would kill to get that XP device. So, Bo, you want to pick up from here? Yeah, sure. I'll be back. Not sure what's in your slide deck, so I'll probably just use it. Nothing. Don't use it. OK. Yeah. Well, then I'll put this down. Yeah.

So where should I start? One of the critical things that Josh kind of alluded to, and as I'm on, I can't hear myself. Can you hear me in the back? I mean, you're in the back. All right, all right. There we go, there we go. I think I'll just do this. Maybe it's cutting out. It's cutting out. I don't know. So, all right, all right. So, one of the things that really kind of disturbs me when I go and talk to, about two weeks ago, we called it IT Security for Medical Conference. And it was a bunch of the automatomakers who were there to learn about security in vehicles. It was a really good conference over the course of two days. And a lot

of people said a lot of things like we're saying here today. And the automakers were like, yes, yes, this is all very good. We're learning something. And a lot of the folks in the room were part of the security groups within the automakers, which is really encouraging to see those security groups standing up within automakers. the OEMs, the car brands like BMW, as well as the tier ones like Bosch, like Continental.

But one of the common themes is when I was talking about the timeline to respond, the German automakers were saying, well, yes, it takes time to do security right. We want to get it right because we're German. It's a very German thing to want to take our time and be deliberate and get it right. I said, okay, that's great. So how long is long enough? Well, you know, standards processes, they take a couple of years to brainstorm and then define and then once you've defined them, it takes a couple of years to get them into some of the designs that we're going to do because there's revisions. And then once we get them into the designs, it takes a couple of years to get them into specs and

RFPs. and then out to vendors, and then a couple more years to get it from the vendor into our designs, and then a couple more years to get it into the cars. So, okay, so what does it look like? What's the timeline between when you know that you have an urgent need and when the first car rolls off the assembly line? Like, oh, you know, it can be seven or eight years. So seven or eight years between when you know you have a problem that you need to address and when you can actually get one car on the road, let alone the fleet of them. and going by the math of seven to 11 years

in production, you could have a 20 year lag where you've got huge exposures of the car fleet. And they're quicker than medical, they're quicker than oil and gas, they're quicker than nuclear. So in one of our best poised industries, it would take 20 years to fix these problems. And then I said, okay, well, as you're taking your time and being very deliberate with security, how many of you are putting in app stores? Oh, all of us. running on Android and connected to the brakes. How many of you are putting in 4G LTE Wi-Fi hotspots? Oh, all of us. Again, plugged in, connected to the entertainment system, which is connected to the brakes. You're adding all of these things very, very quickly in much less time than you can

actually put in any security framework, let alone one that's specific to those. Now we're racing ahead with the exposure. and lagging behind with the security of that exposure. And then you've got things like third party dongles, which anyone can plug in. They can go and buy it today and plug it into a car that is properly isolated from the internet that doesn't even have a Wi-Fi connection or a 4G connection, no app store, and you can turn it into a vulnerable exposed device. So as you're going slow in getting this right, which is a good thing, you're also leaving yourselves exposed and vulnerable. And they had to think about it for a while because they're Germans and they're very deliberate in their thinking and their actions. But

even more than that, I said, as we heard yesterday, 35,200 lives lost per year on American roads. 94% of those are due to human error. Somebody falls asleep, somebody turns into a lane of oncoming traffic accidentally, somebody runs a red light because they're not paying attention, 94% of those 35,200 deaths per year on American roads are caused by just human error. Which is why NHTSA, the National Highway Traffic Safety Administration, is rushing so hard and so fast towards autonomous vehicles. They saw the one fatality so far that's happened and they said, this is not going to deter us, it's not going to stop us from pushing ahead with this. because we're losing about 80 lives a day due to preventable things that autonomous

vehicles could do. So a single death across the entire time that we've had autonomous vehicles, which is not a very long time, is less, much, much less than 80 people per day. So as you're slowing down to do security deliberately, you're putting at risk 80 people's lives per day. And when you start talking to policy makers, start talking to automakers, start talking to others, These are the balances that they think in terms of. So while we all think one death is a tragedy, it's a shame and it shouldn't happen, especially a preventable death, the reality is that if we go too slowly, if we try to be too deliberate with these things, we're actually putting people at risk. And this is the same in medical as well.

So I started out my career in a hospital. I was an IT guy and then I was an InfoSec guy. And what I learned pretty quickly is that whenever I take a dollar to do something security related, I'm stealing a dollar from patient care. And that weighs pretty heavily on a lot of medical device makers' minds. I know some of the people that I've talked to who are medical device makers have that same philosophy. It also weighs pretty heavily on the hospitals' minds, people who are in hospitals think about that a lot. So as we're trying to do security, we're taking money away from the place where it actually helps people. So if we do security wrong, you know, in one way, if we do no

security, there will be harm to patients, there will be harm to drivers, to passengers. We go the other way and we do too much security, then we'll be stealing money from the people who can actually get the benefit from it. On the other side, and this is in a FDA workshop in January. We were talking about some of these problems in medical devices and in hospitals, and someone came up to the microphone and he said, you know, we've already been doing information security for a long, long time. We've got things we know work. Why couldn't we just apply PCI to medical devices? And just about everybody wanted to get up and punch him because that would be the stupidest thing we could do because it,

you know, Josh often calls PCI the No Child Left Behind Act for security. It's highly prescriptive. All the major merchants that have been breached have been compliant, so it doesn't even work the way that we think it works. Whether you believe it has some value or not, to apply it to medical devices would be catastrophic. So what happens if we put a strong 12 character password with multi-factor authentication on a defibrillator device, how long will it take a physician to access that device and use it? Probably a long time. Is it longer or shorter than the time it takes to save a life with that device? Probably shorter, maybe, in most cases. What happens if they forget their password or they forget their second factor authentication? Well,

then you just have an acceptable loss. The patient died so you could have PCI on medical devices. So while we've, optimized PCI and most of our IT security controls for a data protection or data confidentiality solution space, trying to apply these same types of things into operational technology or Internet of Things or cyber safety systems is a problem space that is human life integrity or human life availability. So even if we took the best, most perfect security standard and applied it directly on top of these new technologies, again going back to why IoT is different and why safety systems are different, we'd have a fundamental mismatch. If we got it perfect, we would still fail. So this is one of the

things that for me personally I've had a kind of a journey on in the last few years is I used to think we were bad but getting better. I used to think that we could take some of the things that we knew and apply them. Now I'm not so sure about that. I think we probably need to go back and question some of the very fundamental assumptions that we have. Do we want to have antivirus running in our cars? Does anyone? No. Do we want to have firewalls in our cars? Couple of people, so maybe that's a good thing. Do we want to have mandatory access control versus discretionary access control models? in our medical devices? Well,

I don't even know how to answer that, right? So these are the types of things that we need to be thinking about as we're going through in the safety domain.

You're absolutely right. So the point made was that regulations and things like HIPAA, things like high tech are causing the types of checklist based data confidentiality controls that will put patient safety at risk. And that's absolutely right. But in the absence of someone from our community standing up and saying, hey, we've got to rethink this. Let's move forward with something better. That's all they kind of can do. That's all they know. If you go talk to policy makers, they would probably say, PCI has been a smashing success. We should definitely apply that to medical devices. They don't know these things the way that we know them. They know them in their own terms, which is very broad, very

macro. And that's one of the risks as DC starts to look to DEF CON, a different DC, and ask, what is it that we can do? How can we be better? We have to ourselves know what we can do and how we can be better. And then we have to flip that. So we have to engage with them in a trustful way. And set aside maybe some of your political differences. Set aside the fact that a lot of us think that maybe regulation is absolutely wrong for anything. And understand that if this is coming, if we can't avoid it, then the best we can do is try and harness it and at least prevent it

from doing harm. So,

One of the things that Josh mentioned is, has anybody heard the Drake equation? Does anybody know what that is? A couple of people. So the Drake equation is a physics thing and it's essentially a mathematical model to emerge philosophical ideas. And the idea is the Drake equation should calculate, you should be able to calculate the number of intelligent species in the universe, in the entire universe, that we can communicate with. And then the observation is we can calculate that number and most of the calculations we come out to say that there should be some intelligent species that we're communicating with. And then the conclusion from that is where the hell is everybody, right? We've got all of

these billions and billions of galaxies, billions and billions of stars, billions and billions of planets. On some of those, some life form should have emerged that we could communicate with.

Right, so there are many, many different elements to the equation and one of them is longevity, right? How long does an intelligent species have to be around before they can communicate with us within our 100 year lifespan of being able to actually communicate back with them? But I looked at some of the things that we have to believe in security to say that we will never have a catastrophic failure, a cyber crisis on the scale that reaches a national security

level or some other type of level that we would agree is horrendously bad for society. He said, this sounds a lot like the Drake equation. So what if we came up with a cyber Drake equation? Maybe we can just spend a few minutes, I'll steal Josh's computer since he left it unlocked, and pull up the Drake equation if I can. Well, now we've got a black screen. Oh, there we go. So let's see if there's a browser tab I can open.

Okay, well, we failed on that. But maybe we can go through and just think if there were such a thing as a Cyber Drake equation, what might it look like? In the Drake equation, you take the number of stars across the entire universe, across all of the galaxies, and you say, of those stars, what are the percentage that have planets? What are the percentage of those that are habitable by life forms? What are the percentage of those life forms that could develop intelligence? kind of progress that way. So I would say that the Cyber Drake equation might start with what are the number of people on the planet, right? So number of people on the

planet and then we could ask what are the percentage of those people who have the knowledge to be able to pull off something like a large scale attack. So of the percentage of people who have the knowledge, how many would? What's the willingness or the motivation? And then of those with the knowledge and the motivation, how many are aware of these things? And then knowledge, motivation, awareness, what else could we say? Means, motive, opportunity. Yeah, that's a good way of looking at it.

The means would be the technical expertise, right? Technical expertise. There's the expertise and then the ability to access. Yeah, so somebody, you know, of the seven billion only, maybe five billion actually can get to the internet. So that's a good limiting factor. And Steve, I'm assuming you're writing these things down. Because you're not particularly well, sorry. Okay, yeah, no problem.

brought out a hacker, radicalized it. So they may not necessarily need the expertise or knowledge so much as the opportunity to get somebody and recruit them. Yeah, so there's resources that you could put towards getting the expertise. Right. So that would still be means.

Or you could make it really easy and say, if you've got the means to download Metasploit, you have the means. So there's the means. Motive,

I studied psychology in college, so there's a certain percentage of the global population that are sociopaths. And people disagree on what that number is, but in general it's agreed that it's between like 0.3% and 5%. So that's across the five billion people who can get to the internet, that's a non-zero number. It's actually a pretty high number of total numbers.

Then opportunity. So this is where we're talking about access to the internet. There's also awareness factor. So people who know about these systems know that they could use Showdam.

What are you trying to do? Just a presentation. Okay.

So we've talked about the actor side. What about on the other side? What about devices? So if you're going to have actors, they're going to have to act on something. So if they act on something, then there has to be a dependence there, right? Because if we're talking about

software that doesn't go into the physical stack, right? If it's just a server sitting off on the side of the road somewhere that's not doing anything, if it's not connected into an automotive system, if it's not connected into a medical system, then it doesn't matter. You can hack it all day long. All you're gonna do is maybe set up a spam bot, right? So you have to have a software system that is dependent. So of all the software systems out there, which ones have a dependence or which ones are connected to something that matters.

Then you have to have the vulnerability. But we know that all software code has vulnerabilities. It's just the degree to which those are exploitable. And we have ways to figure those out and to measure those. Then there's exposure. It's gotta be plugged into the internet basically for all five billion people to touch it. If it's not plugged into the internet, you can reduce that space so maybe it's only a thousand people, let's say. But for the moment, maybe let's just keep that plugged into the internet and connected directly. What other types of things do we need to know on the system side?

The effects of the system, yeah. So what would be the total impact?

Is it something, and I think there, it might make sense to keep it, is this something that would cause a societal level impact or does it not reach that threshold? But we can talk through that. Yes.

vulnerability, zero days, let's own them, or oh, that sounds really horrible, let's talk about the medication for a patient. But we have to really understand that there are, there's quite a bit of medical devices that have completely compromised and have very well income options. And that might be despite what you think they do or what Hollywood says . If you compromise the vibrator,

Well, there's 15 other telemetry units right next to the patient that are different devices. I mean, they're already connected to two other ones. So if the EKG failed on the defibrillator device at bedside, it wouldn't matter. But we all like to think, oh, I compromised a defibrillator, it must mean that that patient's gonna die because every time I've watched an episode of ER, that's a really important piece of medical device and they need to shock him to live. Well, you have to really understand that maybe the exploit doesn't have anything to do with the capabilities to defibrillate a patient. So we need to be able to really be honest with ourselves about what the impact

of this is and frankly, a lot of us lack understanding of patient care, physiology, and the impact of the patient to be able to make that call. I think you need to be able to talk to people who do. For instance, if you compromised the patient's laboratory device and they were unable to get labs, for a vast majority of patients that would not matter. For 97% of the patients in the hospital not being able to get labs on the patient for a day until they figured out a solution because you ransomware their laboratory machines downstairs would not matter. And they often, other hospitals will have capabilities to, if it really did matter, if there's a critically ill patient in the ICU on a vent and you needed to

know what their acid pH was, that you could get that by a handheld device that may, well that probably was not compromised in the same attack. However, it's, I would like to draw attention to that there are systems of care that are very fragile that can be, we should probably be focusing our attention to because they are device agnostic. They are, every hospital relies on these processes and the ability for all the patients in the hospital to be affected by them are very real. So if you, for instance, turned off the refrigeration for the penicillin where that's kept and the penicillin spoiled, that would affect almost all of the patients at a hospital. Well there's 15 other antibiotics. There's 15 other antibiotics in the pharmacy

that have the same coverage as penicillin. That don't require refrigeration. And that's something that is important to talk about, right? Because we think about that penicillin is a life-saving antibiotic. A patient has an infection that needs an antibiotic. If I take out the refrigerator and all those drugs are dead, then those patients are dead. That probably is not true. And that's because how are we supposed to know as hackers which antibiotics need to be refrigerated and which ones don't? And which antibiotics cover which infections? That's not what we're trained for. That's not what we say. We don't give a shit about that. Nor should we. But what I think it offers is an opportunity to talk to clinicians, talk to healthcare practitioners and say, hey, what are the low

hanging fruits here? What if what if this device failed? I know it's a defibrillator, I know it's really dramatic, I know I'm supposed to shock a patient back to life with it and it sounds like it's important. What if this machine went out? What would happen? They might say nothing. I'm gonna grab the defibrillator that is not connected to the internet three feet from it. That is an opportunity for us to talk with healthcare providers and say, well what if this other machine failed? That would be catastrophic. You would see patients all across the hospital be be impacted and you would see patients die. You can't glean that from Wikipedia article and frankly it's not

worth our study, it's worth the collaboration. Let's identify these targets that are really dangerous, the ones that matter, the ones that impact patient healthcare and that's going to require a team of us. It's going to require I am the Calvary, all the stakeholders coming together identifying these things and let's get rid of the really serious scary ones first. Yeah, I absolutely agree and so I want to dig into that point a little bit more because I think there's a good opportunity to talk about some of those things. I think for right now, let's capture that as impact in the Cyber Drake equation. You had something you wanted to ask?

Not just like a denial of service thing, but like you said, what about penicillin? Well, what if you just got into the EMR and made everybody who's allergic to penicillin not? Or if you got into the prescription drug medications and turned everything from where it thinks it's one cc, it's 1,000 cc. You can be a lot more malicious without having to just take something down. And it also kind of goes back on his point about knowing what specifically can cause an issue. With a pharmacy machine, if you know it's compromised, you have pharmacists who can manually do it, but you've got to know. Otherwise, it's just a... a scan on a bracelet, a scan on a tube, and away you go. Yeah, you're right.

So the impact has to be measured and measurable, and we have to know what that impact is. I like the comment earlier about the timeline. So over what timeline are we talking about? And if we have that as one of the factors, that might be like a year or 10 years. or the way I like to think about this one is essentially if you might have this type of thing happen within the lifespan of the vulnerable system, the dependent, vulnerable, connected system, then that's a good way to talk about it. Yes? Can you clarify quickly what you mean by timeline? Right. Right, so over what timeline would an actor need to act on a device to

cause the societal level catastrophe that would kind of trigger or precipitate something like a loss of trust in government, a loss of trust in the public health system, a loss of trust in connected vehicles and autonomous vehicles.

So one of the interesting parts of this equation is that if you can we can use it to explain and to dig into exactly those types of things, right? What is the impact? How do we know that that's the impact? How do we know that this is the ground truth? What information do we have that supports it? What happens if that's taken down? Then we can analyze those things. But one of the interesting parts of a thought experiment that I like doing with people is saying, all right, if we assume, and this is particularly powerful with policymakers, if we assume that the number of these cyber crises will be zero, That means that one element in this equation must also be zero, because that's the only way you can

get to a truly zero number, especially when you're starting with a number like seven billion people on the planet. So let's peel into which one of these might be zero. And that's when you can start to get to those things like impact. If, for instance, there's a downtime procedure for every single thing, and we have the ability to detect an attack, then okay, the number might be zero because the impact is zero. We've already thought about the backup systems and processes, and we've got that worked out. And as we saw in Ukraine, when part of the power grid went out, it went out for about six hours before they were able to go in and use manual backups to turn the power back

on, to get the lights back on, to get everybody up and working. So where a bunch of people point to the Ukrainian power grid outage that was caused by attackers and there's actually video of the cursor moving on the screen. The guy who was at the control terminal, by the way, took out his cell phone and recorded the cursor moving on his screen without him using it and clicking to shut down the things. So we know that this was an intentional act and intentional action. Pretty clear evidence there. So when something like that, that's an intentional action, only takes out power for six hours, that doesn't rise to the level of impact that we really need to be concerned about

it. So that's a great one to talk about. Did you have something you wanted to say?

and you need people working on a connected device. It is highly directed appropriation, it is a diagnostic support. On the critical, explosive vulnerabilities, but the demand is coming to the last manufacturer, fix it all, fix that. You can't. You're exceedingly willing to do that. So driving the organization. We've already identified critical infrastructure. We've already started there. But within those critical infrastructure, we need to go a step lower. That's probably the most important next step. It's not that difficult to say most of these HBOs have very similar risk points that can be utilized system by system by system. and each one of them is trying to recreate the real themselves and driving so much chaos. Right, yeah, you're absolutely right. When it comes to

prioritization of resources to get things fixed, that's a huge challenge. And I think when I've been talking to some of the medical device makers, talking to some of the car makers, one of the things that everyone kind of gets stuck on to is we talk about fixing future systems, but we've got so much legacy stuff out there. And I think people's brain get a little bit DDoSed because they think about all of the problem space and it's just impossible to function. But one of the things that I often tell them is, look, if you've got multiple problem sets, you might need multiple solutions. So maybe it's not that we only tackle legacy or only tackle future. If we have a plan

for future, we have a plan for something like things that can't be changed that are in the system but haven't yet gone to market, we can do more with them than we can the legacy devices. Legacy devices are yet a third problem space we need to tackle. So we think about prioritizing those resources, how do we do that? And one of the arguments that I make is if you can invest in future devices, it will be a lot higher return on those investments, both in your ability to control the systems and your ability to do things with them. But also, when you look at the ability of those systems to come online, there's a lot more connected devices

that are gonna come out tomorrow than were out there yesterday. So I saw a stat from the car industry that was something like 35% of cars on the road today connected to the internet, in 2020, 98% will be connected to the internet. So if we can fix the 98% or fix the 35%, even at an equivalent return to investment ratio, fixing the 98% is a better investment just looking at it from that standpoint. Not only that, if you can somehow get people to buy more of the future cars, you can get rid of some of the legacy. So no matter what you do to the legacy systems, can't make them as good as a well-engineered, safer, more secure system by retrofitting. So if we can

somehow incentivize people to ditch their old cars or medical devices and buy the new ones that are safer and more secure, then it might be a way to solve the legacy problem by just aging those devices out quicker, which could be a really interesting thing that we can talk about later on today or this afternoon. Steve. So I work at the MITRE Corporation on the team that directly supports Suzanne Schwartz and the FDA at CDRH. And one of the projects that we're doing is touching quite a bit on what Christian has discussed and what you've also talked about as well, which is trying to look at CVSS and other risk-related methodologies to try and adapt it or figure out how to utilize it within a healthcare setting to consider

things such as what is the affected functionality and the safety relevance of it, tying it to the kinds of hazard analysis that medical device manufacturers already do as a result of safety considerations. And, you know, there are definite concerns about, you know, how do hospitals wrestle with this onslaught of, or this potential onslaught of vulnerabilities or concerns where everything is necessarily treated as high risk. How do you consider the additional complexities within the hospital environment of, Okay, maybe there's not a patient safety component, but if it's a vulnerability that allows you to basically brick a million dollar device or there may be financial impacts, there's HIPAA and privacy considerations. There are considerations of the devices in terms of how they can be used to

attack other resources within the network and so on. So a lot of these kind of questions, I know this is the problem section. But it's still our problem, basically, to try and figure out how to sort of address this. But I just wanted to make people aware that minor is working to do that. I'm Steve Coley, and I will give them a second thing that sets the meet up on Thursday. So I just wanted to touch on that. Yeah, so I want to pull on Christian's point a little bit more on the form. What if we had a vulnerability that had zero impact in the real world, right? So there was a healthcare organization in New York that when Hurricane Sandy hit, their power went out and their

generators were flooded so they didn't work. So they had to go to manual procedures for all of their patients. For some of their patients, particularly infants in the mental intensive care unit, It was too much, right? They had all doctors on staff on standby, all nurses on standby. But because they had to do so many manual processes, it became infeasible to provide world-class healthcare to those patients. So they moved them. If the impact of a hack is only that you move a patient, sure, there's a big financial cost, but if there's no harm associated with it, do we need to kind of give up on the idea that any security problem, should have the same gravitas as any other.

And that might play into your prioritization point too. How do you prioritize? Can we do this one's 20% higher, this one's 20% lower? Or do we need to say this is orders of magnitude larger and just do something like t-shirt sizes? This is a triple XL priority. This is a small priority or an extra small or a petite size 7, size 20 kind of thing.

Yeah.

In order to get them to not have us convert the resources from actually the public systems or to convert the resources from the military and the public system, we actually go to Washington with a lot of this, meet the head of DA, Sheldon this. His comment was, well I'm never even seen enough to begin with. It was given by somebody else's department. And you convinced me, but you know what, VA hospitals are actually mental organizations. So you have to go to each one of them individually to convince them that you don't have to go to resources away from someone that's not local. Obviously, away from someone that picks something like that. So this is a tangible example of a scattered AI,

this online priority,

over and was it actually fixed? Right. So for the camera, basically what I think that came down to and tell me yes or no is there are often regulations or promulgations from on high that when they get to actual implementation come out completely different from intended and cause misalignments in the way that things need to work to make things safer, more secure. Yeah, so... I have a point I'd like to make. We sort of touched on this a little before, which is that the denial of service stuff seems like it doesn't have an actual life impact, like the patients can be moved or we can go and grab a different machine. What scares me with

some of the hacks, and I haven't looked at the medical space, but the hack in the refrigerator stuff is not the complete denial of service, your refrigerator is killed, okay, I'll go to the supermarket. It's the, I'll turn it off for three hours, middle of the night, everything will spoil, it turns back on and you don't know. And so maybe we should be prioritizing the more sinister stuff, the stuff that gives them control of the computer and not denial of service, that's less of a concern to me. Yeah, and that's a great point. there's a concept in security that we want no silent failures. And this is a perfect example of the five star, which I'll bring back up here.

So when we say that we want forensically sound evidence capture in cars and medical devices and these other critical systems, The reason we say that is so that we have no silent failures, so that when something happens, when there is a problem, we can go and trace that back. And right now, the number of medical devices that have something like a common framework for logging critical investigatory information, the number of cars that have a common framework or standard for logging critical investigatory things is like zero. If it's more than zero, it's ones that I don't know about. And if you know about them, feel free to raise your hand and tell me I'm wrong. But when we go and see these

types of things, when we see a death, and I know that Kwadi mentioned this the other day, when we see a death, the physician doesn't necessarily assume, oh, well I need to check and see if the medical device was tampered with. They just assume that it was something in the other treatment course that probably caused that. And so when they do their morbidity and mortality, You don't look at the medical device as one of those things because you assume as a physician and as the medical establishment that it either works or it's failed obviously. Yet that's not an assumption that we should make or can make given the standards of care that we have today.

So that's where something like a forensically sound evidence capture could be incredibly powerful in cars, medical devices, etc. We keep hearing the notion that there have been no deaths from hacking and yet we also have the inability to say whether or not that's true. So just a quick observation on your comment about denial of service. You know, in classic enterprise IT, right, it's about integrity and confidentiality, much more so than availability. And for any number of devices in the medical side that can be replaced or, you know, there may be backups available maybe denial of service isn't necessarily important. However, the risk calculus is perhaps different based on different device classes. So, for example, if it's a denial of service in a pacemaker, right, or a denial of service

in an insulin pump, then that potentially kills the patient. And so denial of service, at least in some of those contexts, becomes much more important. So the classic enterprise perspective, we may utilize a lot of the different kinds of concepts from there, but the relative prioritization may be different than what we're traditionally used to. Yeah, so to tie that back into the central theme of emerging these uncomfortable truths, what I'm hearing is that a lot of the focus we've had so far is confidentiality, and availability. We're gonna look at the CIA triad and use that as a framework. So on the confidentiality side, we have lots of things that we know in IT security that

work for confidentiality. We have lots of things that we know work for availability and uptime. We have lots of solutions for those, but where we're maybe critically lacking is this integrity focus. So if the integrity of the medicine goes away, you don't know that it's integral, then that becomes a real serious problem. If there's some type of a temporary impact to patient care that causes a patient to die and then it comes back online, that's an integrity of the process thing. And maybe in what we typically do in IT security, we don't have any real strong solutions for integrity. And maybe going back again to the elements of IoT and why it's different, maybe that's one of the critical pieces of the solution set that we need

to be thinking about solving for rather than necessarily just confidentiality and or availability. Before we go there, on this point, this should be obvious, but it doesn't seem to be obvious. I sometimes have fights with some of our rock star researchers in this area because they say, well, no one could do this. You have to be as awesome as we are to do this. Like, we're the best in the world. And I think implicit in that, and I just want to call it out because maybe I'm wrong on this. I think implicit in that is when we think about Initial compromise, stealth, persistence, quiet lateral movement. Many of these are hallmarks of an exfiltration of confidentiality and secrecy.

But if your goal is to disrupt service, the barrier to entry to cause a blue screen or to brick something or to just disrupt availability. Like I said, some of these ICS systems can't even handle a port scan. But one of the hospital guys on Thursday in Princeton that they used to scan their devices, because basically most of the IT in a hospital isn't even known to the IT team. They don't even know what they have. So in an effort to scan the devices, they found they were crashing vital services. So they had this chicken, I mean this Scylla and Charybdis kind of problem where they needed to know what they had, and finding what they had caused it to die. So I think when people say it's

too hard to inflict loss of life, they're forgetting that the barrier to entry for denial of services significantly lower than to be stealthy and highly reliable and unobservable for an APT-ish kitten killer. So again, cry BS on that, but I think we forget that. I just want to say I completely agree with everything that's been said so far. I also want to highlight that these systems are very, very complex. And if you use your traditional thoughts of how a company operates and the motives and what they provide, etc. Those can also be very complicated, but you know them. Healthcare is a pretty difficult thing to understand without being exposed to, without working in, without doing patient care. It's very hard to access from

the outside, to understand what the true implications of some of these hacks might be. For example, I agree, a denial of service on some devices might not matter at all, and some devices they might matter quite a bit. The conceptions are for things like, well, what if we did a denial of service attack on a pacemaker? What would the impact be? If we all took a poll right now, a lot of people would say they'd die. I don't know if that's true. It depends entirely on what their disease is. Maybe their pacemaker's only a sensing, and it only shocks their heart when they go into ventricular fibrillation. Or maybe it's there to pace them because

of their natrial fibrillation. And if you turned it off, who cares? There'll be a natrial fibrillation, and if they try to run around, they'll just get really tired. Or if we've attacked someone's insulin, they don't get insulin for three days. They'll go into diabetic ketoacidosis, they'll get real sick and they'll go to a hospital and I'll fix them. They might not die. Or if they get delivered a deadly insulin bolus, what if it's right next to one of their friends or family members who knows about hypoglycemia and they get treated? It's just the impact of these hacks are very difficult to predict and they're not universal. Furthermore, denial of service I think is something very, it's those big buzz terms or whatever, but let's talk about

denial of service attack attacks on networks of care. I completely agree that denial of service attacks on maybe a single device, et cetera, might not have tremendous amounts of patient harm. But we're talking about networks of care. The Affordable Care Act has forced hospitals, and this has been happening for a long time, to consolidate into networks of treatments. Raise your hand if you've heard about a hospital closing in the last five years. Well, they happen all the time. It's because the smaller hospitals can't afford to function by themselves anymore. They don't have the infrastructure, they can't meet meaningful use, they can't pay for these systems of care to deliver high quality health care, so they go out of business. Or they sell out and join large

hospital networks. What do those large hospital networks do when they acquire them? They say, you're going to run our exact EMR, you're going to run our back end, all of our enterprise solutions are going to apply. What we're talking about is now the consolidation of health care in America to networks of care, large health organizations, where if one of them gets owned, they all can get owned. And then if we're talking about it, because they're all running the exact same stuff. You can do that. And then this is the important thing. If you do a denial of service on one hospital, who cares? You can divert patients to another hospital. The hospital Presbyterian hack is

very scary, I agree. But when you say the word, like, go on divert, my hospital goes on divert all the time because we get 13 ambulances and a trauma rollover, and our trauma resources are exhausted. We go on divert all the time. I mean, it's a weekly occurrence. Sometimes it happens multiple times in a week. every hospital in a geographic zone. So think about an entire network of care going out. Then all of a sudden, diversion actually matters. Well, who are you going to divert to? The hospital down the streets, EMRs down as well, because you're running the exact same system. You're part of the same network of care. So all of a sudden, all

the hospitals in the metropolitan area have the exact same issue. None of them can deliver care. Their ability to take care of patients is outstripped with a single hack.

just a coordinated, let's talk about all the different ways we can knock it out. It's kind of a scary thing and it's only going to get worse. And I'm not picking on any one vendor per se, but when you look at this as an epidemiological issue and you look for common mode failures and shared attack surface and shared risk, there's a few systems that are near monopolies, especially as consolidation happens. Like everybody uses Epic. So were I wanting to hurt everybody, I would target flaws in that. And there's some good security people there, and they're doing some good security things. But many of these policy choices we've made to modernize medicine and get away from

paper copies and get to more sharing and get to the next stage is precision medicine, where they want to get rid of the proprietary incompatibility between these things and freely share data across large regions and practices. We are encouraging more common mode failures, more monocultures, to use a Dan Gere-type term.

magnifies and amplifies harm. Not picking on Epic, but it is one of the elephants in the room. Oh, can we please pause the reminder?

is 100 of the Fortune 100 companies have lost intellectual property despite massive security teams. Like one of the banks told the HHS task force they have 500 full-time security people on staff. And they're still breached all the time. And 100% of the PCI breaches were PCI compliant that year. So we have this lie we've all bought into, which is that compliance is a good proxy for security. How many of you have heard of my H.D. Moore's law? That's it? Darn. I've got to work harder. Everybody knows Moore's Law is compute power doubles every 18, 24 months or whatever. Let me do it this way for you. I basically said the strength of an unskilled attacker grows at the rate of the Metasploit project. And H.G. Moore

wrote Metasploit, obviously. And it's not just Metasploit. It's like Poison Ivy, Kali Linux. It's whatever's freely available to a Script Kitty. And the way I kind of drove a dagger through the heart of PCI was I finally, after two and a half years doing it the hard way, I said, your PCI compliant organization that just passed today and run today's Metasploit on it. And if you can detect everything, not even prevent, if you can detect it all, then you're safe. And not single person that passed their audit could handle even a fraction of Metasploit. So I said if you're not stronger than the least skilled adversary, you're not strong enough for anybody. But if the

standard were written like that. Yeah. You could fix it by saying you must, you know, here's the control objectives, not the controls. Here's the intent, not the brittle So the electric industry started towards down the path of how you make compliance be security instead of compliance be letter of the law because there was something called the nine substation problem where there was a report two or three years ago now that if they took out nine transmission substations in the U.S., it would be a nationwide power outage. And so this made a lot of people panic when it was first released and privately by the government. And so the FERC said, you need to make a regulation and you need to do it right now, yesterday.

And the electric industry made the regulation in, I think it was 97 days, which is... Unheard of. Unheard of. The current ones we're doing, they expect to take two to three years. But they basically said, you need to hire somebody who's a third party who's qualified. They need to do a risk assessment. If that risk assessment says you need to do something, take that, go to somebody else to review it, so you got two outside people, and then do what the risk assessment says. And then have a third party come in and see did you do what the risk assessment says. And so there's really no way to go to the letter of the law.

You kind of have to go to what can we do to make ourselves more secure.

Is your mic on? I'll turn it on. So PCI is very similar to that. If you get past the 12 things, essentially this is a risk assessment, right? Where then you have the problem of, well, are you going to pay someone who's going to fail you? And will you pay them the next year? So you're misaligning incentives there if that's the thing. And one of the things that I've observed in a lot of these spaces is Like mechanical engineers who are putting together car bodies know the physics of the universe really well. They know at what rate metal will corrode in a certain environment. And it's really easy. Physics doesn't change over the course of two years. Security does. So any attempt to quantify that specifically

and at the level where engineers are comfortable and familiar with this is doomed to fail because essentially the physics of our universe It could change tomorrow, right? It probably will change after DEFCON, right? I mean, on the road, back to the physics point, the road doesn't start to play chess against you and start moving. We have sentient adaptive adversaries. So it's more game theory and psychology than it is inertia. Now, yes, there's some predictable dynamic range of social science, but it's not the same thing. I just looked in the clock. Until our scheduled break, we have a little under 30 minutes. And we seem to have some momentum. Is there an appetite for me to at least tease a non-healthcare topic? Or would people like to

continue to talk about the health care stuff? One of the things, and this is why I'm a little hesitant myself, one of the things that Bo and I talk about is, and I did a little poll through the Cavalry account last week. We tend to believe that security through obscurity is no security at all. And when I was talking about there's zero technical barrier for somebody who wanted to shut down patient care for a whole region, there's zero technical barrier for them to do so right now for a sustained amount of time. Like that's just the cold, hard, uncomfortable ground truth. So then we're like, well, why hasn't it happened yet? And if you saw

Alan Friedman yesterday, we've had lots of arguments. Well, why hasn't it happened yet? And the means, motive, and opportunity thing is not quite comprehensive enough. The only thing they're missing is they don't know. And that's why we're really reluctant, because we want to raise attention and compel action, because the recourse and the corrective loop will take 5, 10, 15 years. But we won't even start that loop until we have a failure. So I said, what happens if obscurity is all we have? And that's why my stress level has gone up lately. So as much as we've had some amazing accomplishments, and you saw from the FDA and from FTC, and you've seen some of the impacts this particular group is having, we still got a lot of these really

hard problems, and I don't know how to fix them. And when we look at this, one thing that dawned on us is that when people can't see that this is a clear and present danger, instead of judging them, because we're all smart, I start asking myself, what do you have to believe? come to this conclusion that we're safe. And instead of just asking that rhetorically, if there's anybody in here that's skeptical, it's really useful through dialectic for us to surface. Like, have you bought in that somebody like a Janiyad could do serious harm? Is there any doubt on the exposure? You know, you look at the equation. Our attack surface is approaching infinity, right? So

attack surface is going up. The barriers to entry are going down through attack tools and metasploits and shodans and don't know yet. And I was concerned that the accidental denial service changed that equation enough. And number two, I've noticed a phenomenon. Maybe I'm wrong. This is the part I'm more wrong on, maybe. Nobody found any problems in OpenSSL forever. We had this longstanding belief that with many eyeballs, all bugs are shallow. And the published source code, if they were bugs, they would have been found by now. And when HeartLead was found, What nobody else paid attention to is there were 41 other CVEs in that same calendar year. So you get a little drop of water in the

sharp circle. Or if you want to use a gold rush analogy, somebody finds some gold in the hills and there's a gold rush. This happened on OpenSSL. This happened on Bash. This happened with Anonymous taking down sites. It happens on everything. So what I see is a long period of no one finding something. The first mover does and you see a whole bunch more bugs in that same area. And I think we have data to support that. So that's my fear. I guess let me just stitch them together because sometimes I have to talk it out loud before I even realize my own beliefs. Number one, I just don't think they know. And when I

saw Hollywood Presbyterian give them a hint, I got more scared. Number two, once one does it, you see a lot more copycats. And number three, as I started looking closer at this, most failures you can do a patch or you can shut it off or you can take it off the internet. And our ability to respond and mitigate to this particular exposure is very protracted. So it's, you know, we fail all the time, but we can do a fast detect and respond. And our detect and respond is terrible. So please criticize or add to any of those three things. But that's why I think things have changed for me to your point.

You can also go to imthecavaly.org slash the number five star, the word star, five star. I think working on the healthcare bend of this, right here, working on the healthcare bend of this, I think that when it comes to healthcare organizations, it seems to me that the motive is more variable You attack a lot of different organizations, you either want money, or you want a claim, or you want specific pieces of data. You know, you either toss some malware that they'll get to pay a bitcoin, or you want resources where you want to control their systems, or you want certain types of information that you have. You attack healthcare systems, sure, you want information. You might want information, but, or do you

want to kill someone, or there's a lot more unknown.

in healthcare systems because of the specificity of the information that it requires to operate such systems. If I turn off this one hand here, I don't always know what it's going to do. If I turn off 10 cron jobs on 10 Linux boxes, I pretty much know what that's going to do. So there's not always a lot of research and a lot of knowledge about doing and helping your systems. So I think part of that is reward. The reward for attacking healthcare systems, apart from information, or apart from a ransomware attack, is what do you get out of it. what do you get from changing someone's prescription unless you have a personal vendetta against that person. You get less reward for that type of thing. And I think that

besides those two variables, there's a few other ones as well, but those two variables, I think, aren't as targeted or aren't as poignant as attacking a lot of other types of businesses where you have a lot more knowns and a lot less variables when you're attacking. I think that that's part of the obscurity behind why healthcare networks have maybe not made as big of a splash, vulnerability wise, as some others? Yeah, there's lots of, specifically healthcare, there's lots of other reasons as well. Like when they spent, they have an incredibly oppressive burden to pass their, you know, HIPAA type compliance, which is highly focused on health records and confidentiality. So when that's a real pain in the butt and takes a lot

of time and effort away from delivery, they don't want to go above and beyond that. Or some of them don't even know to go above and beyond that. So I don't think we have time to do this whole thing, but just so you know it exists, David Etchew is one of my favorite collaborators in my life. He and I, many years back when I was still director of security intelligence at Akamai, I got kind of tired of IOCs, like indicators of compromise, because that's really a how. I think the most important part is a who maps to a why, maps to a what, maps to a how, and you chain them together. And with this

model, I was kind of routinely spotting false flag operations that were pretending to be anonymous, but were really a Russian fraud ring or something like that. And what you do is, if you start with a who, then you map out your adversary classes that your organization's likely to face, given what you do and the industry you're in. And then those map to a motivational structure, which is how they'll play a game and what motivates them. It might be being economic with their time. It might be a grievance. It might be different things. So you can't assert one set of game theory to everybody. And then within that motivational structure, they go after some subsets of

the prey. Predators have prey. So which things do they target? Which assets in your kingdom do they target? And then, only then, what's their dynamic range of capabilities, or their TTPs, or tactics, techniques, and procedures? And when you chain them together, what you start to realize is one of the reasons Anonymous was so effective is they weren't, you know that cliche of I don't have to be faster than the bear, just faster than my buddy? It's the belief, implicit, that an attacker is economic with their time. And even though they could get you, why would they bother? They'll just go to a softer target. But that doesn't work with target sticky adversaries, and that's one

of the reasons we were so gobsmacked for five years. So if a nation state wants your IP and they can't get into you, they'll go attack RSA. to you. So the target stickiness changed that cliche. And with anonymous, they weren't nation states, but they were mad at you. You poked them in the eye, right? So what I showed is, you know, they're going to fight differently. They don't go after credit cards. They went after web properties. They don't have every skill in the book. They had DDoS and whatever. And I teach this in my CMU course because a lot of people are still conditioned to think we should just look at, you know, IOCs or,

you know, forensic evidence and we'll do attribution and hack back that way. What I really like about this is I use this with executive stakeholders annually to figure out where should we prioritize our protections based on who's after us, why they're doing it, what they're after, and how they can do it. And you map your controls appropriately. I'm not turning this into a CISO workshop, but I think we should start doing this kind of thing on who are the number one, two, three adversary classes for health delivery organizations. I don't think it's going to necessarily just be criminals or nation states. I think it will also be this newer one like Geniad. And it got very little coverage, but Anonymous did take down a hospital in Boston for

a long time. They were mad at somebody. Do you remember what? Boston Children's. Boston Children's, right. Hey. Oh, we were just talking about that. You walked in the right time. You walked in the right time. Typically, your blind spots and your really big catastrophic failures are when you're missing something from your purview and your belief structure. So we're not trying to scare everybody that you should be worried about cyber terrorists. But we also know that if you blindly assume that no one would do this, that's usually where you're wrong. And what I can't do is necessarily make these devices immune to attackers. But the good news in all this is the kind of attackers that are willing to do it, aren't as tall as the nation

states and the criminals. They're not as talented. So the finish line for this is just raise the tide line high enough to be taller than their current capabilities, instead of blowing the ocean and trying to stop every attack from everywhere. And another piece of good news is if we decide we can't secure some of these environments, that the dependence is undependable, we can also retreat a bit and connect fewer things to everything else. Oh, you're motivated. on the record? Yeah. So I think this got touched on a little bit when we were going through the cyber-drake equation. But another sort of uncomfortable truth that we haven't talked about yet is even with this variety of actors

and motivations, I think at least in healthcare there's a sense of what is the likelihood of anyone actually going and launching a tech? And in a sense, it's already been sort of touched on in why haven't we seen one. But we don't have any real insight into likelihoods, especially with respect to catastrophic events. So I think that also further complicates how we analyze and prioritize what the best solutions are. So one, I'm gonna tee you up, hopefully not putting you on the spot, but We can shut off the camera if we need to. You can do a filtered version first, and then we can shut off the camera. But as we hand the mic over, some of these events that have the

potential for high catastrophe, but you can't estimate or guesstimate the probability, we still do things in other parts of the world. Like, it may be a rare event that you'll have a flood or a hurricane or a multi-day power outage. We still do disaster recovery business continuity crisis management exercises to see were this to happen, what's the play block? What should we do in response? And one of the things I'm calling for in this task force is let's run a sustained denial of service on a whole region of patient care for a prolonged period of time so we could see where we are really well prepared that we didn't realize and where we're really poorly prepared. I mean, we have power outages all the time. And to his point,

diverts happen to other hospitals all the time. How long can you sustain that before you start to get an aggregate back up? Or before you start losing people where seconds matter? Or when the ratio of humans to patient has to increase for the paper copy? So to me, I don't think we have, even the probability, to his Drake equation, if the probability isn't zero, and you have a one in a million chance when you're doing several million events a day, you're going to have it on a daily occurrence. So it's still math. And also to that, When something happens, it becomes exponentially more likely to happen again. Yeah, the gold rush in the show. Right, that's right, the gold rush. So it's oftentimes, when we look at

these things, we assume likelihood follows some actuarial type pattern that you can discern. But in actuality, it's more epidemiological. You see patient zero, and then the entire vulnerable, exploitable population is affected within a very, very short period of time.

So is your response to me basically saying likelihood is not a hard problem? I think guessing likelihood is very hard. I think if it's non-zero, some level of prudent preparedness is merited. So I don't remember where I saw this, but somewhere in FDA documentation, it says, if we have seen the occurrence once, we assume we will see it again. Therefore, we treat it as if it is a major issue. One of the things that I think is left open there is whether or not a clinical or a laboratory environment, a staged proof of concept, counts as we have now seen it once. And I'm not speaking for the FDA, but I know you were close to several

of these conversations. It felt to me like their starting point was, well, just because it's vulnerable doesn't mean it'll hurt people. To them having this aha moment of, this isn't like a defect that affects one X thousand devices. It's a defect that affects all devices. And that shifted them from proof of harm as a burden. It felt like it shifted them from proof of harm to an unmitigated pathway to harm. So to tee up the question to you for your semi-public answer to start with, we've had some questions earlier this morning of, I talked about the ransomware that took out Hollywood Presbyterian patient care. I know you've had some data and some experience investigating just

how widespread is the exposure to that ransomware. And for those who didn't hear me say this before, I think ransomware is a distraction. It's a payload. One of many is a symptom, to use a medical term, not the underlying root cause or disease. Other payloads could be the, you could still use the ransomware kit and set the ransom to immediate. You could DDoS. You could do a bunch of different things. So don't latch onto the ransomware. But the exposure that enabled that ransomware when you want to shut off the camera, but tell the group how widespread it is and how repeatable it would be for someone like a Janiyad Hussein to do. Fairly trivial, right? So the exposure, I think what you said as far as making

sure that ransomware, or making sure you don't focus on the ransomware, but focus on the fact that ransomware was just a payload, but more focus on that the vulnerability was widespread and how widespread is it essentially was the question. The last scans of the Internet gave us several million, didn't they, for that particular vulnerability? I didn't share any stats because I didn't want to get it wrong. I don't want to get it wrong either, but I'm fairly certain it's several million. I'd go check my sources before. I just came off the airplane, so I didn't know this was going to happen. Yeah, so several million, and not all of them were hospitals. Right. And it could have been anything. It didn't have to be ransomware. That's just

what the bad guys chose to deploy that day. Which vulnerability you're referring

to? The Java deserialization vulnerability? JBoss? Where do you want to go with this? Well, and we also know that the Java deserialization issue is not limited to JBoss. It isn't limited to JBoss. It's found by box gloves in Apache Commons collections and maybe some of my friends. Yeah, so the scans that I was referring to where I was talking about several million were just referring to scans for the JBoss problem. we brought in this out to all the Java deserialization, I'm not even sure we could reasonably scope it. All the things, right? One of our, before I left where I was working, one of our quick analysis of which parts of the Java open source ecosystem leveraged the deserialization technique, and I believe it was 2200

projects. Yeah. Camera.

Can we shut the camera off for a minute, please? And kill the mics.

So I guess we, this morning was really trying to focus on some uncomfortable truths. I didn't even get to raise one of the ones that scares me even more than the hospitals. But the goal was not to try to jump to solutions, but to maybe confront us with some of these things to get us in a mindset where we're more motivated to look for the really big things. And the slide I don't have time to pull up is that yesterday I showed this slide from the Martian movie where he said he's going to have to science the shit out of this. Like there's not enough food, there's not enough time, he's not going to live,

but he uses intuition, innovation, and ingenuity to stay in the fight. We have solved really big problems when we have a grand challenge. We have the Manhattan Project. We had the Space Race. We have the Moon Shot. When we prioritize something, we can catalyze massive innovation. And often that innovation, for one purpose, can be reused to stimulate private sector and whatnot. And what I'd like to do people are somewhat motivated is definitely get some good food in your belly, come back, and let's try to talk about how we might science the shit out of this. And it's not just science. It's going to be hold our own nose, eat our lima beans, and maybe talk about legislative work

or insurance work or things that are a little wonky, but get really creative. If you look back the last 15 years, the things that really took a bite out of bad stuff were things like DEP and ASLR. They were things like having home Wi-Fi routers, just one step removed from publicly addressable things. You look historically at the things that had the biggest impact. They weren't obvious at the time. So how do we take that spirit, do some really creative brainstorming and uncomfortable brainstorming and controversial ideas with no consequences during lunch and when we get back from lunch? Because we now have a platform to talk to congresspeople. We are working with some of the more clueful ones. One of our best relationships is a congress staffer with

tattoos and has a programming background and is tech literate. knows that they can bring us any topic at any time, we will find the world's best person on the subject who can also speak to Congress. And when they screw up, we just translate a little bit. It's necessary but insufficient. But until that's there, I look at this as a terraforming exercise where we don't have a breathable climate yet. But we're building a breathable climate so that we can capitalize it when we need to. So for now, I'd say thank you for coming this morning. I know it was a bit unstructured, but the This morning was only to stimulate us to have really bold ideas

when we get back. So thank you and we'll talk to you later. Thank you everyone. We're back on here at 2, right? So the stream will be back on then as well. Sorry we cut out and we will probably cut out again this afternoon time. But thank you to all of our sponsors as well. Amazon, Protivity, Verisprite. I'm probably forgetting a few but all of our sponsors are awesome. And see you guys after lunch.

We're not very good at, we're not very good at,

And one thing is, don't worry about, at this stage, maybe we'll worry about in the second half of this block, don't worry about the law of unintended consequences. It's a given. We can make things worse. In fact, if you've ever been involved in a breach, it's not the breach that kills you, it's your bad response to it that kills you. So yes, law of unintended consequences, we should measure thrice, cut once. All those things are true. Really, we're looking to surface ideas, even if they're bad, because there may be a nugget of truth in a bad idea. So let's just rapid fire whoever was next. All right. So this is a clarifying question. When you

said there are devices that have 1,400 vulnerabilities, are you referring to medical devices like a pacemaker, or are you referring to E-records? Because I think those may be two separate problems with different solutions. So for- Yeah, there's a variety of devices, each with different levels of attack surface, each with different levels of complexity in code and operating system. not a pacemaker. Okay, yeah. For eRecords, I think the low-tech solution is probably better. They hate the electronic records. The people, like their doctors, and they have office staff, and their job is not IT. So why not have something like H&R Block for Taxes, where it's like they just send copies of their files to this central office, and they deal with it, because it's people like

the new cyber task force that fixed Obamacare. Why isn't there something to fix like medical records? Who's next? A reminder, you can feel free to point out things that have worked in enterprise IT that had a big impact as well. I'm going to ask the gentleman who was speaking about fire drills. How would we go about enforcing two hospitals? This is supposed to be a dialogue. How do we go about having these people who would be self-selected? Why would I as a hospital practitioner decide to join your fire drill? What's my business incentive?

Yeah, that was the first part of the comment, which was we need some kind of forcing function to get these people to understand that this actually is a problem, right? Demos, right? Have people that know how to exploit these systems, maybe that are in the room, to go into these places and exploit the systems with an easy back door or, you know, go in there and just do a port scan and shut stuff down. It seems to me like going through all the different hospitals. One at a time, yeah. Going through every hospital one at a time in order to demonstrate that they're vulnerable one at a time when there are millions, I don't know how many hospitals there are, but millions of hospitals, right? We don't

have the infrastructure to do that. So I don't know that that's a viable solution.

Maybe so we don't get stuck on this one even though it's a great one. And we do have some ideas that we're holding back. Let me put that experience into maybe an incentive structure. So for certain publicly traded companies, they have to go through business continuity, disaster recovery, annual tabletop exercises. And they have to have a play for things like a hurricane or an outbreak or this or that, and hospitals do this as well. They already do drills for things like a sustained power outage. So yeah, it wouldn't just be that this kind of an experience could help. It might be that there's a requirement to have a cyber play in your certification or your

insurability from your underwriter. So try to connect the technical and the incentive, whether it's government incentive, insurance incentive. But I like where you're starting. But let's expand it to all sorts of levers. I'm from Canada and we had an election last year and I was coordinating the security for that. And so like six or eight months before what we did is we actually had a pretend election. Like we opened an office, we hired people, we gave them the training and then we threw lots of security incidents at them like jerks and then saw how badly we did on some things and then got way better very quickly. And so now they're going to do an entire simulation every year. but it's like a smooth machine for

the, do you know what I mean? And like, I couldn't believe how much we learned from the simulation and I don't know how to motivate a hospital to do that, but like, I don't know, you practice before you go out on stage and play music, right? Like, you should practice for bad stuff too. I mean, our kids have to do a fire drill before they can leave, you know. Right. So they know where to go when there's a fire. You have your hand up?

I really like that you're going after policy and I'm glad you're, you know, you guys are heading on the right path there. I think that's the rules of the road. That's where the game is going to be changed a lot. I think there's another opportunity that we should look for. I visit with a lot of C-suites level type people and have for years, 20 plus years, healthcare, IT and security. So what I've seen a lot is a real reluctance even though there's people might be identified as the accountable person that's either signing off on an attestation or whatever, there's an opportunity there to go after something that's a little more dear to them, and that's their money. Okay, so if their boards or they are not able

to see their bonuses or we can affect change in policy that requires them to meet certain requirements before they can get their bonus. I think that might start to have an effect on IT spend and then IT security spend and they might get a little bit more interested in the problem. So that's a stick approach, right? A fear of penalty. There could also be carrots.

So my name is Suzanne Schwartz from the FDA in case, for those of you who weren't here yesterday. I want to comment a little bit further or provide a little bit more context with regard to the suggestions that have been already kind of put on the table with respect to fire drills or exercises and that's something that FDA, Health and Human Services, government working together with hospitals, with manufacturers, with others actually already have

in terms of establishing what is needed with respect to taking a simulation and having people go through the motions of what would that response look like to a specific kind of a crisis. We do do that all the time for different types of hurricanes, for power outages, for electrical failures. And in fact, there have been a number of really good exercises, what are called beyond tabletops, but functional several day exercises that have taken place with respect to a cyber type of an attack. leveraging things like organizations such as American Hospital Association, the AHA, that brings together, that's where you're able to get that scalability of getting a whole slew of hospitals across the country to participate. Leveraging different trade organizations among

manufacturers so that manufacturers can participate in the play of those exercises also. Leveraging parts of government, and I'm not talking only about federal government, but because there is an entire infrastructure, we're talking about critical infrastructure here. There's an entire response mode that goes into the state and local level with emergency responses, with departments of health, with like really down into the weeds. There is that need to sort of kind of out what might something look like if it goes bad and how do we recover from that. I just wanted to share also really kind of an important anecdote that once was said to me by the person who's the Assistant Secretary for Preparedness Response, the ASPR. That's Rear Admiral

Lurie who has said, we exercise to failure, not to futility. failure. The whole point of an exercise is to stress the system to the point where we don't pat ourselves on the back afterwards and wow we did everything really really great and we've got it all together but rather where are the gaps? Where are the learnings that we're going to need to fill in to assure that people, patients do not get hurt and not to lose our sense of confidence, so not to futility, but to failure, and then you iterate on that and you keep on shoring that up with new situations. Yeah, I think the blueprint exists, but thus far we haven't found folks that have done a cyber exercise

that affected patient life. They may have happened, we just haven't encountered many. And if they have happened, I don't think they have reached the whole ecosystem yet.

Without saying more than I probably should, we did get a readout of Cyberstorm 5. It did involve some pretty key people in the industry ecosystem. And they did involve some health care injects. If you're familiar with how these things work, it's like a CCDC type thing. But none of the injects involved any loss of life. So to the point of stressing, we're sort of working on something that might be a great demo. stressor simulation with the right kind of stakeholders to maybe catalyze some action. So that's a great idea and there's probably other ideas as well but simulation is a good topic area. And one of the things that I've observed as we're trying to go through these is I was walking through something with

a colleague of ours and they were saying well what we need to do is to get insurers to go do this. Okay well why now we've got to go convince insurers. How do we convince insurers? Well the convinced by this and this and this and you start pulling those threads until you find the bedrock. What are they internally incentivized to go do? What's their intrinsic motivation? Once you find an intrinsic motivation, at that point it becomes a little bit of a job of awareness. How do you make them aware of that? And then you unlock them to just go do that work for you. Hello. Sorry, I have the mic. I'm from the Netherlands and in the Netherlands we are already working on it so

it might be good to watch it. We have a law now which states that if you as a company lose personal information via hack or whatever the Dutch government can fine you for 10% of your yearly revenue. So that means that you have to show that you have done enough to secure your site when you are breached and they are actually working on it now and they have the law and sure if it will work for America. Yeah, that's the problem. But you have to say, you have to state that you've done enough for what you can do. So that means penetration tests, firewall, etc. And if you have those things in place and were updated, then you cannot get the fine. Yeah,

that's just privacy. Okay, but

a start and it also affects a lot of hospitals in the Netherlands.

Yeah, that's correct. Can you repeat some of that for the people online? His point about privacy? Okay, thanks. I just noted that that's the EU privacy and it's again, it's focused on privacy and oftentimes focus on privacy diverts our attention from security denial of service. So you can fully meet the EU regulation, which you still don't have to do for two years, and be completely exposed from a security concern. Yeah, I said something I might not have should have said this bluntly. He's next. At a Detroit event, like a week and a half ago, I was kind of pointing out that some of the privacy advocates might be getting in the way of the necessary evidence capture. And I had a sticker I pulled out of

my pocket that said, I love privacy. joke we used to make, to thought provoke, was I love my privacy, I'd like to be live to enjoy it. But I took it a step further in Detroit and I said, I don't want to have a situation where we have a corpse with its privacy intact. So these are truths, competing truths, that both matter, and they both matter differently in different contexts, that have to be resolved. One cannot nominate the other. And I just said it again, so I guess I didn't regret it that much. Your turn. So I think it's every 10 years or something, the Army Corps of Engineers goes around America and looks at

critical infrastructure, bridges, highways, key systems, dams, and they give a rating. Our infrastructure's at a C plus or it's at a D. And we've had a lot of years where we've gotten really bad reports. Bridges are rated Ds, they need rebuilt. There was one, I think, was it Minnesota that basically collapsed and that bridge was known to be like, it was like a D minus rating. And we have this, you know, the government is already going out and giving these ratings to critical infrastructure as it is and we're still not doing any action with it. So I mean, one of the big problems here is even if we figure out how to identify where there are these weaknesses in infrastructure, maybe every time a hospital's closed down

and a new one's open, I know Stanford's doing this soon in California, they're opening a brand new hospital. go in there and say, okay, well this is all the existing infrastructure that's probably in most other hospitals of its age. Let's go in and run like a disaster scenario over a week. Like let's have patients of this level of life, you know, simulate it and run through what an attack would look like just to give a ranking of like, okay, well this is like a baseline of what we have in this environment. Like how would it score in readiness? All right, so someone mentioned that, let me just springboard off this a little bit. Somebody mentioned

a stick, right? Some fine for getting it wrong. One of the things Bo and I have talked about is there are certain hospitals that want to be the exemplar, the most cutting edge, the best and most connected in the world. There's one in Canada that comes to mind. I think it was like Hummer River or something like that, where it's the most connected hospital in Canada. We talked to some people in, I think in Dubai, that want to have incredibly world-class, cutting edge technology. One thing you can do is you can punish failure and point out fail. Another thing you can do is we can do a reference architecture. We can go in from the ground floor and to design a more defensible experiment that others could emulate.

Because one of the things we said yesterday is there's this classic story of the Cuyahoga River in Ohio that caught on fire many times, and nobody did anything about it until it was on the cover of Time magazine, I think. But you had a burning river of fire to show how bad the pollution was and the industrial runoff was. And sometimes it's going to take that. of argument, let's say we have to wait for our burning river on fire moment for clinical environments. What do we do the next day? Because we will have a knee-jerk response, and sometimes that response will make things much worse. So liberate yourself from the idea that maybe we can

even stop these things. But what's the recommended after action plan? All right, who's next? You're after him? OK.

I'm trying to think laterally here. I spend a lot of my time in operations. That's my primary focus, security secondary. And one thing that we spend a lot of time mulling over is how do you measure availability? What does it mean to be systems what's uptime right is it when the customer comes to make a request did you satisfy it went on well maybe that's another lens to look at this thing through like if if half of your infrastructure is down due to an exploit or a defect or a flaw then your capacity is diminished and you can measure over time you know if you've got a hundred beds and you can only effectively use

52 of them at you know for a month at a time that is a way of quantifying the posture and the particular arrangement of an actual hospital installation. It's like, find some way of measuring. Yeah, you may have 100 beds, but on a given day, odds are you might not be able to use more than 50% of them. And that'd be a way of characterizing the problem and providing a way to do an apples to apples comparison between different organizations. Say who's doing better, who's doing worse? So we have some metric to measure progress against. Yeah, I think operational metrics will be necessary. Why don't we stay on this side just for the mic movement? And then we'll go right back to you, I'm sorry.

In DevOps, for example, they measure mean time between failure and time to respond or restore services. So they have the MTTR and things like that. I think there are already some of those in clinical environments and we would only know under a sustained attack what this looks like but if we aren't measuring it we can't manage it. I think it's your point. Alright. Real fast and then. Yep. So I have three quick points. Uh oh. Sorry. First one is NHISAC, the National Health Information Sharing Analysis Consortium, launched a new utility called Cyberfit, which was announced in April, actually May timeframe, where what they're trying to do is create these utilities for anyone that's a member of the NHISAC to get you services at better, more effective pricing.

So the first two that they're working on are shared assessments, where if you're an NHISAC member and you do a third party assessment of a vendor and you share that through the shared assessments platform, Another NHISAC member can go pick up that shared assessment instead of doing their own independent assessment of that third party could use that if they, you know, meets their standards. The second is a pen testing service. So using the power of the NHISAC and the members, having agreements with third parties for pen testing services at a much more affordable rate for HDOs and such. Whereas if they went on their own, the price might be 20% higher. There's an opportunity for

a more cost effective option there. So there's more that they're planning to work on, but that was recently announced to try to help some in this space. The second one is there's a group called the Cybersecurity for Healthcare Alliance. That's a newer group that formed this year. And they've been going in kind of circles for what actually is going to come out of it. But they're trying to create of what Josh is saying here, reference architecture per se, where they're looking at all these different categories of security and trying to create a scoring system. And where it's been heading right now is to use that scoring system for your own internal assessment, kind of like

a capability maturity model assessment, where you take the scoring system, rate your organization, and then, you know, where it goes, we're not sure yet, but if that gets fed up as just anonymous data, then you can take benchmarks on the average HDO sits here. average medical device company sits here and you can rate yourself based on that. It's kind of in the grassroots right now, still early stages, but it's looking to get there. The third point was one that I heard last night that I thought was pretty interesting and the analogy I put in my head, I'm a sports guy, so I apologize for the sports analogy here, is in many of the professional sports

they do revenue sharing. So there was an issue years ago where smaller NFL or professional baseball teams or such couldn't compete with the ones that made all the money that were in the big markets. So they created a pool of money where they revenue shared so the smaller teams had the opportunity to compete by getting some of this extra money. So I'm not saying we'd say hospitals, you have to take a percentage of your money and put it in this pot and everybody can use it. But along those lines, if there's some centralized pool of money, the HDOs can use, whether it's a fund for anybody, whether it's incentives, whether it's tax breaks for something,

to try and maintain your cybersecurity level. I just thought it was a different way of thinking about it, and I thought that was kind of unique. I could see something like that feeding into insurability or risk bans once there is a need for that insurability. But there's no liability yet for some of it. Thank you for your patience. So I'm more thinking of like, I work at a healthcare network right now, so I'm a security engineer there. So one of the things that we're doing, we're kicking off right now, is a prioritization level for biomedical devices, because we have lots of them, and we have more than we probably know about, and we don't know the impact. Right. Right? So, but it occurred to us that

we work with a lot of doctors who do, so what we're doing is starting off with tabletop exercises where we go through, like, you see a patient with this, And we just run through the checklists of all the devices they hit. And then when they hit one that we know we can do something for, that we just say, okay, what do you do if this device isn't there? And some of it's, well, I grab the other one over there, and then that one's not connected. But then we're starting to hit points where, like pharmacy systems, like what if this one's malfunctioning? Well, then the nurses got to do this. I'm like, what if that's malfunctioning

for everybody? And they say, oh, well, we got to start, scaling back on the amounts that we can do, because we can only push through so many, we gotta start pulling people and staff. And so with that, we're able to start make a prioritization list of devices that we need to look at and see how we can better improve our defense in depth strategies for that. Because logging, if we could get logging just to be able to know what's going on with these devices. And because we get, some vendors are great,

Some vendors are just horrible and a lot more horrible ones than good ones right now. And it doesn't help that... You mean horrible at logging? Horrible at just support, right? So like it's been pretty well known for a while now. FDA said like, no, put your security patches on your thing. But you know, still got people running MRI machines that say, oh, we need to patch that. but we have buildings that are built around pieces of equipment. It makes it hard for me to say, what's the potential of this? So you get logging in there just to begin with. You're talking about reference framework. You could have some kind of references. You have this type of syslog server that you can ingest and then export that

to some kind of sim analytics type tool. That would be great. And to point out, I mean, they're lucky to have a team that knows what segmentation is and knows and has security experience. Yeah. And like I work for a healthcare network. We have several hospitals that work for us. But I'm a team of three. Right. So. While we're on this, one of the things that came up in the task force was when we were trying to figure out how we close this gap, what are the big levers? And they said, well, we can't afford a CISO because all the good ones go to banks. What if the government subsidized and gave you a free

CISO for three years to every HDO, a health delivery organization? I was joking. And they said, yeah, the next problem is there aren't enough. We don't have enough CISOs on the planet. So there's a strategic workforce shortage. And to Jim Ralph's credit at the NHISAC, he's also on the FSISAC, which is the financial services one. And he's been encouraging people that retire from banks to add two more years to their career to go work in a hospital to at least pull some of their experience It's a clever idea. It's about two years he asked for. Some do it longer.

There's a real strategic workforce shortage too, which is part of the reason I'm concerned. They're lucky to have you. Who's next? I didn't see.

To your first point, sir, it's just trying to maybe flush that idea out a bit more. are the people making the purchase orders for specialized equipment at hospitals, whoever those guys are, do they have access to the data of which third party vendors? So say I'm trying to purchase an MRR machine for my hospital and I'm not a tech guy, I'm just a hospital MRI purchaser guy. Do I have access to the data about which one's more secure? Do they have access to that now? And if not, what's being done to use that data in an intelligent way?

Well, so I'll preface for those who weren't here yesterday. I'm Colin Morgan. I work at Johnson & Johnson, so I'm on the manufacturer side. So my understanding, that's the goal where they're headed. They want to be able to have that information shared. So, for example, we do third-party assessments of vendors, have our tools. We do a full comprehensive evaluation of them, but then that's ours. We don't share that with anybody. And most other organizations do the same thing. We constantly hear from vendors, you know, you guys are asking us to fill out this questionnaire. We just had five other companies last week ask us the same thing with their questionnaires. there's an assessment overload from

both the vendor side plus the hospital side, the manufacturer side. We're all asking the same questions a little bit different way to the same companies and really what's the value of that? If we're all using a vendor for the same purpose, can't we find a common ground and ask the same sets of questions and get the right information? Can we trust an SSAE 16 or PCI assessment which I personally trust them, but is there some middle ground where we can trust components to that? Share that information out, and if there's something above and beyond we wanna know, then we can ask those questions.

So we're talking about having some sort of, say, organization that just says,

different, here's a list of all the different, like I as an organization, I'm dedicated to providing intelligent assessments of all the different healthcare equipment out there. So I have one section full of hackers that just focus on MRIs, they go out and they audit all the MRIs and provide the data of the MRIs to the healthcare market and maybe the healthcare providers pay a premium to get access to that data. Would that be the kind of thing that we're talking about?

No, no, not... Yeah, and we can talk more offline about it too. No, not from that perspective. This is more of the, if you're using a cloud provider for data storage or if you're using Amazon for some service. Not anything that is you're assessing a device and you're finding out what the vulnerabilities are and then sharing that with everybody. It's more around, if I'm using Salesforce, if I'm using Amazon, or if I'm using Office 365 and I fully assess them, then use the same assessment. And if we do it all through the NHISAC, then that can be shared amongst the NHISAC. The NSD...