Exploited: The Cyber Truth,  a podcast by RunSafe Security. 

Paul Ducklin (00:06)

Welcome back, everybody, to Exploited: The Cyber Truth. I am Paul Ducklin and I’m joined for this episode as usual by Joe Saunders, CEO and co-founder of Run Safe Security. Hello, Joe.

Joe Saunders (00:19)

Greetings, Paul. Great to be here.

Paul Ducklin (00:22)

And very excitingly, as it happens, we also have Doug Britton, EVP Chief Strategy Officer and co-founder of RunSafe Security. Hello, Doug.

Doug Britton (00:36)

Thank you for having me.

Paul Ducklin (00:40)

And our title today is a broad, deep, and fascinating one. So there’s at least three dimensions, probably many more to it. And it is, “You Can’t Patch Your Way Out of This: What Mythos Means for the Future of Cybersecurity.” 

Now, those of you who are regular listeners will know that my role in this podcast is the host. In this episode, I’m not so much the host as, if I may use a bicycle race analogy, I’m the driver of the team car. I’m the guy who keeps the riders on course, hands out the water bottles, make sure everyone is on time and on target. Because this is a special episode because we have the co-founders of RunSafe Security. And RunSafe is, as Joe likes to say, an aptly named company that aims to help you run safe regardless. 

So listeners, imagine that you are a fly on the wall at a RunSafe strategy brainstorming session. Sit back, relax, and enjoy two industry experts as they get stuck into the history, the present, and, very importantly, the future of cybersecurity where we are running to get ahead, not merely running to avoid falling yet further behind. So without further ado, Joe, you’re up at bat first. Off you go.

Joe Saunders (02:10)

Well, thank you. Yeah. And, I think maybe the pressing question is not so much, you driving the race car, but are you actually the highly skilled and very, very talented prompt engineer to keep me and Doug going in the right direction? And I think that’s maybe apropos since we’re talking about the effects that AI has on cybersecurity. 

And what’s funny about it for me is it really kind of takes me back a few years because Doug and I, when we founded RunSafe, had a common bond about the economics of the cyber industry and cyber defense. And we have always shared the desire to look for those moments where there is an asymmetric shift, not only in the economics, but in the technology to develop resilience in software. 

And so Doug, think that is one of the most exciting things about Mythos coming out more recently is you know, our fundamental bond, our fundamental premise about RunSafe is playing out yet again in across the industry with AI entering the fold here in a massive way for cybersecurity. And I just think back to our founding story and what it meant for how we went about innovation itself.

Doug Britton (03:32)

Yeah, no, I completely agree because what we were trying to aim at is disrupting the underlying sort of hacker economics. And, you know,  just like everybody, hackers have finite resources. You know, we wanted to look at a set of problems when we undertook RunSafe that if we’re successful in disrupting their ability to weaponize this class of risk, it deprives them of an entire class of assets. So it’d be economically equivalent to if we’re able to take a class of risk that represents a big chunk of the attack surface and render that inert, it’d be economically equivalent to devaluing diamonds or devaluing gold. In an economic sense, that’s what we aim to do.

And if it’s no longer worth it to go mine for gold, because it’s all of sudden devalued, then people are not going to put their cognitive capabilities on developing these classes of attacks. And so we look at it and taking some of the attack methods that have previously been only the domain of the attacker, you know, polymorphism and dynamism and moving target defense. And we wanted to make those things accessible to the defender without them having to go to like, you know, cyber Hogwarts and become masters of all these other skills. We wanted them to be able to just drop this set of capabilities in. And I think AI has put a fine point on that because even though, you know, even if in a world where, you know, you can imagine that AI, you wave a wand and now you have this access to all of these vulnerabilities, you still have the problem of deploying and testing and that you’re still at very, problem that doesn’t scale very well. And so you still have some deep economic challenges there.

Joe Saunders (05:47)

