Interviewer / Host (3:34)

How did you communicate that to folks at the board level, that kind of prioritizing? Because I could imagine that they're thinking, well, it's all going to be patched, right?

Snehal Antani (3:44)

Yeah. There's two aspects to it. The first aspect is the answer isn't just patching. You know, I feel in industry we over rotate to patching is, is the end all, be all that solves everything. But actually it's a small part of your defensive remediation plan. There are compensating controls to go off and put in. There are things you can do to reduce your blast radius, you know, reduce the roles of particular credentials, reduce the access to particular share drives or whatnot. There are things you can do to improve detection and response so you at least have a chance at stifling and containing the attacker if they get in. So the first part was for all of these issues, what are the, the options that I have to reduce risk or to minimize or contain damage? The second part was in that list. What is the actual consequence? Like don't just tell me I'm vulnerable to a particular vulnerability or I might be vulnerable, show me that I'm actually exploitable. Show me that threat actors are known to abuse it and make clear the consequence to the business if we don't do something. So for example, don't just tell me I've got ransomware risk. Tell me that this vulnerability is exploitable, known to be abused by Salt Typhoon, and will enable the attacker to gain access to accounts receivables credentials, access the accounts receivables system and steal or interdict financial payments. Right. That level of precision is key to having the board understand the risk that they're accepting and understand why they should adjust priorities or marshal new resources to get after it. And until we're able to precisely describe the consequence in that risk narrative, it becomes very hard for the board to understand the risk that they're accepting or why they need to sacrifice resources from one area and realign those resources to.

Interviewer / Host (5:48)

You urgently well along the way in your own journey. When did continuous pen testing become something that you recognize the specific value of?

Snehal Antani (6:02)

So it, it started even my first day as CIO at GE Capital back in 2012, I had no idea I was secure until the bad guy showed up. Am I fixing the right vulnerabilities? Am I logging the right data in Splunk? Does my team know how to actually respond to a breach? Or is my EDR actually tuned and working correctly? And the answer is I don't know. I have to wait to get hacked. Or I could hire a consultant to show up once a year and test a sample set of my environment. And for every patch Tuesday I wanted a pen test Wednesday, every time my environment changed, I wanted to assess whether I was exploitable. And so I wasn't able to find a way to solve it. Back then I tried a variety of techniques and tools and resourcing. And then I saw this as a pervasive problem during my time as CTO of Splunk because I had the opportunity to meet with Watts of CIOs and CISOs in that job because we work with the. I work with the largest Splunk customers at the time. And then when I left industry to serve within the Department of Defense, I had that same feeling I did when I first stepped in the role of GE Capital. I don't know where all the cyber risk is in the organization. It's a massive footprint. I don't know where the issues are. I don't know what I should fix first. I don't know what the consequences are. And I need to rapidly assess my security posture so I can fiercely prioritize my cybersecurity hardening plans. And in that job, that's when it really clicked. The commander of JSOC said to me, 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's always changing and the adversary always has evoked. And that's when I realized that it is just not possible to do this if I'm dependent on hiring a consultant or a government red team to show up once a year, once every 18 months. I needed to find a way to frequently test the security controls and security posture of my environment as often as possible.

Interviewer / Host (8:07)

Well, help me understand here. Let's level set a little bit. How do pen tests do differ from traditional vulnerability scans?

Snehal Antani (8:17)

Yeah, it's a great question. There's two aspects to it. The first is when you think about a vuln scanner, you know, I was one of the largest tenable customers in the world at one point. I was one of the largest qualis customers in the world at another job. And when you run a vuln scanner, it is looking at vulnerabilities on a single machine. It doesn't know if those vulnerabilities can actually be exploited. It doesn't know if there are compensating controls that are going to prevent the attacker from actually exploiting that issue. It just knows on this machine is a potential problem. It also doesn't know how the attacker could use that and combine it with other issues or laterally maneuver across the environment. It's basically looking at one thing on one machine in complete isolation, and that's just not how attackers behave. Attackers are combining together different problems. They're, they're even rarely using vulnerabilities or CVEs. They're using misconfigurations, credentials that they've collected through a variety of techniques, misconfigured security tools, and other things that don't even constitute being a vulnerability. And by that purest definition, and it's how they're combining these things together, chaining them across machines, laterally maneuvering across machines to achieve a goal, to steal your data, to compromise your domain and get admin access to everything. Vuln scanners can't show you how to chain things together. They can't show you the consequences of what happens, like domain admin or sensitive data exposure. It's just an isolated standalone point in time view. Pen testing gives you the attacker's perspective. And in cybersecurity, the only perspective that matters is is the attackers. Like the attacker's perspective is what you need to prioritize, what to fix. It's what you need to make sure your tools are working, your controls are working, your team has the muscle memory. Penetration testing is the only way to get that attacker's perspective of your environment.

