In this episode of Modern Cyber, Jeremy sits down with Joe Saunders, CEO of RunSafe Security, to discuss what it to takes to prevent attackers from exploiting vulnerabilities.
In this episode of Modern Cyber, Jeremy sits down with Joe Saunders, CEO of RunSafe Security, to discuss what it to takes to prevent attackers from exploiting vulnerabilities. Joe highlights the prevalence of memory safety issues across critical infrastructure and discusses how RunSafe's unique technology offers a seamless solution without the need for hardware or code changes. With insights into the challenges of vulnerability management and the evolving threat landscape, this episode provides valuable perspectives on the future of cybersecurity.
About Joe Saunders
Joe Saunders is the CEO of RunSafe Security, a cybersecurity company specializing in protecting critical infrastructure against memory-based vulnerabilities. With an extensive background in cybersecurity, Joe leads RunSafe in its mission to make the world a safer place by fundamentally changing the economics of cyber defense.
RunSafe Website - https://runsafesecurity.com/
Joe Saunders Linkedin - https://www.linkedin.com/in/joesaunders/
Jeremy Snyder (00:00.734)
Hello, welcome to another episode of Modern Cyber. I am thrilled today to be joined by somebody who comes from a little bit of a different background than some of our recent guests from a field that is emerging in the cybersecurity space, but is super important and critical. And I think we're going to learn a lot from today's conversation. I am delighted to be joined today by Mr. Joe Saunders. Joe is the founder and CEO of Run Safe Security, a pioneer of cyber hardening technology for embedded systems, devices, and industrial control systems.
Joe leads a team of former US government cybersecurity specialists who know how attackers think about problems, how they weaponize attacks, and how they choose their targets. A 25 -year veteran of many leadership and cybersecurity roles, Joe is on a personal mission to transform cybersecurity by challenging outdated assumptions and disrupting the economics that motivate hackers to attack. That is a lot to dive into there, Joe. Thank you so much for taking the time to join us today.
Joe Saunders (00:56.75)
Thanks, Jeremy. It's great to be here. I look forward to the discussion and look forward to chatting with you.
Jeremy Snyder (01:02.142)
Awesome. Awesome. Why don't we just kick things off with a little bit about RunSafe? I know it's a company that has been around for a number of years now, but maybe not everybody in our audience will have heard of RunSafe. So why don't you just provide a little bit of background to help us, help us know a little bit about yourself and your organization.
Joe Saunders (01:18.126)
Sure, RunSafe is set out to protect critical infrastructure from cyber attacks. And we do that by protecting the software itself that is deployed, whether it's in data centers or energy facilities or on airplanes or even on weapons systems, we are protecting software and doing it in a way that kind of matches our early vision for the company. And that is to fundamentally change the economics of the cyber attack. So...
We know attackers spend hours, weeks, months planning attacks, reverse engineering technology and doing other things. And what we set out to do is even if the attacker gains entry to a target device, we want to prevent their exploit from working in the first place. So unlike most cyber tools that are looking to identify vulnerabilities and perhaps fix them, we want to prevent the exploit from working in the first place. And so from that regard, it's been a wonderful ride.
because I work with fantastic people, folks that came out of the NSA and other places to do great work, both understanding exploit research and also asymmetric cyber defense.
Jeremy Snyder (02:30.046)
Awesome. So there's a couple of things that I'd like to just dive into there, even just from that brief blurb. So one of the things that you mentioned is something that I think we hear a lot about, which is about, you know, kind of prioritization of how we attack cybersecurity, right? So almost every organization that I've worked with over my entire career has had more cybersecurity problems than they have resources to deal with those problems. And so...
you know, I spent some time working in the vulnerability management space, I looked at cloud security, etc. And, you know, the same was true again and again in those organizations. And so it was, let's find these vulnerabilities, let's eliminate them, let's maybe shift left our thinking so that if we're doing things in an automated fashion, we can kind of work these vulnerabilities out of our system designs before things go live. But you said something in that little intro there that I want to dive in on and make sure we understand.
for both for myself and for the audience, which is that even if we find the vulnerabilities, the attacks won't work. So help us understand what does that mean?
Joe Saunders (03:33.102)
Well, so again, in the first place, a lot of focus is put on shift left and helping developers resolve vulnerabilities and weaknesses that are in code. And of course, that is a necessary step and it's certainly the best approach to build security in to adopt secure by design practices and the like. But what's proven over the years, you could go back 30, 40 years.
attackers still find ways to get onto devices, into systems, inside networks, they learn how to gain access. And so our fundamental assumption at RunSafe is attackers will gain access, but we want to prevent their exploits from working, even if they do gain access. And the way we do that is novel, and I'm sure we'll go into that in a lot of detail, and I'm happy to go into it now even. But the fundamental premise is that
Jeremy Snyder (04:07.806)
learn how to gain access. And so our fundamental assumption is that we need to be able to do that.
Joe Saunders (04:29.966)
If you are an attacker and you reverse engineer software, you rely on the same determinism that software provides to all the system it deploys on. I think the great promise of software is if you build a million copies of the software, of a code base, it works identically on all one million devices. And that determinism is great. If it's an airplane, with all the same inputs, you get the same outputs.
Jeremy Snyder (04:52.83)
Yeah.
Joe Saunders (04:58.126)
But from the attacker's perspective, that determinism also works in their favor. If they find a weakness or a vulnerability in a single instance of that software, they can build an exploit that will take out any of the airplanes in a fleet or the drones in a fleet or the vehicles in general. And so, our approach is to employ moving target defense in the software memory itself.
so that even if there is a weakness in the code at runtime, it can't be exploited because the attacker can't find it.
Jeremy Snyder (05:33.854)
Gotcha, so if you're saying like, hey, normally the software uploads something into memory space, ABC123, and the hacker relies on this bit of running software code being at memory space, ABC123, it may not be there. It will still be executing its proper function as we expect the software to do, but it might be doing that at PQR789 instead of ABC123 if I'm understanding you correctly.
Joe Saunders (06:00.366)
100 % right, and every time the software loads, all those functions go into different locations uniquely every time, when run safe is applied. And so the benefit then is that a attacker can't build the reliable exploit in the first place to work.
Jeremy Snyder (06:16.766)
Gotcha, gotcha. So I know that there has been some recent discussion around some of these exploits and some of the ways that exploits are, you know, exploiting the vulnerabilities in some of this software code up to the point of making some headlines and there being some recent cybersecurity advisories and recommendations from the likes of FBI Director Christopher Wray, Assistant Director Jenny Easterly, NSA Director Paul Nakasone with some recent testimony in front of Congress about a
about the Chinese threat to US critical infrastructure. What can you tell us about that? What was all the noise? What was all the news? What are some of the implications?
Joe Saunders (06:56.718)
Well, the underlying problem that they're identifying has been out in terms of software weaknesses, has been out there since the late 1980s, early 1990s. However, in November of 2022, the NSA issued guidance suggesting that those who deploy software across critical infrastructure need to achieve memory safety. And it was that guidance from the NSA that sort of...
started the ball moving in a pretty aggressive way. First, the Office of National Cyber Director got involved and said, you know, part of our national cybersecurity strategy, we must achieve memory safety in software, which I can explain. But it went from there. CISA rolled out secure by design and included memory safety principles in there. Congress has funded programs to apply memory safety protections. And the DOD is developing policies in this arena.
All that has happened in the past 12 months. And the reason why is because China is in US critical infrastructure. And so the testimony before the select committee on PRC just a couple of weeks ago that you referred to was all about the fact that if China decides they want to administer an attack, they already have access to US critical infrastructure. So the point is,
the US is vulnerable to Chinese cyber attack. And from a run safe perspective and from a national security perspective and just business continuity in a normal well -functioning society, we really want to ensure that those attacks are not successful. And so I think what Director Ray, Director Easter Lee and Paul Nakasone were suggesting and sharing with Congress was this is a real threat with immediate horizons.
Jeremy Snyder (08:46.206)
Gotcha. And so if we think about this across critical infrastructure, I tend to think about critical infrastructure as being really difficult to kind of manage for a number of reasons. One is that these are a lot of systems with, you know, embedded Linux versions, or they might be systems with even like even more restricted operating systems that aren't a full kind of, you know, let's say interact.
Joe Saunders (08:46.83)
It could be in the next two, three, four years something like this could take place.
Jeremy Snyder (09:16.062)
operating system. So when we think about that, coupled by the way, within, you know, thousands of normal PCs and hundreds, if not thousands of workers, so you've got this kind of like, very heterogeneous environment with everything under the sun, from a both a technology and a process and people perspective, kind of falling under it. How do we think about addressing that threat and addressing that vulnerability? Because I know a lot of these systems,
are let's say like not frequently patched or updated. And when we think about vulnerability management, that usually is the solution to the problem is like, Hey, let's get the latest patches. Let's apply the latest fixes. Maybe there's other things we want to do, like let's say micro segmentation and controlling blast radius for any particular event and so on. But when we think about such a diverse heterogeneous environment that might span multiple geographies, et cetera, what are some of the core recommendations that you guys think about over at RunSafe to help?
people who operate those systems keep them safe.
Joe Saunders (10:17.71)
Well, it's multifaceted for sure. And as you say, it's a hodgepodge of technology. It could be real -time operating systems. It could be embedded Linux, applications built on embedded Linux. These are OT networks that are really there designed to make infrastructure work. It's not like IT systems, which may be web -based and may be web technology -based tools with languages written in Python or Java.
A lot of the code, because it's been around for so long and because it's hard to patch, it was written 10, 20 years ago. It was written in compiled native code languages like C and C++. And those languages have inherent vulnerabilities that folks like attackers from China or other places, they really understand how to find the weaknesses in those codes and attacks. So...
Our recommendations have been pretty consistent with what the government wants to do as well. We need to achieve memory safety and compile code in C and C++. And we need to eliminate the ability for those attacks to happen. But to do that, what we recommend is really taking an inventory of all those assets, as well as generating a software bill of materials on those assets, identifying the vulnerabilities, and then finding which devices...
have the most attack surface exposed to these kinds of attacks and addressing them with solutions that eliminate entire classes of vulnerabilities. And naturally that's where RunSafe fits is we eliminate entire classes of vulnerabilities, whether the vulnerability is known or unknown. And we do that by adding in our software memory protection. So if you take an inventory of assets, identify the software bill materials, identify those vulnerabilities, prioritize those systems you want to.
Jeremy Snyder (12:04.062)
So if you're just picking it up for your best bet. Yep.
Joe Saunders (12:12.366)
address and then apply protections that work independent of all the many different applications, operating systems, chip instruction sets, and all the variations that those hodges of technology have, then we have a semblance of a way to address the issue without consuming a lot of resources.
Jeremy Snyder (12:33.086)
And when we think about that exact kind of approach towards implementation, what should people know about where RunSafe works? Like what are, you know, basic system requirements, not in terms of, let's say the hardware and the performance aspect of it, but in terms of compatibility, where can customers think about deploying RunSafe?
Joe Saunders (12:52.462)
Yeah, really, it's any of your devices that are deployed in critical infrastructure that are written in native code, written in C and C++, that work on a wide variety of operating systems, Linux, VxWorks, Lynx, GreenHills, and variations of all of those across instruction sets. So if the chips are Intel -based,
you know, that works just as well as ARM -based 32 -bit or 64 -bit, you know, processors and the like. And so what that means is it's a, it's, you know, really 95 % or more of the software deployed in critical infrastructure kind of fits that broad category, even though I gave real specific technology. And so as a result, that's, you know, that's what's happening is, you know, that software is exposed. But the good news is there are things that we can do about it. We can...
Jeremy Snyder (13:26.206)
Okay.
Jeremy Snyder (13:40.222)
Yeah.
Joe Saunders (13:51.022)
apply RunSafe into the build process of that software so that all future vulnerabilities, whether known or unknown today, can be protected.
Jeremy Snyder (13:51.166)
Yeah.
Jeremy Snyder (14:02.238)
And if I think about kind of the methodology that you're talking about in terms of protecting these platforms, it occurs to me that this is kind of a different approach towards vulnerability management in a sense that it is, it's not, let's say, eliminating the vulnerabilities by applying the standard patching and update and upgrade and so on, where, you know, historically there have always been challenges around.
whether a patch might break a piece of functionality and so on, and, you know, compatibility with third party components and things like that. We're, what you're suggesting is really just kind of like, Hey, here's a completely different approach. You don't need to patch or upgrade because we know that those things might break your systems. What we've got here is something that'll take your existing systems and kind of just say like, look, they're a moving target. As you said earlier,
And so these exploits that could potentially be deployed against these systems, the likelihood of them failing goes up. I don't know what the percentage is, and you can talk about that if you'd like to. But really, that's kind of the approach that you're talking about here, if I'm hearing you right.
Joe Saunders (15:09.71)
That's 100 % the approach. And I think the patch, the fixing and patching cycle, some of our customers have identified over four years worth of fixes and patches they need to implement. And that timeline means that they're exposed to those same vulnerabilities in that period. So if we can dramatically reduce the timeframe and smooth out the patching process by virtue of preventing attacks from happening,
on those vulnerabilities in the first place, then not only do we save time, but we kind of save that critical crisis moment from folks. But with that said, just to touch on it, we work closely with North Carolina State University, who has done a fair amount of research on scanning tools, identifying vulnerabilities in Linux -based applications, and even the Linux operating system and other open source software.
You know written in C and C++ languages and the problem is even worse than just finding ways to patch and fix scanning tools do not do a good job of Identifying the vulnerabilities that are memory based vulnerabilities in the first place what North Carolina State University found is at least 80 % of the vulnerabilities that Get disclosed were never previously identified by a scanning tool in the first place
Jeremy Snyder (16:22.942)
Yeah. Yeah.
Joe Saunders (16:36.302)
And so scanning becomes really an inventory of things that you have, of known vulnerabilities that you have patched or not patched. And in today's world, what people also need to think about is how they are exposed to future unknown zero -day vulnerabilities that can be compromised today, because we don't know the vulnerability exists in the first place, but the adversary or the attacker does.
Jeremy Snyder (17:00.67)
Yeah.
Joe Saunders (17:01.71)
And so we've been working with a lot of researchers to help identify those problems. And I think that's kind of fascinating. How can you assess your code to identify future zero -day potential and find ways to reduce that attack surface at the same time?
Jeremy Snyder (17:20.766)
And I mean, aside from using something like what RunSafe is doing, how can you identify what your future state, you know, attack ability is?
Joe Saunders (17:30.606)
So in the case of memory -based vulnerabilities, which really are the result of software weaknesses that allow the attacker to take remote control of the system, what you can do is, and without geeking out too much, there are ROP gadgets, and these are return -oriented program gadgets that attackers look for in code. And when they find a couple of gadgets, they can string them together into a ROP chain.
Jeremy Snyder (17:52.286)
Okay.
Joe Saunders (18:00.206)
and build a reliable exploit. So we've been working with researchers to identify how you can expose where ROP gadgets exist in compiled code. And that's the groundbreaking kind of breakthroughs. There's a group we're working with to do that now. And the whole idea is to use that to then say, how exposed am I not only to the known vulnerabilities today that I haven't patched, but the unknown ones in the future?
Jeremy Snyder (18:01.584)
So we've been working with researchers to identify how you can expose where rock gadgets exist in compiled code. And that's the groundbreaking kind of breakthroughs in the group.
Joe Saunders (18:29.326)
And so, naturally, I think that has tremendous implications because if you think about like a DoD weapon system, scanning tools today don't do a good job, like I said earlier, of finding underlying vulnerabilities in proprietary code, purpose -built for such things as weapons written in native code languages like C and C++. Scanning tools just don't do a good job. But...
Jeremy Snyder (18:31.678)
Right.
Joe Saunders (18:56.302)
Do you think the DOD is satisfied with understanding their underlying risk by relying strictly on scanning tools alone? So the answer is no, obviously. What do they do? They do other things. They might do penetration testing and invest in red teams to identify those weaknesses. We're looking for ways to automate that as well.
Jeremy Snyder (19:07.166)
Yeah, yeah. Yeah, yeah. Yeah. Yeah. Interesting, interesting. It's one of those questions that I think like, you know, I often get asked the question, how much is enough security? And it's one of the hard questions to answer, because ultimately,
You know, the answer is, of course, it depends. And it's such a dissatisfying answer to so many people, myself included. And I've heard so many different people taking various approaches towards it. I previously I interviewed three people who had written books on threat modeling.
And they'll always say, Hey, look, you have to rewind all the way back to identifying what your threat model is. And that comes down to identifying, you know, what type of organization you are, who might want to be after you. What are your physical controls? What are your logical controls? Who are the people working for your organizations? What are the risks that they might present as insiders, et cetera. And they want to take this very kind of holistic step -by -step approach to go through every stage of an organization.
Joe Saunders (19:52.046)
Thank you.
Jeremy Snyder (20:14.814)
and then design a defense strategy that aligns towards where they think the highest risks and the highest threats are. And it makes a lot of sense on paper. The challenge that I see with it in the day to day is that nobody steps into an organization that they can start from zero and go back that far and design the threat model. Everybody steps into a running organization that's already up and running and has operations and might have
products and technologies and systems and customers and you know, it's the active runway problem, right? It's where you've got all of this stuff going on and you can't shut down everything to try to then reverse engineer what your threat model is and deploy a security defense against it, meanwhile shutting off things for X number of months until you do that. And so when we think about
Vulnerability management, I've seen a lot of dissatisfactory approaches on that side as well. But I think what you guys are proposing is really quite interesting and quite a different approach. I'd be curious, what can you share with us, if anything, and I know you may work with customers that are in sensitive areas like critical infrastructure, but what can you share with us about what some of your customers have experienced in using RunSafe?
Joe Saunders (21:28.75)
I think the biggest thing is that the entire class of vulnerabilities that I've been describing, the memory safety related issues, are comprised about at least 70 % of the vulnerabilities in compiled code deployed across critical infrastructure. So if you take an approach where you can eliminate the exploitation of 70 % of the vulnerabilities, imagine what that does to help optimize your threat models and your program.
Jeremy Snyder (21:34.206)
Yeah.
Joe Saunders (21:58.222)
You know, it has a dramatic savings both in terms of a tax surface and operational cost savings. And so I think those methods are all really good to help clarify how everybody talks about what they're trying to stop. But in critical infrastructure, what the NSA said, what the Office of National Cyber Directorate, what FBI director, director E .C. Lee from CISA have all said is we must prevent attacks.
Jeremy Snyder (22:05.214)
So I think the methods are all really good to help clarify how everybody talks about what their trying to stop. But in critical infrastructure, what the NSA said, what the Office of the National Security Director, FBI director, director of the ESU, have all said is we must prevent attacks on U .S. critical infrastructure and specifically solve the member safety issues across critical infrastructure. So, you know.
Joe Saunders (22:27.054)
and US critical infrastructure and specifically solve the memory safety issues across critical infrastructure. So, you know, I'm working on that guidance and finding ways to make that an easy way for our customers to deploy. And our customers do deploy easily. So you can deploy our technology in 15 to 30 minutes, and you can run our technology every time you do a software build and have the security protections built in. So it's very easy to deploy. And also,
Jeremy Snyder (22:34.942)
I'm working on that guidance and finding ways to make that a way to support our customers to deploy. And our customers do deploy easily. So you can deploy our technology in 15 to 30 minutes. And you can run our technology and turn it into a software build that has a security package built in. So it's very easy to deploy. And also, you don't have to change hardware. You don't have to change software. There's no impact on functionality. There's no impact to system overhead.
Joe Saunders (22:56.302)
You don't have to change hardware. You don't have to change software. There's no impact to functionality. There's no impact to system overhead. We have customers working on big, massive engine controllers that have lots of compute power and processing power. And we have highly constrained small devices that have maybe one chip and not a lot of parallel processing or anything else. And we can still deploy on that limited.
power constrained device without changing system overhead or performance or requiring any new hardware.
Jeremy Snyder (23:29.598)
I mean, I think those last couple of sentences that you described there just really encapsulate a pretty strong value proposition. So if you think about that, you don't have to change devices. You don't have to change your code base necessarily. You don't have to change the running systems other than to kind of add this component in. Yeah. And I think that's, that's really a great benefit to people using that. I thank you for sharing that.
You mentioned something in there that I want to just make sure we don't leave this conversation without explicitly talking about, you know, the guidance that came out after some of that testimony. I know there was a release, I don't know if it came specifically for the White House, but it was something around encouraging the use of memory safe languages. Maybe you can, I'm sure you followed it a little bit more closely than I can, and I'm sure you can share with the audience exactly what that mandate, executive order, I'm not sure exactly what to call it is.
Joe Saunders (24:23.63)
Right, so memory safe languages are modern versions of code such as C and C++ that don't have the same inherent weaknesses that attackers rely on today to exploit embedded software across critical infrastructure.
Jeremy Snyder (24:26.686)
what it was and actually just explicitly what our memory safe language is.
Okay.
Joe Saunders (24:49.806)
Now, what the guidance says from the NSA and what the Office of National Cyber Director is and CISA are also promoting is the adoption of memory safe languages. And of course, run safe supports, we've been using memory safe languages like Rust and Go and other languages ourselves internally to protect some of our code bases. But the guidance goes further and says, well, product manufacturers, device manufacturers,
you know, folks like Schneider Electric and Eaton and Siemens should all rewrite all their products in memory safe languages. And of course, the challenge for those organizations is they have thousands of products that might have 10 to 30 year lifespans. And for them to invest all the time to rewrite their products in memory safe languages today is nearly an impossibility. You know, there's no corporation that can justify
Jeremy Snyder (25:42.398)
Thank you.
Joe Saunders (25:47.534)
simply rewriting a thousand products in a new product language just to be more secure. So, you know, it is that for that reason, we think RunSafe is a great alternative for people. You can achieve memory safety without rewriting a single line of code, but it goes beyond just rewriting. So a lot of these systems, even in critical infrastructure, are using 40, 50, 60, 70, 80 % of their code is open source software also written in C and C++. And that...
Jeremy Snyder (25:53.31)
So, you know, it is, for that reason, I think one thing.
Joe Saunders (26:17.326)
As you mentioned, compatibility issues, if you update one component, you may have an effect on other items in your software image. And so, our premise is you don't have to rewrite any code, you don't have to change, affect versions based on dependency trees by swapping out new open source libraries or components. You simply apply the software memory protection to the existing code.
Jeremy Snyder (26:26.622)
Yeah.
Joe Saunders (26:46.638)
and you get all the benefits without rewriting and without the incompatibility.
Jeremy Snyder (26:51.166)
Awesome, awesome. And then the guidance that came out, what was that specifically saying?
Joe Saunders (26:56.238)
So in November of 22, the NSA said implement memory safe languages or other mitigations to solve for memory safety. The Office of National Cyber Director came out with its recommendations for open source software and basically said, you know, also rewrite or implement. And then CISA has been the most comprehensive. CISA rolled out secure by design, which has a bunch of features.
Jeremy Snyder (27:02.526)
or other mitigations to the control program. Okay.
Joe Saunders (27:25.358)
to include achieving memory safety in the software that you write. But some of the things you alluded to earlier, things like shift left and build security in, do the automated testing and everything else in all your releases to ensure that the code you release is free of defects in the first place. And that would be great, but we just know that defects don't just magically disappear, even with the best of processes.
Jeremy Snyder (27:29.15)
Yep.
Jeremy Snyder (27:48.574)
Yeah, and I mean, even with the best of coders, defects don't disappear. And very often it can take years for defects to be found. I think we've seen recently last year, you know, the largest, what I would call the largest single incident of the year, although calling it a single incident is kind of difficult, but MoveIt file transfer software from Progress Software was kind of the largest single attack surface, if you want to call it that, across the year.
And it was thousands of organizations breached. And it was the kind of thing where the software had been out in existence. This version of the software had been out in existence for years. And, you know, it took a lot of effort for the, the criminal organization that figured out the exploit to find it. But again, it was years later. It was years after the fact. So, um, I think, you know, secure by design, all of those things, they're well and good, but they may not.
for zero days that are discovered many years after the software is released. This is one of the challenges around, one of the many, many challenges we face around software security in our fast evolving world.
Joe Saunders (28:55.904)
Yeah, I like to say, you know, so my youngest daughter is 17 years old and she'll be going to college in the fall. And there are vulnerabilities and exploits out there that are at least the same age. So apparently they're ready to go to college as well. They're growing up to be adults and have been around 15, 17, 18 years. And, you know, and maybe they'll wreak havoc for longer.
Jeremy Snyder (29:13.566)
They're ready to go to college.
Jeremy Snyder (29:19.038)
Yeah.
Yeah. I mean, look, the, when I started in cybersecurity, my very first or second job out of university was pretty focused on cybersecurity with the organization that I was with. We went through pen testing. We went through many other things. We had to pass a clean bill of health in our, you know, from our pen test results for a lot of our enterprise customers, et cetera. This is before Sock2 by the way. So I'm dating myself quite a bit looking back on this, but I, you know, I just remember all the things that we did.
And I remember hearing the statistic at that time. And so we're in the early two thousands here. And the statistic was that most vulnerabilities that were identified on internet facing systems lived for more than 180 days before being patched. Right. Here we are, by the way, 2024, that stat is pretty much the same. And it's shocking to me that we've come, you know, we've come from.
back in those days, building our own data centers, et cetera, to nowadays cloud first, cloud native, by the way, hackers have cloud two, hackers have automation. I tend to think everybody is a target nowadays, but the stats are the same. And it's, it's really shocking to me that we've not found a better way to handle vulnerabilities in the 20 some years in between. So I think it's really interesting to hear an alternative approach. So I applaud you and the team over at RunSafe for what you guys are doing.
I'm curious, aside from RunSafe, what keeps you up at night?
Joe Saunders (30:53.518)
Well, I think what has me most worried actually is the fact that China has access to our critical infrastructure and Director Wray went on the record to say that the US intel community believes if China attacks Taiwan, does military action against Taiwan, it will also do a simultaneous attack on US critical infrastructure.
And they put that threat horizon window between 2027 and 2030. So, you know, we, we talk about having these problems that exist for 10, 20, 25 years and, you know, things don't seem to change worth three to six years from that event. Uh, and so that, that keeps me up, uh, at night tremendously. You know, I certainly have concerns about disinformation and AI and, and related social stuff that's affecting, you know, that I see affect my kids, uh, who are.
Jeremy Snyder (31:25.598)
Yeah.
Jeremy Snyder (31:35.39)
Yeah.
Jeremy Snyder (31:43.23)
Yeah.
Joe Saunders (31:50.382)
you know, becoming adults. And so, you know, they grew up on social media and I just think the world is changing a bit. I think the pervasiveness of super apps that China deploys around the world, that also includes, you know, sending out disinformation, but also includes payment information, e -commerce applications and the others. And if you combine all that data together, you have a pretty good profile of an individual globally.
Jeremy Snyder (32:12.414)
application today.
Joe Saunders (32:19.79)
at a global scale of individuals and consumers everywhere. And so imagine the knowledge that China has on the global South, on US social media users, and payments and commerce in general. China dominates the top 10 in terms of digital commerce and social media. And so I think we're exposed. And I think we need to be mindful of both.
Jeremy Snyder (32:44.656)
So I think.
Joe Saunders (32:48.718)
the digital footprint we have and the social media footprint we have and our cyber defenses. And, you know, unfortunately, I think all that stuff is, you know, building to, you know, a not pretty outcome. And so that keeps me up at night as well. And I do think there's time for us to turn it around. I am optimistic, but it just seems like we really need to, you know, really take charge here and try to resolve some issues.
Jeremy Snyder (33:13.566)
Yeah, I think that's a really strong message to end today's conversation. And I'll certainly echo the sentiment, you know, one of the directors of an investment firm that we have firetail work with full disclosure has a favorite saying, which is that cybersecurity is national security. And it's not that I personally believe that any particular nation state is a threat to me personally.
Joe Saunders (33:27.168)
And we proceed.
Jeremy Snyder (33:39.07)
but may have geopolitical intentions towards where I live, where I do business, where I work. And I think every state, every organization wants the ability to have its own determination and operate its own systems in the way that it intends to operate those systems, free of interference, free of hacking, free of espionage, free of all of those things. And I think there are a set of assumptions and a set of kind of...
guidance and ground rules that many organizations operate on that maybe aren't being observed on a global level. And there's some asymmetry there. And so anything that we can do to kind of bring back control to the organizations that we serve and that we work with certainly goes a long way towards helping them in their own missions.
Joe Saunders (34:24.302)
Yeah, and from our perspective, the RunSafe mission really is to make the world a safer place by fundamentally changing the economics back into the favor of cyber defense. And just to your point, I think I mentioned this earlier, but Director Ray talks about the fact that China has a 50 to one manpower advantage in cyber warfare in general over the United States. And so in my mind, innovation, technology,
Jeremy Snyder (34:51.806)
and asymmetric center of events is what's needed to counter a 51 % advantage. And so...
Joe Saunders (34:52.014)
and asymmetric cyber defense is what's needed to counter a 50 to one person advantage. And so, I think RunSafe takes its mission out of exactly what you're describing. We think we're playing a small role in a broader kind of geopolitical battle, if you will, but that role is important to critical infrastructure and important to the world to help keep things operating in normal ways that normal society expects.
Jeremy Snyder (35:20.542)
Awesome, awesome. And with that, I will say thank you to you, Joe Saunders, for joining us today. For those who are looking to learn more about Run Safe, where can they find you?
Joe Saunders (35:29.582)
Find us certainly on the web at runsafesecurity .com. You can also follow us in LinkedIn, also at Run Safe Security, and even email us directly from the website.
Jeremy Snyder (35:44.446)
Awesome, awesome. Well, Joe, thanks again for taking the time to join us today on Modern Cyber. Really applaud you and the team over there for what you're doing. Securing critical infrastructure is so important. And I'm sure it's more than just critical infrastructure, but securing your customers' organizations, the components that they're building is a very noble and worthwhile use of your time, I hope you feel, as I do. And for signing off from Modern Cyber, this is Jeremy Snyder. Thanks for joining us today.