1 00:00:05,240 --> 00:00:11,960 It's basically looking at the weaknesses or bugs in a code that opens up the 2 00:00:12,000 --> 00:00:25,440 ability for a cyber hacker to enter and attack your code. Welcome listeners to 3 00:00:25,480 --> 00:00:29,679 the Industrial Security Podcast. My name is Nate Nelson. I'm here with Andrew 4 00:00:29,679 --> 00:00:34,880 Ginter, the vice president of Industrial Security at water Fosscurity Solutions, who's going 5 00:00:34,920 --> 00:00:38,679 to introduce the subject and guests of our show today. Andrew, how are 6 00:00:38,679 --> 00:00:42,479 you. I'm very well, Thank you, Nate. Our guest today is 7 00:00:42,479 --> 00:00:49,280 Susan Ferrell. She is a strategic advisor for ot and Industrial Cybersecurity and our 8 00:00:49,359 --> 00:00:54,200 topic is more or less scanning for zero Days. She's going to be talking 9 00:00:54,200 --> 00:01:00,600 about a micro repository. I wasn't aware of the common weakness enumeration repositors rather 10 00:01:00,640 --> 00:01:06,719 than the common vulnerability repository that I was familiar with. So you know, 11 00:01:06,959 --> 00:01:14,480 zero Day's weaknesses not vulnerabilities. That's our topic. Then, without further ado, 12 00:01:14,560 --> 00:01:19,959 here's you with Susan. Hello Susan, and thank you for joining us. 13 00:01:21,120 --> 00:01:23,879 Before we get started, can I ask you to say a few words 14 00:01:23,879 --> 00:01:27,879 for our listeners about yourself, about your background, please absolutely. And Andrew, 15 00:01:27,920 --> 00:01:33,959 thank you so much for inviting me to this podcast. The first twenty 16 00:01:34,040 --> 00:01:41,079 years of my career I spent in oil and gas exploration and production or upstream 17 00:01:41,439 --> 00:01:48,640 side of the business, working for the Halliburton Software division, Landmark Graphics work 18 00:01:48,840 --> 00:01:59,319 for Silicon Graphics or SGI, and high performance visualization of hydrocarbon reservoirs as well 19 00:01:59,439 --> 00:02:08,879 as Paradigm Geophysical. Then I shifted over to it cybersecurity, and because of 20 00:02:08,919 --> 00:02:16,039 my oil and gas background, that migrated over to a focus in ot ICs 21 00:02:16,080 --> 00:02:21,639 cybersecurity. So for the last ten years as what I've been very focused on. 22 00:02:22,840 --> 00:02:30,599 Also last couple of years have been focused on taking otics cybersecurity that was 23 00:02:30,639 --> 00:02:43,479 developed for defense purposes and commercializing that for protecting critical infrastructure and nuclear manufacturing, 24 00:02:43,560 --> 00:02:47,719 oil and gas, chemical, et cetera. And our topic today is mapping 25 00:02:49,000 --> 00:02:53,039 for zero days. I've never heard of this. What is mapping for zero 26 00:02:53,120 --> 00:02:59,919 days? What problem are we solving here? So it's really interesting, Andrew. 27 00:03:00,000 --> 00:03:06,919 So there's a lot of focus when you think about otics or industrial vulnerability 28 00:03:06,960 --> 00:03:19,039 management is to look at cvees or common vulnerabilities, and those are the vulnerabilities 29 00:03:19,080 --> 00:03:24,080 and software code or firmware code that sits in embedded devices that have actually been 30 00:03:24,199 --> 00:03:35,680 published. There's also another layer of vulnerabilities known as keVs or known exploited vulnerabilities. 31 00:03:36,159 --> 00:03:43,199 Again, those are the cvees that have been known to be exploited in 32 00:03:43,240 --> 00:03:51,439 different environments and software. What cwes are are common weakness enumerations or it's a 33 00:03:51,479 --> 00:04:02,080 category system that was developed by MITER and KPAK that identifies weakness and vulnerabilities in 34 00:04:02,360 --> 00:04:09,599 software code, both at a hardware and software level. So when you're looking 35 00:04:09,639 --> 00:04:15,599 at firmware for instance, So that is what a CWE is. It's basically 36 00:04:15,719 --> 00:04:24,279 looking at the weaknesses or bugs in a code that opens up the vulnerability or 37 00:04:24,399 --> 00:04:31,600 the ability for a cyber hacker to enter and attack your code. I'm familiar 38 00:04:31,600 --> 00:04:39,040 with the the CVE system and database. I am aware of the non Exploited 39 00:04:39,079 --> 00:04:44,480 Vulnerabilities list, but you know, probably don't consult it often enough, but 40 00:04:44,519 --> 00:04:48,839 I know it's out there. CWE. I've never heard of weaknesses? Can 41 00:04:48,879 --> 00:04:54,240 you? Can you talk about that a bit more? What is a CWE? 42 00:04:54,519 --> 00:04:59,000 Sure? So, again, it represents a weakness in the code. 43 00:04:59,079 --> 00:05:10,120 So one example is a buffer overflow, and buffer overflow is the ability for 44 00:05:10,240 --> 00:05:19,319 a cyber attacker to over instruct code and be able to literally shut down the 45 00:05:19,439 --> 00:05:28,839 production of a PLC for instance, or may overratchet the PLC and cause it 46 00:05:28,879 --> 00:05:36,560 to explode, for instance. So there's even a cwe that represents malicious AI 47 00:05:36,759 --> 00:05:46,279 code. It's called CWE ten thirty nine. There are cwees that represent cryptographic 48 00:05:47,439 --> 00:05:55,639 problems in code or a dangerous function within the code. So basically it's just 49 00:05:55,839 --> 00:06:01,040 outlining the different weaknesses that a code can have in it that can be exploited. 50 00:06:02,600 --> 00:06:11,319 One of the great activities that I did over this past year is participated 51 00:06:11,439 --> 00:06:18,639 in the cwe pep kpec ICs Working Group, where we mapped cwees to six 52 00:06:18,759 --> 00:06:26,279 two four four three so that you can determine if there are any cwes that 53 00:06:26,360 --> 00:06:35,040 might be resident in firmware on an otics device that puts you at risk of 54 00:06:35,360 --> 00:06:45,279 unmet requirements from a compliance perspective. Andrew, I'm quite familiar with cvees, 55 00:06:45,480 --> 00:06:50,279 but cwees are a new concept to me, and I'm not yet entirely clear 56 00:06:50,439 --> 00:06:55,319 on the distinction. I mean a buffer overflow to me, sounds like of 57 00:06:55,399 --> 00:07:00,279 vulnerability. Yeah, I wasn't familiar with cwe's either, but you know, 58 00:07:00,319 --> 00:07:03,439 if you google it, miter or CWE, there's a whole repository there's hundreds 59 00:07:03,439 --> 00:07:11,040 of these things. And you know, if if there's a buffer overflow in 60 00:07:11,079 --> 00:07:15,680 a CVE, it says something like this PLC, if you send it that 61 00:07:15,759 --> 00:07:18,879 command, it triggers a buffer overflow that can be exploited to blah blah blah. 62 00:07:18,920 --> 00:07:25,160 You know, these seventeen models of PLCs run that same software, they 63 00:07:25,199 --> 00:07:30,800 have this vulnerability. That's a CVE. That's that's a known vulnerability. In 64 00:07:30,920 --> 00:07:35,959 CWE, there's an entry for buffer overflow that says a buffer overflow is when 65 00:07:36,399 --> 00:07:44,680 somebody sends a message that you know is usually too long, and you know 66 00:07:44,920 --> 00:07:48,079 it describes what is a buffer overflow, and that says that's it. It 67 00:07:48,120 --> 00:07:53,480 does not say it's in this PLC or in that web browser or in CVE 68 00:07:53,959 --> 00:07:59,879 is sort of specific, whereas CWE is sort of the idea saying, well, 69 00:08:00,759 --> 00:08:03,600 if you're not checking the length of your buffers, you could have a 70 00:08:03,600 --> 00:08:07,800 buffer overflow. If you're not careful about how you manage memory, you might 71 00:08:07,000 --> 00:08:11,519 use memory after you free it. If you are not, you know, 72 00:08:11,879 --> 00:08:18,439 careful about keeping track of your your web browsers, you could have cross site 73 00:08:18,480 --> 00:08:24,360 request forgery. So CWE is describing types of vulnerabilities where a CVE is describing 74 00:08:24,800 --> 00:08:31,160 one of those types is specific in these six products, and if you, 75 00:08:31,160 --> 00:08:33,559 you know, get the patch, you fix it. So in a sense, 76 00:08:33,639 --> 00:08:39,120 CWE is is a long list of stuff that could go wrong in software, 77 00:08:39,159 --> 00:08:43,279 and you know, to me, it's I thought it would be primarily 78 00:08:43,399 --> 00:08:48,320 useful to software developers saying, oh, I'm writing software. Here's you know, 79 00:08:48,480 --> 00:08:52,919 literally hundreds of things I could do wrong. Let me go through them 80 00:08:52,960 --> 00:08:56,320 and see if I've done any of them. Does that make more sense? 81 00:08:58,440 --> 00:09:01,080 It does, so then if if I follow you correctly, it isn't that 82 00:09:01,120 --> 00:09:07,559 we're applying these cwe's too specific software products. They're just a general list of 83 00:09:07,639 --> 00:09:13,679 categories, sort of like miter attack, but for vulnerabilities. You know, 84 00:09:13,200 --> 00:09:16,639 I hadn't thought of it that way, but yeah, minor attack is all 85 00:09:16,720 --> 00:09:22,320 of the ways, you know, sort of types of ways that bad guys 86 00:09:22,480 --> 00:09:26,639 could attack us, and you know, CWE is all of the you know, 87 00:09:28,039 --> 00:09:33,279 kinds of vulnerabilities that could be latent in a particular product. So yeah, 88 00:09:33,720 --> 00:09:37,720 in a sense, CWE is the miter attack of vulnerabilities. I haven't 89 00:09:37,759 --> 00:09:41,200 thought of it that way. I think that's that's probably a good way to 90 00:09:41,240 --> 00:09:46,960 think of it. Buffer overflow. I understand you said you mapped it to 91 00:09:48,039 --> 00:09:50,200 six two four four three, though I mean, you know what, I'm 92 00:09:50,320 --> 00:09:54,399 the standard I look at all the time in six two four fur three is 93 00:09:54,519 --> 00:09:58,559 three dash three which talks about you know, you should put a firewall here, 94 00:09:58,720 --> 00:10:03,799 you should do anti virul there. It talks about security controls. It 95 00:10:03,840 --> 00:10:09,279 doesn't talk about vulnerabilities. What part of six two four fourth e did you 96 00:10:09,360 --> 00:10:16,000 map these vulnerabilities into? So the three different parts that we as a group 97 00:10:16,080 --> 00:10:20,679 focused on were parts three dash three, four dash one, and four dash 98 00:10:20,759 --> 00:10:31,519 two in for example, we were assigned a specific CWE each subgroup. I 99 00:10:31,840 --> 00:10:37,360 was my first CWE that we mapped as a group was CWE seven ninety eight, 100 00:10:37,399 --> 00:10:48,480 which represents cryptographic issues in code, and it is was not a hard 101 00:10:50,000 --> 00:10:58,039 exercise to map it to specific specifications within three dash, three, four dash 102 00:10:58,120 --> 00:11:05,399 one and four dash. We just mapped the wording from the definition of CWE 103 00:11:05,519 --> 00:11:11,639 seven ninety eight, for instance, to the specific parts within three three FORDSH 104 00:11:11,679 --> 00:11:18,679 one and FORDSH two. And then as a result, what Miter did is 105 00:11:20,080 --> 00:11:30,159 published the mapping of the CWE so that if you're looking at setting your compliance 106 00:11:30,279 --> 00:11:37,600 requirements, you can do an analysis of the firmware to see if any of 107 00:11:37,600 --> 00:11:45,320 those cwes exist, and then determine if by continuing to use that firmware in 108 00:11:45,360 --> 00:11:50,279 its existing state, if it is causing compliance issues to six two four four 109 00:11:50,399 --> 00:11:58,840 three. The same can be done for eight hundred fifty three or eight hundred 110 00:12:00,480 --> 00:12:05,840 eighty two to map the compliance requirements to it. Could you give me an 111 00:12:05,879 --> 00:12:09,879 example of that. I mean, you know, if you look at the 112 00:12:09,919 --> 00:12:15,759 PLC and say, well, it appears to be written in C. That's 113 00:12:15,759 --> 00:12:20,080 sort of the signature of the binary and the firmware, So it is probably, 114 00:12:20,600 --> 00:12:28,480 you know, somewhere possibly susceptible to a buffer overflow. In what sense 115 00:12:28,039 --> 00:12:31,720 you know? A? Have I got that example right? And B if 116 00:12:31,840 --> 00:12:37,159 I've got it right, in what sense is that a compliance violation? There's 117 00:12:37,200 --> 00:12:39,960 no, there's no. There's no requirement in six two four four three that 118 00:12:41,000 --> 00:12:46,039 says your your code must be free of bugs. You're correct, But it 119 00:12:46,159 --> 00:12:56,679 does say that you have to practice good uh uh cryptographic practice. Or it 120 00:12:56,720 --> 00:13:09,840 does say that you cannot have any cross scripting weaknesses in your industry four point 121 00:13:09,919 --> 00:13:18,039 zero web application for instance, or it will say that if you do have 122 00:13:18,080 --> 00:13:31,399 a buffer overflow issue in your code, you are not meeting the compliance requirements 123 00:13:31,440 --> 00:13:37,879 of certain parts of three dash three, fourd ASH one and four dash two. 124 00:13:39,720 --> 00:13:41,440 So Nate Susan went through that real fast. Let me give you a 125 00:13:43,159 --> 00:13:48,720 concrete example. You know, uh six two four four three three dash three 126 00:13:48,080 --> 00:13:54,039 is the standard that applies to systems. If I have a a system that 127 00:13:54,080 --> 00:13:58,240 I've designed in my power plant and I wanted to be compliant with the standard, 128 00:13:58,240 --> 00:14:03,279 I would look at three dash three four dash one is a certified software 129 00:14:03,320 --> 00:14:07,759 you know, secure software development process. So if I'm developing product and I 130 00:14:07,799 --> 00:14:13,279 want to be certified as a developer of secure product, that's the standard I 131 00:14:13,559 --> 00:14:20,080 my product development team is evaluated against. My processes are evaluated. Four dash 132 00:14:20,159 --> 00:14:24,840 two is when you certify actual product. If my team has produced a product 133 00:14:24,960 --> 00:14:30,519 and I want the product to be certified as compliant, it would be four 134 00:14:30,559 --> 00:14:35,600 dash too that I'm compliant with. So you know, concrete example, cwe 135 00:14:35,039 --> 00:14:41,279 is possible is what's you know, vulnerabilities that are possible, and what we're 136 00:14:41,279 --> 00:14:46,200 mapping is, look, if you wind up with one of these vulnerabilities, 137 00:14:46,399 --> 00:14:50,840 then you have a problem with this part of your compliance process. So concrete 138 00:14:50,879 --> 00:14:56,840 example, you know three dash three has a rule number five dot seven that 139 00:14:56,120 --> 00:15:01,440 you know, the language is complicated, but effectively it says, if you're 140 00:15:01,440 --> 00:15:05,120 going to send a password across a network, then you have to encrypt it 141 00:15:05,159 --> 00:15:09,279 so that people can't just read your password. Okay. And you know, 142 00:15:09,639 --> 00:15:11,679 the example that Susan gave was a CWE saying well, there might be a 143 00:15:11,720 --> 00:15:16,559 bug in your encryption process that you know, lets people see, you know, 144 00:15:16,879 --> 00:15:20,200 decrypt and uh uh, you know, see the password. Okay. 145 00:15:20,240 --> 00:15:28,799 So the mapping says, look, if you have this vulnerability in you know, 146 00:15:28,080 --> 00:15:31,919 your products, in your system, and that's an if okay, CVE 147 00:15:33,240 --> 00:15:37,360 is what's actually their CWE is what's possible if you wind up with this vulnerability, 148 00:15:37,399 --> 00:15:43,120 then you would have potentially a problem with compliance with rule five dot seven 149 00:15:43,440 --> 00:15:46,440 because the bad guys could use the vulnerability to steal the password. So that's 150 00:15:46,440 --> 00:15:54,360 my understanding of how this this mapping against standards works. I've gone to the 151 00:15:54,480 --> 00:15:58,519 to the website. I see, you know, micro dot org Common Weakness 152 00:15:58,799 --> 00:16:03,679 Enumeration. You know, I see a long list of potential vulnerabilities, and 153 00:16:03,879 --> 00:16:07,320 you know, I can see if I'm a vendor, I mean I've worked 154 00:16:07,320 --> 00:16:11,799 for vendors all my career. If I'm a person developing the software in a 155 00:16:11,840 --> 00:16:15,200 PLC and whatnot, you know, I'm staring at a CWE talking about I 156 00:16:15,200 --> 00:16:18,840 don't know, cross site you know, cross eight scripting or cross site request 157 00:16:18,879 --> 00:16:26,480 forgery. These are vulnerabilities that my software developers should be looking out for when 158 00:16:26,480 --> 00:16:30,919 they're writing the code. But you know this list here, you've sort of 159 00:16:30,960 --> 00:16:36,639 connected it a bit to compliance. Do end users use this list? What 160 00:16:36,720 --> 00:16:38,399 good is this list to an end user? Is it? Is it primarily 161 00:16:38,480 --> 00:16:42,240 a tool for developers to say we should be on the lookout for these seven 162 00:16:42,360 --> 00:16:48,600 hundred different things in our source code. There are several different use cases for 163 00:16:48,759 --> 00:16:56,440 cwees, and you're right, Andrew, it is a very valuable useful resource 164 00:16:56,559 --> 00:17:04,640 for devsec ops as especially from a shift left perspective when they're looking at cyber 165 00:17:04,799 --> 00:17:17,920 informed engineering or secure by design of the devices, being aware of the cwes 166 00:17:18,039 --> 00:17:29,359 during the continuous integration and continuous development of otics device firmware code. But beyond 167 00:17:29,400 --> 00:17:37,839 that, if you are an asset owner, and let's say that you have 168 00:17:37,079 --> 00:17:47,000 just completed your asset inventory, it is typical that twenty to forty percent of 169 00:17:47,039 --> 00:17:55,640 your assets may be end of life or legacy assets and it's no longer being 170 00:17:55,680 --> 00:17:59,799 supported by an OEM, but it is still in production, it's still connected 171 00:17:59,839 --> 00:18:08,079 to your network, and you will want to either a hire a threat hunter 172 00:18:08,319 --> 00:18:15,960 threat modeler to look at the firmware of those end of life devices to see 173 00:18:17,000 --> 00:18:22,720 if there are any of the cwees that are in the firmware. That can 174 00:18:22,759 --> 00:18:32,279 be done through reverse engineering, it can be done through binary analysis scanning to 175 00:18:32,359 --> 00:18:41,960 see a the cwees are present in your firmware. What actions you take after 176 00:18:41,160 --> 00:18:48,559 determining if there are any potential zero days in your firmware is to either a 177 00:18:48,680 --> 00:19:00,440 triage that end of life asset for replacement or work with your OEM provider to 178 00:19:00,559 --> 00:19:10,640 see if there are any remediation steps to be taken. But the other way 179 00:19:10,759 --> 00:19:18,039 of handling that is fencing the device, much like what Waterfall does with providing 180 00:19:19,880 --> 00:19:30,680 directional communication to an end of life device to protect it from exposure to a 181 00:19:30,720 --> 00:19:37,160 cyber attacker. So yes, there are many things that both an asset owner 182 00:19:37,839 --> 00:19:48,119 and an OEM manufacturer can take in reducing risk if a cwe has been identified. 183 00:19:49,319 --> 00:19:52,480 This sounds almost too good to be true. If I've got a list 184 00:19:52,519 --> 00:19:57,559 of I don't know how many hundreds of potential weaknesses. And I've got scanners 185 00:19:57,599 --> 00:20:00,279 available that can scan my firm where I mean, you know, let's say 186 00:20:00,319 --> 00:20:04,680 I'm a vendor, can scan my my my stuff and come back and say, 187 00:20:06,200 --> 00:20:11,079 here's all of your vulnerabilities, fix them all. You know, now 188 00:20:11,799 --> 00:20:15,720 my code has none of you know, these these vulnerabilities. You know, 189 00:20:15,759 --> 00:20:19,119 the only thing I'm exposed to is I don't know, misconfiguration someone puts a 190 00:20:19,119 --> 00:20:23,559 week password in, or you know, new kinds of vulnerabilities being discovered. 191 00:20:23,559 --> 00:20:27,240 It sounds really good? Is this? Is this how people use this? 192 00:20:29,319 --> 00:20:34,160 Quite truthfully, Andrew, there are no silver bullets out there for doing binary 193 00:20:34,160 --> 00:20:41,319 analysis and finding one hundred percent of potential zero days or cwees, And not 194 00:20:41,400 --> 00:20:47,400 all cwees are even exploitable. So even after you find a CWE, could 195 00:20:47,400 --> 00:20:51,640 a hacker get to it? Is there a path to it? So you 196 00:20:51,720 --> 00:20:57,960 really have to use, uh the scanning as a part of your full stack. 197 00:21:00,240 --> 00:21:03,680 When you're looking at your vulnerability management, you're using your s bombs, 198 00:21:04,279 --> 00:21:11,799 you're using your hardware bill of materials. You're looking at endpoint protection, you're 199 00:21:11,839 --> 00:21:19,119 looking at network monitoring, you're looking at the configuration of the assets. You're 200 00:21:19,119 --> 00:21:29,079 making sure that there that your vulnerable assets are fenced properly, that the information 201 00:21:29,440 --> 00:21:33,119 is being properly fed to your SIM or your SORE so that you can trigger 202 00:21:34,160 --> 00:21:44,640 security policies too to keep an eye out on access to your more vulnerable or 203 00:21:44,759 --> 00:21:52,680 end of life or legacy assets. You want to add threat intelligence to your 204 00:21:52,880 --> 00:22:00,880 stack. You want to add you know, potential membership into an I sack 205 00:22:00,559 --> 00:22:07,960 that is sector specific to what you're involved in. There's you know, also 206 00:22:08,680 --> 00:22:22,799 the great capabilities that AI is adding to industrial automation looking for anomalies within the 207 00:22:22,839 --> 00:22:30,039 code. So this is just a part of your full stack, but I'm 208 00:22:30,200 --> 00:22:41,440 advocating not to miss the ability to proactively look for potential zero days in addition 209 00:22:41,200 --> 00:22:48,079 to monitoring for bad behavior on your network, because often by the time that 210 00:22:48,160 --> 00:22:52,519 you see the bad behavior on your network, it may be too late. 211 00:22:52,720 --> 00:23:02,799 So add both proactive detection as well as responsive totec. An additional part of 212 00:23:03,039 --> 00:23:11,359 that full stack is also digital twins. Digital twins are not only providing value 213 00:23:11,599 --> 00:23:18,880 for mechanical asset integrity, but also from a cybersecurity standpoint, it's providing that 214 00:23:19,079 --> 00:23:27,759 redundancy and resiliency for your critical infrastructure environment to then apply patches or to then 215 00:23:27,920 --> 00:23:37,119 have discussions on remediation for these potential zero days, triaging your end of life 216 00:23:37,240 --> 00:23:42,480 asset replacement strategy. So it, you know, I just want it to 217 00:23:42,599 --> 00:23:52,960 be viewed and not be glossed over. There's a lot of value in knowing 218 00:23:53,000 --> 00:24:00,359 whether or not there's potential zero days that are sitting in your firmware. Okay, 219 00:24:00,440 --> 00:24:04,039 so you know you've covered a lot of ground in terms of where cwe's 220 00:24:04,319 --> 00:24:08,160 might add value to a defense and depth posture. Can I give you a 221 00:24:08,200 --> 00:24:11,759 concrete example? Can you walk me through, you know, assume let's say 222 00:24:11,759 --> 00:24:17,359 that I am, I don't know a medium impact power plant. That's what 223 00:24:17,640 --> 00:24:22,759 personally I'm most familiar with NIRKSIP. I've got to comply, means I've got 224 00:24:22,799 --> 00:24:29,279 to do a risk assessment, a security assessment on my system. I don't 225 00:24:29,279 --> 00:24:33,160 know what is it every eighteen months or something like that, whatever the rule 226 00:24:33,279 --> 00:24:36,960 is. And let's say as part of that, I bring in, you 227 00:24:36,960 --> 00:24:41,519 know, an outside assessor. They come in and you know, very carefully 228 00:24:41,880 --> 00:24:45,680 run I don't know NESSUS or something, and you know, on all of 229 00:24:45,680 --> 00:24:48,960 my one hundred PLCs and hmis and everything else, and it comes back and 230 00:24:49,039 --> 00:24:53,559 says, you have three vulnerabilities you didn't know about. These three PLCs have 231 00:24:53,960 --> 00:24:57,079 a vulnerability. It's in the cve it was added ten days ago. And 232 00:24:57,119 --> 00:25:02,119 I go, what what not supposed to have any of these? Quick? 233 00:25:02,200 --> 00:25:04,799 Put a plant and page in place, patch this figure out if I have 234 00:25:04,839 --> 00:25:08,039 to report this to the regulator, you know, and another sort of a 235 00:25:08,079 --> 00:25:11,880 month or six weeks later, when the patch has been tested, it's been 236 00:25:11,960 --> 00:25:18,240 rolled out. You know, I'm done. I am aware of no vulnerabilities, 237 00:25:18,279 --> 00:25:22,759 no cvees that are evident in my asset inventory. You know, I'm 238 00:25:22,799 --> 00:25:27,400 clean again. But I've learned about cwees. Now go look at the CWE 239 00:25:27,519 --> 00:25:33,680 database and it doesn't have the name of my PLC in it. If I 240 00:25:33,759 --> 00:25:38,240 have that sort of let's say NRKSIP infrastructure in place already, how would I 241 00:25:38,319 --> 00:25:45,160 use a CWE That is an absolutely fabulous question, Andrew, and I think 242 00:25:45,200 --> 00:25:51,200 that's a lot of where companies they think that if they've handled all of their 243 00:25:51,240 --> 00:25:56,359 cvees that they can call it a day, and it is, you know, 244 00:25:57,960 --> 00:26:03,279 definitely a step forward. And saying that you've eliminated all of your uh 245 00:26:03,680 --> 00:26:11,119 cvees, that's you know, a fabulous accomplishment. But again, the cve 246 00:26:11,000 --> 00:26:19,559 is a published vulnerability, it is not going to recognize a potential zero day. 247 00:26:21,240 --> 00:26:26,440 And if you know, you look at your ot threat report that you 248 00:26:26,519 --> 00:26:33,000 did, your your twenty twenty three threat report, some of the attacks that 249 00:26:33,119 --> 00:26:41,519 were reported were actually taking advantage of zero days and not published cvees. So 250 00:26:41,960 --> 00:26:49,000 you're not finished. After you after you patch remediate all of your cvees, 251 00:26:49,480 --> 00:26:59,920 it is important to do a deeper dive and do vulnerability scanning of your firm 252 00:27:00,039 --> 00:27:12,119 where looking for cwes. That responsibility can be delegated to your third party vulnerability 253 00:27:14,160 --> 00:27:22,240 management provider, your compliance provider. It can also open up dialogue with your 254 00:27:22,039 --> 00:27:33,279 OEM manufacturer relationships that you have. But you know, the importance here is 255 00:27:33,319 --> 00:27:37,480 that you don't stop just at the cvees or or the caves. Is that 256 00:27:37,039 --> 00:27:45,160 you do continue down the path of being proactive and seeing if there are any 257 00:27:45,519 --> 00:27:52,920 cwes that reside in your assets. Okay, so maybe another way of asking 258 00:27:52,960 --> 00:27:56,480 the same question, let's take the other extreme. You know I have I 259 00:27:56,519 --> 00:28:03,119 don't know, a shoe factory with hundreds of PLCs and other robots, and 260 00:28:03,200 --> 00:28:07,920 I know I know that I have hundreds or even thousands of instances of vulnerabilities. 261 00:28:07,960 --> 00:28:11,039 This, you know, this PLC that I have seventy three of, 262 00:28:11,200 --> 00:28:15,559 has you know, nineteen vulnerabilities that I know about, and I just haven't 263 00:28:15,559 --> 00:28:18,720 got around to patching it. So I've buried, you know, these these 264 00:28:18,799 --> 00:28:23,319 vulnerable PLCs behind six layers of firewall and some encryption and some antivirus and some 265 00:28:23,359 --> 00:28:29,319 intrusion detection. And you know, I already know that I have thousands of 266 00:28:29,359 --> 00:28:33,240 cvees that I haven't patched. Does CWE do me any good? What sort 267 00:28:33,279 --> 00:28:37,079 of what? How mature do you have to be before you can get some 268 00:28:37,200 --> 00:28:45,359 benefit out of a CWE scanner or approach or whatever it is. Yeah, 269 00:28:45,400 --> 00:28:52,640 I think just about any critical infrastructure can take advantage of it. I wouldn't 270 00:28:52,680 --> 00:29:02,440 necessarily place a shoe manufacturer is being critical infrastructure. So you know, if 271 00:29:02,480 --> 00:29:11,240 you look at the you know, the the digital grid, power generators, 272 00:29:11,279 --> 00:29:22,440 electricity providers, you're looking at wastewater treatment plants, you're looking at nuclear power 273 00:29:22,559 --> 00:29:33,160 generation or anything that could affect national security. You know, chemical refinery plants, 274 00:29:33,279 --> 00:29:42,680 because you know, you're looking at highly targeted sectors for potential terrorism. 275 00:29:44,680 --> 00:29:55,079 Those are the low hanging fruit of sectors that take the most advantage of what 276 00:29:55,119 --> 00:30:06,599 we're talking about. So the more mature critical infrastructure providers so andrew in its 277 00:30:06,759 --> 00:30:11,720 simplest form, cdwe's and cvees. They're both tackling ultimately the same sorts of 278 00:30:12,240 --> 00:30:19,559 software bugs, but cvees from the after the fact perspective known vulnerabilities you deal 279 00:30:19,559 --> 00:30:25,039 with them in turn. And cwe's, as she mentioned, are the more 280 00:30:25,079 --> 00:30:29,400 proactive, the looking for the things that will one day be cvees if not 281 00:30:29,519 --> 00:30:34,960 dealt with today. Indeed, But you know, to me, cwe's highlights 282 00:30:36,000 --> 00:30:40,079 sort of a very common blind spot that I see in engineering teams. I 283 00:30:40,119 --> 00:30:45,119 see way too many people, you know, often technicians sort of people hands 284 00:30:45,119 --> 00:30:48,279 on lower down, you know, nose to the grindstone make this stuff happen, 285 00:30:48,880 --> 00:30:52,799 focused on known vulnerabilities, and the you know, the calculus in their 286 00:30:52,799 --> 00:31:00,119 mind sort of goes, well, you know, if I can pack all 287 00:31:00,200 --> 00:31:04,079 of my vulnerabilities, if I can get rid of all of my vulnerabilities, 288 00:31:04,519 --> 00:31:11,720 then I am invulnerable. And they work really hard to patch everything, and 289 00:31:12,519 --> 00:31:17,160 you know, the whole system is sort of blind to the fact that, 290 00:31:17,319 --> 00:31:22,519 well, that addresses the known vulnerabilities. But who knows what's out there on 291 00:31:22,559 --> 00:31:26,160 the unknown side, and CWE is sort of a tool that you know, 292 00:31:26,240 --> 00:31:27,799 once you have a glance at it, you go, there's hundreds of these 293 00:31:27,839 --> 00:31:32,519 things. There's hundreds of potential problems going to bite me. If the bad 294 00:31:32,559 --> 00:31:34,680 guys find these before I do, before the good guys do, before there's 295 00:31:34,680 --> 00:31:41,440 a patch available, then we're in trouble. So to me, CWE sort 296 00:31:41,440 --> 00:31:47,519 of is a powerful way of reminding people that it's not just about patching. 297 00:31:47,559 --> 00:31:52,039 There's there's bigger fish to fry here. There's sort of more dangerous scenarios that 298 00:31:52,079 --> 00:31:59,920 are possible. And this isn't to undermine the necessity and the difficulty in pat 299 00:32:00,240 --> 00:32:02,960 everything, but it strikes me that maybe part of the problem is that it's 300 00:32:04,000 --> 00:32:08,599 simply easier to conceive of all of the known vulnerabilities than to creatively address and 301 00:32:08,680 --> 00:32:12,839 go through all the things that you don't know about. That's right, and 302 00:32:12,880 --> 00:32:15,559 you know it's to me, part of the problem is that the term vulnerability 303 00:32:16,799 --> 00:32:21,680 when CVE uses the term, you know most most of the vulnerabilities in the 304 00:32:21,720 --> 00:32:25,839 CVE data based tens of thousands of them are bugs in the software that can 305 00:32:25,880 --> 00:32:31,279 be patched. If you look at the definition of the term vulnerability in the 306 00:32:31,319 --> 00:32:37,559 six two four four three standard. It's defined as any way that a system 307 00:32:37,640 --> 00:32:40,839 can be compromised, many of which are you know, bugs in the software 308 00:32:40,839 --> 00:32:45,680 that can be patched, but others are configuration mistakes, are stolen passwords, 309 00:32:45,720 --> 00:32:51,599 our default passwords, are you know, any of the many ways that you 310 00:32:51,640 --> 00:32:58,200 can attack a system without exploiting a software vulnerability. But the fact that they 311 00:32:58,279 --> 00:33:00,599 use the same word for both of these is very confusing. You know, 312 00:33:00,640 --> 00:33:06,160 we had Eric Cosman on like a year ago and he admitted, look, 313 00:33:06,200 --> 00:33:13,039 this is you know, there's confusion in the industry. Vulnerabilities are bigger than 314 00:33:13,400 --> 00:33:17,960 software bugs, and again cwe uh, you know, reminds us about software 315 00:33:17,960 --> 00:33:22,079 bugs we haven't even seen about. But the bigger picture is, you know, 316 00:33:22,200 --> 00:33:24,079 we need to be concerned about all of the ways that we can be 317 00:33:24,119 --> 00:33:30,079 attacked, not just exploits of known vulnerabilities. We do need to address those 318 00:33:30,119 --> 00:33:34,240 exploits, you know that that possibility. Uh yeah, I don't want to 319 00:33:34,279 --> 00:33:38,920 belittle that. It's a it's a very hard problem to solve, but the 320 00:33:39,440 --> 00:33:43,799 you know, security is is bigger than that is sort of the lesson and 321 00:33:43,880 --> 00:33:49,000 c W is one of the ways of reminding us of that. And you've 322 00:33:49,039 --> 00:33:52,880 been working with this concept with you know, end users like this for some 323 00:33:52,039 --> 00:34:00,599 time. Can I ask you, you know, when you look at at 324 00:34:00,640 --> 00:34:04,319 CW you said there's scanners available. If you run one of these scanners on 325 00:34:05,359 --> 00:34:08,079 you know, a system that is you know, has a bunch of known 326 00:34:08,159 --> 00:34:13,039 vulnerabilities and a plan to get rid of them, and you know has already 327 00:34:13,039 --> 00:34:16,760 got rid of all of the other known vulnerabilities, and you run one of 328 00:34:16,760 --> 00:34:21,519 these scanners and you come up with what do you come up with? You 329 00:34:21,559 --> 00:34:27,800 know, how many instances do you come up with? How unhappy are these 330 00:34:28,159 --> 00:34:31,280 these owners and operators to discover that you know there's more to do. Can 331 00:34:31,320 --> 00:34:39,559 you talk about the experience of working with CWE fine in a CWE is not 332 00:34:40,639 --> 00:34:47,239 the end of the world for the OEM or the asset owner, and it 333 00:34:47,800 --> 00:35:00,159 provides a great collaborative opportunity. I was just included in just listened to a 334 00:35:00,199 --> 00:35:07,920 podcast from Dragos for instance, that was using the use case of working with 335 00:35:08,559 --> 00:35:22,719 Rockwell Automation where they discovered some cwees that then goes through the reporting exercise of 336 00:35:22,880 --> 00:35:29,239 Actually CWE is a precursor to a c CVE. I didn't explain that earlier, 337 00:35:29,280 --> 00:35:35,039 But you have to find a CWE, you have to determine it is 338 00:35:35,480 --> 00:35:46,639 exploitable. You then discuss it through either CISSA as the route management of that 339 00:35:46,840 --> 00:35:53,199 CWE for the o T I c S sector, and then once it's been 340 00:35:53,239 --> 00:36:00,519 communicated to the OEM, they're given the opportunity to remediate and then it becomes 341 00:36:00,719 --> 00:36:09,159 a named CVE and Dragos is a is A is a CVE naming Association ers 342 00:36:09,199 --> 00:36:15,880 also referred to as a CNA. They went through the whole scenario of finding 343 00:36:15,239 --> 00:36:25,119 h cwees associated with Rockwell automation devices or assets and found it to be a 344 00:36:25,280 --> 00:36:37,760 very positive collaborative discussion where Rockwell was very proactive in coming up with remediation before 345 00:36:37,000 --> 00:36:45,039 it was published. So it can be a very positive activity in finding a 346 00:36:45,039 --> 00:36:55,559 CWE because it only reinforces our critical infrastructure cybersecurity position. I've led development teams 347 00:36:55,599 --> 00:37:00,639 for much of my career. You know, we were responsible for products that 348 00:37:01,159 --> 00:37:07,760 had hundreds of thousands, sometimes several million lines of code in them. And 349 00:37:08,440 --> 00:37:12,719 you know, in spite of our best efforts of you know, me and 350 00:37:12,719 --> 00:37:16,360 every one of my development teams, every piece of production product that we released 351 00:37:17,039 --> 00:37:22,920 had bugs in it. There's a certain defect density depending on how vigorously you 352 00:37:22,000 --> 00:37:25,760 test, vigorously, you inspect vigorously you design the code. In spite of 353 00:37:25,840 --> 00:37:32,079 your best efforts, there's always defects residual in the code, more defects in 354 00:37:32,239 --> 00:37:37,519 larger artifacts as a rule than in smaller artifacts. And some of those defects 355 00:37:37,679 --> 00:37:44,119 are security vulnerabilities, just statistically, and you know, some of those those 356 00:37:44,199 --> 00:37:47,960 vulnerabilities we've discovered or are going to be discovered by the good guys and are 357 00:37:49,000 --> 00:37:52,039 going to be fixed by the good guys before the bad guys find them. 358 00:37:52,320 --> 00:37:54,719 Some of them, potentially the bad guys are going to find and use against 359 00:37:54,840 --> 00:38:00,400 us before we have a chance to patch them. You know, this is 360 00:38:00,440 --> 00:38:02,599 sort of back of the envelope. This is my personal experience. This is 361 00:38:02,679 --> 00:38:12,840 this is sort of of principles of you know, software development in practice. 362 00:38:14,519 --> 00:38:17,079 You've been using you know, these scanners, you've been using c w E. 363 00:38:17,519 --> 00:38:22,800 How you know if I scan a random h M I with two million 364 00:38:22,800 --> 00:38:30,880 lines of code in it, do I find zero days? Typically, the 365 00:38:30,880 --> 00:38:37,320 the older the the device or asset is, the more likely you are to 366 00:38:37,400 --> 00:38:44,960 find cwe's in it. Because you know, chances are it wasn't included in 367 00:38:45,000 --> 00:38:51,400 a cyber informed engineering program or secure by design program, So yes, you're 368 00:38:51,440 --> 00:39:00,719 gonna you're going to find cwe's. The chances of those cwees being exploited is 369 00:39:00,760 --> 00:39:09,239 then the next step that you take. So it's not a doomsday message that 370 00:39:09,559 --> 00:39:17,559 every asset is going to include a CWE that's exploitable. So that's why the 371 00:39:17,599 --> 00:39:25,519 importance is is to triage it based off of resiliency and how old the asset 372 00:39:25,719 --> 00:39:29,800 is and if it's being connected to the network. So there's a lot of 373 00:39:29,800 --> 00:39:34,159 different factors on whether or not you even want to do this scanning on it. 374 00:39:34,760 --> 00:39:42,880 But you also need to prepare for how you would respond if these assets 375 00:39:43,000 --> 00:39:52,079 or these zero days are actually hacked. So getting involved in incident response training 376 00:39:52,119 --> 00:40:07,480 programs like the isa's ICs for ICs where teams can be focused on the forensics 377 00:40:08,159 --> 00:40:15,159 of the zero day attack and how to respond to it, how to protect 378 00:40:15,599 --> 00:40:24,840 yourself from that going forward, and most importantly, how to prevent it by 379 00:40:24,880 --> 00:40:36,559 being proactive. And so there's a high connection between doing CWE scanning and awareness 380 00:40:36,599 --> 00:40:49,199 of zero day vulnerabilities with your incident response training program. Andrew, how do 381 00:40:49,239 --> 00:40:57,440 you prepare teams for scenarios where a zero day vulnerability is uncovered and now you 382 00:40:57,519 --> 00:41:00,199 have to, you know, rush to patch everything. That's a good question. 383 00:41:00,400 --> 00:41:04,920 I wish I'd asked Susan that question, but sort of off the top 384 00:41:04,960 --> 00:41:09,000 of my head, there's a couple of things you have to do. You 385 00:41:09,039 --> 00:41:14,880 know, the we talked about sort of the definition of vulnerabilities. It includes 386 00:41:15,239 --> 00:41:19,559 zero days, includes other kinds of you know, misconfigurations or you know, 387 00:41:19,639 --> 00:41:28,599 attack opportunities. Zero day specifically, you know, to me, there's a 388 00:41:28,599 --> 00:41:31,960 couple of things. You've got to look at the big picture and anticipate the 389 00:41:32,000 --> 00:41:39,440 possibility in in your designs and in your risk planning when a zero day is 390 00:41:39,519 --> 00:41:45,519 announced. Let's say, even there's occasionally an announcement saying here's a cve A 391 00:41:45,639 --> 00:41:50,960 zero day is being actively exploited and there's no patch available for it yet. 392 00:41:51,159 --> 00:41:54,239 It's sort of an emergency announcement. So that's not really incident response, that 393 00:41:54,360 --> 00:42:00,000 sort of emergency management in the entire program. You know, the intrusion detection 394 00:42:00,119 --> 00:42:06,719 vendors will rapidly produce a signature for the vulnerability being exploited. You know, 395 00:42:06,760 --> 00:42:10,199 what bites have to come across the network to exploit it. You can put 396 00:42:10,199 --> 00:42:15,920 that in place to you know, see if you're being attacked. You might 397 00:42:15,599 --> 00:42:20,800 add even a drop the connection rule to your firewall. It says, if 398 00:42:20,840 --> 00:42:23,079 I see a packet comeby and match this signature, it's you know, called 399 00:42:23,159 --> 00:42:28,559 virtual patching. Even before a patch is available, you can hopefully prevent the 400 00:42:28,599 --> 00:42:35,599 attack propagating into the vulnerable system. You can take other mitigations. You can 401 00:42:35,639 --> 00:42:38,760 say, you know, that subsystem that has the vulnerability is not vital to 402 00:42:38,840 --> 00:42:43,119 operations. I'm going to disable it, you know, for a week and 403 00:42:43,360 --> 00:42:50,159 live without it until a patch is available, and you know, sort of. 404 00:42:50,280 --> 00:42:54,800 But more to your point, my guess is that if there's an incident 405 00:42:54,840 --> 00:42:59,719 in progress, well you've got to deal with the incident no matter how it 406 00:42:59,760 --> 00:43:04,239 got in. But at some point you want to find out how did they 407 00:43:04,280 --> 00:43:07,119 get in? Because once we've you know, shut everything down, cleaned everything 408 00:43:07,159 --> 00:43:12,079 out, we don't want to start it all up again until we know the 409 00:43:12,079 --> 00:43:15,000 bad guys aren't going to get in five minutes later. And so the forensic 410 00:43:15,239 --> 00:43:19,519 analysts, while we're cleaning things out, they are analyzing the data trying to 411 00:43:19,519 --> 00:43:22,800 figure out how did they get in? And you know, we have to 412 00:43:22,800 --> 00:43:28,800 design our systems so that these incident responders to forensic analysts have the information, 413 00:43:28,960 --> 00:43:32,360 have enough information to be able to figure out how this happened. And that 414 00:43:32,519 --> 00:43:37,559 means you know, detailed audit logs if we can on all of the devices, 415 00:43:37,639 --> 00:43:42,719 especially the Windows and the Linux machines, so we can see what did 416 00:43:42,760 --> 00:43:47,320 the user, uh you know, do on the compromised machine to bring about 417 00:43:47,320 --> 00:43:53,679 these these undesirable results, escalation of privilege or whatever. Some sites keep you 418 00:43:53,679 --> 00:43:58,639 know, networks, just keep packing, keep copies of packets on their networks, 419 00:43:58,679 --> 00:44:00,960 or keep copies of packets on their networks that came in through let's say 420 00:44:01,000 --> 00:44:06,639 the firewall interface, keep them for a long time. It means a huge 421 00:44:06,679 --> 00:44:09,800 amount of storage. But it does mean that in an emergency, you're a 422 00:44:09,840 --> 00:44:15,159 forensic team as a fighting chance of going back through those packets and trying to 423 00:44:15,199 --> 00:44:20,800 figure out where did you know, when did the attack come through, and 424 00:44:21,079 --> 00:44:23,400 you know, what did the attack look like, so that they can figure 425 00:44:23,400 --> 00:44:27,639 out, you know, what kind of vulnerability has been exploited here, and 426 00:44:27,679 --> 00:44:30,000 you know, report it to the authorities and put measures in place. So 427 00:44:30,719 --> 00:44:36,039 long answer, it's you know, this is sort of what what it means 428 00:44:36,119 --> 00:44:42,599 to be to have a security program and a response team aware of the possibility 429 00:44:42,679 --> 00:44:49,639 of zero days and especially the zero days in the CWE catalog. Well, 430 00:44:49,679 --> 00:44:52,440 Susan, this has been tremendous. I learned something, you know, I 431 00:44:52,440 --> 00:44:57,000 didn't even know that cwe's existed. Thank you for this. Before we let 432 00:44:57,039 --> 00:44:59,880 you go, can you sum up for us what is sort of the main 433 00:45:00,039 --> 00:45:01,760 messages? What's you know, what's the one thing we should remember from from 434 00:45:01,800 --> 00:45:07,119 this episode? Thank you Andrew. You know. The one takeaway that I'd 435 00:45:07,159 --> 00:45:15,679 really like listeners to to have is to be proactive instead of just being responsive. 436 00:45:17,159 --> 00:45:24,719 You know, if you look at the overall UHNST framework of being able 437 00:45:24,800 --> 00:45:32,039 to you know, detect and respond, I think it's really important to be 438 00:45:32,199 --> 00:45:42,639 proactive in in your overall cybersecurity program. Uh know your assets. I think 439 00:45:42,679 --> 00:45:47,679 that a lot of times, uh if the the larger the critical infrastructure is, 440 00:45:49,800 --> 00:45:58,440 the greater the chances that you don't know every single asset in your infrastructure. 441 00:45:59,320 --> 00:46:07,760 And then even more so triaging the assets based off of resiliency and having 442 00:46:07,880 --> 00:46:14,280 a focus on your end of life or legacy assets that are still in production, 443 00:46:15,000 --> 00:46:19,719 still connected to your network and because their end of life. You may 444 00:46:19,760 --> 00:46:25,199 not have had a patch even available to you or support of that asset available 445 00:46:25,239 --> 00:46:32,400 to you for some time, and it represents the danger of a zero day 446 00:46:32,519 --> 00:46:42,440 lurking within your infrastructure. And cwees give you that opportunity to really do a 447 00:46:42,519 --> 00:46:49,440 deep dive into those triaged assets to see if you've crossed all your t's and 448 00:46:49,480 --> 00:46:52,599 dotted all your eyes from a compliance perspective. Well, if any of the 449 00:46:52,920 --> 00:47:02,480 listeners want to get involved with the Miter cwe ICs Working Group, I encourage 450 00:47:02,519 --> 00:47:07,920 you to do that. It's a great group to get involved in. Also, 451 00:47:09,000 --> 00:47:20,920 reach out to your compliance service providers when you're looking at your compliance alignment 452 00:47:21,920 --> 00:47:29,440 and introduce this concept when you're looking at your vulnerability gap analysis and your asset 453 00:47:29,760 --> 00:47:35,199 inventory management, and feel free to reach out to me. I'm on LinkedIn. 454 00:47:36,480 --> 00:47:44,039 My LinkedIn is Susan Ferrell, so it's LinkedIn dot com for slash in 455 00:47:44,239 --> 00:47:50,239 for a slash Susan Ferrell, and I look forward to discussing any of these 456 00:47:50,280 --> 00:47:57,800 topics with you. Andrew. That concludes your interview with Susan. Do you 457 00:47:57,880 --> 00:48:00,199 have any final thoughts to take us out today? Yeah, Well, you 458 00:48:00,239 --> 00:48:05,719 know there's something new in my understanding the world. You know, cwe's common 459 00:48:05,719 --> 00:48:12,119 weaknesses. You know, they strike me as as more useful for mature organizations 460 00:48:12,119 --> 00:48:15,360 that are looking forward at what might come at them versus you know, less 461 00:48:15,360 --> 00:48:20,599 mature organizations that are just getting started. Strikes me as very useful for developers, 462 00:48:21,880 --> 00:48:24,320 you know, a long list of stuff to look for, to to 463 00:48:24,480 --> 00:48:30,639 watch for, to avoid when we are developing industrial products, you know, 464 00:48:31,079 --> 00:48:35,599 increasingly sort of as an aside. You know, a lot of modern developers 465 00:48:35,800 --> 00:48:40,079 are you know, thinking about problems like this, and they're using tools like 466 00:48:40,119 --> 00:48:45,280 you know, writing their their their products where possible in in you know, 467 00:48:45,400 --> 00:48:49,880 Java or other languages that just you know, Java managers memory automatically, other 468 00:48:49,960 --> 00:48:55,280 languages manage other kinds of things automatically takes entire sets of possible vulnerabilities off the 469 00:48:55,360 --> 00:49:00,000 table. But you know, the CBLB repository strikes me as you know, 470 00:49:00,039 --> 00:49:06,639 it reminds us of the potential for new vulnerabilities coming at us, especially in 471 00:49:06,840 --> 00:49:12,320 older gear whose developers weren't looking at their code this way, weren't thinking about 472 00:49:12,400 --> 00:49:15,119 all these kinds of things when they develop those products that a lot of us 473 00:49:15,159 --> 00:49:20,360 are still using. So a useful resource, okay, well with that, 474 00:49:20,480 --> 00:49:23,199 thanks to Susan Ferrell for speaking with you, Andrew, and Andrew, as 475 00:49:23,199 --> 00:49:28,159 always, thank you for speaking with me. It's always a pleasure. Thank 476 00:49:28,199 --> 00:49:32,519 you. This has been the Industrial Security podcast from Waterfall. Thanks to everybody 477 00:49:32,559 --> 00:49:39,159 out there listening