Yeah, and you know, the economics behind that testing, the scaling, the deploying is particularly acute in critical infrastructure for a couple different reasons. Why,  you know, these are mission critical applications that, you know, rely on, you know, software to work with determinism on real-time operating systems. And so there’s a lot of expectation that systems simply work. Another aspect of that is that, you know, these are in safety-critical applications. You know, safety of flight, autonomous driving, these are, there is a dramatic consequence or a significant consequence if something goes wrong in these areas. And we know that cyber security can disrupt, you know, a cyberattack can disrupt a well-functioning system and cause something to go out of state or be unpredictable or fall into chaos or not be deterministic because you haven’t planned for the outcome potentially.  

Paul Ducklin (06:57)

And to be clear to everybody, when you talk about real-time, you don’t just mean fast. In fact, it could be slow. What you mean is dependable, predictable, deterministic, does the same thing every time, no matter what.

Joe Saunders (07:14)

Exactly right, and especially in infrastructure. So we need to know that the valve is going to open when it is supposed to open, you know, within milliseconds, because lots of things could be depending on the reliability of that happening within a certain time parameter. And so if that gets disrupted, then things can really go wrong. And so that brings to maybe the second side of the economic equation across critical infrastructure, which is, you know, it’s very, very difficult to apply a patch and take systems out of production when large-scale infrastructure is dependent on them. 

And so operators and infrastructure, you know, aren’t wanting to consistently apply updates on a regular basis. In some cases, they go several months without applying a patch. And so even if there is a cyberattack, how do you or even if there’s a new vulnerability and or known exploit that gets released, it’s very, very difficult to push updates out into the infrastructure. And I think that’s part of economics, Doug. I think it’s the testing that you say, it’s the certifications, but the patching process has its own set of economics just to reach the target systems. And those systems are ones that last for a long, long time out in the infrastructure. They’re not built to be replaced in a year or so, are they, economically?

Doug Britton (08:45)

No, you’re absolutely right. In the safety certified space, this would include like aviation and automotive, the typical heuristic is that to push a patch takes a year and $1 million at the least. And that’s because every time you need to push a patch, the volume of testing that needs to go into that patch is extensive, as it should be if it’s going to control a jet engine or a flight control system. You want it to be robust. So the challenge is, you know, this deluge, the tsunami of exploits that are now being publicized, is going to cripple the security of the safety certified systems, especially if you’re now increasing the volume of patches, not by one or two a year, but by 500x per year or a thousand times per year. Like this is, this is going to be devastating. 

And so, um, you know, you need things that, uh, you know, reset those economics again in favor of the defender so that you are able to have systems run reliably in, these safety certified spaces where, you know, there’s vulnerability, agnostic approaches that, you know, even if ones exist, they cannot, you know, they can’t be weaponized. So that’s what you know, our goal in the company wasn’t to just chase the next one volume. It was to render an entire class of cyber weapon assets, you know, inert and to solve the whole thing, not just one, cause it, the challenges of getting a company started and building it. It’s not interesting if you’re just doing better, like 5% better. You got to do, in my opinion, a thousand times better.

It’s got to be because otherwise you’re not going to survive the challenges of commercialization.

Joe Saunders (10:48)

And imagine the fear of a manufacturer who is subject to regulatory requirements or compliance requirements when they face, as you say, a tsunami or an exponential increase in vulnerabilities, and they still have to stay in compliance with their regulatory requirements and their compliance requirements. And so an organization thinks, oh, I’ll just counter AI with AI, or I will add more people to the problem because I have to solve it and I have to stay in compliance. So there’s this urgent need that is out there related to a surge in vulnerabilities and a need to stay in compliance. And therein lies the dilemma, the economic dilemma for a manufacturer who needs to ensure that their software remains resilient for these safety-critical and mission-critical systems. 

So I think you know, in part,  maybe this brings us to our second topic. And what is the state of the alternatives? And today, if I may suggest that there are other things people do inside,  you know, the embedded software ecosystem, they might be, you know, scanning, you know, their software, doing software composition analysis, they might be generating Software Bill of Materials in trying to identify and associate vulnerabilities associated with that. And they also might be doing static analysis to identify vulnerabilities. 

