Rohit Parchuri, CISO at Yext, on Keeping Humans in the AI Pentesting Loop

Ryan Rutan

Ryan Rutan: Hello, everyone. This is Ryan Rutan bringing you another episode of The We're In Podcast, sponsored by Synack. Today with me is Rohit Parchuri, Senior Vice President and Chief Information Security Officer at Yext. And we're today, we're here today to talk about AI, security, and risk management. So Rohit, how's it going? How are you doing today?

Rohit Parchuri: Great, buddy. How are you?

Ryan Rutan: It is just another day in paradise. Like I said, I thought it was really funny when we were first introduced. I was like the first thing that stood out to me was that I noticed that you're from Texas, which, again, I'm from Austin, you're from San Antonio, and again, it's where I picked up all my things and love for ta- technology and tacos, and I just I thought it was very funny. So I was very much looking forward to this conversation. So, really quick, just jumping in really quick, would you be interested in sharing a little bit of your origin story? Like, you know, and when did you like figure out that this is what you wanted to do with your life and career?

Rohit Parchuri

Rohit Parchuri: Absolutely. Yeah, first of all, that's amazing that you're also from Texas. So I haven't I wasn't born or brought up in Texas, but my early career, of course, was in San Antonio, Texas. Loved the place. You know, certainly want to go back sometime. Anyhow, my origin story: So, you know, my love for computers began back in the dot-com era. This was, you know, for people that are not aware of that, about two and a half decades ago. And you know, for me, that's something I really want to get into. Like it was more fueled by my curiosity about things. But although I was, you know, since my I was born and brought up in India, you know, we the focus for education has always been on the core subjects. Computer science was not a core subject back then. So my dad was like, "Hey, you know, you can do computer science. You got to pick something else." And so the deal, you know, between him and I was, "Okay, I'll do what you want in the morning college, and then I'll do computer science in the night college," because that's something I really wanted to do, right? And so I did that through my bachelors, and then after that, you know, I jumped into security because computer science led me to security—the same, you know, the same fuel as curiosity. Like, you know, I just felt it wasn't called security back then, it was called really ethical hacking or hacking, for that matter. And it was just to go deeper into, you know, into computer system itself. Like, you know, I was doing a lot of what was kernel hacking and also kind of, you know, tampering and manipulating with computer programs, so I just felt it was fun to do. And it was a cool thing to do back in the day, also. So yeah, and then, you know, after that, I pursued my master's in cybersecurity in US. That's when I made my way from India to US, and you know, since then, my professional journey began, I should say.

Rohit Parchuri

Ryan Rutan: Very nice. And I can't not move forward. I noticed that you worked at Rackspace, and I thought that was pretty interesting. Rackspace was one of those like lore companies in Texas, you know, the mall, the big slide, the you know, the buses going back and forth between Austin and San Antonio. What was it like working there in that in that time of like that dot-com era boom, if you will?

Rohit Parchuri: Oh man, that was that was too good. I think Rackspace back in the day—and and by the way, for people you know, who are not aware of this, Rackspace converted an abandoned mall in San Antonio into their headquarters. And it was beautiful, like the way they converted that. And they, you know, the ambience was similar to how a Silicon Valley company would operate—you know, slide you talked about, you know, and all sorts of things. I think just the culture was so different. And it felt as if you're kind of, you know, working for Google or something, you know, something like a very company. Yeah, I so I had a brief stint there at Rackspace, you know, when I was working for network security you know, function at Rackspace, and you know, all thing all pretty cool things, I should say. And I think after that is when they established the Austin office after San Antonio, and then, you know, of course, there was just more presence and just not in San Antonio, but also, you know, across the state. But now, it was it's very nostalgic, I should say, like, you know, thinking back about all things we had to deal with and do, especially in network security. And I used to work in the night shift, so the things got even more interesting. So yeah, it's a great experience overall.

Ryan Rutan: Nice. Yeah, definitely it's like a definitely a mark on the bingo card for sure in your career, so anyway, so cool. So wait, you were securing firewalls at Rackspace and then now you went to a CISO at a publicly traded company. Like what is something that you wish you would known before you did that first CISO role?

Rohit Parchuri

Rohit Parchuri: Yeah, I think, you know, configuring firewalls and load balancers and routers and switches, all things network appliance-wise, it has a certain visceral feeling, which you don't really get in CISO role anymore. You know, actually hands-on the keyboard and, you know, changing settings and configurations on the fly is really something else. But your but your question about what I wish I would have known before getting into CISO role, and it's taken a journey, right? I think it's taken, you know, a few decades for me to, you know, move from that to this. I think the one thing I underestimated was essentially the business acumen that's needed to operate in the role that I operate right now and, more importantly, to be successful in the role. You know, earlier in my journey, of course, I thought like, "Hey, the best way to, you know, solve a security problem was build, you know, higher defense wall." I mean, because that's pretty clear. You have a finding, you go fix the finding, and that's it. Like, you know, when you fix it, you have a fix in place. But, you know, I would, you know, now, you know, thinking back, you know, that was a foolish way to approach success in a security role, especially when, you know, when the when you're leading the program, and that program is in has an intrinsic relationship to the business. Because what you think as a security person may be completely different than a business person looking at it. You know, I think security like one thing I've also learned along the way is security risk should not be any different than how finance or legal views risk at the company. And you you're kind of, you know, the nature of the problems are different, of course, but the consequences are not really that different. You're having, you know, kind of the same impact, excuse me, if you may, you know, when you're thinking about the risk at the company level. You know, I'll give you an example, right? If you if you find a security bug or, I should say, a security vulnerability, you know, on a critical system, well, you may think it's a critical system as a security person, what does business think?