Interviewer / Host (10:17)

So when you go to a team, a security team, or even an IT team, and you say, hey everybody, good news, we're going to start continuous pen testing. Do there tend to be any hurdles, either technically or even culturally, that those teams understandably sort of throw up in your way?

Snehal Antani (10:36)

Yeah, it's really interesting. It's still a very split market. So a really simple qualifying question is, with an unlimited budget, how many pen tests would you run a year? 1 to 2 or 4 or more? Just keep it super simple. And if the answer is one to two, you're talking to somebody that has a compliance mindset to cybersecurity and a compliance mindset to pen testing. And if the person says four or more, or as many as possible, you're talking to a person that cares deeply about Cyber resilience that cares deeply about proactive security. Because the goal of running a pen test is not to find problems, it is to quickly fix problems that matter. That's the goal. And so the more often you run pen tests, the higher the resolution you have of your exploitable attack surface, the better understanding you have of what's exploitable. How quickly are you fixing them, how often are they reoccurring and why? How effective is your detection and response? And so I've found that single question of with an unlimited budget, how many pen tests would you run to be a really clear way to understand who I'm talking to. Compliance centric person that's trying to check a box or a person that's actually focused on cyber resilience of their organization.

Interviewer / Host (12:10)

We'll be right back. So you mentioned that you spent some time in the private sector at some high profile places, and then some time working with a DoD. What was it that led you to start the current company?

Snehal Antani (12:39)

So it's really funny, I've dreamt of this product and capability since I was 12 years old, 1992. So I kind of grew up admiring that hacker culture, the hacker world, the hacker movies. And I remember kind of envisioning or dreaming like imagine being able to look at anything and point, click, shoot and take it over and actually remember the scene. I think it's like Iron Man 2 where Tony Stark is testifying in front of the House or the Senate pulls up his camera, double taps and hijacks the television, has now hacked everything around him. So it's been this elusive but very interesting idea for a long time. The hard part of the problem, honestly, is finding offensive talent that knows how to write exploit code, that can run against production systems and that aren't criminals. When I left industry to serve within the US Special operations community, I had the privilege of meeting and working alongside these incredible cyber professionals. And so when you start a company, the idea honestly doesn't matter. It's the early team that matters. And that early team, as my co founder Tony retired from the Air Force and the other folks that had served in various cyber roles finished their tour in the military, it became the perfect early team to assemble to go off and solve this problem.

Interviewer / Host (14:07)

My understanding is that you all are making good use of automation here and you use the term AI hacker, unpack that for us. What does that mean?

Snehal Antani (14:17)

Yeah, so when you think about this idea of point, click, shoot, hack, a good analogy is chess. So in chess there are well defined opening moves. You're going to move the pawns to the center of the board. You're going to take the knight and maximize reach and maneuverability of them, and so on. And there are well defined closing moves. You're going to use the rooks to roll up the king or whatever else. But the middle of the chess game is completely dynamic. It very much depends on what your opponent is doing also. And so pen testing is actually very similar. There are well defined opening moves. You're going to conduct a ping sweep to understand everything that's network reachable. You're going to use that to do deep service inspection to understand all of the services running on every host you've identified, Use techniques to harvest user IDs and passwords or NTLM hashes. You're going to identify juicy or interesting landmarks. Dell idrac, hp, ilo, Veeam backup and recovery, other kinds of virtual appliances, and out of band services that are used by admins not normally monitored by the SOC team and possess highly valuable credentials. Those are well defined opening moves that you can automate to be able to execute against. There are well defined closing moves of pilfering data, looking for sensitive information, or finding ways to become domain admin through querying SMB and other things like that. Those can also be automated, right? You don't need any special technology magic, you just need significant deep domain expertise. But the middle of the chess game, that dynamic part is actually where a blend of machine learning, reinforcement learning, LLMs and aspects of AI and expert systems become very important because it's all about the next best action. Should this AI hacker go after the router, the printer or the television next? And the answer is, well, it depends. What were the discovered services? What is the historical record of success? What is the likelihood that that going after the television is going to lead to domain compromise or sensitive data exposure and other things like that. So at the end, our AI hacker uses the right technique for the task. Certain tasks are best solved by just good old boring automation. Other tasks are best solved like very narrow reasoning problems. Is this data valuable? Is really well solved by an LLM. But if you ask an LLM to solve a large unbounded problem, it's going to quickly veer off the road and go nuts. And so Markov decision processes or traditional machine learning might be better there. So I think that a good technical architect always understands the problem and tries to use the right tool for the job versus over rotating towards chasing the next technology trend.