And I guess it’s our experience, Doug, and everyone we talked to, that those three disciplines, they have two problems with them. One is that the lines between those solutions are blurring, they’re starting to overlap, and AI is disrupting all three of them. And so they don’t have a defensible position that makes economic sense anymore. AI is going to undermine a lot of companies and the confidence of manufacturers in the space that will look for alternatives to identify vulnerabilities. So with AI entering the fold and these solutions already blurring, to me, the economic message is there’s probably a lack of differentiation and a race to the bottom on price.

Doug Britton (13:14)

Yeah, and I think unfortunately, you know, the industry is going to have a bunch of challenges around the fact that basically, you know, what we’re seeing now is that some software that’s nearly 30 years old, that the oldest example that’s been recently publicized in a series of announcements around Anthropic and Mythos, you 26 years old, you know, that software had undoubtedly been tested thousands of times and bugs remained. And, you know, this is going to be, you know, quite mentally disruptive. There’s, you know, a manager could look and give themselves a, you know, the illusion or the patina of comfort that because they’ve tested like, Hey, I’ve tested, I’m good.

And I think that we’re going to see, know, and our customers are already, you know, having conversations with us that that’s no longer actually a defensible position to say, well, I tested, I’m good. Well, yeah, if, you know, it’s clear, if it’s no longer resolved that, you know, testing equals found things, then the underlying principle of affirmative governance there is  undermined dramatically. And so, do you want, what is now the objective? Is the objective to say, I tested, I’ve covered my rear, or is the goal to say, I feel confident doing commerce? I feel confident doing commerce in a way where the pace of vulnerability generation and the time it takes to generate an exploit is falling.  No boss, we’re good. We can keep moving out with product releases. Well, I checked the box. We tested. We’re good.

Joe Saunders (15:19)

Yeah, 100%. I tested, and we’re good. And it reminds me of one of my favorite cartoon videos. And that is Wile E. Coyote Super Genius. 

Paul Ducklin (15:32)

Go ahead, Joe. I’m just imagining this.

Joe Saunders (15:32)

If we’re all sitting in a lab thinking, you know, we’re, we’ve got all the latest patches available and we’re good, or we’ve done all the testing and we’re good, we might be hit by that train and there could be a whole, you know, explosion of problems that could result. And so, you know, I just needed for my own inside joke to work in Wile E. Coyote. but I think the idea is maybe I can challenge you with this, Doug and say, is it organizations could do differently if they can’t patch, if scanning and testing is not good or sufficient anymore? I guess what are the options? And of course it’s RunSafe. They should just run safe. But if you go back to our founding principle and the challenges people face, if testing and scanning doesn’t catch enough of the problems and AI is the train that’s coming, what can people do is, I guess, one of the questions.

Doug Britton (16:36)

Yeah. And so I think you laid out the first couple of, you know, legs of that problem. If testing doesn’t find everything, patching is expensive and the amount of time, you know, there’s a kind of this, it’s assumption implicit and false that, you know, bad, you know, the, the attackers are not weaponizing the vuln until it’s known, which is a false assumption, then you’re like, you have this train of just bad assumptions and bad constructs around security. there’s a bug. You tested, all right, now there’s a zero day. Now you’ve got a patch. So you’ve got time between when the zero day becomes public and when you can patch, when you have a patch. So now that you have a patch, you’ve got to test the patch and then you’ve got to deploy the patch. 

Now, some operating systems, Windows and Android have, and Apple, for highly connected devices have, even those can’t keep up with the pace of exploit development, but they have a reasonable chance of being able to get a patch to a system. But for just about everything else in the world, the time between the patch being released after it’s been tested, etc., to when it gets on deployed systems is thousands of times longer than it takes to create an exploit. And with highly industrialized criminal elements that are able to get the exploit quickly and then get it deployed, you need something that is gonna take a whole of class risk off the table. 