Rohit Parchuri

Rohit Parchuri: What's the worst-case if that happened? What's the impact to the business itself? Is that does that cause a disruption or not? Is that valuable? Is that a valuable resource that you need to put, you know, put right now to fix that, or is there, you know, a better alternative? Like, you know, "Hey, maybe you want to unlock a new market, maybe you want to provide more funding to finance to build a better pipeline, maybe more R&D." It's not your decision to make, and I think what you could do as a security person is to provide the context, you know, about the finding, about what the likelihood impact is, and what you think would be, you know, at stake, but it's ultimately the business's job to really find out like what exactly, you know, you need to start investing in. And I think that's the biggest, you know, thing I've noticed is, you know, just having a good understanding of the business and also communicating that in a way that people do understand. Like, translating technical to business to technical, you got to figure out, you know, the middle ground, so to speak, on how you communicate things.

Ryan Rutan: I think you, personally, I think you hit the nail on the head. Communication is big, articulating impacts, the ability for people to understand. I think, to me, the single biggest role CISO does is sort of translate what is the impact, and then again, working with their colleagues to determine what are the next steps, right? And not taking it personally whether or not something is or is not fixed at that moment in time. So I think it's I love your answer, so awesome for that. So yeah, so let's I want to talk a little bit about AI pentesting. You know, I come from the red side, you know, I run a red team where, you know, researchers are constantly, you know, you know, using AI and tools and capabilities to kind of constantly like force people to build higher walls, as you're as you were saying earlier.

Ryan Rutan

Ryan Rutan: And I guess I had a couple questions I wanted to throw out just to kind of get your take on it, if you don't mind. So first off, is like a true/false or a yes/no question depending on how you want to approach it, but here's a question for you. So AI testing is only for compliance testing at scale. This is something I've heard a lot from different people. I've heard both sides of that fence do you fall on or do you have like a unique way of looking at that that question?

Rohit Parchuri: Yeah, I think I would fall purely on false side of things. Don't get me wrong, like compliance benefits from AI testing. It's not that it doesn't, but that's not the real intent on why you're doing AI pentesting or even pentesting for that matter. You know, I think there's more to the, you know, to the story there, and we I'll let you ask more, you know, more questions there, but I would say it's false.

Rohit Parchuri

Ryan Rutan: Okay. And yeah, and there's really no, you know, right or wrong answer, it's just there's everyone has an opinion, so I was very curious. So given that you're on the false side, which is fine, I'm curious like when you look at AI pentesting, I guess what are some of the hallmark I guess capabilities that you look for in the tools that you use? Again, doing continuous testing is a very challenging process, right? You're the number of assets that you get are growing every day, potentially if you're if you're managing all your security correctly. Hopefully, they're being launched or rolled out in a secure way, but overall making sure that they're all under constant testing and coverage. And I'm just curious, from an AI perspective, like what are those hallmark characteristics? You know, and how you choose those solutions or how you value those solutions?

Rohit Parchuri: Yeah, for sure. You know, I think just the proliferation of AI services, and especially pentesting platforms and capabilities are growing by the day. There's a lot of noise, of course, in the market about all things, you know, vendors can do, of course. But, you know, it's your job to kind of navigate the noise and figure out the signal, right? Take taking a quick step back, like I think we should look at this domain for what it is. Like AI pentesting, right? If this solution that you're trying to offer is pentesting on steroids, such as the solution is helping me kind of expand the scope and just run the static playbooks in and out, you know, in a continuous manner, that doesn't really help me a lot. I think what it what helps me is going beyond that, going deeper to understand the business context—again, going back to the business acumen—is you really need to understand the business, and where am I coming from, where's the security leader coming from, where are the other leaders coming from, when we're looking at the results or the outcomes that come, you know, from this capability or a platform. Because ultimately that's what depends that, you know, that's what defines what the success would look like both for the program and also, you know, for the tool that you're trying to implement. I think in terms of characteristics, I would, you know, a few things come to mind. Number one, I think, is the threat coverage, meaningful threat coverage, I should say. Do all the homework before you can even start testing. Like what does that mean? Like effective threat model. Like, you know, we've always had this mindset as security professionals that when you're trying to approach a problem, let's start, you know, going back a little bit and start thinking about what kind of paths can an adversary take to break a system, disrupt a system, disrupt a business, you know, for all we for all we know. I think really having that perspective and lens is very important. And then identify the attack paths, right, which also kind of, you know, falls into the threat modeling itself.

