[00:00.000 --> 00:05.960] All right, so what is the problem? I think one of the things that I really like so much [00:05.960 --> 00:10.360] about where DEF CON has grown up with the villages is that when you're looking at industrial [00:10.360 --> 00:16.220] control systems, one of the big challenges is not only the technical intimidation of [00:16.220 --> 00:21.000] where do I even start to understand how to access this code, look at these protocols [00:21.000 --> 00:26.460] and understand this equipment, but there's also a barrier to entry of this equipment [00:26.460 --> 00:32.240] is hard to find. It's very expensive. And so being able to get your hands on it and [00:32.240 --> 00:37.400] to touch it and to be able to start to play with it is a barrier to being able to start [00:37.400 --> 00:42.180] that research and have an open dialogue between the security research community and of course [00:42.180 --> 00:46.980] the vendors and the corporations that use this equipment. And the villages of course [00:46.980 --> 00:51.560] have all of these things there set up for you with experts happy to walk you through, [00:51.560 --> 00:56.060] let you touch it, ask those questions. So I encourage any of you who haven't been to [00:56.060 --> 01:00.080] the ICS village or any of the other villages, please do so because this is that kind of [01:00.080 --> 01:03.860] opportunity where the kinds of things that we're going to talk about, you get to go actually [01:03.860 --> 01:21.740] physically touch that and it's not just abstract. The second year, it was a bit more, there's [01:21.760 --> 01:27.360] a lot of us on this wire. We continue to see further digging in. The opportunity is being [01:27.360 --> 01:33.020] taken, but it needs to be encouraged. We're still way beyond the eight ball. And Atlas [01:33.020 --> 01:40.560] aside for the most part, this is not sexy. So it's not the challenges. Strike the pose [01:40.560 --> 01:48.960] again, please. That says industrial control systems. Thanks for dropping the beat, man. [01:52.520 --> 01:56.560] It's not sexy. And a lot of the challenges and a lot of the solutions and a lot of things [01:56.560 --> 02:01.580] that need to be done are not sexy. I mean, when you start looking at a lot of the conversation [02:01.580 --> 02:07.220] that's happening in the research community at large, sexy, zero day being dropped, SWIFT [02:07.220 --> 02:19.320] being compromised, sexy, man speed infrastructure. We have another mic? Don't drop it. Far enough. [02:19.660 --> 02:29.540] You don't know how far I'm going to go. All right. So sexy, the SWIFT, the various things, [02:29.540 --> 02:35.380] banking and maybe, well, destruction of dams is pretty cool, but it doesn't dive into the [02:35.380 --> 02:40.820] problem deeply enough. But a number of years ago we did have some sexy parts of the grid [02:40.820 --> 02:46.580] and it was called AMI, advanced metering infrastructure. The concepts were relatively new, they were [02:46.580 --> 02:52.940] exciting, they had ARA grant money, they had backing, they had momentum, and yet industrial [02:52.940 --> 03:00.080] control system sat on the back burner and every IOU I spoke with, IOU, industrial utility, [03:00.080 --> 03:04.520] everyone that I spoke with just kind of shut the conversation. Oh, no, that's something very [03:04.520 --> 03:10.160] different. We don't have money for that at the moment, but we're working on it. The other part [03:10.160 --> 03:14.960] of the not sexy, of course, is we're people. We do what we're incentivized to do. Part of that, [03:14.960 --> 03:18.660] of course, is we're pursuing our individual passions, but starting to take that challenge of [03:18.660 --> 03:24.500] cost and limited ability to start to do this, and in the last two years we've started to see [03:24.500 --> 03:30.340] the rise of the bug bounty concept and crowd-sourced vulnerability disclosure programs. [03:30.820 --> 03:37.420] Where are those for this kind of community? Where's that kind of incentive? You want to touch on [03:37.420 --> 03:45.140] longevity? Yeah, I thought you were hitting longevity. I was going to, but I forgot it, so I'm [03:45.140 --> 03:56.460] passing it back to you. There, I touched on it. Longevity. We have industrial control systems. [03:56.460 --> 04:04.360] Hey, big surprise. They're built to withstand many decades. Okay, it's not surprising, because [04:04.360 --> 04:12.440] these systems control that which makes our life what it is. An attack, not to be too [04:15.340 --> 04:24.560] accelerant, but a certain type of attack could potentially change the way we live. So, do we get [04:24.560 --> 04:30.520] into this? Crap, I'm forgetting what's in the next slide. So, forgive me if I say things twice. [04:31.370 --> 04:39.220] So, what we have is a problem of systems that were created, designed 20 years ago, put in [04:39.220 --> 04:46.140] place 15 years ago, but they've got a 20 to 30 year lifespan that has been amortized by [04:46.140 --> 04:53.860] utilities and people deploying, anybody who's deploying ICS. The manufacturers have been [04:53.860 --> 05:01.320] strong armed into the lowest possible price or it will go somewhere else. They didn't build in [05:01.900 --> 05:07.360] money to maintain these systems for long enough. They were never intended to be connected to [05:07.360 --> 05:14.920] the internet, but as we all know, every IP network wants to and will eventually be connected [05:14.920 --> 05:20.400] to the internet. So, the where's Waldo of industrial control systems is if you're looking at a [05:20.400 --> 05:23.820] box and you want to know whether it's an industrial control system or just a traditional [05:23.820 --> 05:28.420] computer, if it's at least 20 years old, it's an industrial control system. I mean, we're [05:28.420 --> 05:36.280] talking top of the line 30 megahertz. That's an impressive piece of equipment. And actually, [05:36.280 --> 05:41.480] funny story here, just since we've been talking about insecurity, we'd actually had props as a [05:41.480 --> 05:48.180] part of this presentation where keeping in line with OSHA, which prescribes the standards for [05:48.180 --> 05:52.220] folks that are working with dangerous things like industrial control systems and SCADA, etc., [05:52.220 --> 05:57.900] that we would have hard hats on and safety vests. They were stolen. So, that just kind of [05:57.900 --> 06:06.400] shows you that you got to have physical security at all times as well. So, God grant me serenity. [06:07.180 --> 06:14.620] What can we change? What can you change? This is an actual statistic that we made up that 93 [06:20.760 --> 06:26.580] percent of all code is shit. And that is the technical jargon for it. And we made that up, but [06:26.580 --> 06:33.560] we're not wrong. And that code is code built on top of code built on top of code. I think one [06:33.560 --> 06:37.560] of the more interesting conversations I've ever had with a manufacturer was through some [06:37.560 --> 06:42.640] level of acquisition, they had code through some little subsystem of one of their boards. [06:42.640 --> 06:47.960] And they're like, nobody knows what that code is. Nobody has any idea. Whoever wrote that is [06:47.960 --> 06:52.960] long gone through some acquisition of some time ago. We have no idea. We just kind of let it [06:52.960 --> 06:58.720] go and we sort of know how to poke it and occasionally it pokes back, but that's it. So, we [06:58.720 --> 07:03.200] have to accept that crappy code is going to make it into the systems that protect our lives [07:03.200 --> 07:10.000] and provide for the way that we like to live. Do we give up on code? Do we say, oh, it's crap? [07:10.000 --> 07:19.140] No. Just recognize there is a natural tendency towards crap, chaos. Entropy. Entropy. [07:19.140 --> 07:26.820] Well, couldn't we just keep them off the internet? Sure. I'd like to see you do that. So, [07:26.820 --> 07:35.580] people. People. Oh, people. Management and people on the ground don't know how to talk to [07:35.580 --> 07:41.600] each other. You can't do that. It's stupid. If you had any brains in your head, you would [07:41.600 --> 07:51.300] not have even suggested that. You can't do so many less things. Anyway. That was loud. You [07:51.300 --> 07:56.740] almost... Bet you don't want to hear me anymore. No, you almost threw off my pacemaker. That [07:56.740 --> 08:02.920] would be the next talk. That's another talk. We do medical devices. The challenge here is the [08:02.920 --> 08:10.680] classic nerd versus operations and management. Nerds speak nerd. They're kind of abusive [08:10.680 --> 08:15.440] actually. Unchecked. We kind of beat each other up. Why? Because we were beaten up as kids. [08:15.440 --> 08:23.740] We're nerds. Now that I have some power, man. Meanwhile, management is there ensuring the [08:23.740 --> 08:27.740] function of the operation, right? They're caring about revenue. They're caring about the [08:27.740 --> 08:32.080] business and they're trying to do that. You make that sound really sexy. As an engineer, I'm [08:32.080 --> 08:36.820] kind of offended. I don't know what the interpretive dance is for dollar sign. I do, [08:36.820 --> 08:49.660] actually. We're in Vegas. Management is focused on operations and the nerd guy runs down [08:49.660 --> 08:53.940] and is like, hey, boss, we have this huge problem that we just found out. There's this issue [08:53.940 --> 08:59.560] with code and immediately starts running down into the technical bits. Management glazes [08:59.560 --> 09:05.120] it over, waits for him to leave the room. You know what happened? I don't know what happened. [09:05.120 --> 09:11.840] Stupid or not, the management has a job and they have things that are very important to them. [09:12.040 --> 09:17.320] Maybe their paycheck. Maybe they actually care about security or at least safety and the [09:17.320 --> 09:23.120] mission of their organization or if you have a great environment, they may actually care [09:23.120 --> 09:32.500] about you. However, what's the secret to communication? Understanding the other side. I like to [09:32.500 --> 09:39.300] say that there are no crazy people on this planet. You just don't understand the system of [09:39.300 --> 09:46.100] reference or their decision making. There are no crazy people. What's important to you? What's [09:46.100 --> 09:52.640] in it for me? Oh, you had to go there. A little bit later we're going to go through a little [09:52.640 --> 09:57.600] bit more granularity about the different kinds of stakeholders in this and the pieces of the [09:57.600 --> 10:04.620] supply chain. But fundamentally you have this challenge of this, the two sides speaking Greek. [10:04.620 --> 10:09.500] Nerd speaking nerd, management speaking operations and in the middle of this gap. And this is [10:09.500 --> 10:13.740] often times where security research companies like us come in between because we're there to [10:13.740 --> 10:18.220] bridge that gap between. We have the technical understanding of working with the equipment at [10:18.220 --> 10:22.620] a very granular level and understanding the implications there. And then importantly we can [10:22.620 --> 10:28.640] tie it back to the business context and impact because that's the key. That's how you got to [10:28.640 --> 10:33.960] bridge that. When you're thinking about, it's not code, it's the impact of the code. Compromise [10:33.960 --> 10:40.220] is not compromise is not compromise. Compromise or a hack or an exploit only has value within [10:40.220 --> 10:45.740] how does that vulnerability affect the business, affect the operation. That impact helps you [10:45.740 --> 10:52.680] understand prioritization. That impact helps you understand the correct remedial solution [10:53.340 --> 10:58.320] because it's not just a question of, there are lots of different ways to fix problems. It's [10:58.320 --> 11:02.960] fixing it the right way for the context of how it's being used. And you don't want to take [11:02.960 --> 11:08.800] responsibility as an engineer for something that is going to get your boss fired. It's his [11:08.800 --> 11:14.880] responsibility. Your responsibility is to provide information, to understand and to bring [11:14.880 --> 11:21.300] along. A very dear friend of mine last night at our party said, Atlas, we've had a couple of [11:21.300 --> 11:27.420] drinks so we're all kind of reclining by the hot tub. He says, Atlas, what's important to you? [11:27.420 --> 11:36.020] How do we fix this? What are you thinking? And I didn't have this canned but the three things [11:36.020 --> 11:45.780] that came out of my mouth were education, motivation and partnership. I didn't realize that [11:45.780 --> 11:50.040] that applied so well to what we're going to talk about today. Go ahead. [11:50.940 --> 11:57.360] But wait, there's more. So as we discussed, we talked about the agent incentivization [11:57.360 --> 12:04.540] problem where is the security community really incentivized to become engaged in this. And [12:04.540 --> 12:10.000] then of course looking at where's the clear mandate coming from? Who is in fact pushing [12:10.000 --> 12:15.020] that? Because this is a top-down problem. You're not going to have the average consumer, which [12:15.680 --> 12:22.540] everyone in this room is. Last time I checked, we all use electricity and water. Everyone in [12:22.540 --> 12:27.480] here is a consumer and a stakeholder. And we as a large group are not really able to [12:27.480 --> 12:32.260] effectively advocate for something that is a very complex problem and set of problems. This is [12:32.260 --> 12:36.940] something that needs to be top-down driven. Accountability? [12:37.800 --> 12:44.040] Yeah, no, I don't. I'm not a consumer. I live in a yurt. Solar power, dude. [12:44.220 --> 12:45.820] Ryan, how's that yurt coming? [12:48.540 --> 12:56.740] So there's no clear mandate. Who is responsible for fixing these problems? The way that we [12:56.740 --> 13:03.840] live affects all of us, as he just said. But who has to fix this? Is this the vendors, the [13:03.840 --> 13:10.260] people who made PLCs, RTUs? Is it the utilities? Is it their problem? I've seen some pretty [13:10.260 --> 13:15.520] amazing engineering going on in utilities. Is it their problem? How about regulatory [13:15.520 --> 13:21.240] agencies? Show of hands. Who wants the regulatory agencies to fix this problem for you? [13:22.360 --> 13:44.860] Oh, I love this. This is great. Go, Joe. He's saying if it's regulatory, it will be check the [13:44.860 --> 13:50.080] box. It's the only way that they know how to do it. And in fact, they're incentivized with [13:50.080 --> 13:57.980] both carrot and stick to make it check the box. Very good answer. I mean, there are a couple [13:57.980 --> 14:05.860] different agencies. We'll talk about that in a minute. Go ahead. So the first thing, let's [14:05.860 --> 14:13.020] address the problems that we can right now. There are things we can do. We actually want to [14:13.020 --> 14:19.900] have a 5, 10, 15 year plan. Hopefully not 15. Please, Lord, let us fix this faster. But there [14:19.900 --> 14:25.060] are things we can do right now. Show of hands. Anyone want to give an offer? Any ideas? [14:27.080 --> 14:33.420] I can build my house on stilts so that when the dam breaks, I'm good to go. I like the idea. I [14:33.420 --> 14:40.360] already have my house built. I'm not sure that I want to jack it all up. Anyone else? Tim, I [14:40.360 --> 14:46.280] know you. No, I'm just kidding. So where do we start? Well, we begin by assessing what the [14:46.280 --> 14:54.960] problem is in our own backyard. Every one of the people on the last page, even the [14:54.960 --> 15:01.160] regulators, we want to become aware of the problems that we can fix right now. For example, [15:01.160 --> 15:07.580] if we are still using Modbus, probably a good idea to get that off the wire. I don't care if [15:07.580 --> 15:14.440] you're doing serial. Okay, there are worse things to use. But if you're using Modbus right [15:14.440 --> 15:21.200] now over Ethernet, please stop. There are other options. And I'm sure that there are business [15:21.200 --> 15:26.440] decisions that made Modbus the right thing and it takes money and time and effort. But it's [15:26.440 --> 15:35.640] something that we can fix. If the protocols that you use offer security, lab it up, make sure we [15:35.640 --> 15:43.480] don't roll out some big change and take down the grid or the water supply or back up the poop. [15:44.440 --> 15:53.040] I mean, we're talking about more than just the electric grid, right? But lab it up, test it, [15:53.040 --> 15:58.840] migrate to something that at least offers security, even if it's not perfect. DMP3 has tons [15:58.840 --> 16:05.000] of bugs. But at least it, as he stepped on the chair, I was thinking he was going to call out [16:05.000 --> 16:11.520] the fact that you may be still kind of surrounded by shit, but if you can get a little higher, [16:11.520 --> 16:19.540] you can be in it less. Pick something better. If you have systems that are, have replacement [16:19.540 --> 16:25.520] upgrades and you can put into place a better system, maybe a system that actually has a [16:25.520 --> 16:32.880] vendor that's still around or a vendor that you trust to partner with you, this is a good [16:32.880 --> 16:40.480] first step. There are many things that you or we, whoever is doing this assessment, can sit down [16:40.480 --> 16:47.300] and identify, within the next year, we can do this. Let's talk to the right people, work it [16:47.300 --> 16:56.560] out, get something as part of a bigger process. To emphasize, this is the all is not lost slide. [16:57.000 --> 17:02.540] You can start somewhere and have that vision of where things can get better, circle the wagons [17:02.540 --> 17:12.980] where you can establish control and then iterate from there. Best practices. I mean, [17:13.530 --> 17:20.620] so, a few other things that we can throw into the mix that you can do within the next year to [17:20.620 --> 17:28.120] two. Authentication is a problem we all deal with. There are many technologies available [17:28.120 --> 17:33.020] because everybody is struggling with it. Two-factor authentication for the right systems [17:33.020 --> 17:40.220] is a good first start. If you have to use passwords and not tokens or keys or fobs, please. [17:42.140 --> 17:49.600] The next step, guys, I know that we didn't mean to plug the grid into the internet, but we've [17:49.600 --> 17:57.380] done it. We didn't design our systems and our networks to withstand the type of onslaught that [17:57.520 --> 18:05.300] a nation state is willing to offer. In fact, the state of many organizations, many people here [18:05.300 --> 18:14.940] without state funding could do it. So, I'd like to lay out the idea of a multi-tiered castle. At [18:14.940 --> 18:21.180] the very center, with the most restrictive protections in place, you have crown jewels, you [18:21.180 --> 18:27.740] have head ends, you have things that actually change significant parts of life. Outside of [18:27.740 --> 18:34.080] that, you have slightly less trusted, less protected systems, but still very highly [18:34.080 --> 18:43.060] protected. And so on and so forth. I recommend three to five layers at least. And these layers [18:43.060 --> 18:50.160] play into a potential for protection. So if you have a system that there's absolutely no way [18:50.160 --> 18:57.980] that you can have assurance that it is protected, then it falls in the outer ring. For example, [18:57.980 --> 19:06.100] pole top devices. Anyone here that's been at DEF CON, you're not, you cannot possibly argue with [19:06.100 --> 19:15.440] me that a system being on top of a pole is not secure. Unless it's in a compound with guns. [19:17.260 --> 19:24.800] Patching policy. This is just regular SEC 101. The systems that are being used to pivot into [19:24.800 --> 19:31.220] attack your critical infrastructure, generally people's workstations, check an email, surf [19:31.220 --> 19:36.780] on the web, these systems have to be maintained and protected. Now this is not going to keep [19:36.780 --> 19:42.320] off everybody. I'm going to try not to throw out nation's names because I know everybody's [19:42.320 --> 19:51.180] represented here. But patching, keep at least the end days done. And then there are [19:51.180 --> 19:59.060] configurations in our PLCs and RTUs that again can be used to turn on security features. [19:59.060 --> 20:05.120] Encryption and strong authentication and other things to lock down access that you [20:05.120 --> 20:10.240] shouldn't have available on your PLC. Now there are many who will say encryption takes time [20:10.240 --> 20:17.860] and I need point blah blah blah milliseconds response time. If your critical systems can't [20:17.860 --> 20:25.460] handle that type of waylay and processing power, those might fit on your list to replace. [20:28.390 --> 20:34.950] Monitor all the things, all the comms. So this is while end points might not be the place [20:34.950 --> 20:40.530] that you can do that monitoring, certainly there can be transmission paths and one of the [20:40.530 --> 20:45.830] challenges with this of course is not all of the communications are going to be wired. You have [20:45.830 --> 20:49.970] to keep in fact that a lot of things are going to have RF communications and you need to [20:49.970 --> 20:53.410] start thinking of the physical security and the physical presence of those things. Please [20:53.410 --> 20:57.570] don't allow your cell phones to connect to your network and talk to your head end. There's [20:57.570 --> 21:02.730] one good rule of thumb. But if you do have cell phones connected to a network, it better be [21:02.730 --> 21:09.890] on something you can monitor really well. Hunting, who here has heard of hunting? Okay, [21:09.890 --> 21:16.510] about one percent of you. Hunting is the act of scouring your network. No penetration [21:16.510 --> 21:21.750] testing has to go into this if you're worried about breaking things. Simply monitoring [21:21.750 --> 21:29.650] traffic patterns. Traffic can be cataloged, identified and put into a database and [21:29.650 --> 21:37.470] analyzed. For example, there's no reason why workstation in the office needs to talk [21:37.470 --> 21:45.330] directly to head end. If you have this type of communication or other strange communication, [21:45.330 --> 21:53.150] A, that's something you want to understand better. B, it may be the thing that tells who's [21:53.150 --> 22:06.510] on your network. Fuck Modbus. We've beaten Modbus. Modbus is unauthenticated. And perfectly [22:06.510 --> 22:14.150] sane to kick the shit out of here. There are others like it, but this is Modbus. Please [22:14.150 --> 22:21.290] choose something that has some sort of protectiveness. If you have critical systems [22:21.290 --> 22:28.030] that must use an insecure protocol, maybe because you're worried about latency, you should [22:28.030 --> 22:40.500] have armed guards around everywhere that that network touches. This is the self-promotion [22:40.500 --> 22:44.460] slide, so I'm just throwing that out there because this is some of the stuff that we do. But [22:45.020 --> 22:52.340] it's more, even if you don't do it with us, please understand, we have yet to get to the [22:52.340 --> 23:00.700] point where I need to throw binary exploitation against most control systems the way we do [23:00.700 --> 23:04.940] your laptop, the way we do your servers, the way we do against firewalls and routers. We [23:04.940 --> 23:14.640] don't have to do that. It's not hard enough to warrant that kind of work. But there will come [23:14.780 --> 23:21.320] a time, hopefully very rapidly, where that's not the case. As we fix the fixable, digging [23:21.320 --> 23:30.120] into hardware, software and firmware, that was sexy, identifying weaknesses in code, weaknesses [23:30.120 --> 23:37.220] in design of hardware, weaknesses in what your vendors are shipping out, like hard-coded [23:37.220 --> 23:47.160] passwords, these still exist. Assessments of all three things will provide you, when we finally [23:47.160 --> 23:53.300] get our poop in a group, something that is defendable. And if we don't start now, it will [23:53.300 --> 24:00.820] just be that much longer before we get to something that's defendable. But I've got limited [24:00.820 --> 24:07.540] budget. Well then prioritize. If you have systems that are most widely deployed, those should [24:07.540 --> 24:14.880] make pretty high on the list. If you have significant systems that control large, [24:14.880 --> 24:23.940] potentially irreplaceable parts of your systems, that may make a very good top place. You can [24:23.940 --> 24:29.660] get to the older stuff later. You guys know how to think about boundaries, right? We do the [24:29.660 --> 24:36.180] most important first, we then back up. We don't stop until we're done. But we get the best [24:36.180 --> 24:43.060] that we can for now. So while we list three device categories here, of loose categories, [24:43.060 --> 24:48.240] there are also three kinds of assessments. White box, gray box, and black box. And I list those [24:48.240 --> 24:53.680] because those also require careful consideration for what you're trying to accomplish. A black [24:53.680 --> 24:59.080] box assessment is saying, hey, you're just like somebody else out there anywhere and you are [24:59.080 --> 25:04.180] required to do all of the open systems intelligence and gathering to try to figure out what kind [25:04.180 --> 25:09.020] of information can you gain. And then from there start to work that to then be able to [25:09.020 --> 25:13.120] determine how you're going to conduct your research for exploitation. Gray box is going to [25:13.120 --> 25:16.700] be a mix of you have access to all of the documentation, so there's kind of that in [25:16.700 --> 25:21.240] between. And some of the factors there are going to be trying to understand how much is [25:21.240 --> 25:26.780] obfuscation your friend, and obscurity is your friend, versus how much of it do you really [25:26.780 --> 25:30.800] want to just get straight to the technical research and understanding, which is what white [25:30.800 --> 25:36.960] box is going to do. And there's also one other thing to point out. This is not check box [25:36.960 --> 25:43.240] things. Check boxes get you the first layer of an assessment like this, because you can [25:43.240 --> 25:48.980] actually put into place a list of things that you want to check to gain knowledge about the [25:48.980 --> 25:56.740] next steps. Once you're past that, you need people who are creatively evil, and you need them [25:56.740 --> 26:06.460] to have the time to sit in their creativity and think, oh, hey, Tim, do you think that we could [26:06.460 --> 26:20.140] do blah, blah, blah, blah, blah? Yeah? Let's go do it. Oh, this is my slide. Sorry. So as we [26:20.140 --> 26:26.480] said before, we need devices that we can deploy that have security baked in from vendors [26:26.480 --> 26:34.800] who think about security. We also need, we need to reassess what we're doing for comms, [26:34.800 --> 26:40.280] because there are radios that have encryption enabled. Almost by default. Oh, but it's [26:40.280 --> 26:48.020] really easy to enable them. You simply have to choose one of 256 standard encryption keys. [26:49.180 --> 26:58.900] That doesn't sound like a lot. Hey, it's AES fucking 128. With one of 256 different keys. And [26:58.900 --> 27:03.400] please, understand, one of the things that, actually one of my favorite parts of my career [27:03.400 --> 27:07.100] has been breaking into banks, breaking into government buildings, and doing things with [27:07.100 --> 27:12.780] cyber that aren't typical pen testing things. You may think of them as red teaming. If so, [27:12.780 --> 27:18.920] that's great. But some of our assessments have really gone, oh, well, I can hop the fence. [27:18.920 --> 27:22.960] Okay, here's the device, you're going to get there. You don't have to hop the fence, I know [27:22.960 --> 27:28.380] that you can do it. And we've gotten our hands on a lot of attacks after. In fact, the reason [27:28.380 --> 27:34.760] that I call out MDS is because they're deplorable in many of their at least older stuff [27:34.760 --> 27:43.260] that's still widely deployed. For being able to use one radio that you purchase off eBay to [27:43.260 --> 27:51.460] attack all the others, and even brute force within 18 hours, guaranteed to be on any network. [27:54.330 --> 27:58.170] So, the people. We've talked about the people, we've talked about the people through multiple [27:58.170 --> 28:03.250] things. Where are these folks, right? So, first of all, I think that this is, again, what I [28:03.250 --> 28:07.650] love about DEF CON is this is the meeting of those passionate folks who really do care about [28:07.650 --> 28:12.290] this problem for various reasons. Either you're motivated by how we can all help humanity [28:12.290 --> 28:17.950] together, or you have a particular interest of the matrix metaphor of going down the rabbit [28:17.950 --> 28:26.630] hole and seeing how far it can go technically. Your vendors should be having security-minded [28:26.630 --> 28:33.270] people in their hiring process. They should be actively pursuing not just bullshit bingo [28:33.270 --> 28:40.110] security, but true security. And utilities. They need to be able to call bullshit. They need to [28:40.110 --> 28:48.630] be able to have the knowledge and skill to say, that's crap. Fix that. Or better yet, get out [28:48.630 --> 28:55.750] of here, these other vendors, they have people who know what they're doing. So, go ahead, I'll [28:55.750 --> 29:01.850] let you take the top. How to fix for the who's who. We have two regulatory agencies, FERC and [29:01.850 --> 29:06.050] NERC, and there is a challenge there where there is a mix between the overlap of [29:06.050 --> 29:10.870] responsibilities and a difference between suggestion and compliance. And while we talked [29:10.870 --> 29:14.870] about compliance being a challenge from a checklist perspective, we also talked about the [29:14.870 --> 29:20.470] fact that this is a top-down mandate that needs to push and encourage this action. And that is [29:20.470 --> 29:24.430] the purpose of government and legislation. And that's where these organizations need to come [29:24.430 --> 29:28.870] into more of a common agreement with the vendors in the industry to help push that. Now, they [29:28.870 --> 29:34.150] need to be light-handed right now. We've already got some very heavy-handed things in place [29:34.150 --> 29:39.690] that do not, that actually can detract from true security. They have to be careful how they [29:39.690 --> 29:44.650] engage, but FERC and NERC do play a very important role. Our public services commission, our [29:44.650 --> 29:49.330] public utility commissions, these are the state-run organizations that kind of keep our [29:49.330 --> 29:54.810] utilities in check. They are the protectors of the consumers. Now, I have seen some [29:54.810 --> 30:03.710] significant investment from several PSCs into researching cyber security. They want to [30:03.710 --> 30:08.330] understand. They want to know how they can fix the problem. And they have a big role. They [30:08.330 --> 30:14.830] control how much a utility can make for a year. They also allow a utility to do a rate hike, [30:14.830 --> 30:20.850] which allows them to charge more per kilowatt hour or per gallon of water or whatever. In [30:20.850 --> 30:26.910] the interest of maintaining a grid, a water system, a water treatment system that services [30:26.910 --> 30:33.670] our needs. But our vendors, they're saying, where the hell is the money coming from? The [30:33.670 --> 30:37.590] utilities don't want security. They're not willing to pay for it. I can't make it unless [30:37.590 --> 30:43.390] they're willing to pay for it. So utilities, phony up. Utilities are saying we don't have [30:43.390 --> 30:48.190] any vendors that provide things that we can put into place that are defensible. They have [30:48.190 --> 30:55.930] crap. And this is what I have to deal with. Encourage. Educate. Make the decision. And in [30:55.930 --> 31:05.510] fact, you have a lot of sway. The unfortunate side is we have decades of utilities beating up [31:05.510 --> 31:12.610] vendors for the lowest price. We have lost the partnership that is provided for our [31:12.610 --> 31:19.350] country and our world. We got to get it back. And so that concludes the amount of time we [31:19.350 --> 31:24.730] have for this. This was a lot to condense into a short talk. So I'm Bryson. I'm Atlas. And [31:24.730 --> 31:27.630] we're Grimm. Thank you.