So again, you need to be able to get rid of, you know, in an interpreted code universe and you get rid of all command, command injection, you need to get rid of all OS configuration risks. You’ve got to, you’ve got to figure out, look, you know, deliberately at how you’re going to do that, you know, in compiled code, you know, how you’re going to get a whole class, you know, memory risk off the table. Like this, trying to chase one bug at a time.

I mean, I don’t, I don’t know how somebody in good conscience tells the leadership of their organization, if they’re a fiduciary that, you know, this is we’re good in a, in a hunt and patch, you know, respond-based approach where, you know, we’re going to just try and patch our way out of this. And, and the number of attacks that have been coming up in the last couple of weeks are just, I mean, it’s just exploded into new areas of the economy that are stunning. 

Paul Ducklin (19:37)

Doug, would you agree that additionally, in terms of exploits against a system such as embedded systems, you’re generally much closer to weaponizing them, if you like, than you are for something, say, like an iPhone, because even a very basic, what will be unimportant on an iPhone vulnerability, like a denial of service, could put you out of specification for your real time response.

So don’t always need the same level of control that you would have to get with say somebody’s iPhone to spy on what they’re doing to cause an enormous amount of disruption. So it’s almost as though just finding the vulnerability alone is almost enough in some cases.

Doug Britton (20:22)

What product managers have previously relied on as a layer of sort of security, if you will, in the embedded and control system space is that the assertion that exploitation of those phones is harder. And thus, fewer people can do it. And that is no long, I mean, it wasn’t a valid assertion originally, but it is demonstrably less valid. 

Paul Ducklin (20:50)

No, it wasn’ If one person can do it, anybody can do it because that one person just has to tell the other people how to do it, right?

Doug Britton (20:59)

And sell it and just post it. So it’s just a demonstrably false assumption that weaponizing these is harder because now you can just ask AI to weaponize it for you and it will. So that’s a real challenge. And the problem is in the industrial control system space and the weapon system space, national security space, these systems simply are not updated with the same frequency. And that means the attacker, they’ve got years, they can plan their attack very patiently. So again, the need is for class risk reduction. That’s what product managers need to focus on. And if, if, if you’re looking at, I, tested, I’m good. I mean, that’s asking to be the next fodder for newspapers. So go ahead, Joe.

Joe Saunders (22:08)

Yeah, and you bring up national security and I think about nation state attackers and we have talked about many times a well-funded attacker group or you know, nation state can spend months doing preparation in the battlefield for getting on target, for perfecting their exploit, for ensuring they can deliver a payload at a moment’s notice and you know, historically, you know, those well-funded organizations would be very patient. And then once they’re on target, they could potentially detonate a cyber bomb at a time and place of their choosing, as you like to say, Doug. And that is true. We’ve seen infiltration of critical infrastructure over the years. But what I would say is a scary thought from an economics perspective then is in the hands of nation states looking to maybe exercise a cyber attack on critical infrastructure in another country, they are now also leveraging AI to their advantage. 

So they might find and identify vulnerabilities faster and they might develop exploits faster. And with that, yes, they might have to still do the preparation of the battlefield, but they might be able to distribute things sooner, faster and get on target in faster ways anyway. And so I think the economics are accelerating and there isn’t anything better in my mind than someone spending six months, 12 months planning for an attack and then suddenly the landscape changes on them and they don’t know why their highly reliable exploit now fails. And so I guess that’s part of the exciting thing here is you know, if AI is going to accelerate those nation states, it’s going to help condense some of the investment that they need to make as much as it does for defenders to figure out how to protect systems. And so with that, we still need a way to disrupt nation-states, even if they can accelerate their ability to execute an exploit in the first place.

Doug Britton (24:31)

Yeah, because they’ll be you.

Paul Ducklin (24:31)

Joe and Doug, do you want to say something at this point about where you think the market is going in particular, let’s say from the secure by demand angle, where the people who are buying devices are requiring security rather than just waiting for security and design? In particular, based on, I know you’ve done some market surveys recently to find out in say healthcare and automotive, what the market thinks about cyber security and how it’s prepared to pay for it and where it expects to come from.