Rohit Parchuri

Rohit Parchuri: But also go beyond that, like ingesting historical facts, because you as the business, you're a very heterogeneous organism, right? You have a lot of different things that you're working, not just a technical platform, but you also have a business, you have sales, you have HR, you have, you know, yada. So I think ingesting all the business facts from the perspective that if there have been incidents and events in the past, can you take that as a learning, you know, learning model and put that, you know, into platform so you can actually get better at it and also identifying the existing weaknesses. You know, that's number one. I think number two would be, you know, just given all things AI can do, that you have to figure out what safe autonomy means for AI, which essentially means that you can you would allow AI to do all things, like, you know, based on threat coverage, based on all the context it's gathered, now it's time to go, you know, to go and execute that. While I want to know all things that could be damaged by an adversary, which is the whole reason we're doing this testing, I'd also like to have some kind of a rollback or in a way, a change management process, you know, with the tool. You know, we're still testing, right? This is not happening in real time. We're still testing, so I want to have some kind of guardrails around it. So if something goes bad, right, I'm able to audit things, I'm able to restrict its capability of what transpired and also, you know, more importantly, like restrict access to irreversible actions. A consequence which could be an irreversible event, that could be really bad. Like, you know, example could be customer data, right, or a system that is so critical to the business workflow, if that gets damaged, what are you going to do? Like you got to have like, you know, some kind of a test harness built around it. Last thing I'll talk about is mostly the outcomes, right? Have some way of defining a measurable outcome for the exercises of continuous testing that you're performing. Because for me in my role, the most important thing, we spoke about this communication piece, is that I'm also trying to leverage the platform to get that communication out. Like as a CISO, talking about the outcomes from a tool or a technology should directly map into the business outcomes for the exercise. You know, this could be maybe improved and effective, you know, coverage that we have, asset and process coverage, or faster remediation time, right? Or we're able to, you know, enable less fewer false positives because that this tool is, you know, helping us achieve that. And then look at the peripheral business benefits. So I think if these things, these characteristics meet, I feel it's a more comprehensive solution overall.

Ryan Rutan

Ryan Rutan: Woah, again, I what you're describing I think is Nirvana. Like I just In terms of like, you know, if everyone could have that, I mean, it would be it would be great to see how much of the world we could secure at the same time. So I guess the question that I have on that, you mentioned guardrails, you mentioned harnesses and control, and I'm interested, you know, one thing with Synack that we like is human-in-the-loop, the ability for AI and humans to work together. And I'm curious where in all of that loop do you see the humans playing the most valuable roles, specifically from an ethical hacking perspective? And then also where are you feeling most comfortable in letting AI just kind of run on its own with those harnesses and guardrails in place?

Rohit Parchuri: Yeah. Oh, that's a good question. You know, let me start with this. We talked about automated testing, right, autonomous testing, I should say. Autonomous testing does not mean unrestricted testing, right? The permission boundary or the scope have to be established or has to be established before you even start testing. So I think that's the homework we, you know, have to do as leaders and, you know, people who are executing the capability or the platform, for that matter. By doing that, you're allowing AI to operate independently on clearly defined scope with repeatable checks, but more importantly, the low-impact environments. I think that's the clear boundary that I would define at least at this point in time, based on, you know, what the maturity of AI pentesting is.

Rohit Parchuri

Rohit Parchuri: To be honest, I'm not fully confident letting it go all places, especially after we've seen the Hugging Face incident, you know, with OpenAI, you know, whatnot, and many more, right? So I would I would kind of limit the blast radius of what and where AI can operate. I think where human comes in is still would be those human high-impact environments and exploit chains, especially where there's, you know, an ambiguous behavioral relationship or a use case where, you know, you're trying to track multiple different things, but it needs human intelligence and decision-making to actually figure out what the finding or what the impact itself would be. And the other thing also is sensitive data. I spoke about this before. Anything customer data, anything that could compromise the availability of customer systems or data, that is, you know, absolutely sensitive for me, and there's no way, you know, I would let AI simply, you know, go at it. And the last thing I'll say is anything destructive for the business. This could mean like maybe having some destructive persistence. Memory persistence is something that we see with AI more often than not, depending on the model that you're implementing, like, you know, sometimes these models, you know, we don't even know what kind of model we're actually getting when a platform is kind of, you know, working through that. So I would put those, you know, kind of factors in to define, you know, what AI can do and with, you know, where a human can step in. I think, you know, a combination of AI doing what it does best is automated repetitive things and also validating in remediation, you know, checks, for example, building out, you know, use cases and allowing people to, you know, kind of, you know, take rather than us going back, like especially engineers in this case, rather than looking at unvalidated cases and, you know, and wasting their time on just going through that without getting into the remediation part, AI can easily do that, especially when you have a lot of volumes, you know, from vulnerability findings. But everything beyond that, I think a human, you know, definitely need to need to come and play there.