Interviewer / Host (17:14)

Do you have any examples, any stories about how an autonomous pen test surfaced? Something that was actionable that maybe something that a traditional process would have missed.

Snehal Antani (17:26)

Yeah. So a really interesting example is Windows Defender at a particular company. So one of our customers had about 14,000 endpoints and they had Windows Defender installed on all of them. And they initiated a pen test with our product, Node zero, and our product ran through its discovery phase and then dynamic execution phase and so on. And it found one host. One Defender agent out of 14,000 was misconfigured. Just one, and then that one misconfigured EDR agent. Node Zero was able to gain host compromise. He was able to gain access to sensitive processes like SAM and LSAs. It was able to gain access to sensitive credentials as a result, and then laterally maneuver across the organization, eventually becoming domain admin. 1 out of 14,000 is all it took for that to happen. And if you think about it, you can't hire a pen tester and give them all 14,000 endpoints as part of the scope. That's just too big, it's too expensive, it's going to take too long. Clearly the customer missed this in their own configuration because this had been a problem for an extended period of time and they had no idea. You can't trust that your security tools are working. You have to verify that they're delivering the defenses you expected them to deliver using the attacker's perspective, using that idea of autonomous pen testing. So autonomous pen testing gives you speed, scale and comprehensiveness. And that was a really interesting example of the customer did all the right things in 13,999 places. All it took was one.

Interviewer / Host (19:09)

Yeah, it's a literal needle in a haystack. So where do you suppose we're headed here? Do you think that continuous autonomous pen testing is going to replace traditional audits and Red Team exercises, or is this going to be a thing where they coexist?

Snehal Antani (19:26)

They're going to coexist, but I think in very different ways than in the traditional world. So first and foremost, algorithms, AI infrastructure, AI hackers like Node Zero are really awesome at network penetration testing because network penetration testing is a graph analytics problem. At the end of the day, there's this Microsoft quote. Attackers think in graphs, defenders think in lists. That is absolutely true for network penetration testing, especially of production systems, which we're the best in the world at doing. The adjacency to that is in web applications. But very specifically, testing for broken authentication and app to internal pivoting, that's just a natural extension of infrastructure network penetration testing. What algorithms are not good at, though, is finding logic flaws in custom code. Humans are uniquely gifted at that type of problem set. So I think humans end up focusing on finding logic flaws in custom code because that's what they're uniquely good at. And then algorithms. AI hackers are going to primarily focus on infrastructure pen testing at scale, kind of number one, the next two areas are security of your source code. LLMs are actually proving to be really effective at finding vulnerabilities in software that completely transforms the way we do static application security testing. Claude Code, OpenAI, Aardvark, other tools like that are incredibly effective at finding bugs in software. Semgrep, which is a really awesome SASD tool, has written an interesting paper on how they use a blend of traditional static application security testing techniques with LLMs to find very low false positive, high impact software flaws. So I think that's going to be machine driven. But the final area that's human driven is the long tail of OT and industrial control systems. You know, at Horizon 3, I can't go buy myself a nuclear reactor and add it to my cyber range to learn how to hack these. All the control systems, I don't have access to that kind of machinery. I don't have access to the long tail, bespoke aspects of OT and ics. And so I think that's where humans become very focused and specialized. Also we see this with Dragos. I mean, Dragos is an amazing company, primarily consulting services, because it takes a very special type of human with bespoke expertise to do long tail OT testing. So I think, Dave, the answer is it's going to be a mix. There are certain parts of the problem or stack that AI is incredibly capable of solving and there's very specific areas that humans are focused on and humans should really be working on things that'll put them on stage at defcon and let AI take care of the rest.

Interviewer / Host (22:31)

Our thanks to Snehal Antani from Horizon.

Dave Bittner (22:34)

AI for sharing his insights and experience.

Interviewer / Host (22:37)

Snehal Antani makes the case that pen testing isn't just about finding problems, it's.

Dave Bittner (22:42)

About about fixing the ones that can truly hurt you and proving your defenses can stand up to real world pressure. In a landscape drowning in theoretical vulnerabilities, he argues the smarter path is focusing on what attackers can actually exploit and how quickly you can respond. Our thanks to Snehal for sharing his insights and experience. I'm Dave Bittner. Thanks for listening to this. Cyberwire X special edition.

Snehal Antani (23:08)

Sam.