Joe Saunders (25:10)

Yeah, I can take that. Yeah, I mean, Secure by Design, you know, we have even looked at market research where organizations who are buying devices, they might be buying those devices because it’s a hospital system and they’re looking to buy secure medical devices, or it could be energy infrastructure or utility, looking to buy devices that help make the infrastructure operate, like HMI devices or SCADA and ICS systems. 

And more and more, these organizations are expecting security to be built into their systems. And the Secure by Design notion is meant to arm the buyers of technology to know when and how to ask for security to be built in so that they’re buying highly resilient devices in the first place. And our most recent  Medical Device Cybersecurity Index report had shown that just in the past year,  there’s an increase of about 10%, from 45 % roughly to 55 % roughly of hospital systems have decided not to buy certain cybersecurity devices because they lack sufficient cybersecurity protections on those devices. And so I think the notion that organizations are expecting security to be built in is certainly helpful. 

And with that said, I do think that there’s a challenge with security changes in the ecosystem. And what I mean by that is if AI can produce or identify vulnerabilities faster than people can patch, as we’ve already discussed, and if it can identify and build exploits, perhaps even before people know the vulnerabilities exist, as Doug suggested, then there’s this sort of notion of how do you disrupt AI? How do you disrupt and mitigate vulnerabilities that are being produced at machine speed? And it’s very, very difficult, but I think, Doug, RunSafe has a unique position relative to that very question. And I would love for you to summarize that position.

Doug Britton (27:31)

Yeah, the whole posture, the underlying economic premise of RunSafe is we’re going to neutralize, we’re going to devalue an entire class of cyberattack assets. We’re going to render them inert and we’re going to do it without having to rewrite a line of software, by integrating and very simply without changing performance, without changing build tools or line of software, being able to add in something in compile time that makes it so that that whole class of things doesn’t work. 

As has been demonstrated, you know, by the numerous organizations that have redeemed it and analyzed it and still been satisfied with, you know, no measurable performance impact. It’s been exciting. So, you know, organizations have found that it does just drop into the build process in a way that has been seamless. You know, that’s, know, people don’t have to go retrain their developers, they don’t have to rewrite everything. It’d be, I mean, it’d be cheaper to rebuild all the highways in the US than it would be to rebuild, you know, all the software that powers the economy and get rid of these kinds of vulnerabilities. 

So that’s the proposition. And it’s so easy. And I mean, it is, we joke internally, it’s like right click easy. But, but that’s what our customers have found. And so again, the job is, the reason it’s economically sound is we’re not chasing bugs. People sometimes say, well, how are you getting bug updates? We’re not, we don’t need to know. We assume everything’s vulnerable. We protect the software exactly assuming every line’s vulnerable. But even knowing, even presuming that everything is vulnerable, you still can’t weaponize the attacks.

That’s the reshuffling of the underlying economic proposition. And it’s technically simple, it’s robust and it’s highly effective. It’s, you know, nothing else has been able to get through the certifications of how, of being safety certified for use in aircraft, for use in automotive. So, no, it’s that simple.

Joe Saunders (29:50)

And the normal reaction when someone says that AI is producing vulnerabilities at machine speed and developing exploits within hours of a vulnerability being identified, if not before, of course, before it’s released, if that is the fundamental shock to the system, AI is producing vulnerabilities at machine speed, the natural reaction is to say that I need to counter AI with AI.

But what you have explained, Doug, is kind of the foundation for why I have conviction that only RunSafe can mitigate vulnerabilities at machine speed. Why? Because we mitigate it before AI even identifies it and before the exploits even written. And so in my view, the best approach to counter AI is to cut it off at the knees to prevent it from actually working when RunSafe or other technologies like RunSafe are applied and eliminate the class of vulnerabilities as opposed to, as you say, chase the vulnerabilities. And so it becomes exhausting. And imagine it’s almost like spy versus spy or AI versus AI or the cold war, the cold war of cyber domain, AI versus AI is a losing battle, and whoever has the best AI is going to win.