Rohit Parchuri

Ryan Rutan: Okay, and I'll add one more wrinkle to that. What about AI testing AI? Any thoughts about that?

Rohit Parchuri: Oh. AI testing AI. That's, you know, I think AI testing AI, like one thing we should also think about maybe in terms of testing AI itself, even before we get to the AI testing AI, it kind of exposes additional attack surfaces. Traditionally, like, you know, the way we do pentesting or the use cases we have for pentesting is much different than when you approach AI testing. You know, this could mean like, you know, things like prompt injection, indirect direct prompt injection, or cache poisoning, the MCPs depending on the architecture you have, right? The MCP itself, and also what MCP hides in the background, like the tools and API connections and credentials, AI identity, for example, that would be a big one, right? I think you have to think about the elements that are that are very specific to the AI way of operating things, but also don't forget about the traditional testing. You still have to bring that back in. I mean, OWASP does a great job at defining this, like they have this AI security verification standard. They kind of combine multiple things together, but they also suggest that, you know, make sure your traditional testing is enabled, but also add these elements for AI testing. So now going back to AI testing AI, that is not something I've thought through yet, but I feel there is a good use case on what the fall of AI itself is doing, right? I think once you map out what the AI system is doing, like the tools it's ingesting, the data, the supply chain it has access to, I think depending on that, you would either have an AI testing AI, I'll be a little more confident once I have a good map of those, especially in non-prod environments. But if it's a prod environment, a sensitive environment, then I would really not allow AI test AI. I would rather have a human being, you know, kind of come in and, you know, have, you know, some sort of independent validation, you know, to enable that. So.

Ryan Rutan: Nice. No, I mean, again, like it's a it's a crazy thing. Like, you know, you mentioned Hugging Face, you mentioned AI just doing whatever it wants and, you know, and again like I don't I don't think anyone knows the answer to that just yet, but I definitely think it's evolving and it's you know, good to get your take on it. So with that, let's take a little bit of a of a of a de- of a jaunt, if you will, on the other side to the blue side, I guess. I want to talk a little bit about Yext, you know, it's like what do they do, what problems are you trying to solve, how are you trying to solve them?

Rohit Parchuri

Ryan Rutan: Like help me understand like, you know, what's the, you know, what does your company do and then, you know, what is it you're trying to do for your company, I guess?

Rohit Parchuri: Absolutely. Yeah. So Yext is a business, we're a public SaaS company that provides enterprise software for our clients to build their brand and more importantly enable the brand, so their digital presence is, you know, essentially visible across multiple different channels, you know, make their brand more visible. But that also means we work with a lot of back-end network providers to enable that, you know, to enable the brand visibility to happen for our clients. So we're, you know, taking the that to network providers to enable, you know, this whole business model to operate. In terms of business, I think, you know, we're definitely on the growth curve, right? The enterprise growth, both organic and inorganic, both are happening. Definitely improving the engineering velocity to keep up with the business, like, you know, you name it, coding agents, you name, you know, just the GenAI interfaces and building SLMs to enable, you know, better things on the platform. We also came up with the agentic capabilities for marketing operations on the platform, which also is a significant change, you know, from how we operated in the past versus, you know, how we're going about now. And also, you know, between all this, we still have to keep the customer trust intact, right, especially at the pace, you know, now AI with AI, everything is supersonic, right? So we got to make sure that the trust is not, you know, broken while doing that. So that would be mostly my job. You know, adding on to the security problems, like within Yext specifically, or the things that we're trying to address, is definitely keep up, you know, just like how technology is keeping up with business, we also want to keep up with technology, right, with the with the pace at which they're going. So this would mean, you know, SDLC testing, you know, scanning, incident response, monitoring for things, both with AI, like both securing AI, and also AI, you know, helping out with certain security capabilities ourselves. So yeah, it's there's definitely a lot going on, no doubt.

Rohit Parchuri

Ryan Rutan: That's great. I think it's interesting you talk I mean, again, it seems like you guys are covering the full gamut, which is awesome. One element that I have that's kind of close to my heart a little bit is around because I've always about my the people I work with are all about creating the vulnerabilities to submit, right? And so I'm curious from an internal side, do you how much do you trust an AI agent to actually prove a vulnerability is exploitable without a human checking it? Like without being in the loop. Like do you need a human to be there to be like, "Yeah, that's real," or do you feel like AI can properly, you know, establish that a vulnerability is exploitable and then potentially give it the proper impact ranking internally to base whatever model that you decide to use?

