1 00:00:00,000 --> 00:00:12,160 This is the AmpicCyber Critical Assets Podcast. Each episode we cover important OT and ICS 2 00:00:12,160 --> 00:00:16,540 security topics with an eye towards standards and regulation to keep you ahead of your adversaries 3 00:00:16,540 --> 00:00:19,000 and your auditors. 4 00:00:19,000 --> 00:00:27,640 Hey everyone, welcome back to the Critical Assets Podcast. I am Patrick Miller and with 5 00:00:27,640 --> 00:00:33,040 me today I have Leslie Carhartt, also known as Hacks for Pancakes and I am just thrilled 6 00:00:33,040 --> 00:00:37,720 to have you on. I've got so many questions, I'm so interested in what you're doing. And 7 00:00:37,720 --> 00:00:41,080 let's just start by telling us a little bit about yourself for the audience that doesn't 8 00:00:41,080 --> 00:00:42,440 already know who you are. 9 00:00:42,440 --> 00:00:46,760 Hi everybody, my name is Leslie Carhartt and thank you for having me, Patrick. It's nice 10 00:00:46,760 --> 00:00:52,680 to be here. I am an OT cybersecurity professional. I've been doing that for quite a long time. 11 00:00:52,680 --> 00:00:57,640 Specifically, I work for a company called Dragos and at Dragos we specialize in industrial 12 00:00:57,640 --> 00:01:02,760 and critical infrastructure cybersecurity and I work specifically there in incident response 13 00:01:02,760 --> 00:01:09,600 and digital forensics for systems like power plants and mines and transportation that have 14 00:01:09,600 --> 00:01:12,880 been compromised by various types of adversary groups. 15 00:01:12,880 --> 00:01:16,920 Awesome. So keeping the people safe from the big machines. 16 00:01:16,920 --> 00:01:20,840 I'm certainly trying to do that. That's important to me. 17 00:01:20,840 --> 00:01:26,280 Fantastic. Well, on that same thread, these systems are definitely different than IT, 18 00:01:26,280 --> 00:01:31,760 right? They're very different. What are some of the unique challenges for incident response 19 00:01:31,760 --> 00:01:37,360 and forensics in OT generally? Like, can you do the same things that you would do in IT 20 00:01:37,360 --> 00:01:40,080 in the OT world and if not, why? 21 00:01:40,080 --> 00:01:45,320 Incident response is stunningly different in OT. Yes, we use some of the same forensic 22 00:01:45,320 --> 00:01:49,920 tools to do investigations of malware and compromises and computers and things like 23 00:01:49,920 --> 00:01:54,160 that, but there's some things that just make it a completely different way of life. The 24 00:01:54,160 --> 00:01:59,040 first one, of course, is process consequences. Everything. When you're talking about physical 25 00:01:59,040 --> 00:02:02,840 kinetic systems like industrial control systems, you're talking about things that can kill 26 00:02:02,840 --> 00:02:08,600 people. They can cause critical services to fail if they aren't there, like water, power, 27 00:02:08,600 --> 00:02:14,440 things like that. They can also harm operators. They can cause environmental damage, facility 28 00:02:14,440 --> 00:02:17,740 damage. They do physical stuff in the real world. 29 00:02:17,740 --> 00:02:22,760 So everything that we do in cybersecurity in OT, we have to do with these process consequences 30 00:02:22,760 --> 00:02:27,200 in mind. And so when you're talking about a system that's been compromised, there's 31 00:02:27,200 --> 00:02:31,960 a whole bunch of extra considerations that go into the response and recovery efforts 32 00:02:31,960 --> 00:02:38,280 like how long can the system be down without people dying? How long can we operate on manual 33 00:02:38,280 --> 00:02:44,440 operations without any of the computers before things start failing? And then there's a side 34 00:02:44,440 --> 00:02:49,400 of the investigation too. What tools can I safely run in these computers that aren't 35 00:02:49,400 --> 00:02:54,520 going to cause a worse consequence? You're not going to find EDR or XDR on a bunch of 36 00:02:54,520 --> 00:03:00,000 industrial hosts. You just can't do that on a lot of vendor and older hosts. Even on newer 37 00:03:00,000 --> 00:03:06,400 hosts, they have to operate in a very structured, vendor approved way to operate safely. So 38 00:03:06,400 --> 00:03:11,760 limited security tooling and oftentimes very old systems with very, very legacy security 39 00:03:11,760 --> 00:03:16,400 tooling and the forensics tools we have to use in those hosts are very old as well. If 40 00:03:16,400 --> 00:03:23,240 we're talking about Windows XP or older Windows 95, I see on a routine basis, Windows NT. 41 00:03:23,240 --> 00:03:28,240 So old school forensics, sometimes very manual forensics, and then very judicious risk decisions 42 00:03:28,240 --> 00:03:33,240 about what we can and can't do and how much time we actually have to do those forensics 43 00:03:33,240 --> 00:03:34,240 efforts. 44 00:03:34,240 --> 00:03:37,320 What do you mean by time? So talk to me about that. 45 00:03:37,320 --> 00:03:42,440 Sure. So everything in a process, when you're talking about business continuity and process 46 00:03:42,440 --> 00:03:47,000 operations, everything comes down to time. Time of how fast the process functions, how 47 00:03:47,000 --> 00:03:53,160 many widgets you produce, how much power you put out per minute, per hour, per day, et 48 00:03:53,160 --> 00:03:58,080 cetera. And that ties into your bottom line of whether you can stay in business or not. 49 00:03:58,080 --> 00:04:03,960 And then time in terms of how long you can safely run without your computers. The computers 50 00:04:03,960 --> 00:04:09,520 that I'm talking about, the industrial control digital systems I'm talking about are things 51 00:04:09,520 --> 00:04:15,540 that provide telemetry. So making sure systems are operating safely and effectively and efficiently. 52 00:04:15,540 --> 00:04:20,360 They provide process efficiency. And a lot of human beings have been removed from the 53 00:04:20,360 --> 00:04:25,680 mix and a lot of process environments and their roles of keeping things running smoothly 54 00:04:25,680 --> 00:04:31,000 have been replaced by computers. So switching back to manual operations is a big deal. And 55 00:04:31,000 --> 00:04:37,140 then even more beyond that, some things like modern micro grids and smart grids are so 56 00:04:37,140 --> 00:04:43,000 complicated and mathematically complex that they have to be run long-term by computers. 57 00:04:43,000 --> 00:04:48,600 So there's the timeframe there of how long can we have these systems down, pulling images 58 00:04:48,600 --> 00:04:53,080 from them, investigating who's compromised them, figuring out what they did, how long 59 00:04:53,080 --> 00:04:57,440 before we just have to start swapping things out with an adversary still in the system 60 00:04:57,440 --> 00:05:03,480 to keep people alive. Everything comes down to these time and risk decisions in our investigations. 61 00:05:03,480 --> 00:05:08,000 Okay. And in some cases, I assume there are even situations where you just can't take 62 00:05:08,000 --> 00:05:11,480 them down, right? You're going to have to do this in a live operating environment. 63 00:05:11,480 --> 00:05:16,360 Yeah. I mean, there's a lot of it depends in what I tell customers when they call me 64 00:05:16,360 --> 00:05:21,560 in on what's usually their worst day ever. And that comes down to what do you need? Do 65 00:05:21,560 --> 00:05:27,560 you need to be up and running in two hours or somebody dies or you go out of business? 66 00:05:27,560 --> 00:05:34,560 Can we spend 24 hours doing an investigation? Things like that. Those are tough conversations. 67 00:05:34,560 --> 00:05:39,160 And in talking about these immature environments where there's less logging and very old systems 68 00:05:39,160 --> 00:05:44,560 that have less forensic detail, all those things play into how much I can actually say 69 00:05:44,560 --> 00:05:50,800 about what the adversary did. Oftentimes these incidents and these more legacy and less defended 70 00:05:50,800 --> 00:05:55,240 environments are detected very, very late. I'm talking about months or years after the 71 00:05:55,240 --> 00:06:01,920 initial intrusion. So I do my best. I have to use a lot of manual, very advanced old 72 00:06:01,920 --> 00:06:07,720 school forensics to pull things out of the ether to try to tell people what the root 73 00:06:07,720 --> 00:06:12,840 cause was in the initial point of intrusion. And sometimes I can't. Sometimes it was too 74 00:06:12,840 --> 00:06:17,280 long ago. Sometimes we just have to get things up and running. And I collect the forensic 75 00:06:17,280 --> 00:06:23,240 evidence I can to do a very manual investigation on after the system's been restored. And 76 00:06:23,240 --> 00:06:27,360 that's a very hard decision to make because you start restoring things on a system that 77 00:06:27,360 --> 00:06:32,240 say a state adversary or criminal adversary group is still in. They're going to respond 78 00:06:32,240 --> 00:06:36,880 to that. They see restoring the systems. If they still have access when the internet connectivity 79 00:06:36,880 --> 00:06:41,760 is restored, they're just going to destroy things again. So very complicated decisions 80 00:06:41,760 --> 00:06:47,240 to make with the leadership in those organizations, with the safety personnel, with the external 81 00:06:47,240 --> 00:06:52,960 experts on that industrial system, and with my colleagues and peers in forensics and intelligence. 82 00:06:52,960 --> 00:06:57,720 Okay. This sounds incredibly challenging. So these organizations, I know that they vary 83 00:06:57,720 --> 00:07:03,040 in terms of maturity and skill sets and technologies, but generally speaking, if you had to pick 84 00:07:03,040 --> 00:07:07,800 like, you know, top three, top five, what are the things that you think they could do 85 00:07:07,800 --> 00:07:12,800 better to enable you to do your job easier? Like when you walk in, what are the things 86 00:07:12,800 --> 00:07:17,720 you wish or you hope they have ready for you or the capabilities that they have for you 87 00:07:17,720 --> 00:07:20,640 to use to actually make your life easier to help them? 88 00:07:20,640 --> 00:07:26,560 Start with the basics. There's a white paper out through SANS called the five critical 89 00:07:26,560 --> 00:07:30,600 controls for industrial cybersecurity. And they name things like basic architectural 90 00:07:30,600 --> 00:07:36,320 controls, vulnerability management, remote access control, having some fundamental incident 91 00:07:36,320 --> 00:07:42,120 response plan and some fundamental security monitoring and logging. And those are things 92 00:07:42,120 --> 00:07:46,920 that you build onto over time. You start with the very basic elements of those five capacities 93 00:07:46,920 --> 00:07:51,800 and start with something. Give me something to work with. Give me anything. Give me some 94 00:07:51,800 --> 00:07:57,520 logging. Give me some architectural diagram, some asset inventory, some idea of how your 95 00:07:57,520 --> 00:08:03,860 environment is connected to remote access. Anything helps. If I don't have those foundational 96 00:08:03,860 --> 00:08:08,400 details at the beginning of one of these very critical response efforts, I have to go find 97 00:08:08,400 --> 00:08:13,320 that stuff. And that's time in these. I was talking about how important time is when you're 98 00:08:13,320 --> 00:08:20,200 talking about restoring a perhaps crippled industrial environment. Time is crucial and 99 00:08:20,200 --> 00:08:25,520 you don't want me at incident response rates having to build you a network map. And so 100 00:08:25,520 --> 00:08:30,760 think about those very foundational things like understanding your environment, building 101 00:08:30,760 --> 00:08:35,720 some segmentation in it, doing some logging, some monitoring, having some plan of what 102 00:08:35,720 --> 00:08:41,440 you'll do if you do see something nefarious. Anything is better than nothing there. 103 00:08:41,440 --> 00:08:48,160 Excellent. Okay. That's fantastic advice. Totally agree. Well, in general, I mean, the 104 00:08:48,160 --> 00:08:52,480 critical infrastructure organizations, OT organizations, and I'm going to generalize 105 00:08:52,480 --> 00:08:58,800 this just globally because I know I both work on a global scale. Which sectors do you think 106 00:08:58,800 --> 00:09:03,280 are leading or lagging in general? Kind of curious to get your take. 107 00:09:03,280 --> 00:09:10,440 Yeah. So it usually has to directly equate to the funding of the organizations. So it's 108 00:09:10,440 --> 00:09:13,760 not necessarily related to the size of the organizations either. It's how much money 109 00:09:13,760 --> 00:09:21,320 they spend on IT and cybersecurity. So the ones that have the most money for cybersecurity, 110 00:09:21,320 --> 00:09:26,040 the best resources are usually like the large oil and gas firms and some of the very large 111 00:09:26,040 --> 00:09:32,020 electric utilities. There's some legislative pressure there to do cybersecurity and they 112 00:09:32,020 --> 00:09:37,880 also have money and they're willing to invest that money, that margin on cybersecurity, 113 00:09:37,880 --> 00:09:44,960 on preventative controls. So they generally in the range of things are doing better. And 114 00:09:44,960 --> 00:09:49,480 then you have like municipal utilities that are also doing very important things like 115 00:09:49,480 --> 00:09:54,100 making sure we have safe drinking water and our toilets flush and garbage goes away and 116 00:09:54,100 --> 00:10:00,960 transportation works, our traffic lights work. And a lot of those are very underfunded organizations 117 00:10:00,960 --> 00:10:06,200 in general. They're small municipal organizations. They maybe have one or two IT people and things 118 00:10:06,200 --> 00:10:11,400 are much, much more challenging there. Things are prioritized in terms of keeping the water 119 00:10:11,400 --> 00:10:18,000 running instead of spending money on margins of things for cybersecurity. So that's one 120 00:10:18,000 --> 00:10:22,400 of the scariest spaces for people who are professionally in this field. If you're talking 121 00:10:22,400 --> 00:10:28,040 about like manufacturing, even like big manufacturing firms oftentimes have big problems with industrial 122 00:10:28,040 --> 00:10:31,880 cybersecurity because of the low margins, even though they can make a lot of profit 123 00:10:31,880 --> 00:10:37,000 and be very large companies, they don't tend to invest as much in IT because that's not 124 00:10:37,000 --> 00:10:43,280 green dollars coming in. That's an expense. That's a cost center. So we see problems there 125 00:10:43,280 --> 00:10:48,240 as well. This is generalization. So I mean, we see variation in organization size and 126 00:10:48,240 --> 00:10:54,320 global locations in those various industries. And the thing I do want to express is that 127 00:10:54,320 --> 00:10:57,480 spending a bunch of money and having a bunch of people in your cybersecurity program is 128 00:10:57,480 --> 00:11:04,600 good, but it's not necessarily a complete defense against intrusions. I respond to incidents 129 00:11:04,600 --> 00:11:10,120 in those organizations too. They have their own challenges. But in general, the industries 130 00:11:10,120 --> 00:11:14,720 that concern most of us, and I don't know if you agree with this, municipal utilities, 131 00:11:14,720 --> 00:11:21,300 things like water, sewage, any power that's handled by a small co-op, things like that. 132 00:11:21,300 --> 00:11:26,200 Those are scary spaces that do really important stuff and don't have many resources for cybersecurity. 133 00:11:26,200 --> 00:11:31,320 Yeah, I would generally agree. And I would also say the same where I've seen very large 134 00:11:31,320 --> 00:11:35,680 organizations that have spent lots of money on a wide range of tools and they've got even 135 00:11:35,680 --> 00:11:40,720 multiple divisions within a security department. And they still suffer from, in some cases, 136 00:11:40,720 --> 00:11:44,600 fundamental issues where I've seen some smaller organizations, even in some of these co-ops, 137 00:11:44,600 --> 00:11:49,600 for example, that they've got just a superstar one or two people that can do an amazing job 138 00:11:49,600 --> 00:11:54,840 with limited tool sets. So people that are there and the investment from senior leadership 139 00:11:54,840 --> 00:12:00,040 in how much they care about cybersecurity and stand behind those people. And in general, 140 00:12:00,040 --> 00:12:03,720 sometimes you can be more agile as a small organization. So don't feel defeated if you 141 00:12:03,720 --> 00:12:07,920 are that small organization. You have potential to do really interesting things too. 142 00:12:07,920 --> 00:12:13,160 Yeah, absolutely. Now in these sectors, like I agree, I've seen a lot in the electric sector, 143 00:12:13,160 --> 00:12:19,960 oil and gas space as well. They do have generally deeper pockets. I would see them definitely 144 00:12:19,960 --> 00:12:23,840 leading, especially in front of local water utilities, even in some cases like rail and 145 00:12:23,840 --> 00:12:33,000 manufacturing and shipping, mining. Yeah. Now, just globally, I wanted to bring a little 146 00:12:33,000 --> 00:12:38,440 bit of a global aspect. Which areas do you see are more advanced or further along, shall 147 00:12:38,440 --> 00:12:43,440 I say? I hate using the word mature or advanced, but I guess further along on their security 148 00:12:43,440 --> 00:12:45,440 journey than other areas. 149 00:12:45,440 --> 00:12:50,520 Well, I mentioned like oil and gas tends to be very, very well-resourced. They have a 150 00:12:50,520 --> 00:12:55,560 lot to protect and they've invested a lot in their IT programs and in their cybersecurity 151 00:12:55,560 --> 00:13:01,520 programs and they're willing to have larger margins in these things that aren't direct 152 00:13:01,520 --> 00:13:08,720 income. So yeah, so that's usually one where cybersecurity is quite strong. Again, there's 153 00:13:08,720 --> 00:13:12,600 still problems there when you have that large of an organization and oil and gas tends to 154 00:13:12,600 --> 00:13:16,320 be very distributed operations with a lot of different facilities, remote facilities 155 00:13:16,320 --> 00:13:20,760 that make cybersecurity very challenging. When you're talking about like platforms out 156 00:13:20,760 --> 00:13:26,080 in the ocean, that's a tough one. That's a really hard thing to secure, but they tend 157 00:13:26,080 --> 00:13:31,560 to do quite a bit better. When we're talking about like electric utilities, that depends 158 00:13:31,560 --> 00:13:36,680 on how they're regulated and organized in different parts of the world, whether they're 159 00:13:36,680 --> 00:13:40,760 centralized, whether they're a bunch of different companies, whether they're small co-ops, if 160 00:13:40,760 --> 00:13:46,240 there's a lot of like independent generations, smart grids, et cetera, that changes things. 161 00:13:46,240 --> 00:13:53,360 But in general, beyond those verticals, it tends to be the organizations that have good 162 00:13:53,360 --> 00:13:58,520 management buy-in and a willingness to have that cost center of cybersecurity that put 163 00:13:58,520 --> 00:14:03,600 organizations ahead of other organizations. Okay. Yeah. And I'm even thinking in terms 164 00:14:03,600 --> 00:14:08,560 of a global perspective, like in some cases it's been regulatory driven and in other places 165 00:14:08,560 --> 00:14:16,440 it's been market driven. So I've seen situations where, oh, let's say higher threat locations 166 00:14:16,440 --> 00:14:20,920 obviously go for a higher security profile, right? And then there's other areas where 167 00:14:20,920 --> 00:14:27,000 just the regulation in that region or that country have caused the whatever sector to 168 00:14:27,000 --> 00:14:31,760 do more. In the U.S. of course we have NERC SIP for the electric sector. We have the TSA 169 00:14:31,760 --> 00:14:36,560 pipeline security directives for our gas space. There's been talk about the water sector. 170 00:14:36,560 --> 00:14:40,880 In Europe they have more of a general approach overall with the NIS2. And then of course 171 00:14:40,880 --> 00:14:46,320 each individual member state has their own quasi, that's a quasi that I almost direct 172 00:14:46,320 --> 00:14:51,360 in some cases specific to state things like German DSI or UK has a framework like the 173 00:14:51,360 --> 00:14:57,720 CAF, Australia has their own CSF. Any of those that you see are really kind of, I guess becoming 174 00:14:57,720 --> 00:15:02,840 more of the standard to which others should look to, I guess is the best way to ask the 175 00:15:02,840 --> 00:15:08,160 question. I think that there's a lot of good things coming out of Europe and the U.S. and 176 00:15:08,160 --> 00:15:15,600 Australia. I'm always a very cautious person on critical infrastructure cybersecurity regulation. 177 00:15:15,600 --> 00:15:20,720 And I'll tell you why. It's because oftentimes I see two problems. The first one is that 178 00:15:20,720 --> 00:15:26,920 it's very strategic and it doesn't actually provide tactical details. So strategic in 179 00:15:26,920 --> 00:15:31,880 terms of who owns what, who's in charge of what and very, very high level directives 180 00:15:31,880 --> 00:15:36,000 that can be interpreted in a lot of different ways. And I understand why they do that because 181 00:15:36,000 --> 00:15:41,800 there's so much variety and variation and debate about how to do a lot of these things. 182 00:15:41,800 --> 00:15:46,000 But I do wonder about the efficacy in some of those cases where it's just very, very 183 00:15:46,000 --> 00:15:52,240 high level and strategic. But the bigger concern to me is when things are regulated without 184 00:15:52,240 --> 00:15:57,360 providing resources to do them. Again, thinking back to like the small municipal utilities, 185 00:15:57,360 --> 00:16:02,280 those water utilities, they got one IT person, maybe half an IT person, maybe they're an 186 00:16:02,280 --> 00:16:07,360 operator the other half of their time. And you're going to tell them to do a bunch of 187 00:16:07,360 --> 00:16:13,880 installing EDR patching or installing elaborate network controls. That's going to take away 188 00:16:13,880 --> 00:16:17,640 from something else. Have you thought about what that's going to take away from? Is that 189 00:16:17,640 --> 00:16:22,520 going to stop them from doing monitoring? Is it going to stop them from responding to 190 00:16:22,520 --> 00:16:27,160 trouble tickets from the operators who see stuff happening? What is that going to take 191 00:16:27,160 --> 00:16:33,520 away from if you don't give them tools and actual functional resources to do that cybersecurity? 192 00:16:33,520 --> 00:16:39,800 So anytime I see regulation like that come into play, I also want to see at least good 193 00:16:39,800 --> 00:16:45,940 educational resources being provided to those utilities. More preferential would be giving 194 00:16:45,940 --> 00:16:52,720 them monetary resources, incident response resources, tooling, licenses for tooling to 195 00:16:52,720 --> 00:16:58,880 do things that you're legislating. This stuff is expensive. It's hard to do. OT cybersecurity 196 00:16:58,880 --> 00:17:05,500 is hard and it costs money. And again, if you're regulating stuff, that money and those 197 00:17:05,500 --> 00:17:10,720 people are coming from somewhere. So be very cautious about that. But in general, I mean, 198 00:17:10,720 --> 00:17:14,800 to answer your question, there's a lot of good ideas in that legislation. They are reaching 199 00:17:14,800 --> 00:17:20,520 out to industry. They're reaching out to specialists in the field in most of those countries. And 200 00:17:20,520 --> 00:17:24,720 they're thinking about, again, those kinds of critical control things like, gosh, we 201 00:17:24,720 --> 00:17:29,160 really need to control remote access. We really need to make sure that we understand vulnerabilities 202 00:17:29,160 --> 00:17:35,960 in these environments. We really need to segment. Yeah, that's all really important stuff. But 203 00:17:35,960 --> 00:17:41,480 again, doing that is not easy. You think it's hard in enterprise. It's really hard in a 204 00:17:41,480 --> 00:17:46,520 legacy industrial environment that you can't shut down. So a lot of considerations to go 205 00:17:46,520 --> 00:17:50,440 into that. And I wish there was a little bit more tactical recommendations and resources 206 00:17:50,440 --> 00:17:57,400 coming out from those countries too. Yeah. I have the joy of having written regulation 207 00:17:57,400 --> 00:18:02,080 and then they forced it. So I've seen what it looks like on the other side too. It's 208 00:18:02,080 --> 00:18:07,600 really difficult to write regulation in a tactical way because technology moves so fast 209 00:18:07,600 --> 00:18:11,600 and threat actors change their tactics so quickly. So you're basically forced to write 210 00:18:11,600 --> 00:18:17,480 it strategically. It's a difficult balance. But one thing I am seeing on a regular basis, 211 00:18:17,480 --> 00:18:22,160 I would say commonly through much of the regulation that leans into the critical infrastructure 212 00:18:22,160 --> 00:18:30,280 spaces in an OT and our world is definitely a push for good incident response. One of 213 00:18:30,280 --> 00:18:36,480 the things I've debated with Danielle Czaponski on a previous podcast was if you had to write 214 00:18:36,480 --> 00:18:41,080 one regulation, if you just had the capability to write one, what would it be? And we both 215 00:18:41,080 --> 00:18:45,640 kind of circled around the concepts of just incident response or just threat hunting. 216 00:18:45,640 --> 00:18:50,880 I see how they kind of go both hand in hand, but I have seen this as such a common thread 217 00:18:50,880 --> 00:18:55,360 through a lot of these different regulations across multiple countries and regions. And 218 00:18:55,360 --> 00:18:59,920 when I ask those that are writing it or influencing it, it seems to come down to the fact that 219 00:18:59,920 --> 00:19:06,440 there, of course, many companies will not report an incident on the street, right? To 220 00:19:06,440 --> 00:19:11,800 any federal agency or to the news or to anywhere, basically other than even to their shareholders 221 00:19:11,800 --> 00:19:17,000 in some cases. It just, if it only goes up and out to the places, it absolutely must. 222 00:19:17,000 --> 00:19:26,640 So given that we've got a really bad and patchwork and misleading set of actuarial data. So we 223 00:19:26,640 --> 00:19:33,840 know that if Leslie eats bacon cheeseburgers every day and never exercises, watches TV 224 00:19:33,840 --> 00:19:37,240 and is extremely sedentary, there's a chance that you're going to die by 40. But we know 225 00:19:37,240 --> 00:19:42,600 this because of the actuarial data we have on humans and healthcare for like, you know, 226 00:19:42,600 --> 00:19:48,360 arguably a thousand years or more. We have, you know, in some cases, not only, you know, 227 00:19:48,360 --> 00:19:52,080 none, but misleading data in this space. And this is what they're trying to do is what's 228 00:19:52,080 --> 00:19:57,800 working and what's not. What's actually being effective and what isn't. So these regulations, 229 00:19:57,800 --> 00:20:02,000 when I ask about them, this is what they're trying to get to is how do we get this information? 230 00:20:02,000 --> 00:20:09,800 So barring, you know, asking and getting inconsistent, well, as a euphemism, inconsistent answers, 231 00:20:09,800 --> 00:20:13,240 regulation and forcing it out of them is pretty much the only way. So that's where we're seeing 232 00:20:13,240 --> 00:20:20,300 a lot of this incident response regulation or standardization in some cases around it. 233 00:20:20,300 --> 00:20:24,800 So do you think this is even a good idea given what you do? This is your world and you do 234 00:20:24,800 --> 00:20:29,420 this every day. So is this something they can do? Is this a good idea? Is this useful 235 00:20:29,420 --> 00:20:30,920 for the regulatory bodies? 236 00:20:30,920 --> 00:20:35,800 I'll start with for the audience. I do this every day. I am an incident responder for 237 00:20:35,800 --> 00:20:40,920 industrial systems. I am busy enough and I have been for the last seven years at Dragos 238 00:20:40,920 --> 00:20:45,160 that this is what I do every day. There is a lot more going on in the industrial incident 239 00:20:45,160 --> 00:20:49,600 space than people see on the news. And all the things that you described are true. Nobody 240 00:20:49,600 --> 00:20:53,160 wants to have a big eye incident. They don't want to report it to their board. They don't 241 00:20:53,160 --> 00:20:57,600 want to have to report it to regulators. They don't want to get dinged for whatever they 242 00:20:57,600 --> 00:21:03,520 think they were responsible for in the intrusion, even if they weren't. And so that really is 243 00:21:03,520 --> 00:21:09,080 a thing. There is a resistance to reporting incidents when there's no regulatory requirement. 244 00:21:09,080 --> 00:21:14,080 We do track those incidents. We have our own numbers, not with customers named, obviously, 245 00:21:14,080 --> 00:21:19,280 but just general to what types of incidents are happening and how many per year. And yeah, 246 00:21:19,280 --> 00:21:24,000 I mean, that's important information. That's important information to track adversary activity, 247 00:21:24,000 --> 00:21:27,720 to understand what threat groups are doing, what criminal groups are doing, and how people 248 00:21:27,720 --> 00:21:32,320 are adapting their techniques to attack, especially lower level industrial systems, which is happening 249 00:21:32,320 --> 00:21:38,320 too. Now, the other side of that, though, is a lot of stuff is not being detected in 250 00:21:38,320 --> 00:21:42,800 time. And there's a few different reasons for that in industrial environments. First 251 00:21:42,800 --> 00:21:48,920 of all, the security maturity is so low. There is a lack of detection tooling. There is a 252 00:21:48,920 --> 00:21:57,560 lack of host tools, network tools, antivirus, EDR, smart firewalls, things that we are very 253 00:21:57,560 --> 00:22:03,200 dependent on in our security operations centers are only trained on these days don't exist 254 00:22:03,200 --> 00:22:09,120 in a lot of levels of the industrial environments. So picking up things is hard. Oftentimes it 255 00:22:09,120 --> 00:22:15,360 takes somebody at a system seeing something weird happening or something actually breaking 256 00:22:15,360 --> 00:22:20,280 or something visible, like a ransomware pop-up, something like that, to detect things. And 257 00:22:20,280 --> 00:22:26,760 that can happen quite late. And there's a built-in temptation because of the poor relationship 258 00:22:26,760 --> 00:22:30,680 oftentimes between cybersecurity and these OT environments that do their own thing for 259 00:22:30,680 --> 00:22:36,240 a multitude of reasons to just swap out boxes when something weird happens, troubleshoot 260 00:22:36,240 --> 00:22:41,560 it like it's a equipment failure and not a cybersecurity issue. So we don't know how 261 00:22:41,560 --> 00:22:47,600 many things are just being swept under the rug because systems aren't monitored or when 262 00:22:47,600 --> 00:22:52,120 they have problems when they're infected past the point of no return or an adversary destroys 263 00:22:52,120 --> 00:22:57,200 them. They just get swapped out by the vendor or the people on site because that's what 264 00:22:57,200 --> 00:23:04,760 they do. And you can talk about incident reporting, but if nobody ever detects anything, things 265 00:23:04,760 --> 00:23:11,080 aren't going to get reported anyway. And if they are massively de-incentivized to detect 266 00:23:11,080 --> 00:23:16,600 anything, they aren't going to ever detect anything because they're not going to install 267 00:23:16,600 --> 00:23:22,440 any more detection controls. So you mentioned having a debate previously about detection 268 00:23:22,440 --> 00:23:28,160 versus having incident response as the primary capability. And they're both important. They 269 00:23:28,160 --> 00:23:33,320 go hand in hand. I don't have a horse in that race. You have to have something to do if 270 00:23:33,320 --> 00:23:38,840 you detect something. It can be very minimal. And to be able to do something, do incident 271 00:23:38,840 --> 00:23:42,560 response and report anything, you have to have some kind of detection. They're both 272 00:23:42,560 --> 00:23:46,280 essential. They're both critical controls in the five critical controls for industrial 273 00:23:46,280 --> 00:23:51,720 cybersecurity. You have to start a little bit on both of those and slowly build both 274 00:23:51,720 --> 00:23:57,080 of them up over time. But yeah, if you just build an incident response plan, there's a 275 00:23:57,080 --> 00:24:01,520 lot of organizations out there with some kind of OT incident response plan. Maybe it's never 276 00:24:01,520 --> 00:24:07,920 been tested that have zero detection and they're never going to detect anything because when 277 00:24:07,920 --> 00:24:12,480 somebody perhaps gets horribly injured in a critical incident that was perhaps caused 278 00:24:12,480 --> 00:24:16,560 by somebody tampering with their environment, they're just going to treat it as an equipment 279 00:24:16,560 --> 00:24:20,640 failure. The vendor is going to swap out all the equipment and nobody's ever going to know 280 00:24:20,640 --> 00:24:27,320 that it was a cyber attack. So culture is really important there. Building a strong, 281 00:24:27,320 --> 00:24:34,920 healthy culture between OT operators, vendors, OEMs and cybersecurity firms, agencies, et 282 00:24:34,920 --> 00:24:40,200 cetera, is really important. And then making sure as we're building that legislation, we're 283 00:24:40,200 --> 00:24:47,440 putting a focus on both of those things, both having some capability to actually do investigations, 284 00:24:47,440 --> 00:24:52,000 make cybersecurity part of root cause analysis, do detection in those environments, even in 285 00:24:52,000 --> 00:24:58,800 a very rudimentary way, and have some plan to do incident response so you know there's 286 00:24:58,800 --> 00:25:05,040 an incident going on and you can report it. All that stuff, it's cyclical, it's dependent 287 00:25:05,040 --> 00:25:09,480 on one another. You can't pull one of those elements out, unfortunately, but the trick 288 00:25:09,480 --> 00:25:12,520 is just starting with the very basics in each of those things. 289 00:25:12,520 --> 00:25:18,560 Excellent. Yep, you summed it up right there. That was fantastic. So if they're going to 290 00:25:18,560 --> 00:25:26,220 mandate incident response reporting, and this in some cases, even when I talk to the regulators 291 00:25:26,220 --> 00:25:31,960 who are writing this stuff, they assume that there is the capability for detection. They 292 00:25:31,960 --> 00:25:36,360 assume that there is the capability for all the things that feed into the incident response 293 00:25:36,360 --> 00:25:41,000 capacity because you can't respond effectively if you don't have this other information. 294 00:25:41,000 --> 00:25:47,360 So they try to, I would say, imply that you need these other capacities in order to do 295 00:25:47,360 --> 00:25:51,440 incident response. So they do this in a lot of ways by saying you must have these minimum 296 00:25:51,440 --> 00:25:58,600 components that you report, and that kind of passively or indirectly says that you must 297 00:25:58,600 --> 00:26:02,040 have the capability to detect these things in order to provide this information in your 298 00:26:02,040 --> 00:26:06,880 incident response report. So they kind of get to it through that roundabout waivers 299 00:26:06,880 --> 00:26:11,920 as directly mandating that you have detection capabilities, for example. If they were going 300 00:26:11,920 --> 00:26:17,080 to do that, what do you think would be the most useful minimum set of things that they 301 00:26:17,080 --> 00:26:20,120 need to know? 302 00:26:20,120 --> 00:26:25,880 You have to understand your environment, which is more challenging than people expect. I 303 00:26:25,880 --> 00:26:29,440 know that, again, these cybersecurity people coming from the enterprise side of things 304 00:26:29,440 --> 00:26:34,360 are like, yeah, sure, I just go into my asset inventory software and it tells me based on 305 00:26:34,360 --> 00:26:40,400 agents what computers I have. It's really easy. That's not the case in OT. Like, what 306 00:26:40,400 --> 00:26:45,480 computers do you have? What do they do? Who owns them? Where do their logs go? A lot of 307 00:26:45,480 --> 00:26:50,960 that stuff has to be figured out on paper in OT environments, and it's really, really 308 00:26:50,960 --> 00:26:58,840 tough. So I highly recommend starting there, having a foundational knowledge of your environment, 309 00:26:58,840 --> 00:27:08,200 your logging, remote access. That's another really tough one. How are things connected? 310 00:27:08,200 --> 00:27:14,580 Those are all tough things to understand. And then what things mean in your OT environment. 311 00:27:14,580 --> 00:27:18,760 That's the hardest bit. A lot of organizations get to the point of actually being able to 312 00:27:18,760 --> 00:27:22,080 do security monitoring and they have some knowledge of the environment. They stick their 313 00:27:22,080 --> 00:27:27,540 sock on it. They get their security personnel to start looking at logs from that environment, 314 00:27:27,540 --> 00:27:32,120 and they have no idea what anything means. Because they don't have a good relationship, 315 00:27:32,120 --> 00:27:36,560 again, with the OT personnel, and they don't have anybody to ask, and weird stuff comes 316 00:27:36,560 --> 00:27:42,540 out of those devices. It's a totally different set of protocols, and the domain is different. 317 00:27:42,540 --> 00:27:47,440 The devices are different. There's older systems, and you don't know what any of it means. You 318 00:27:47,440 --> 00:27:53,160 can establish something of baseline, but something's change doesn't tell you a lot. So I recommend 319 00:27:53,160 --> 00:27:57,360 job shadowing programs. I think that's a really, really important thing. If you're going to 320 00:27:57,360 --> 00:28:03,400 build a healthy cybersecurity program for OT, I highly recommend that you implement 321 00:28:03,400 --> 00:28:09,080 some kind of job shadowing for your cybersecurity personnel to spend time in the OT environment, 322 00:28:09,080 --> 00:28:12,960 and how people work there, and how the system works, and just build a good relationship 323 00:28:12,960 --> 00:28:19,120 to ask those types of questions. What does this mean? What's going on here? Is this bad? 324 00:28:19,120 --> 00:28:22,960 That kind of stuff is going to help you a lot at those beginning stages. 325 00:28:22,960 --> 00:28:30,840 Okay. That's super useful. Yeah. When I look at, for example, NERC-ZIP or Circea, and even 326 00:28:30,840 --> 00:28:35,760 the NIST 2, it doesn't have a lot of specifics that you have to report. But I look at what 327 00:28:35,760 --> 00:28:42,200 they're asking for, and I'm just wondering, is that enough for them to really... It sounds 328 00:28:42,200 --> 00:28:46,340 like they're just really grasping... Oh, like incident details? Like what happened 329 00:28:46,340 --> 00:28:54,560 in the case? Yeah. Yeah. I mean, anything is helpful there. It depends on the level 330 00:28:54,560 --> 00:29:01,000 of investigation. Yeah. What vertical was it? How many systems... I mean, how many systems 331 00:29:01,000 --> 00:29:04,640 is going to depend a lot on how flat your network is in a lot of cases? 332 00:29:04,640 --> 00:29:07,280 And how much you know about how many of them were actually hit? 333 00:29:07,280 --> 00:29:11,760 And what security controls you have in place? Whether you have some security controls that 334 00:29:11,760 --> 00:29:19,760 prevented lateral movement. But more relevantly, there is fundamental threat intelligence data 335 00:29:19,760 --> 00:29:24,720 there. Do you know which adversary group it was potentially by any name, by any organization's 336 00:29:24,720 --> 00:29:31,600 identifier? What were their tactics across MITRE ATT&CK? That's useful. What parts of 337 00:29:31,600 --> 00:29:37,920 the kill chain did you forensically analyze and identify? So we can track that in somebody 338 00:29:37,920 --> 00:29:44,880 else's environment. IOCs are important. All of that information can be useful to peers 339 00:29:44,880 --> 00:29:49,740 and to tracking these adversary groups at a national level. If you're talking about regulation, 340 00:29:49,740 --> 00:29:54,560 you're talking about what's useful for intelligence agencies to understand what other countries 341 00:29:54,560 --> 00:29:58,920 are doing to our critical infrastructure or to other friendly nations' critical infrastructure. 342 00:29:58,920 --> 00:30:05,160 So all of that tactical detail is useful. But I wouldn't make all of it obligatory because 343 00:30:05,160 --> 00:30:09,320 people don't always have the maturity to get all that information. You might see one little 344 00:30:09,320 --> 00:30:15,520 piece of MITRE ATT&CK. You might see one little piece of the cyber kill chain. You might just 345 00:30:15,520 --> 00:30:20,840 know that a system was tampered with and have no other details. And that's still important 346 00:30:20,840 --> 00:30:21,840 to know. 347 00:30:21,840 --> 00:30:28,160 Yeah, I've been advising that less is more. Just notification of incident in some cases 348 00:30:28,160 --> 00:30:33,400 would even be enough that they're having a problem. Because while I would love to have 349 00:30:33,400 --> 00:30:36,600 that rich data set you just described, some of them I've never even heard of the MITRE 350 00:30:36,600 --> 00:30:37,600 ATT&CK. 351 00:30:37,600 --> 00:30:41,400 Yeah, you can't really legislate that. You can't require it. They don't have the capability 352 00:30:41,400 --> 00:30:48,040 to provide it. You could provide suggestions. Again, when I'm talking about more tactical 353 00:30:48,040 --> 00:30:52,280 details in some of this documentation, I'm talking about cross-references to supplemental 354 00:30:52,280 --> 00:30:57,920 documentation, not necessarily obligating people to do it as part of the regulation. 355 00:30:57,920 --> 00:31:03,360 But again, those resources, the supplemental resources to help people do stuff, when things 356 00:31:03,360 --> 00:31:08,680 are very high level and vague, they can feel very overwhelming for a less mature organization. 357 00:31:08,680 --> 00:31:12,720 So if you're going to say you have to have an incident response plan, then gosh darn 358 00:31:12,720 --> 00:31:17,840 it, maybe we should start having government sanction templates out there for various types 359 00:31:17,840 --> 00:31:23,160 of playbooks and incident response plans in OT. Because the enterprise ones don't work. 360 00:31:23,160 --> 00:31:25,720 So yeah. 361 00:31:25,720 --> 00:31:29,040 That would be tremendously useful. Maybe one of our agencies like CISN or even MITRE can 362 00:31:29,040 --> 00:31:31,160 produce something like that for us. 363 00:31:31,160 --> 00:31:32,160 Maybe. 364 00:31:32,160 --> 00:31:36,640 Yeah. We can certainly ask. We know some people. Okay. And then the next piece on these is 365 00:31:36,640 --> 00:31:43,320 not just what is reported, but the timeframe. So what, I mean, you've done so many of these. 366 00:31:43,320 --> 00:31:49,760 What do you think is realistic for any, again, generally speaking, and I know I understand 367 00:31:49,760 --> 00:31:55,480 it widely varies, but generally speaking, is 72 hours enough time? I mean, because NERC 368 00:31:55,480 --> 00:31:58,840 sets as an hour after you notice an impact to your operation. 369 00:31:58,840 --> 00:32:00,400 After you notice some things going on. 370 00:32:00,400 --> 00:32:01,400 Yeah. 371 00:32:01,400 --> 00:32:05,680 The sad reality is, okay, so let's say an adversary uses a system as a testbed. Maybe 372 00:32:05,680 --> 00:32:09,200 they pick a little co-op and they want to test one of their future attacks against a 373 00:32:09,200 --> 00:32:13,480 big city. So they pick somewhere they think is less defended and this happens, this is 374 00:32:13,480 --> 00:32:20,600 the real thing. And they test their attack on them. So there is a impact. It's successful. 375 00:32:20,600 --> 00:32:25,880 It does something bad. It has a process impact. What are the things that happen early on in 376 00:32:25,880 --> 00:32:30,240 the first day of that? Well, first of all, the operator and the engineers try to figure 377 00:32:30,240 --> 00:32:34,040 out, troubleshoot what's going on. They try to fix it themselves. And then when they can't 378 00:32:34,040 --> 00:32:39,760 do that, they call in their OEM. And maybe then the vendor has to get called in by the 379 00:32:39,760 --> 00:32:45,920 OEM because the OEM can't figure out what's going on. And then we've got the iffy situation 380 00:32:45,920 --> 00:32:49,480 where maybe they just swap out the box because they can't figure out what's going on, or 381 00:32:49,480 --> 00:32:53,600 maybe they call their cybersecurity team because they think it's so weird and they want them 382 00:32:53,600 --> 00:32:58,360 to be part of root cause analysis. So how long has that taken? I mean, that could have 383 00:32:58,360 --> 00:33:04,200 taken days of troubleshooting, of getting the vendor to go out to the site. They have 384 00:33:04,200 --> 00:33:09,720 to get it, dispatch somebody, they have to get in their car. Then they decide that it's, 385 00:33:09,720 --> 00:33:13,880 you know, first they called out an engineer and the engineer couldn't fix it and then 386 00:33:13,880 --> 00:33:18,840 they called out the OEM. The OEM couldn't fix it. Then they called out the vendor. So 387 00:33:18,840 --> 00:33:24,640 I mean, I don't want to let people take more time than is necessary, but understand that 388 00:33:24,640 --> 00:33:30,640 there is time involved in troubleshooting OT stuff. Now if it's ransomware, if it's 389 00:33:30,640 --> 00:33:35,840 like, you know, you see some mouse moving on the screen, that's quite visible, although 390 00:33:35,840 --> 00:33:39,760 there is going to be troubleshooting involved in that too. Somebody's going to, an engineer 391 00:33:39,760 --> 00:33:43,400 is going to have to call somebody and they're going to have to call somebody, but it's not 392 00:33:43,400 --> 00:33:47,880 going to happen fast. I'm getting called in six months after incidents. I'm getting called 393 00:33:47,880 --> 00:33:53,640 in six years after incidents. Like it's a slow process right now because of that lack 394 00:33:53,640 --> 00:33:59,200 of detection and incident response maturity I talked about. It's a really slow process 395 00:33:59,200 --> 00:34:04,680 for people to figure out it's a cyber thing and get somebody involved who knows what to 396 00:34:04,680 --> 00:34:10,800 do with that. So I don't have an answer to the question. Like, you know, 72 hours, if 397 00:34:10,800 --> 00:34:16,160 it's ransomware, yeah. If it's something that's visibly cyber, yeah, but don't expect that's 398 00:34:16,160 --> 00:34:20,880 going to happen when it's actually the big bad doing something to a process. It's not 399 00:34:20,880 --> 00:34:26,240 going to happen that fast. I've often said the more advanced the adversary, the longer 400 00:34:26,240 --> 00:34:29,880 it's going to take for them to notice it's an actual incident. So those are the ones 401 00:34:29,880 --> 00:34:33,760 you're actually trying to solve. Yeah. Yeah. And that's the really scary stuff because 402 00:34:33,760 --> 00:34:38,920 they're making the same thing happen as a dangerously failed piece of equipment. So 403 00:34:38,920 --> 00:34:44,240 it's going to look like a dangerously failed piece of equipment. Yeah. Well, it's good 404 00:34:44,240 --> 00:34:51,160 to know that even someone who does this every day doesn't have a good answer. Maybe an actuary 405 00:34:51,160 --> 00:34:56,280 does or something. Maybe looking at the incident metrics, you could come up with a number, 406 00:34:56,280 --> 00:35:01,080 but it takes a long time and that's a big problem that we have to solve first. It's 407 00:35:01,080 --> 00:35:06,160 super challenging. No, I couldn't agree more, but that's, I didn't expect anything. Definitely 408 00:35:06,160 --> 00:35:13,680 be honest. Now the last one I wanted to argue about, argue about, discuss is the definition 409 00:35:13,680 --> 00:35:21,680 of incident because rarely is this well defined. Do you have something you use or is this just 410 00:35:21,680 --> 00:35:26,840 as squishy for you as it is everybody else? So definition of how you, how you qualify 411 00:35:26,840 --> 00:35:33,560 one, what an incident means? Yeah. Yeah. So, um, yeah, I mean, I would still use the standard 412 00:35:33,560 --> 00:35:38,920 cybersecurity definition of incident. You know, it's, it's a major event, but what, 413 00:35:38,920 --> 00:35:43,560 how you quantify a major of event, a cyber event in your environment is going to depend 414 00:35:43,560 --> 00:35:47,320 on what matters to you in your industrial environment. And this is something that everybody 415 00:35:47,320 --> 00:35:52,480 misses in OT as well. Um, they usually copy their severity matrix over from enterprise 416 00:35:52,480 --> 00:35:58,160 and it's absolutely goofy and ineffective for OT. Um, your severity matrix in OT, what 417 00:35:58,160 --> 00:36:05,000 you quantify as a high, medium, low severity audit level incident or event in OT is going 418 00:36:05,000 --> 00:36:11,400 to depend on what makes people get hurt. That's, that's the worst day ever is how I usually 419 00:36:11,400 --> 00:36:14,880 explain this to people is what you really need to do is you need to sit down with your 420 00:36:14,880 --> 00:36:18,920 leadership and say, what is our worst day ever? What is our worst case scenario as a 421 00:36:18,920 --> 00:36:23,440 industrial business or an organization that relies on industrial systems? Is it somebody 422 00:36:23,440 --> 00:36:29,600 dying? Is our process failing for 24 hours? A worst case scenario is our, our really expensive 423 00:36:29,600 --> 00:36:34,000 equipment being utterly destroyed, a worst case scenario. And then you work from down 424 00:36:34,000 --> 00:36:38,400 from there and figure out, well, what could practically cause that and what mitigations 425 00:36:38,400 --> 00:36:42,400 for those hazards are in place because you don't want that to happen because an operator 426 00:36:42,400 --> 00:36:46,440 screws up. So there's safety controls in place. They're not all digital safety controls. 427 00:36:46,440 --> 00:36:50,480 Some of them are physical, some of them are human. So you have to do that kind of risk 428 00:36:50,480 --> 00:36:55,700 mapping down from actual consequences you actually care about what would really cause 429 00:36:55,700 --> 00:37:00,640 the worst case scenarios. And those are your high and critical level incidents. And that's 430 00:37:00,640 --> 00:37:05,080 going to vary depending on your industrial environment, your process, your vertical, 431 00:37:05,080 --> 00:37:10,280 your location, et cetera, your redundancy, all of those things are going to play into 432 00:37:10,280 --> 00:37:13,560 that calculation. So you've got to do that for your industrial environment. And that's 433 00:37:13,560 --> 00:37:20,640 how you name what an incident is, what a high severity incident is versus a audit level 434 00:37:20,640 --> 00:37:25,960 event that isn't actually considered an incident to a moderate severity incident, incident, 435 00:37:25,960 --> 00:37:30,440 et cetera. You can't just say, oh, a web server compromise. That can't be in your severity 436 00:37:30,440 --> 00:37:37,480 matrix for OT. It can't be, oh, there's 40 computers infected. Does that actually matter? 437 00:37:37,480 --> 00:37:42,040 If they're infected with Conficker or Sality? No. Shutting down the process to reimagine 438 00:37:42,040 --> 00:37:46,200 those computers is going to have a much worse impact from a consequence perspective. If 439 00:37:46,200 --> 00:37:51,240 it's ransomware and there's a loss of control, that's a very, very different situation. And 440 00:37:51,240 --> 00:37:56,920 you should be calling out a loss of control, loss of visibility situation, not, oh my God, 441 00:37:56,920 --> 00:38:01,360 you've got 40 computers infected with malware. I've been called into environments that have 442 00:38:01,360 --> 00:38:05,160 been infected for 10 years and they finally have a big enough maintenance outage and upgrade 443 00:38:05,160 --> 00:38:09,880 period to get rid of it. So they're calling me in 10 years later. Like consequences are 444 00:38:09,880 --> 00:38:14,640 king there. Yeah. I would say it's, I've been to generation plants and they're just rife 445 00:38:14,640 --> 00:38:17,800 with Conficker and no one cares. It's just not impacting anything. 446 00:38:17,800 --> 00:38:21,440 But they're all infected. Yeah. You can't think about things like that. 447 00:38:21,440 --> 00:38:26,640 Yeah. There are some that argue that it doesn't qualify as an incident unless there is malicious 448 00:38:26,640 --> 00:38:31,200 intent. What are your thoughts on this? Oh my God. I don't care. I don't care. 449 00:38:31,200 --> 00:38:36,880 Design incidents however the hell you want. Like, you know, I see them defined differently 450 00:38:36,880 --> 00:38:42,120 in every industrial org because they define words differently between IT and OT. Sometimes 451 00:38:42,120 --> 00:38:48,280 OT defines incident as, you know, something independent of malicious activity. Yes. I 452 00:38:48,280 --> 00:38:53,200 understand in enterprise environments, we usually clearly define cybersecurity incidents 453 00:38:53,200 --> 00:38:58,720 as things that have malicious intent involved. But in OT, sometimes you've already defined 454 00:38:58,720 --> 00:39:05,840 the big eye incident as anything that impacts the process. So I don't care. I'm sorry. That's 455 00:39:05,840 --> 00:39:11,000 my answer. My old curmudgeonly answer to that is figure out your definition, share it with 456 00:39:11,000 --> 00:39:15,280 OT, make sure you're on the same page with definitions and make sure you've quantified 457 00:39:15,280 --> 00:39:19,840 how you're going to define those incidents at different severities very, very clearly 458 00:39:19,840 --> 00:39:23,560 in a way that actually makes industrial and process and safety sense. 459 00:39:23,560 --> 00:39:28,960 Yeah. No, and I totally agree. I understand. The reason I was asking was it matters when 460 00:39:28,960 --> 00:39:33,320 you're trying to report both upstream within the organization for incident management metrics 461 00:39:33,320 --> 00:39:38,920 or KPIs in addition to outwardly to insurance firms or whether you're going through M&A 462 00:39:38,920 --> 00:39:43,580 or regulatory agency, for example. So yeah. Figure it the hell out. Decide whether that's 463 00:39:43,580 --> 00:39:48,200 going to be a differentiator for that and how that figures into your regulation. That's 464 00:39:48,200 --> 00:39:53,240 the only answer I'll give there is make sure you have a clear, common, shared definition 465 00:39:53,240 --> 00:39:57,360 that everybody knows and make sense for making people stay alive. 466 00:39:57,360 --> 00:40:02,560 Yeah. I'm just still waiting to see what that clear definition is for any of them. 467 00:40:02,560 --> 00:40:09,080 Yeah. I don't think that they're going to include malicious intent in regulation for 468 00:40:09,080 --> 00:40:14,320 incidents. I haven't seen it in a lot of places globally for that type of legislation and 469 00:40:14,320 --> 00:40:20,160 regulation for reporting. I haven't seen that requirement for it to be purposefully malicious 470 00:40:20,160 --> 00:40:24,480 activity. Yeah. It's not in like NIST 2, for example, 471 00:40:24,480 --> 00:40:28,480 but if you get to the NERC SIP standards, they actually have a clause in there that 472 00:40:28,480 --> 00:40:34,400 says attempt to compromise. And that one seems to lean into the malicious intent space a 473 00:40:34,400 --> 00:40:38,780 little bit. To compromise. Is the worm that's just headless 474 00:40:38,780 --> 00:40:43,780 and spreading in your environment and doing bad stuff unintentionally, is it attempting 475 00:40:43,780 --> 00:40:51,560 to compromise systems? Gosh. That's like, is sality getting on something today? Attempting 476 00:40:51,560 --> 00:40:56,240 to compromise. I don't know. I don't know. It's ambiguity again. 477 00:40:56,240 --> 00:41:00,400 Yep. That seems to be the crux of the argument when you have those situations that really 478 00:41:00,400 --> 00:41:06,240 do, they look like they would qualify as an event or a cyber security incident, but you 479 00:41:06,240 --> 00:41:11,520 don't have that malicious intent or that attempt to compromise. So it's one of those things 480 00:41:11,520 --> 00:41:15,840 I just thought it would be interesting to ask. It's an interesting thing to think about. 481 00:41:15,840 --> 00:41:21,600 Again, make sure that you have a common standard definition. And if you are a regulator, make 482 00:41:21,600 --> 00:41:29,560 sure that your definition for other people who need to report to you is clearly defined. 483 00:41:29,560 --> 00:41:32,960 And based on what you want to know about, if you're the regulator, do you want to know 484 00:41:32,960 --> 00:41:37,800 every time somebody deals with Conficker? Do you want to know about that? Is that useful 485 00:41:37,800 --> 00:41:43,720 to you? It has real impacts and environments. It can eat up low resource machines and cause 486 00:41:43,720 --> 00:41:49,600 really weird, bad things to happen in industrial environments. But like we discussed earlier, 487 00:41:49,600 --> 00:41:54,080 pretty much everybody has old headless worms in their critical infrastructure environment. 488 00:41:54,080 --> 00:41:57,600 So do you want to know about everyone? Then you're going to need to define that. You're 489 00:41:57,600 --> 00:42:00,960 going to need to say that in your regulation. Yeah. And then you're going to have to house 490 00:42:00,960 --> 00:42:03,560 all that data and then see if this is trying to make things worse. 491 00:42:03,560 --> 00:42:10,040 That's a them problem. That's definitely a them problem there. Figure that out. Define 492 00:42:10,040 --> 00:42:15,680 it clearly. Don't make these ambiguous definitions. You have to make things clear for people. 493 00:42:15,680 --> 00:42:18,560 Yeah. Do the hard work to actually get it defined right. 494 00:42:18,560 --> 00:42:24,920 Yep. Awesome. Okay. Well, I'm going to wrap up with asking you what is next for pancakes? 495 00:42:24,920 --> 00:42:31,200 What's going on? No. I mean, I guess personally, I am currently 496 00:42:31,200 --> 00:42:37,960 me and making an endeavor to move to Australia with Drago and start working on a new frontier 497 00:42:37,960 --> 00:42:44,600 of industrial operations and incident response there in that region of the world. So there's 498 00:42:44,600 --> 00:42:48,300 a lot of development and growth and incident response there. And I hope that that works 499 00:42:48,300 --> 00:42:54,020 out. I'm very excited to start working in Australia and the nearby nations in defending 500 00:42:54,020 --> 00:42:58,840 their critical infrastructure as well. So that's what's next for me, hopefully. 501 00:42:58,840 --> 00:43:02,600 Okay. Fantastic. I really hope that works out because I know it would be a valuable 502 00:43:02,600 --> 00:43:04,600 resource anywhere you go. So I certainly hope that happens. 503 00:43:04,600 --> 00:43:06,960 Thank you. You're so kind. This was so fun. 504 00:43:06,960 --> 00:43:12,040 Yeah. Now, are you going to any of the conferences that we usually see you at coming up? So in 505 00:43:12,040 --> 00:43:13,920 case anybody's listening, they can catch you. 506 00:43:13,920 --> 00:43:22,560 I will be at Shmoocon. I'll be at ChiBurcon in Chicago. I will be speaking in Canada a 507 00:43:22,560 --> 00:43:28,920 little bit later in the winter time. And I don't know beyond that. Right now, my plans 508 00:43:28,920 --> 00:43:33,560 are a little bit up in the air based on when I'm going to move. But I'm always trying to 509 00:43:33,560 --> 00:43:38,560 find opportunities to speak and participate in conferences. So I'm sure I will, whatever 510 00:43:38,560 --> 00:43:41,120 continent I'm on that month. 511 00:43:41,120 --> 00:43:46,880 Fantastic. Okay. And I will put all of your contact info in the show notes so that people 512 00:43:46,880 --> 00:43:51,320 can find you and contact with you and get much, much more of your valuable information. 513 00:43:51,320 --> 00:43:52,600 Oh, you're so kind. 514 00:43:52,600 --> 00:43:55,720 Alyssa, I really appreciate your time. Thank you so much. 515 00:43:55,720 --> 00:44:05,400 It was such a pleasure. Thank you for the really thought provoking questions. 516 00:44:05,400 --> 00:44:09,880 Thanks for listening to the Ampex Cyber Critical Assets podcast. You can find us on all your 517 00:44:09,880 --> 00:44:14,840 favorite podcast sources. So please like, subscribe and share with your colleagues. 518 00:44:14,840 --> 00:44:24,240 Check out our other content such as blogs, news and more at AmpexCyber.com. It's A-M-P-Y-X-C-Y-B-E-R.com. 519 00:44:24,240 --> 00:44:45,120 Ampex Cyber, securing your world.