That is why I think this story gets elevated into technology competition between nations. But more importantly, though, that’s why I think the fundamental question of economics plays a role in this, in that you can’t just rely on countering AI with better, faster AI. It’s a losing proposition. It’ll be, you know, there’ll be back and forth, but I think it’s a long-term losing proposition that only the quality of software will suffer. And so in my mind, if you can eliminate 70%, 80% of the problem that AI produces or identifies and wishes to exploit, then you have a much greater chance of countering AI with AI when you take off the table a majority of the vulnerabilities in the first place. And so in that regard, I think we’ve come full circle around the economics of it.

You can’t just be in a race to have better, faster AI systems and mitigation responses. You need to take some kind of asymmetric shift that counters AI with something that is not AI. And that is almost counterintuitive. Everybody’s gut reaction, initial reaction is to apply AI solutions to counter AI. And I think that is something that needs to be explored in more detail by everybody. How can you disrupt AI in a way that renders it inert for a majority of the vulnerabilities that it wishes to identify.

Paul Ducklin (32:51)

Joe, that’s what’s known in the jargon as RASP, isn’t it? Runtime Application Self-Protection. And it’s a little bit different from what you might do on Windows where you just add a sea of EDR and extra software around it. You’re basically taking the software as it was written so that it’s still compliant, it’s still the same source code, but delivering it in a way that means that any attacks that have been done against it or are being done against it at the moment are basically a kind of rendered moot and the bad guys have to go and start again as you say removing 80 % of the problem giving you plenty more time to deal with the 20 % of the things that you really should be worrying about.

Joe Saunders (33:34)

Yeah. And what we’ve talked about earlier and what Doug spelled out and your question around reliability and determinism in real-time operating systems becomes vitally important because RASP actually could have some negative connotation for a number of people in that you might be relying on some kind of software agent or some kind of additional logic on device that might slow it down or change its behavior.

Paul Ducklin (33:41)

Yes.

Joe Saunders (34:02)

Or alter and those options are just not viable in safety-critical emission-critical applications. It’s just not allowed because you need to have determinism in the way that the autonomous system operates or the aviation system or the flight control software operates. And so you can’t just easily add new software agents, software components because it changes behavior. 

And then as Doug spelled out earlier, the other problem is you can’t necessarily increase the hardware. You can’t introduce something that affects the performance, the system response time, and the memory required for the system to operate. Some of these devices are relying on low power, low CPU, and they’ve been out there for years and years, if not decades. And so you can’t just add software to those devices, additional software and expect them to be protected. Why? Because they won’t behave the same way and they might run out of system utilization and have an unacceptable increase in system overhead. And so, the trick is how do you do that without adding new software onto a device? And that is precisely what RunSafe has mastered.

Doug Britton (35:24)

Yeah, it’s sort of an analogy that I use from time to time. It’s sort of like the spider that bit Peter Parker. So it rewrites his DNA. If Peter Parker is your friend, the day after he got bit, he doesn’t look like a different person. He’s just still Peter Parker. But now his DNA has this extra muscle tissue that, I know I’m mixing metaphors there, but has this extra capability so that he’s able to respond under duress. But when things are normal, it’s just the same old kit. But it’s when under attack, there’s new abilities built in that without changing him, he’s able to respond. And so that’s what we do. But to the developer, it’s a non-change. And they don’t have to change the readability of their code. They don’t have to change the complexity of the code, add new functions, add new variables, like restructure things and that’s why this works.

Joe Saunders (36:29)

So Doug, if you had a magic wand and could paint a perfect world for cybersecurity, what would that include?

Doug Britton (36:40)

Well, puppy dogs and unicorns. so, you know, I…

Paul Ducklin (36:47)

Don’t start singing Doug, whatever you do.

Doug Britton (36:51)