Rohit Parchuri: Yeah. No, that's a great question. I think definitely not AI by itself. Like if AI is coming with an output, I would not just, you know, trust it just because the output came from AI. I think the trust trusting the evidence in proportion to the strength of its validation is what's important, not simply because AI agent produced it. You know, I think machine automated, like in this case AI evidence, you know, could be sufficient, you know, maybe for low impact and routine findings, which is okay to me. Like I think, again, just like we spoke about in the past, for any high impact environments, the findings there, which would mean that there could be a business disruption, which would mean that if I need to push the envelope to actually get the resources in place or get the remediation, you know, taken care of, I would need a human to help me out, and this is, you know, what my team and myself do to really kind of synthesize what AI provided and look through all the elements on how AI came to that conclusion.

Rohit Parchuri

Rohit Parchuri: This could mean like the traces and the logs on, you know, why it's saying like one finding is better, you know, one finding is worser than the other finding. And also independent verification. One thing I found with AIs is you have an agent, it spawns multiple agents. Okay, now do you know which agent actually did the work? Do you know which agent actually used a certain tool to actually get the work done? That is still it's kind of like S-BOM we used to have. You know, we still have it in the software side. We are still not we haven't still mapped this out, but AI-BOM is something would be beneficial. We would know like exactly where the tracing is happening, especially the transitive dependency tracing, and then we would know, "Okay, if it came from this tool, the logs are suggesting, you know, that this evident, you know, based on the evidence, this is a true vulnerability, and this is how it's coming up with a classification of some sort." I would have a human validate that, and then we could come to a conclusion that, "Okay, it's a high impact one, but we also want to make sure that this is taken care of in X number of days, because, you know, yada," but not because AI is producing it. AI is kind of, you know, helping me get to decisions faster, but it's not making its own decision, you know, maybe to put it to put it simply.

Ryan Rutan: Nice. No, I really like that that that tie-in, the BOM materials for or the sorry, the I always have a problem with that acronym, but, you know, establishing a BOM you know, print itinerary for an actual for a vulnerability would actually, again, not only help a human, but also, again, helps you train tools and create automations that will establish trust and help increase that signal. So I think that's a great point. Curious, 'cause it seems like you're kind of moving AI, like you mentioned about AI, you know, operating on the inside, and I'm curious like in terms of what role does AI play in terms of managing your risk forecast, or your risk-managing management process?

Rohit Parchuri

Ryan Rutan: I'm wondering like how are you using it today and basically helping kind of forecast the risk for your company, what role is AI helping accelerate, and then where is it maybe still require some hand-holding along the way?

Rohit Parchuri: Yeah, for sure. You know, I think for risk management, we do have a few models working for us to help out, you know, with what the outcomes for the risk are. So just to take a step back, like traditionally how we've done risk management is two different ways. One is if you're, you know, this all goes back to the risk catalog, right? We have, let's say, 250 different risk findings, we got to figure out how do we move forward with the remediation, or accepting the risk, or transferring the risk, you know, the whole gamut of, you know, how we treat a certain risk. But also what happened along the way is that it's very static, you know, it's a point in time assessment, point in time assessment. And also second, it takes a lot of work, because we're trying to map the frameworks, and I will talk about the frameworks in a little bit, we map the threat framework with a risk framework and then come up with some kind of conclusion that this is important, because it also connects to this business outcome. You know, business outcome could be that we are trying to make, ensure that the customer's happy are happy with the product, and more efficient with how they operate the platform. Okay, in order to do that, you also need to secure the underlying layer of the platform, which is exactly, you know, where the finding may be. But doing this processing and analysis and final synthesizing this, it could take months for people to do it. And I would have dedicated people just to do that. I think what a AI is helping me with is it's able to, you know, kind of take heavy volumes of data, right, ingest that, and also come up with distinct characteristics about what kind of outcomes we need to derive and make it polished in how we want to talk and communicate about these things. I'll take an example. So, you know, we had an incident in the recent past which, you know, which has to do with the third-party risk.

Rohit Parchuri

Rohit Parchuri: And third-party risk, you know, happened because the credentials, or, you know, I should say tokens in this case, you know, the access to the token was much more than what was needed. And this was something that was on the risk catalog all the while, and we did some improvements, but it wasn't completely remediated. So what AI allowed me to do that now is to, like I was talking before, it takes that incident data, because now it's realistic, it's not forecasted anymore, it happened, so it's a real risk, it got realized. So it'll take that, add additional weights to it, and also it uses the MITRE framework to help me understand the likelihood of what this could be, and then it uses the NIST framework on the other side to define what the impact and what the general maturity of a risk remediation would look like once we're done with it. So I think, you know, the different pathways and different channels that, you know, AI could help me with has been tremendously valuable, but again, still would take that, but we reduced about 60% of, you know, an individual's time in doing the risk analysis and, you know, as opposed to now the person would basically take the output from the AI and basically just put that into perspective for the business leaders to ensure that what kind of decision do we need to take, you know, going forward. And this applies to both the task forces that are actually getting the work done, because, you know, for them, it's also a matter of understanding what the problem is, but also we are using that to communicate to the board and the other leaders to talk about what the what is the direction and how are we coming up with the direction of risk management in general.

