Presenter:
Transcript:
My background. I was a CIO, GE capital, I was the CTO at Splunk, and then I left at the end of 2017 from industry, disappeared for about four years, to join us. Special operations. There I was, the first CTO, and that's where I met my co-founder, Tony. And when he retired from the Air Force and I finished my time at Jayhawk, we started Horizon3 together.
And the challenge to go solve in all of my jobs as CIO and then at DoD was I had no idea I was secure until the bad guy showed up. Are we fixing the right vulnerabilities? Are we logging the right data in Splunk? Is my team know how to respond to a breach? And the answer is I don't know either.
Wait to get hacked, hire a consultant to show up once a year. But really, for every Patch Tuesday, I wanted a pen test. Wednesday. Every time my environment change, I wanted to quickly verify that I wasn't exploitable. What I wanted to get to was this motion of find, fix and verify. Continuously assess my security posture, quickly fix problems that matter, and then quickly verify that those problems were actually fixed and know for sure that it may not just be a patched server as the as the way forward, but a compensating control or something else in place to make sure that this issue was no longer exploitable.
The other part was actually fixing problems that matter because traditionally, you know, when you're at GE capital, when you were a DoD, you're a massive vulnerability management customer. I would get a list of vulnerabilities with hundreds of thousands of CVEs on there, and maybe a few of them were actually important. So we spent a ton of calories taking those lists of CVEs, applying a bunch of math to it, and making it a slightly less crappy list of CVEs and the reason why is because just because I've got the vulnerability doesn't mean it's exploitable.
And if it is exploitable, you need to know the consequence of that vulnerability in order to marshal resources and prioritize it. The hardest part of my job as a CIO was deciding what not to fix, and a big part of that was, I've got to look at it, admin in the eyes and tell him or her that they've got to skip their kids basketball game, skip their family vacation, and patch a bunch of servers for vulnerabilities.
We knew weren't even exploitable in the environment. And so the other part was starting to really rethink the way we assess risk in risk based vulnerability management. And I thought about risk across three dimensions. The first one was, is this thing actually exploitable? Can an attacker actually exploit it and do something with it, or do I have the right layers of defense in place?
Number two is if it is exploitable, are actually threat actors known to be using it? That's really important. What is the threat actor pressure for this particular problem. And then the third is don't just tell me I've got ransomware. Give me the precise consequence or the precise business impact so I can appropriately prioritize and do something about it.
What that means is what I want to go through and say, you know, we are exploitable to that active MQ problem, and it's going to lead to ransomware. That's okay. That's not precise enough. I want to be able to say we are exploitable to that problem. It is known to be abused by Salt Typhoon and if exploited, will lead to full operational loss of our environment.
I won't be able to tie the threat actor Salt Typhoon to the exploitable issues in my environment, to the precise business impact, and now suddenly I can take that to my CEO, to my leadership, and either explain the risk they're about to accept or more importantly, use that to understand what to do, prioritize and where to adjust resources accordingly.
The problem is that the only way to truly understand the consequence of the exploitation of a vulnerability is to actually exploit it in the bottleneck is in the world of pentesting. And so this became, the key reason why I ended up starting horizon three. So before I get into the bottleneck, what I realized as a CIO was myself as the CIO and many of my defenders, we didn't really understand how cyber attacks operated.
Like, you'll read about it in the news, this CV led to this issue. Or, you know, you read about some some threat intelligence report. But deeply understanding the anatomy of an attack was a really big blind spot for most defenders. I think it still is. And so we end up spending a lot of time truly understanding what are the parts of the attack that matter the most to us as a defender.
And so when you think about the role of defender, roles of of a cyber attack, you really break it down into two steps. The first step is can they actually break in and gain initial access. And to be honest, there's a ton of ways they're going to get in. Rarely do attackers exploit zero days in custom code.
That's just a rarity. Most of the time they're exploiting a perimeter gateway, a Fortinet device, an advantage device, or so on where you've gone cis a cab and you know this is a big problem. That's the primary way in. Or they've purchased access through an access broker, or you've got an insider, a threat risk or something else. But the crux of a cyber attack really starts with shell on a single host.
You assume they're going to get in. They've gained initial access from shell on a single host. What can they do? And you think about a cyber attack as analogous to a chess game. There are well-defined opening moves. You're going to harvest credentials. You're going to fingerprint everything that's network reachable. You're going to go off and try to crack those credentials.
You're going to look for juicy, interesting servers, and then you're going to get into the middle game, which is completely dynamic based on what you've discovered. And you're going to get into the end game, well defined moves to steal data, compromise your domain and so forth. And so when you think about this attack, how many people here use deli rack or pillow or Veeam Backup and Recovery?
These are you got a lot of fun vacations coming up. I'm sure these are incredibly attractive services for the attacker because they tend to be custom operating systems where you can't deploy an EDR agent. They tend to not be patched very frequently, and they tend to be accessed by, users with significant credentials or privileges. And so as an attacker, that's a great blind spot.
So you're going to come in, you're going to conduct recon. You're going to see that Veeam Backup and Recovery is running. You're most likely going to be able to compromise it to get code execution. And then from there with code execution, you're going to be able to dump credentials from memory running in those processes. HP so all those juicy credentials are stored as clear text in memory.
So once the attacker gains initial access, they've got clear text user ideas and passwords. From there, an attacker is going to credential pivot to a neighboring machine. They don't actually have to use any form of malware or any signature based exploitation to move into a machine. In fact, I think 97% of our credential or our implants in EDR defeat is by credential pivoting into the machine to a compromised credential and SMB protocols or something to that effect.
So you're in a credential pivot to the neighboring machine. From there, you've got access to the machine, just like that domain user. You'll pilfer the share drive. Often you'll find something interesting like the AWS Keystore files if it's an engineering share driver server. And then from there you'll credential pivot into the production cloud. This is an actual attack executed by the AI hacker we built at horizon three called node zero.
And what's amazing here is, not a single security alert went off in this attack. And this company had the best guccis tools you could buy from Splunk as the SIM to, CrowdStrike is ETR and so on. And the reason why is the the HP there, the VM backup and recovery box wasn't being monitored or observed. And everything thereafter was a valid credential log in and pivot.
And that behavior never exceeded any of the user behavior analytics thresholds within the environment. So complete domain compromise, complete cloud compromised in a way that was totally under the radar. And this is just the reality of cyber attacks today. Does that make sense? Okay. So then when you think about how do you go off and find this at scale, the fundamental problem is the way we do exploitation testing the way that we do Pentesting first, you've got to go off and justify why you're going to go hire consultants to Pentesting.
From there, you're going to spend weeks preparing the environment to be ready to get hacked. Then the pen tester is going to show up. I know if it's too soon for this meme, but then the pen tester is going to show up, and then from there they're going to pop you almost immediately. And then this year's reports look exactly like last year's reports.
And that's just not sustainable. And the other part of the problem is you're only testing a small slice of your environment. And so there's this adversarial relationship, no pun intended, between the pen test process and the defender. And what you want to get to is proactively securing your environment, proactively assessing your environment. The issue is there was no way to do this, which is why I ended up starting horizon three.
And the question was, could I build some sort of force multiplier that allows I.T admins, network engineers and other fixers to hack themselves as often as possible to proactively identify what's exploitable, what's the consequence, and fiercely prioritizing quickly fix what's going on. What I wanted to move to was away from these traditional pen tests that only tested a small slice of my environment to comprehensive testing of my entire network infrastructure.
So if you've got 100,000 IPS, there's no way you can hire consultants to assess that entire environment. Yet attackers will. They're going to gain initial access, and they're going to patiently record over months and months until they've mapped out your entire environment. And then from there, they're going to move into execution mode. Finding those Dell, finding those HPI logs, finding those AWS Keystore files, and then abusing to achieve their objective.
And rarely do they actually need CVEs. Oftentimes it's misconfigured software. It's ineffective or misconfigured or poorly tuned eaters and Sims. It's poor credentials or harvested credentials and other techniques like that that are combined together in different ways to achieve that objective. And this is what we need to get to. It's all about comprehensively testing your environment as often as possible.
Our t shirts at our booth literally say go hack yourself. And the whole point is our customer shift from 1 or 2 pen tests a year to 40 or 50 pen tests a month, constantly finding, fixing and verifying. But the goal of a pen test is not to find problems, it's to quickly fix problems that matter. And that's the other fundamental mind shift and cultural shift that's required as we start to rethink this idea of proactive security.
Does that make sense? Okay, so let's take a break for a moment and double click on what do I mean by AI hackers. There's a lot of of conversation going on around the role of AI and offensive cyber operations. So first let's look at what the bad guys are actually doing. There's a really interesting write up by anthropic.
About a month ago on how a single bad actor was able to defeat anthropic and clod codes, safety measures, and use that as a platform to execute ransomware. How many people heard about this story or read about this story? A few. Okay, so it's really interesting. Is anthropic eventually detected that a single attacker did the following. They were able to create a bunch of agents.
Each of those agents executed a very, very specific task in the cyber attack. Those agents were able to defeat anthropic safety measures because of this, concept of extreme compartmentalization. Think of it as if you executed 5 or 6 commands together. In aggregate, it looks malicious. And so anthropic is going to trigger that and prevent you from abusing their system.
But if you have each agent only running one command, and then you're able to use a human or an aggregator agent to collect those together, any individual command doesn't look malicious. In fact, you know, people do this in the Intelligence Committee. If you've ever watched a spy movie, you know it's a need to know. It's all about extreme compartmentalization.
So what this attacker was able to do was, as a single attacker, operate like an entire ransomware team, spin up a bunch of agents, specialize at doing one individual task using a frontier model company in anthropic that is known for safety to ransomware. 17 organizations. In fact, the attacker asked the Lem how much they should charge in the ransom, and the Lem recommended that this data is worth $250,000.
You should ask for that. And then they had another agent actually craft the email to get after it. And once again, this is from the most paranoid frontier company out there in terms of AI safety. And this is not something you can easily protect against as a frontier model, because all you do is further compartmentalize and compartmentalize. Does it make sense?
Okay, the next example here is something called villager that just came out a couple of weeks ago. How many people here have heard of villager news? So villager is really interesting. This started off as a as a hackathon project for students that turned into malicious, fully implemented project or capability by Chinese state actors. They believe Chinese state actors was really interesting.
Then I'll read through some of these is it basically became an MCP server interface to Kali Linux, who here has heard of MCP servers. Think of MCP servers as a chat GPT interface to a piece of technology. And so now instead of having to learn every tool and every API, you can just say, go compromise this Wi-Fi and it'll go off and figure out what commands to go off and execute through that MCP interface.
So what that does is dramatically lower the barrier of entry to running an offensive operation, because you now have a natural language interface to a whole bunch of tools that should have taken you a while to learn. The second part is they integrated with deep seek, the open source Chinese AA model, AI model for reasoning. And so now suddenly you've got a really interesting reasoning engine.
Paired with Kali and MCP. From there, they built 4200 curated system and exploitation prompts in order to get Deep Sik and Kali MCP to start working closer together to do really interesting and advanced things. After that, they had these AI agents self-destruct every 24 hours, making it super hard for your teams to fingerprint what was going on.
They would, they had plug ins for different kinds of logging, keystroke logging, webcam hijacks and so on. They had evasion by design, and they published this as a PyPI package, which means everybody that, makes it super easy to download. So I think at the time there was 10,000 or 11,000 downloads. I think it's up to 30 or 40,000 downloads.
Now, what this does is dramatically lowers the barrier of entry to executing an attack. And so when you think about AI hackers, the bad guys are starting to do some really interesting things. And the speed of attack is only getting faster. Does that make sense? Cool. Useful so far? Give me some ideas. Right. So what we pioneered and we actually, were the first to do this and we're the good guys was we pioneered the concept of AI hackers.
And we pioneered that because we saw these challenges within the Department of Defense. We were also early to Project Maven. So we got to understand, the role of AI in combat back in 2018. And so pairing those worlds together, the leap of faith I had was could we build an autonomous agent or an autonomous system that could point, click, shoot and hack at the end?
Five years later, we literally had a nine year old kid point click, shoot and compromise a bank in four minutes and 12 seconds. No humans involved, no prior knowledge. Just go. And that's just the power of the world of autonomous systems. Game of Active Directory is a really good cyber range. To understand the potential for autonomous systems in AI hackers.
Who here has heard of God or game of Active Directory? Okay, if you game of Active Directory is an interesting cyber range, it's the hard version of it. It's five virtual machines. You can download and spin it up in any environment you want. It's really, it's an intentionally exploitable Active Directory environment. But the the things to exploit are legit hard.
And so when you think about why this is difficult for an algorithm to attack, it's because one, it requires multi-step exploits. You execute step one. And based on that you understand what steps two, three, and four should go off. And B so it's not only multi-step, it's conditional stepping, which is really hard for algorithms traditionally, like old school breach and attack simulation products.
Had to hard code runbooks for an attack. Kind of old school automated pentesting products. We'd have to hard code runbooks. And if the environment changed, the runbook broke, which is why those tools never really work in an autonomous system. It knows nothing about the environment. It has to discover the environment. It's making this next best actions.
The more environments it attacks, the better it gets at deciding what the next action should be. And so on and so forth. In code, you've got to discover an abuse trust. You've got to reason over a file contents. So if I gain access to a shared drive or if I gain access to ball, I need to be able to iterate through six boxes file to figure out are there credentials that are in here?
And you can't just regex your way to a large share? Sure. Drive. If you solve that problem with regex, you have two problems. If you've heard that that joke is an old it heard. And so you've got to be able to do this as an autonomous system with no prior knowledge and with no humans in the loop.
Does that make sense? This should take a senior pen tester 12 to 16 hours to complete. If you're really good, maybe you'll get it to like six hours. If you're a newbie, this will take you a few days, but it's a pretty good benchmark on whether an autonomous system or an AI hacker can solve something legitimately complicated, and what that measures against in terms of human time.
Our AI hacker solved it in 14 minutes and 25 seconds, which is insane. Fastest it's ever been solved. And when you think about how that pairs, now let's just say it's 12 hours, 12 hours or 720 minutes compared to 14 minutes means our AI hacker was 50 x faster than a senior pen tester. The other interesting thing here is I basically have infinite cyber capacity, because I can go off and spin up 100,000 of these instances if I want, and attack an entire country.
If I really wanted to, while looking like the Russians. So you can imagine the power of being able to have infinite offensive cyber capacity, spinning up, using open source off the shelf exploits that any ransomware organizations using. And what this means in terms of the cyber arms race that's occurring out there. And so this becomes a really interesting and really dangerous aspect of where I think the market is going, because not only, do I do I, as an AI hacker, win on speed, comprehensiveness and scale, but now with infinite capacity, I can start to do things like go after your long tail of suppliers.
And this is actually something we're seeing in industry. So if our CIO again, it would be an awful job. In fact, I feel really bad for seeing how many CISOs are in the room. But that's not a job you want. It's just brutal. And you're set up to fail. And the reason why is because not only do you have to secure your own enterprise, you're on prem infrastructure, your cloud infrastructure, your SAS infrastructure.
In the last six months alone, you've had to deal with suddenly, securing vibe coded applications, right? The quick and dirty apps being quickly built, like, copilots and cursor and windsurf apps that are just fundamentally flawed. And if you don't have a good app stack program, those apps are going to come a big issue. You've got to worry about data leakage into ChatGPT and other realms as as employees copy and paste sensitive info.
Your attack surface is increasing exponentially. And now you've also got to worry about attackers compromising your suppliers and swimming upstream. So, for example, I don't have to hack Boeing directly. I don't have to hack Airbus directly. I can understand who their critical suppliers are and start to go after them instead. In fact, there's a story. In 2021, the Japanese provided support to the Ukrainians, the Russians got angry, allegedly, and ransomware at a small company in Tokyo.
And that company in Tokyo provided all of the cup holders to Toyota. And due to just in time logistics and lean manufacturing, Toyota had to shut down 28 production lines, and it cost them almost $400 million in economic damage over cup holders. And the flex by the Russians was knowing where to apply the least amount of effort to cause the maximum amount of economic harm, all below the threshold for war.
And so when you think about what this means, the United States, there's this corridor, Houston to Huntsville, Madison to Pittsburgh, within the center of the United States, where the bulk of the industries around oil and gas, space, agriculture, wind production, manufacturing, and so on are all within that corridor. Most of those are mid-market companies that are all critical suppliers to Ford, GM, Exxon, and so on and so forth.
And with infinite offensive cyber capacity, an attacker doesn't have to marshal their resources and go after one big target. They can go after the entire long tail. So this huge spike in cyber attacks against mid-market and small, medium sized businesses, in the context of either stealing IP laterally, moving into the primary target's environment, or disrupting the cupholder equivalent in causing operational economic harm.
Does that make sense? Okay, so one of the interesting stats in the way that we operate Penta. So for perspective, I run more pen tests a day than big four consulting firms run in a year. I ran more pen tests last year than the entire history of computing every pen test, collecting telemetry that makes the core algorithms, that much better, that much faster.
And so just within the defense industrial base and I, I gave this as a talk at that Blackhat as a keynote with the NSA cyber Collaboration Center. There's some interesting stats that I talked about, across 9000 pen tests and 600 defense industrial based suppliers. Time to compromise a credential. The fastest was 5.5 minutes. The slowest or the median was 72 minutes.
So five minutes. All right, maybe you've got a shot as a defender. 20% of the credentials compromised. Where domain admin credentials. And for those that don't know if you're an attacker, you get domain admin. You've got keys to the kingdom. It's game over. I can delete your infrastructure, change all your passwords, physically lock you out of buildings, corrupt all of your data.
I can do anything I want. If an attacker gets domain admin, you literally have to burn down your network and rebuild everything from scratch and throw away all of your gear. It's an incredibly disruptive impact. To the organization, 20% time to domain compromise. The fastest 77 seconds. If your SoC can't detect and stop me in 76 seconds, it's game over.
That's it. Because that second 77, I've got domain admin. I've got full domain compromise. I'm locking you out of your systems and you're going to have a very bad day. So the question is, can your SoC detect, respond and take stifling actions in 76 seconds or less? And the answer is probably not. We don't have a tools problem in the SoC.
We have an effectiveness problem. Most of you probably already have all of the tools you ever need to buy. On the SoC side, what those tools have not done is been tuned to work together in order to quickly detect and respond. It's about training light to fight, using Pentesting as a sparring partner to improve your effectiveness is one of those key outcomes.
Time to enter a user compromised Microsoft entra who? How many people here are entra users 52 seconds to compromise an entry user was the fastest. Yeah, I don't want to. I don't want to use that use that expletive on on recording. But exactly right. AWS surprisingly 89 minutes to compromise an AWS credential, because what that means is AWS is inherently more secure from an IAM standpoint.
And so I thought this was super interesting because once again, with the volume of data we execute for us, we execute. We've got pretty accurate numbers on best EDR, worst EDR, best MSP, worst MSP, typical hardening guidelines that are missed, hardening guidelines are ineffective, and so on. So it's really cool to start to see that at scale across the, the, the the enterprise in the organization.
Another example, we talked about this at the Black Hat keynote. In less than five minutes, our AI hacker, node zero gained access to 3D CAD files for Nimitz class aircraft carriers and Virginia class submarines in less than five minutes. Once we gained initial access, we're able to, compromise credentials, become a domain user, gained access to a shared drive, and had these CAD files within it.
In that shared drive, you had millions of files. We're able to find the ones that were really valuable and get full IP theft and compromised. This is a defense industrial based supplier in Virginia with about 1000 employees. Now, what's amazing here is one, they had no idea this was a problem. They were compliant to all the compliance requirements they adhere to, but no one ever showed them the consequence of exploiting a particular sequence of vulnerabilities.
Once they understood the consequence of risk to mission, they quickly mobilized resources and did something about it. And that's what I see across the board. Once a company understands the consequence of exploitation, they do the right thing and get after it. And compliance never shows you the consequence. Volm scanners never show you the consequences. Does that make sense?
Okay, so what does an attack path actually look like in more detail? And so when you think about it, you assume breach and gain initial access on a single host. You're going to eventually get compromise on a on a VM backup recovery server. You're going to dump credentials, grab the clear text, validate that it's domain admin. Once you've got domain admin or even domain user, you can drop your job on to another host and drop a rat or an implant.
If I'm able to drop an implant on the host, your EDR failed to do its job. Fundamentally, how many people in here are CrowdStrike users? How many people here are Sentinel one users? Microsoft Defender users? Right. Kind of a mix. Everyone's got it. Those are really the top three headers that are out there. These are all great products.
To my surprise, CrowdStrike only stop that implant 16% of the time. Not because they're a bad, bad product, but because it's really easy to misconfigured. You're an agent, you didn't disable, OS credential dumping, or you're not updating the agents, or it was in observe mode versus block mode. 40% of Sentinel one agents are misconfigured, which means you had the EDR agent installed, but it wasn't actually doing its job.
Similar stats for Microsoft Defender, so on and so forth. So you can't trust that your security tools are actually working because it's super easy to misconfigured or not even have coverage on something that you thought was covered and so on, or you made an acquisition and you just inherited a bunch of tech that you don't even know what they've got from an EDR standpoint.
So you want to validate that the, your defensive tools are actually working from there. Once we gain code execution on the host, how many people here use office? 365, right. Microsoft Azure, how many people here use slack as your collaboration platform? Cool. All of you have MFA set up. We're all feeling really good, except if I get code execution on a host and I drop a rat, I can now iterate through every process on that host and I will iterate through.
You can't see in the back, but all the Microsoft Teams processes are Microsoft 365 and teams is running, and I'm able to pull the off token, your MFA auth token, out of memory of teams and use that to became become an entry user in your network. There's actually nothing you can do to stop the attacker from doing this.
If they defeat the rat and get code execution on the host. This was a Microsoft CEO level conversation and a fundamental design flaw in any desktop application that's MFA. Slack has the exact same problem. This is how Disney got 1.2TB of data stolen from their slack workspace. About a year and a half ago. And so it goes back to you can patch as much as you want, but if I get domain user compromised, if I can get credential pivoting, if I can get a rat on a host, I can pull your MFA token.
You've done all the right things and I'm still going to get there. So understanding the consequences at scale is super important to making sure you've got the right defense in depth. Does that make sense so far? Got good use of your time? I ask a lot just to make sure I don't get too deep or too broad. So with that, the most precious window of time in cyber security is the window between knowing you've got an exploitable issue and knowing you've actually fixed it.
Because if you're a CIO and you get popped in that window, you're excuses don't matter. The board wants to know why you didn't fix it faster, and you're just going to be in a world of hurt. And so by default, we think the answers patching. That's actually not the answer. There's a bunch of steps in between. First and foremost, how do you improve detection response.
All right. You know you're exploitable. Hey Splunk, what did you see on that host at that time when the command was run? Hey CrowdStrike, what did you see? Hey, wow. What did you see? And so on. What can you do to understand the blind spots in detection response and get after that as soon as possible? Because you don't need a patching window in order to make EDR tuning changes.
As an example. So we're able to tell you, for instance, of the the 197 defender occurrences, we found, six of them were misconfigured. You better go fix those six configurations ASAP, because it only takes one for the bad guys to abuse. And you now have a very, very narrow, targeted set of things to go do to improve detection response.
And if you click on any one of those six, here are the exact things the implant or the rat did on that host that was permitted that shouldn't be permitted. We're able to dump SAS, dump Sam dump, LSA, dump, DPC, API, pilfer files over SMB. These are all things that have very specific options in the EDR, and they're literally just check boxes.
If you check the right boxes in the advanced configs in Sentinel one, all of these things get blocked. But most users don't know that, or they've got to pay partners or the ETR vendor a health check consulting engagement in order to go to these products. The next part is, while breaking into your house, I'll install ring cameras along the way.
So while running a pen test, if I get code execution on a host, if I gain access to a shared drive, I will automatically leave behind tripwires, fake AWS credentials, fake Azure tokens, fake SQL dump files, and other honey tokens that become a highly precise early warning system. Who here's tried to use deception technology before anyone? The hardest part of deception is not the tokens, it's where to put them, especially in large environments, until you end up using the pentesting result as the map and compass for the optimized placement of honey tokens in the environment.
And then if a bad guy interacts with any of those tripwires, you've got a rapid alert process that you know, this is ultra high signal and very low noise, and you better do something about it as soon as possible. The third part is your blast radius. At the end of the day, if you assume attackers are going to get in your job as defenders is blast radius management.
How do I minimize network reachability from every key spot in my network? How do I minimize the blast radius of a compromised credential by reducing its permissions? How do I minimize the blast radius of a compromised share drive by minimizing access to that shared drive, or minimizing what's in that short drive? Oftentimes, these things become dumping ground for all sorts of sensitive data that nobody pays attention to.
And so understanding your blast radius becomes the starting point for secure by design and secure hardening types of practices. A fourth one not listed if I gain access to a host, start running proactive threat hunting. Start searching for indicators of compromise on that host. Think of it as while breaking into your house, I notice the door jam is already damaged.
Maybe a bad guy is already here, and now suddenly you're pentesting and driving proactive threat hunting at the same time. All of these are all left of boom activities to improve your cyber resilience, all while in parallel you're opening tickets, you're fixing issues, you're running retest and you're verifying that those particular misconfigurations or patches or whatever else are properly being implemented.
The reason why this is important is this window of time is only shrinking. This used to be like a 90 day window, then a 75 day window, and now it's a 76 second window or whatever else. And everything's about dramatically reducing the window of time between knowing you've got an exploitable issue and knowing that you've got something in place to prevent this exploitation or minimizing the blast radius of that exploitation makes sense.
Okay. Next is this when I was a defender and I got a list of vulnerabilities to go solve or fix, I instantly rolled my eyes by default and I just assumed it was a bunch of noise and it was all false positive or it required exploitation where I needed physical access to the data center. Standing on one foot, holding a pizza like some obtuse conditions.
And so we were conditioned to assume every list of issues given to me by the security team was noise. And so by that, the only way to overcome that noise and realize you've got a real issue is path proof and impact. Show me the exact attack path that the attacker could compromise. Okay, I understand left to right, you don't have to be a hacker to read this.
You started with initial access. You did about a bunch of recon that code execution on a JMS server was able to drop a rat on that host dump. Sam, pull that until, hash became domain admin. Any IT admin or network engineers can build a read that left to right. I now understand the path. I don't believe you.
I don't believe that JMC server is explainable. Cool. If you click on that in the bottom left in green, there's the command I ran. Go run that. Command yourself and be a hacker and watch the output. And you're going to see you're going to get code execution on that host. Suddenly there is no doubt that this is a real issue, because you've got the command right there.
And then the impact domain admin, you know, that's a bad day, and it's better for you to skip your kid's basketball game and fix it tonight. Then burn your Christmas vacation hunting for a new job, because you're going to get blamed for not fixing it fast enough. But remember, the point of running a pen isn't to find problems.
It's to quickly fix problems that matter. Everything around this process has to be a bias for action. So from there, what do I do about it? Well, if you click on that server, there are multiple options. You can either fix authentication at the global level. You can fix it at the local level, so on and so forth. Some of these remediations can be auto executed, like a dangling DNS record that leads to subdomain takeover.
Pretty safe to auto fix. Auto fixing your off mechanism for JMS probably not automatically fixable. You're going to need a human and an architect a little bit more work to go figure out what the second and third order effects are for making these changes. But what you've done is fiercely prioritized, a problem that matters. And now you're having the most valuable discussion, which is what is the right way to remediate it.
What you're going to find as you adopt autonomous pentesting is remediation becomes the bottleneck. You just don't have enough capacity to fix and what I think is going to happen in the market is this convergence of Pentesting and saw as an integrated set of workflows. And here's what I think that's going to look like today. What people do is they'll run a pen, test the open a ticket, they'll code a fix.
Now using your favorite coding agent. They'll auto deploy that fix. They'll run a retest to verify that the issues been solved, and then they'll close the ticket. Cool. This workflow is how people operate. We have all these integrations in place to enable it, and that's where better organizations are starting to move in terms of accelerating the remediation issue.
But there's interesting innovations. I mentioned MXGp servers previously. So the question is how can we further automate this process. So what this looks like in the new world. And if you haven't spent time looking at MCP servers, it's worth a read. Is this idea of a genetic remediation service now has an MCC server or basically a, a ChatGPT interface into a service?
Now there's a ChatGPT interface into CrowdStrike, into Sentinel one, into Palo, now into horizon three. And so these ChatGPT like interfaces allow you to quickly through natural language, say open a ticket, run a, you know, run a patch, so on and so forth. And then from there you can run a pen test. You can get those weakness details, you can get fix actions, you can run a retest.
And the reason why this is super cool is your workflow starts to look something like this. There's a new service, a curve that hits the news wire, and then that's just a curve. You've got to go, run a pen test against your Kubernetes environment as quickly as possible. Well, now you can just go into VS code or whatever your, your, your favorite idea is as a cloud operator and say, I want to run a pen test against Kubernetes.
And through natural language, it'll automatically interface with the MCP server, configure and schedule, and execute a pen test against your Kubernetes cluster. Pretty neat. Every single data point I showed you is available via API, which means as the pen test complete by the MCP server, you're going to be able to pull all of the results. You're going be able to use that as input to a prompt to GitHub, copilot to cursor to whatever else you want to use to accelerate the coding of that fix.
And then while you're doing that, you can say, oh, I want you to open a JIRA ticket as well. All of that information is part of the prompt. Now interface with the JIRA, MTP server. Once the pen test is done, you can go off and run a retest. Once it's retested, you can through the MCP server. Schedule a run retest every Monday if you want to.
What happens is vendor products I think are going to become headless. You no longer burdened by the constraints of the UI of whatever security tool you're running. You're going to be operating with almost a GPT like interface, and you're going to be orchestrating these workflows against five, ten, 15 completely different products where MCP servers become the glue between them.
That's what I think the world is starting to look like. At least we're seeing that in the adoption of, automated remediation combined with autonomous pentesting. So I'll end with and I got about five minutes left autonomous Pentesting, which is around find, fix, verify. You interface that with MCP server. You now have a path into a genetic workflows.
And with the genetic workflows you get into what I call fix ops. You can call it CTM, you can call it purple teaming. There's a multitude of funny buzzwords that seem to change every year in the Magic Quadrant. Just fixing stuff that matters. Just take that as the outcome. Because we want to get to is not just how many problems you have.
How quickly are you fixing those problems over time. That's what matters. And being able to understand your result over time is the key to proving to your boss that you're a boss in the last bit is okay. Everything I talked about was initial access, but the reality is what does the journey look like for companies as they adopt and change the world?
Because I would imagine you're looking at where you are today and your pen test, overwhelmed with vulnerabilities, most of which don't matter. You don't have enough remediation capacity. How on earth do you actually build out a culture of proactive security? It's a huge challenge. We've got customers from the fortune three down to the local law firm and everyone in between.
All of them basically go through the following journey. First and foremost, they start with an incomplete snapshot. Everyone starts there. I started there is a G capital CIO, less than 5% of my environments pen tested once a year, and from there with autonomous pentesting you immediately move to a comprehensive snapshot, which is you're now running a complete pen test against your entire environment, maybe once a year, maybe once a quarter from there, you say, all right, I now have a comprehensive, snapshot.
I've started chipping away at problems to go off and fix. I want to run another pen test the following quarter and do a diff. How does this quarter's results compared to last quarter's results? And now suddenly you've got a quarterly comparison and you've got two data points to show how many new problems were introduced, how many existing problems were fixed, how many problems are sitting around?
You just made progress from there. As you get better at remediation, you start getting into monthly comparisons. I now want to run a pen test every month. What is the diff from this month to last month? About this month from last year? How does that look over time? And that becomes a pretty amazing maturity model for customers. I want to shift towards proactive security.
Every one of our customers goes through this experience where the more pen test they run in blue, the more problems they find in yellow. Inevitably, that yellow curve starts to decrease significantly because the red and the blue teams stop hating each other and they actually start to work together because they all understand the consequences of the problems that were found.
And they're using those consequences to prioritize from there. Just in interest of time, I'll, I'll, I'll skip forward. You get to running from different points of view and you start to run weekly. So I'll end with this. When I was in special operations at JSO, my commander used to say, don't tell me we're secure, show me and then show me again tomorrow, and then show me again next week, because our environment is always changing and the enemy always has a vote.
So what you want to get to is the fact that gone are the days when you can just run a vulnerability scan. You can run an annual pen test, you can run a tabletop exercise and think you're good to go. Cyber insurance claims are being denied because people behave this way. The SEC is litigating CSOs because they're behaving this way.
If you are subjected to this two door and other emerging European regulatory requirements, this is no longer acceptable. So it's not just good practice, it's becoming the expectation from an audit and compliance standpoint. And so gone are the days when you can do that. And instead you need to focus on how many problems do you have. How quickly are you fixing them, how effective is your detection response, and are you getting better over time.
And everything is about results over time and the way you use that to convey risk narratives up and out to your regulators, to the board, and how you use that to prioritize resources under the covers? I'll end there. We're right on time. Was this was this good? Got some good just inside of it. Awesome is being recorded. Thank you.
And I hope you have a great conference.