Well, that’s too bad. We, our house, we love Hamilton. So we’d like to be in the room where it happened. So what, no, what I would be excited about is, you know, turning on, you know, for embedded device for hardware, you know, you’d want secure boot. You’d want to, to be able to have confidence. You’d want to understand the entire attack chain. What is an attacker trying to do? They’re going to try and get on your device. They’re going to try and maintain persistence. They’re going to try and get predictable interruption of execution. And they’re going to try and use a footprint. They’re going to surveil your system. So you’re going to want to think about each layer of the attack of the kill chain and figure out how you can disrupt each one.

You’re going to want to disrupt their ability to get persistence. You’re going to want to disrupt their ability to survey the system from a standoff range. You’re going to want to be able to disrupt their ability to send packets at it and have it behave the way they expect. So, you know, I think, and that what that looks like is going to vary for different software systems. But it’s, but I, I, it’s a mistake to think that you can do just one thing and have disrupted the attacker. Attackers are resilient, they’re aggressive, and if there’s something of value, they’re gonna figure out how to come at it. And so you wanna look at each, I would look at each step of the attack of a kill chain and figure out how you can deprive, make their job harder at each point.

Joe Saunders (38:35)

And I couldn’t say it much better. I would want to add maybe one or two items. And that is in the build process, if you can understand the extent of the vulnerabilities and whether an attacker can reach those vulnerabilities, so reachability, and know if it’s exploitable. When you first identify those vulnerabilities, what’s the reachability, what’s the exploitability of that software so that you can help prioritize the things that you do need to mitigate. And when you can take off the table based on reachability and exploitability, 70, 80% of the problem and focus in just on the limited ones that you need to worry about, then the economics are far better. 

The other angle to that in my mind is when I think about static analysis, the problem I see is that it misses a lot of vulnerabilities and it creates a lot of false positives and people end up turning on and doing static analysis, they end up chasing and wasting a lot of time. So static analysis is not going to survive in an AI world in part. And at the same time, I don’t think generalized large language models, even if they’re good and built around good code bases, do necessarily and inherently understand reachability and exploitability. 

And so if there’s sort of a perfect world in between AI identifying vulnerabilities and static analysis identifying vulnerabilities, it’s something that identifies vulnerabilities that are both reachable and exploitable. And knowing the difference between when certain ones are not reachable and ones are not exploitable so that people don’t waste any time. I think that is the formula for reducing the overall cost of economics or the economic cost to support these embedded systems. And so in my mind, that is the additional area that I hope somebody comes out soon with a solution to identify only the ones that matter and the ones that are exploitable and reachable can be worked themselves instead of a big mess of vulnerabilities that could just waste people’s time.

Paul Ducklin (41:04)

Joe, I think that makes a fantastic point on which to end, because what you’ve made clear, both of you have made clear, is that although we can and should use AI to fight AI, it’s not just a question of continuing the old battle and letting it go on more and more. We can and should work harder if we wish, but we absolutely have to work smarter and differently because just chasing patch after patch and just running to keep up is absolutely, it’s never really worked. And in a Mythos-enabled world, I think everyone has now begun to realize that. 

So, Doug, where should people go if they want to find out more about the tools that RunSafe can provide?

Joe Saunders (42:00)

Well, Doug lives in Maryland and you should probably visit him at his house. But if you don’t want to do that, you can find all of us at RunSafeSecurity.com and learn about the best ways to disrupt cyberattackers and to work faster than AI trying to introduce vulnerabilities at machine speed. So RunSafeSecurity.com.

Paul Ducklin (42:28)

So thanks so much, Joe and Doug, for your passion and your deep knowledge and concern and willingness to take us to a better world if you like. That is a wrap for this episode of Exploited: The Cyber Truth. If you enjoy this podcast and find it useful, please like and share us on social media. If you listen to us on a podcast feed.

Why not leave us a nice review so we can get the message out to get more people listening and more people taking this sort of thing seriously. And thanks to everybody who tuned in and listened. And remember, stay ahead of the threat. See you next time.