Rohit Parchuri

Ryan Rutan: I love the fact that it's about moving volumes of data, right? It's about, you know, creating 'cause again, it's whenever you're, you know, this volume of data is only going to increase over time, so again, you need to be able to find that, like, tools that can even take large chunks of it. So I guess as you do that, I guess what are some guardrails or some things that people might, you know, the industry I guess would say would want to implement in this case so that, again, taking the biggest chunk you can while minimizing the amount of risk in terms of like that you're introducing by putting technology into the loop here?

Rohit Parchuri: I think the biggest guardrail I can think of is just the human validation and human in the loop, at least for now, until we see a full maturity of, you know, how AIs can operate. I think it also it also takes some time for AI to understand the environment that you're working with, because you're also trying to connect or, I should say, overwhelm AI with a lot of different integrations . To make sense of what is it that you actually need and how does business operate within that need of yours and what direction you want to take collectively, and this collectively means not just CISO or CISO team, but also the other business leaders. Everybody has their own, you know, goals and ways to accomplish certain things. So I think when you have when the AI has a better understanding of that, it could come up with better outcomes, but until that point, I think the biggest guardrail I would definitely say is, you know, make sure human validates this and you have a way to communicate this, not simply taking the transcript from, "Hey, AI said so," and, you know, put that into the deck somewhere, but, you know, try to think through and reason between them, you know, between the findings and you actually need, you know, to remediate based on the outcomes you're trying to establish.

Rohit Parchuri

Rohit Parchuri: And also one thing I'll point out is, and I'm sure, you know, a lot of people have different emotions come out when we talk about risk appetites and risk thresholds, but I believe that happened because in the past it was very difficult for us to come up with a dynamic set of appetite scores. I think now with AI, we're able to do it fast and also make it more dynamic, that if you define a certain risk appetite for the organization based on the nature of the business you operate in, it's easy for you as you're doing this risk analysis as an outcome, you could also try to pull the risk appetite scoring methodology and use that as one of the levers, you know, for the business to, you know, kind of implement, you know, whatever that is you're requesting for. That is a part AI could still grab that info, integrate that into the dataset, but ultimately, you're still a human is responsible for connecting the two pieces together and talking, you know, to the you know, decision-makers about, you know, how we should proceed. The other one I'll also point out, and this is definitely more technical, but the identity part of AI has been a very, you know, a questionable thing in the industry now. Like usually the way it happens is you have a human running an agent, and it, you know, it it's taking your assumed identity and performing things, but it's not just that one agent, right? You're spawning multiple agents. Multiple agents are spawning multiple tools. So I think, you know, if you can come out, you know, can build, you know, some kind of a framework to ensure that any agent, any task for that matter an agent is performing has a distinctive identity, it would really help you out like to figure out like how what was the thought process in deriving a certain thing, or if something goes rogue, your incident response team would really appreciate all these details, so you would be able to, you know, kind of trace it back and figure out a good response and possibly recovery to it, depending on, you know, what happened.

Ryan Rutan: As you say that, the thing the theme that I'm picking up is human common sense and sanity injection. Is that how I would phrase it? Like making sure that that's always an ever-present in the process, and I can't agree more. Like I said, I'm willing to trust a lot to robots, but I'm not willing to like just hand over the keys to everything. So at the end of the day, I think, you know, I'm looking forward to hearing more about this, you know, in the future, and again, wishing you guys luck. As that as that, I'm going to close this out with a couple of things.

Rohit Parchuri

Ryan Rutan: I have one more question, then we have a little bit of fun at the end. So but in this question, I'm going to just ask you know, for your fellow CISOs out there, if there's one action item, or if you could give every security leader out there one action item for the next 12 months regarding AI, risk management, or say anything that we've talked about today, what would it be? What would be your guidance or recommendation for everyone to consider?

Rohit Parchuri: You know, I would say there's one thing you want to do, establish one continuous evidence-based validation loop for one critical business service, because this is exactly what risk management relies in, you know, and if you want to really have an effective risk management built in, with or without AI, this is very important. You know, identify like maybe, you know, make it more like a playbook thing, like identify important assets and attack paths if you haven't already. Validate which exposures are actually exploitable, right, not statically, but thinking about this more from a dynamic and realistic standpoint. Prioritize them using a proper business impact and risk, and if you have risk management framework, that makes it even more easier for you. And now comes the people part, right? You need to assign remediation owners and define deadlines, and then, you know, you would actually make a tremendous amount of success once you get that partnership defined. And, you know, and now within all this, try to figure out like where's these repetitive actions where AI can help you out, and then have an individual, you know, take that output and, you know, start filling out the blanks, you know, for it. So I would I would just put it at that.

Ryan Rutan

Ryan Rutan: Nice. Very nice. All right. Well, that's the end of the formal interview, but again, like I said, I don't like doing interviews without a little bit of fun injected in it. So, again, I've put together something that's kind of a bit of a social media element there. But I don't know if you've ever done like a bracket a kind of like a bracket to figure out what is your best or favorite of something. So given that we're kind of both hail or have origins in Texas at some point, I can't not talk about tacos. That's one of my things that I love to do. So what I'm going to do is I'm going to give you a choice between two choices. You're going to choose, and you're going to have four rounds of that, and then I'm going to have you take the winners from each of those rounds, and we're going to ultimately find out, subconsciously, what's your favorite taco. Does that sound good?

Rohit Parchuri: Sounds great. Let's fight.

Ryan Rutan: All right. All right, well, so to kick this off, the first round is going to be, in my opinion, one of the harder ones that I have for you, so apologies for coming out hot on this, but al pastor or carnitas?

Rohit Parchuri: Oh. I can't say both, right?

Ryan Rutan: You can't say both, sorry. There are no ties in this, unfortunately.

Rohit Parchuri: All right, we can't we can't this isn't, unfortunately, football or soccer, so everything has to have a winner, so.

Ryan Rutan: Next one is carne asada or barbacoa?

Rohit Parchuri: Carne asada.

Ryan Rutan: All right. Shrimp or fish?

Rohit Parchuri: Definitely shrimp.

Ryan Rutan: All right. And then the last one: pollo asado or chicken tinga?

Rohit Parchuri: Chicken tinga.

Ryan Rutan: All right. So with that, now for the next round, I've got al pastor or carne asada.

Rohit Parchuri: Oh my god. Al pastor, man, always wins.

Ryan Rutan: Okay, you're a man after my own heart right here. All right, shrimp and chicken tinga.

Rohit Parchuri: Definitely shrimp.

Ryan Rutan: All right, so now we've got the finals here. You've got al pastor versus shrimp. What are you taking? You got a free taco to add on to your order. They're saying you can have one. Which one are you putting in the basket?

Rohit Parchuri: Making it difficult by the question. Al pastor.

Ryan Rutan: All right, man. So, all right, you and I are both of one of the same cloth, so al pastor, pork and pineapple in a wonderful corn wrapped tortilla street taco, so. All right. Rohit, this has been a pleasure talking with you. It's been a great conversation. Looking forward to learning more about Yext and you and how in the future of your career. Wishing you the best. With that, my name is Ryan Rutan with the Synack Red Team, closing out this We're In Podcast. Hope everyone stays secure. Bye.

Rohit Parchuri: Thank you, guys.

Ryan Rutan

So I think it's pretty compelling. And again, I'm excited to to learn more about it and and follow along on the the NATJack journey, if you will. Do you have any of others you wanna talk about without... Regarding NATJack? Otherwise, I have a couple of questions I wanna ask you to kinda wrap this up. One of them might just kinda be a little bit a hot seat thing, but other than that, you know, wanna give you a chance to talk about anything that you might have left unsaid about your research.

Malcolm Stagg

Sure. Yeah. So I talked kind of about two main attacks, the UDP DNS hijacking and the TCP hijacking. I also, I developed two other attacks as well. I I did finally get the thing I was trying to work on initially to work where I could send enough packets to fill up the NAT table in the router, so that no other data could be sent or received. So that was kind of one of the more straightforward attacks, pretty much. But the effect of that is just a denial of service, basically, to anyone that's behind that same router.

Malcolm Stagg

And there was also one more attack I developed as well, an information disclosure attack. Because I found, in one of the cases for the TCP hijacking, I would need to identify which port was used for the connection between the client and the server. I didn't need to know that for one of the attacks because it just ran fast enough that I could cycle through all those ports. But other attack did take a little bit longer. So I had to first identify what that port was. So I've also got a method for doing that. It's based on two behaviors that are a lot of not some use, which are called preservation and endpoint independent mapping.

Malcolm Stagg

And so basically, those are just the port assignment behaviors of the router, pretty much. So I found that I could exploit the way that routers and NAT systems assign ports to basically determine which port is currently being used for a a connection.

Ryan Rutan

So you're saying technology has habits that are predictable. So...

Malcolm Stagg

Yes. Definitely.

Ryan Rutan

Okay. We should all run for the hills at this point. So... Yeah. Alright. Well, hey. Well, I had a couple questions I wanna ask because one, think it's actually kinda funny because, you know, I think, you know, you've been around the block for a while, same same as me. And I know that there was a big moment back in time where we said, you know, I p v six, it's gonna save the world, or are we gonna stick with IPv4 and then that? And I'm just curious, like, where were you in that argument back, you know, maybe fifteen, twenty years ago when when all that was going down? And then secondly, you know, where do you feel like IPv6 is... You know, would help solve this or mitigate this? Or, you know, where does that play in this in this conversation? And, again, the laugh right there just gives me everything I need to know right there. So... But, yeah, I'm curious to know where you land on that.

Malcolm Stagg

Yeah. Thanks, Ryan. Yeah. Yeah. You're you're you're absolutely right. Yes. So so IPv6, definitely, that was another method that was intended to replace IPv4, and the limitation that you can only have the 4,000,000,000 IPs at the same time. So definitely, if there were more universal use of IPv6, that would definitely help to mitigate the attacks. But it seems anything with technology involving the Internet, seems to move extremely slowly. Because you always have to manage the backwards compatibility, that there's still things that don't support the new technology.

Malcolm Stagg

And I think that's been the main thing preventing more widespread use of IPv6. Now, from what I do understand, a large portion of traffic over the internet now does use IPv6. But until that's closer to 100%, I don't think routers and NATs and all that stuff are going anywhere, though. And I should point out as well, though IPv6 doesn't technically need NAT, it often is still being used with NAT. So just using IPv6 doesn't necessarily solve all the problems unless kind of the older infrastructure that uses NAT and IPv4.

Malcolm Stagg

If that were tired, then that would probably help to like solve it.

Ryan Rutan

Nice. Yeah, it's like I p v six is great. You know, it's like in this concept, like, I forget the even the number it was like, so big. I was like, I've lost track of over time. It's one of those trivia things that you want for like, you know, pub trivia. But at the end of the day, you're always gonna have the internal and external component and a translating element there that sits between. I think really interesting. Any time an IPv4 problem shows up, the IPv6ers come out and say, you see? So I thought it I thought it would be an interesting conversation.

Malcolm Stagg

Yeah. If if you don't mind me me saying what

Ryan Rutan

what

Malcolm Stagg

what what thing up. So so like my initial research into this attack was all based on Linux and the Netfilter library. But as I kept on on going further into it, I found that almost all the flaws I found, they weren't limited to just Linux or just Netfilter. So I was looking at a lot of unique NAT implementations. And almost all of them, they had the same flaw. So it affects Windows. It affects Mac. It affects a whole lot of cloud stuff as well that's not based on those same libraries.

Ryan Rutan

Alright. Well, you can't leave a haymaker like that at the end without at least one more question then. So we've talked a lot about the impacts of this, all the ways in which it can be bad or misused or whatnot. I'm curious, I know that you also have been putting together a list of mitigations, best practices, things like that. I was wondering if you could share maybe the top couple of ideas from that list, and then maybe kinda tell us where we can keep up and follow along to of... What's the best way for people that are interested in this topic to stay educated and stay up to speed on how to assess their exposure and or how to put their best foot forward to try to mitigate any impacts to this?

Malcolm Stagg

Sure. So at this point, there have been a few patches released by vendors. But for the most part, for the time being, a lot of NAT systems are still going to be vulnerable to a lot of these attacks. So the mitigations that people can do on their own, they definitely are very important at this point. And probably the best mitigation overall is just the use of strong in encryption, like using a TLS, like HTTPS, just anything where the traffic is encrypted.

Malcolm Stagg

So even if an attacker manages to hijack that traffic, they can't access anything, pretty much. So I would say that's probably the number one mitigation, is just the use of strong encryption. Then there are several other mitigations as well. I would recommend, if your router supports it, to prevent clients from spoofing their IEPs. I think the name of that is sometimes called IP source guard. So it just kind of adds an extra layer of protection there. And another one is limiting the number of NAT table entries that each client can make. So those are just a few kind of common sense things that you can do with your router at this point to help.

Malcolm Stagg

If you're using containers and virtualization, it's always best if you can avoid it, avoid running the container as root. Just kind of try to lower the permissions there as much as possible. And there's one capability that's enabled by default that allows the use of raw sockets. I would recommend just turning that off if you can. So for containers and virtualization, those are a few things that would possibly help an attack. I'm launching a website that will explain more about the attack, and it will have list of of ways that you can help to to mitigate it.

Malcolm Stagg

The website's gonna be live at natjack.

Ryan Rutan

Alright. And that's natjack.io. Just making sure. Alright. Sweet. Well, Malcolm, this has been a fun time. Like I said, I I could... You know, you know me. I can talk forever. And and more importantly, especially when you're talking with people that have a lot of fun stuff to say. So any closing thoughts or otherwise, we can wrap this thing up. And like I said, we'll... You know, looking forward to hearing you talk about this over the next couple of weeks and seeing where this goes.

Malcolm Stagg

Thanks, Ryan. Yeah. I don't think I have too much else to say. But, yeah, I've just really appreciated all my time. I'm getting to learn more about cybersecurity on the SRT and just exploring all fund targets. Yeah, it's it's it's it's been a a, like, blast.

Ryan Rutan

Sweet. Alright. Well, we're going ahead and wrap up... Wrap this up. But I do wanna say thank you, Malcolm, again for spending the time with us today to talk about NATJack, talk about your origin story, talk a little bit about the SRT, and a little bit about DARPA. So, with that, we're gonna wrap this thing up. For anyone who wants to keep and check out more stuff about the SRT, check out synack.com/redteam. And, this is WE'RE IN podcast brought to you by Synack.