The Difference with AI Red Teaming is We Added the Word AI

Is AI red teaming simply a more specialized version of something we already understand? Or do we need to think differently about the risks in LLMs? Do any of our existing tools and methodologies still hold value?

This week’s episode is hosted by me, David Spark, producer of CISO Series and Andy Ellis, principal of Duha. Joining us is our sponsored guest, Khush Kashyap, senior director, GRC, Vanta.

Got feedback? Join the conversation on LinkedIn.

Huge thanks to our sponsor, Vanta

Vanta automates key areas of your GRC program—including compliance, risk, and customer trust—and streamlines the way you manage information. A recent IDC analysis found that compliance teams using Vanta are 129% more productive. Get back time to focus on strengthening security and scaling your business at vanta.com/ciso.

Full Transcript

[Voiceover]  10-second security tip. Go.

[Khush Kashyap] Don’t chase every risk at once. Focus on the few that could truly break your business and communicate them in business terms. 

[Voiceover]  It’s time to begin the CISO Series Podcast. 

[David Spark] Welcome to the CISO series podcast. My name is David Spark. I am the producer of said CISO series. And joining me, a legendary CISO. And by the way, I want you to know that I’m the one who gave him that title. I don’t know if anyone else has called it, but I believe this to be true.

A legendary CISO, none other than Andy Ellis. Andy, say hello to our audience. 

[Andy Ellis] Hello to our audience. See, this doesn’t work as well as the whole good morning, good afternoon, good evening thing. I got to work on this. 

[David Spark] You know what? Nobody cares about that at all whatsoever. [Laughs]

[Andy Ellis] I do. 

[David Spark] I know. You know what you’re doing? You’re fighting to find your Johnny Carson golf swing. 

[Andy Ellis] I am. I don’t have that moment yet. 

[David Spark] [Inaudible 00:01:04]. By the way, I’ll throw this out to the audience. If you want to recommend [Laughs] what Andy could have sort of his welcome, his sign off, whatever it is going to be, to be the equivalent of his Johnny Carson golf swing.

For our younger viewers or younger listeners, look it up. [Laughs] I will say that, look it up. 

[Andy Ellis] Look it up. 

[David Spark] We’re available at CISOseries.com. Our sponsor for today’s episode, a spectacular sponsor of the CISO series. We adore having them on board. It is Vanta. Automate compliance, manage risk, and accelerate trust with AI. More about just that a little bit later in the show.


But first I’m going to ask you this question, Andy. And I just attended one of these recently. And here’s my question. Within the first minute, maybe I’ll give you two minutes, of a panel session, how do you know it’s going to go south? What’s a telltale sign?

I have my answer to this, but I want to know what you…

[Crosstalk 00:02:00]

[Andy Ellis] If you’re within the first minute, only the moderator has spoken, right? So you have to… Just based on the moderator if you’re going for that one. But for me, the single biggest one is when it’s very clear that the moderator doesn’t have a storyline they’re going to tell, which can be they ask a question to anybody on the panel.


No, no, your first question, you’re naming somebody on the panel, they’re going to answer it. Very similar to how we run the podcast where you toss to me, you toss to our guests, maybe then you toss to the guests, you toss to me because you have a storyline.


If a moderator does not have a storyline on a panel, I know it’s going to be a disaster, even if there might be a great panelist. But it means this is not a panel, it’s a bunch of individuals who happen to be orating near each other. 

[David Spark] That is very good. And I agree with you that that is bad. But I think, I know…

[Andy Ellis] Okay, we can just cut the recording right there. 

[David Spark] Cut the recording. David agrees. But I think far, far worse when you hear about this way before, and I’ve said this before, and it drives me bat S crazy, is when the moderator goes, “All right, why don’t you all introduce yourself?” 

[Andy Ellis] Yes, I know that’s one of your pet peeves. 

[David Spark] I want to scream, I want to truly scream when that happens. And I just want to stress, there is not a single talk show host on television or radio who does this, not a single one in the history of all media. They don’t do that for the sole reason it’s horrifically unprofessional.


[Andy Ellis] Well, not only is it unprofessional, you’re putting somebody on the spot. Like, look, I will call myself legendary CISO. So I thought that was funny [Laughs] when you nicknamed me that. I put it on my black cap badge. I have enough healthy ego that I can get away with that, and I’m happy, and people make fun of me.


[David Spark] And there’s a story being that I’m the one who gave you the name. 

[Andy Ellis] And there’s a story. But I’ve done panels where I’m the moderator, and somebody sends me their bio and they downplay everything they did. And I go look them up and I’m like, “This person is amazing.” And if you ask somebody to introduce themselves, they’re going to be very timid and they’re going to downplay.

Whereas you have the opportunity to say, “Look, I have this person on the panel because they’re the field’s medalist in this discipline.”

[David Spark] 1000%. Because first of all, two things. People feel better when they are introduced and people talk them up. Second of all, if you’re the moderator, it’s your show. You invited these people here. It’s like, when you say, “Introduce yourself,” like, “Who are these four yahoos?

Explain who you are.” [Laughs]

[Andy Ellis] Yeah. I think the challenge is that people who are moderating think they’re running a round table. Like, in a round table setting, where I’ve got 15 people, it’s fine for me to say, “The first time you speak, introduce yourself. And if you introduce yourself with just your title, but we’re going to ask a question later, then give your full intro.” That’s fine, round table setting with no audience.


[David Spark] Yes. Yeah. That’s a different story. 

[Andy Ellis] It’s very different. But I think people bring that habit in. 

[David Spark] By the way, I have lots more complaints about panel sessions, but that’s the doozy. And I just can’t… And never in the history of time has anyone begun a panel session asking people to introduce themselves was it a good panel session.

It’s consistently awful because they didn’t know what they were doing out of the gate. 

[Andy Ellis] Yeah. I will say there are amazing moderators out there. I like to think I’m pretty good at it.

[David Spark] I also think I’m pretty good at this.

[Andy Ellis] If you’re going to do a panel session anywhere, then you should get a professional moderator, not just a good speaker, and say, “Hey, we want you to do this.” You’re doing a webinar. You should have a professional who knows what they’re doing.


[David Spark] You’re running the room. 

[Andy Ellis] You want somebody who runs the room.

[David Spark] Again, people don’t think that they have to run the room. Anyway, plenty more about this. 

[Andy Ellis] And I’m for hire if anybody needs a professional moderator. So is David. 

[David Spark] Plenty more on this coming up later. All right. Let’s bring on our guest. So it’s the first time she’s been on any of the CISO series shows. So thrilled that she’s here. It is the senior director for GRC over at Vanta, our sponsor guest, none other than Khush Kashyap.

Thank you so much for joining us, Khush. 

[Khush Kashyap] So happy to be here. 

Are we having communication issues? 

5:53.559

[David Spark] Quote, “Executives want clarity, not a TED talk,” said Will Klusovsky of Appalachia Technologies. Too many security professionals lose executive attention to smartphones and glazed-over stares. He laid out some basic principles for security professionals when talking to executives such as focusing on risk, revenue, reputation.

Oh my god, this is your language, Khush. 

And all of these tips focus on brevity, visual impact, and commanding the room with confidence. So I’m going to start with you, Andy, though, on this. What’s worked best for you when presenting to the C-suite? I know you got a lot of experience here.

And, more importantly, which of those lessons did you have to learn after seeing someone’s eyes glaze over in a meeting? Did you get a signal like, “Oh, I’m losing them”? 

[Andy Ellis] Oh, I’ve certainly gotten that signal a lot in my career. And I think the most important thing is what matters to you is not what matters to them, right? People are so tied into what I know, what I believe. It’s all about what the other person believes.

If this risk is not real to them, it doesn’t matter how long you go talk about it, it’s never going to resonate. 

And so every one of Will’s suggestions is amazing. By the way, people should go read that LinkedIn post. It’s really quick, very brief, as important. But there’s one he misses, which is you should recognize that executives are like computers that are way overworked, right?

They’re constantly context switching. 

The moment you start speaking, they have no idea who you are, let alone what you’re talking about. It takes them a few minutes to page in context. You might have talked to them about this problem a month ago. They do not remember that conversation. 

So if you walk in and you continue from where you were last time, you’ve lost them. So you have to sometimes say, “As we mentioned before, X, now Y.” You don’t just lead in with Y. You always give them an opportunity to page back in what the problem is, what we’re talking about, what the foundation is.

Don’t treat them like toddlers, but recognize that they have the attention span of a toddler. 

[David Spark] Right. And I also refer to this, I call this often the curse of knowledge. You are walking in the room with everything already in your head, and you kind of have this assumption, “Everyone’s up to speed where I’m at, right?” And they’re not, usually.

[Laughs] 

All right. Khush, I throw this to you. Same thing, talking to executives. And I’ll kind of ask the same question I asked of Andy. Did you have one of these “Oh, I’m losing them” moments, “I have to switch gears, or for the next time I do it differently”?

Let us know. 

[Khush Kashyap] Absolutely. Most security professionals are so incredibly smart and technically strong. What happened with me was much earlier in my career, I thought being thorough meant walking through every control, every risk scenario, every framework.


About three minutes in or so, I would notice phones coming out, eyes glazing over, and I realized I was losing the room. That was a very humbling lesson. And what I came to understand is that’s not what executives are looking for. They don’t want a lecture.

They want clarity more than anything else. 

So it’s definitely all the knowledge that we have in our mind, how do we distill it for the audience who’s sitting in front of us, and how do we make it as relevant for them as possible? 

[David Spark] Very, very good point. All right. So I’m going to ask you, closing this out, quick one or two tips to sort of capture the audience, and maybe a tip of keeping them engaged when you’re a few minutes in. Andy?

[Andy Ellis] So I think the first one is recognize what you need them to believe at the end of this conversation. What are you trying to get out of this conversation, and how is everything you’re saying driving towards that? Because if you don’t know what you’re trying to achieve, they certainly aren’t going to fill it in for you.


[David Spark] Khush? 

[Khush Kashyap] On top of what Andy mentioned, I would say also try to clarify what’s the real business impact if something or the risk or the incident materializes. How much would it cost us? And what can we do about it? Make the business context into your talking points.


[David Spark] I will also throw this out. Have a trial run in front of another audience. I’ve done this for really short, sub 15 minute presentations I’ve done. And I must say, I remember doing it… Because I really wanted to nail it. I did it five different times in front of five different audiences, and I swear, what it was the first time versus the fifth time, night and day.

The feedback I got was phenomenal. 

[Andy Ellis] Absolutely. And different audiences is important. One of the biggest sins of security professionals is they do all their prep work in front of other security professionals, and then they go talk to somebody who is not in security. And so you didn’t get an audience that didn’t have your knowledge.


What works? What’s not working? 

10:43.293

[David Spark] How do you react when your staff brings you a problem? Now, your first instinct might be to be a problem-solver. Instead, Elizabeth Lotardo in a Harvard Business Review piece suggested asking, quote, “What have you tried?” So, asking the individual.


It’s always tempting to jump right into the solution mode. “Well, you need to go do this, this, and this,” you know, kind of thing. But Lotardo argued that constantly solving your team’s problems robs them of chances to develop skills and creates dependency on you.


So sounds like great advice. But how much can we apply this to the realities of cybersecurity? I mean, when there’s an active incident, you don’t always have the time for teachable moments. So when do you coach versus command? And I’ll ask you first, Khush, how do you know when it’s time to abandon the coaching and solve the problem yourself?

Give us scenarios what it is. And do you do this yourself? 

[Khush Kashyap] I think it’s all about the context. Understand the context of what you’re trying to solve for. Is it an active incident when you don’t have the luxury of turning it into a teachable moment? Or are you staying in that [Inaudible 00:12:00] all the time?


Because people would bring me a problem, and my instinct was to solve it on the spot because it felt faster and more efficient. But however, the downside was that my team wasn’t getting the chance to build their own judgment. And over time, I realized that if I kept solving everything, I was creating a dependency problem rather than a capability among themselves.

[David Spark] And they would come running to you or running to others at the same time.

[Khush Kashyap] Yes. And that’s when I started practicing the discipline of asking, “What have you tried? What options do you see? What worked well? What didn’t work as well?” It was surprising how often they already had good instincts. They just needed a space to validate them.

And when you give people a chance, they grow, the team becomes much more resilient. 

[David Spark] And you bring up a very good point of asking questions. And I’m going to throw this to you, Andy. Often people’s success is they don’t know what questions they should be asking or answering for that matter. I mean, I know I’ve run into this when I tried to do something that I was out of my comfort zone.

And I remember someone hitting me with all these questions, and I realized, “Oh my God, I’m not ready for this at all,” kind of a thing. “I didn’t even think to ask these questions.”

[Andy Ellis] So Matt [Phonetic 00:13:17] Ringles, a co-worker I used to have, he had what he called the 15-minute rule. And he said, “First you must try, then you must ask.” He said, “You have to try to solve a problem for 15 minutes. Then you can go ask for help.

But before you ask for help, you have to write down what you tried, what you know, what your question is.” 

Partly so that you preempt that conversation when somebody says, “Have you tried? Have you tried? Have you tried?” You walk in and you say, “Look, I’m having a problem with X. Here’s what I have done, here is what I know. Now what should I do, or what’s next?” 

So it helps you… It also means when somebody asks you novel questions, you can update your own model for that process at the end of 15 minutes. Because what I love about it, the number of times that I have hit a wall and then I stopped and I said, “What do I know?

What have I tried?” and I solved the problem in that step. That I had already solved the problem and just hadn’t realized it. And so it creates this discipline. 

The flip side of this, which I also want to talk about, is certainly as you get more senior in the organization, you have senior people working for you, sometimes when they bring you a problem, it’s not because they need help solving it. Sometimes they’re bringing you a problem so that you’re just forewarned.


They’re telling you, “Hey, I’m having this issue with a colleague,” whatever. They don’t need you to do anything. They’re just telling you, so in case that colleague escalates, you’ve heard it from your team before you hear it from somewhere else. 

Sometimes they bring it to you because they need a therapist. Like, “I am so pissed off at this person I’m working with. I just need to tell somebody, and the only safe person to tell is my boss, so I’m telling you.” So I have found it to be really helpful when somebody brings me a challenge to say, “What role do you need me to play?

Am I solving the problem for you? Am I coaching you through it? Am I your therapist? Or am I just hearing an escalation.”

[David Spark] This is also good parenting advice when your kids come complaining. 

[Andy Ellis] Oh, absolutely. 

[David Spark] Before we go any further, I do want to tell you about our spectacular sponsor. And that would be Vanta. Automate, centralize, and scale your GRC program with Vanta. If you’re not already have Vanta on your radar, you should be checking them out.


Vanta’s trust management platform automates key areas of your GRC program, including compliance, internal and third-party risk, and customer trust. And it streamlines the way you gather and manage information, and the impact is actually… It’s real.


A recent IDC analysis found that compliance teams using Vanta are, get ready for this, 129% more productive. So get started at Vanta. Go to vanta.com/CISO. The reason you want to do vanta.com/CISO is they know that we sent you there. And they know that they love sponsoring the show.

So please go to vanta.com/CISO. 

It’s time to play “What’s Worse?”

16:00.026

[David Spark] All right. You know how this game is played, Khush? 

[Khush Kashyap] I think so. 

[Andy Ellis] Your goal is just agree with whatever I said. 

[David Spark] No, don’t agree with whatever he says. Your goal is to answer it as truthfully as you would like. So essentially, it’s a risk management exercise. And you talked about risk at the very beginning. So you’re going to answer which is the worst scenario in terms of risk here.


All right. This comes from Dustin Sachs of CyberRisk Collective, which he’s contributed lots of wonderful What’s Worse? scenarios. Just so you know, Khush, I make an Andy answer first, and you can agree or disagree with him. I love it when you disagree.


[Andy Ellis] I love it when you agree. 

[David Spark] Here you go. Very short. Two scenarios. Scenario number one. Not having visibility into your OT environment, operational technology, or not knowing all the vendors your company has contacts with, essentially shadow IT, which one is worse.


[Andy Ellis] So I hate to start with “it depends.” 

[David Spark] By the way, I’m telling you right now, Khush, “it depends” is not an option. 

[Andy Ellis] It’s not an option. So I’m going to say that 90% of the time it’s going to be one of them, and I wanted to tell you the 10% for the other one. 

[David Spark] Right. Because some companies have no OT whatsoever. 

[Andy Ellis] Right. Yeah. I’m going to say that for 90% of the companies, it is worse not knowing who your shadow IT is. Because that’s how you run your business. Your business is run on IT, on SaaS. You don’t know who these people are, that’s going to be your bigger problem.


There’s 10% of you for whom, “No, no, no, that’s not true.” Mostly OT companies. If you’re a manufacturing business, everything you do is probably OT. That matters far more for you. So that might arguably worse. 

[David Spark] Right, it depends on the actual business itself. 

[Andy Ellis] Yeah. If you don’t know that GE is running all of your power and all of your manufacturing equipment, you have serious issues. But I’m going to say that’s not the norm. So I’m going to go with it’s much worse to not have visibility into the way in which you actually operate your business.

Because at this point we’re all IT and SaaS companies, and not having visibility there matters far more than not knowing who your HVAC vendor is. 

[David Spark] But if you’re running the electric grid…

[Andy Ellis] If you’re running the electric grid, you are an OT shop, in which case your shadow IT is your OT. But I must go with shadow IT is the bigger challenge.

[David Spark] But hold up. But your shadow IT is your OT. Would that make them equal problems here? 

[Andy Ellis] Well, no, no. Sorry. [Laughs] What I’m referring to at that point is the concept of shadow IT. Your only IT is the electrical grid is the electrical grid, which is OT. So at this point, I could make an argument that shadow IT is the same thing as OT at that point, but that would be silly.

Let’s just go with shadow IT for the vast majority of our listeners. And those of you in manufacturing and power can tell me I’m wrong, and I’m wrong inside your context. 

[David Spark] Yes, so “it depends” definitely plays a good hand here. I will agree on that. 

[Andy Ellis] Yeah. 

[David Spark] All right, Khush, do you agree or disagree with Andy? 

[Khush Kashyap] I completely agree. 

[David Spark] Completely agree. Oh, Khush.

[Andy Ellis] David hates those. 

[David Spark] I’m so disappointed. [Laughter] All right. Why do you completely agree? For the same reasons or other reasons? You can agree for different reasons. By the way, to me, that’s like disagreeing. 

[Laughter]

[Khush Kashyap] I do agree. The supply chain attack surface is a big, big problem for all industry verticals. And I do think for the mass majority, shadow IT does pose a more imminent threat. Just like the industry verticals and the companies who rely on OT and OT security is a strong capability for them are far and few.

And that’s why for the majority of them I completely agreed with Andy on it. And that’s why option number two there.

[Andy Ellis] Yeah. I think seven years ago, if we go back to pre-COVID times, we would have anticipated having a different answer. Because at that point almost all IT was in-house, in your building, there was a very little SaaS, and the SaaS that was there was all big companies.

Like, “Oh yeah, we had Salesforce.”

[David Spark] Oh, you’re just saying seven years. I would go even further back than that. 

[Andy Ellis] No, I actually think only seven years ago, SaaS was not something… Look, I was investing in SaaS security seven years ago. People thought I was insane. Like, “Who would have this much SaaS?” But yes, I had 500 SaaS vendors seven years ago.


But even then, we really thought that OT was going to be our biggest blind spot, that we really would care about all the OT in our corporate headquarters. Guess what? Most companies don’t have headquarters anymore. So I think the shift in COVID, the enablement of everybody to buy SaaS, that, yes, started more than seven years ago.

But I think seven years is where we still believed OT would be the bigger risk, and now it’s clearly not. 

[David Spark] Well, those in OT would argue with you. 

[Andy Ellis] I’m not saying it’s not a risk, just to be clear. This is not a binary of only care about one.

[David Spark] But others would tell you, like, “If the water stopped pumping or the electric grid goes down, you got a way bigger problem than who’s using a different version of Dropbox.”

[Andy Ellis] But I’m not worried about the OT in my house, or my headquarters depriving me of water.

[David Spark] Correct. 

[Andy Ellis] I’m worried about my next-door neighbor cutting into the water main. This happened to me over the summer. I lost water. [Laughs] Wasn’t my OT problem. It was my utility. 

[David Spark] [Laughs] What happened to your neighbor? What did they do? 

[Andy Ellis] They were doing construction, and they cut into the water main. They were trying to widen their main. And occasionally when you do this, you sort of screw up and you cut right into the main. So they had to shut off water for our whole neighborhood.

And so we’re all out. And it’s one of the hottest days of the summer. And so, all of a sudden, they’ve got 12 people come out of their houses and going, “When do we get water back?” And they’re like, “If we knew, you would already have it back.” 

[Laughs]

Please, enough! No, more! 

21:49.760

[David Spark] Our subject today on Please, enough! No, more! is risk quantification. We just played it with What’s Worse? And I’m going to ask you, Andy. I know you’ve got tons of opinions on this subject. What have you heard enough about with risk quantification, and what would you like to hear a lot more?

So what’s going right and what’s going wrong, and where would you like it to go? 

[Andy Ellis] So I think that there’s this underlying problem under the risk quantification space that people functionally believe that humans and organizations are “rational decision-makers,” and I’ll put that in big giant air quotes, which is all you have to do is present an equation that says that we will get more out of our investment by doing this, and therefore we must do it.


And that presumption just underlies everything. Like, “If we can get better at our estimates, if we can have more data, then.” Here’s the reality. Almost nobody is making quantitative decisions anywhere in the business outside of very narrow industry verticals.

It all comes down to the belief sets of executives. 

And then if you don’t make them believe about a risk, it does not matter if you walk in and say, “This is an $80 million risk,” because they can always find one thing wrong in your equation, at which point they get to ignore everything you said. 

So you have to play to their beliefs because what you’re really trying to do is change their worldview. You do not cause someone to make a different decision by presenting them with a perfectly logical case. Very few people operate in that. You get them to make a different decision by having changed the way they view the world such that this new decision makes sense to them.


[David Spark] I like that. All right. I’m going to ask you the same question. You can feed off of what Andy said or not. What have you heard enough about with risk quantification, Khush, and what would you like to hear a lot more?

[Khush Kashyap] I want to talk about a different methodology and approach of risk quantification that I agree and don’t agree with. For me, I’ve heard enough about risk quantifications being dominated by fair models that fixate on asset values, key risk scenarios, and then layer on Monte Carlo simulations and more statistical modeling.


Don’t get me wrong, these models have value. But too often they get so academic that they paralyze the conversation. You spend months, I have seen companies, years, debating assumptions. And by the time you produce a number on some key risks, that business has already moved on.


I would also say no to the notion that this is the only credible way to do quantification. The pursuit of precision can sometimes take us further away from actually helping executives make better decisions. What I would love to see more of is using more data that’s outside of our purview.


For example, using the depth of cyber insurance data because it reflects real-world incident losses and claim payouts. And then contextualizing that data for your own environment. That gives you a grounded, credible baseline to talk about risk in financial terms without over-complicating it.


Honestly, the space is ripe for transformation. For too long, risk quantification has been about building models that impress security folks, but fail to resonate with executives. It’s time we flip that. Make the output simple, relatable, and rooted in business reality.

I also want to say one thing to Andy. Risk quantification doesn’t need to be perfect. It needs to be useful. 

[David Spark] All right. By the way, Andy loves you. 

[Laughter]

[Andy Ellis] Yes. I don’t want to be inappropriate, but oh my God, I have the biggest work crush ever right now. 

[David Spark] By the way, I may just grab that clip of you, Andy. Just the video of Andy, just the way he was falling over, laughing. Oh my God. I’ve never seen Andy agree with someone with his body language more than what I just saw there. [Laughs]

[Andy Ellis] Let me just say that we need to take what Khush just said and frame that. Hang that in the Smithsonian. 

[David Spark] By the way, there will be a transcript of this episode. 

[Andy Ellis] Make it a requirement of everybody who has a CISSP needs to read that. That entire monologue is so correct. Normally, I’m here disagreeing with everybody in the risk-quant space, everything someone says. That’s it exactly. Risk quantification doesn’t need to be more accurate, it needs to be useful.


[David Spark] Okay. So I want to hear your feedback to that line because I like that line. But I’ll be honest, I don’t fully understand what that means. What does it mean that it doesn’t need to be accurate, but useful? Obviously, I’ll ask you, Khush.

But first you, Andy. 

[Andy Ellis] So the challenge is people try to get to precision. They try to say something like, “This is a $40 million risk.” And now the problem is the moment you say it’s a $40 million risk, everybody’s like, “Oh my God, is it really 40? Is it 39?

Is it 41?”

And so you keep fighting over precision and accuracy when look, here’s what matters. This is the biggest risk. Why is it the biggest risk? Because these crown jewels are at risk from a credible threat that can do this. You tell the story. The point of risk quantification was not to get to a number that you delivered.

It’s an interim step for you to look at and say, “Oh, $40 million is bigger than $30. Let’s go look at the $40 million risk.” 

But now I have to sell it. And if I’m selling it to somebody who wants to hear $40 million, I use $40 million. If I’m selling it to somebody who wants to hear the fairy tale of how Little Red Riding Hood is getting lost in the woods and eaten, and that’s going to cost 40 million, I tell them the fairy tale.

I don’t mention 40 million. It’s about the utility of getting somebody else to believe in the risk and invest in it. That’s what matters. This number is completely irrelevant without action. 

[David Spark] All right. I’m going to ask the same question I asked Andy. And I want to know your take on the same question of, what does it mean? I mean, I think Andy gave a good answer, but I want to know if you want to add or double down or edit. What does it mean you don’t have to be accurate, you have to be useful?

What is that useful versus accurate mean? 

[Khush Kashyap] Yeah. Because as I was saying before accuracy comes for certain people who have been in this space for a long time following very precise models, applying statistic, probabilistic reasoning to a lot of the numbers for few critical risk scenarios going to asset impact quantification and whatnot.


If you steer away from that and focus more on Andy’s points around what is the business value? What are your crown jewels? What is it that is keeping the executives and the leaders stay up at night? Focus on the so what, focus on the key risk, focus on why it’s important for us to come here and talk about them, and where our investments are already there where they need to be and where they need to be made further.

I think that is a much better conversation than fixating on the numbers and the accuracy and the modeling and the academic side of things. 

What about this AI security challenge? 

28:58.933

[David Spark] Is AI red teaming really that different or just a specialized version of what we’ve always done? Patrick Sullivan of A-LIGN makes the case that it deserves to be treated as something new. While traditional red teaming focuses on breaking into systems to test security controls, AI red teaming examines what comes out, testing whether models behave fairly, safely, and as intended.


He breaks down three risk layers: bias training data that creates stereotyped outputs, model decisions based on probabilities rather than fixed logic, and where users can manipulate responses through prompt injection. AI risks aren’t just about external attacks.

You’re trying to figure out what the model learned to do without being explicitly taught. 

So he makes some really good arguments that it’s very different. There’s a lot of new behaviors here. So, Khush, does that distinction make sense to you, and what shifts have you noticed in red teaming methods even in recent months as this tech is changing.


And just also a point, I had three meetings in the first day of Black Hat this year where they were all offering sort of automated continuous AI red teaming, and they were all saying exactly the same thing and just saying, “Oh, but we’re better than them.” And I had to believe them.

[Laughs] So what’s your take here? 

[Khush Kashyap] Yeah. So I do think that AI red teaming deserves to be treated as something distinct. Traditional red teaming is absolutely still very critical, but it serves a different purpose. It’s about breaking into systems and testing whether your controls hold up.


AI red teaming, on the other hand, is about probing the model’s behavior. You’re not just checking if the lock can be picked, but you’re checking if the lock sometimes decides on its own to open for the wrong person. So, [Laughs] what I’ve noticed even in recent months, I have noticed something very similar.

AI red teaming is moving from one-off exercises into continuous pipelines. 

It’s no longer enough to test a model once before launch. You need ongoing evaluation because the data shifts, the model evolves, and new jail breaks appear every week. So for me, both disciplines are very important, but they’re not interchangeable. 

[David Spark] All right. Very, very good point. And I like this scenario of the lock just designed to let someone in for some random reason. 

[Andy Ellis] Unless you’re into a different doorway than the one it was actually on. That’s the biggest problem with some of the AIs. 

[David Spark] All right. So, again, echoing what was said, there are a lot of these solutions out there fairly recently, Andy, too. And are they just trying to mimic a historical behavior of red teaming, or are they trying to truly red team AI? 

[Andy Ellis] I think the challenge is, is that when people say “red team AI,” I don’t think they’ve actually thought through what they’re talking about. 

[David Spark] I would agree with that statement, yes. 

[Andy Ellis] Because sometimes, the way this question is phrased, is it actually comes and talks really about models from data analysis. We’ve gone… And think through the old redlining conversations that the Community Reinvestment Act did away with from, what was that, 20 years ago, right?

Those were models, but that was a model that said, “Oh, if you live in a neighborhood that is poor, you’re less likely to repay loans, so we’re going to charge you more money, right? 

And at the end of the day, the actual math behind the model is actually sound, but the impact of the model was very significantly problematic. Basically said, “If you live in a poor,” read, minority, “neighborhood, we’re not going to loan you money. It’s going to cost you more money.” We decided, “Eh, we should stop doing that.”

So there’s one set that’s all around when we say the model’s there, it’s not LLMs. These are data models of how are you making decisions based on data? That needs one set of red teaming that has nothing to do with breaking in, and everything to do with how do you find the corner cases?


Imagine autonomous vehicles, right? If tomorrow we could put Waymo’s on the street, or whoever you want, only autonomous vehicles, no more human-driven vehicles, and we dropped the fatality rate from driving down from 35,000 people a year in America dying to 3,000 people a year in America dying, would you think that was an improvement?


But what if I told you that they were all going to be, insert your favorite minority type here? It will only kill Black people, Indians, Sikhs, Jews, whatever, but, “We’re only going to kill 3,000. Look how many lives we’re saving.” We would all be like, “We have serious problems with that model if it’s going to consciously choose who to kill and always choose in the same direction.” Seems like a poor choice.


So that’s a very different problem than the LLM space where often we’re taking an LLM and we’re handing it… It’s not a lock on a door. It is the lock on every single door. And so you’re walking up to a building, and when you’re saying, “Look, I need to get access to room 110A.

Can I have the file and the third drawer of the second file cabinet?” and the person you’re asking has the master key to everything and says, “Sure,” and opens up every door and says, “By the way, here’s how much money your boss makes,” that’s a different level of red teaming.


Now that looks a lot closer to WAF bypass. There’s a lot of comparabilities to things that have happened in the past. It’s just a little more natural language than the traditional fuzzing has been. 

Closing

34:36.867

[David Spark] Very, very good point. And that brings us to the very end of our conversation right here. I want to thank Khush for joining us for our discussion. The only thing I could disagree with you on Khush is your amount of agreeing with Andy. 

[Khush Kashyap] [Laughs]

[Andy Ellis] Because Khush is brilliant. Khush is legendary already. 

[David Spark] Little too much agreeing with Andy. Khush Kashyap, who’s the senior director for GRC at Vanta. And Vanta, huge thanks to Vanta for sponsoring us. Remember, if you want that 1.29x increase in productivity over what you’re doing, you got to go check out Vanta.

And go to vanta.com/CISO. Khush, I’m going to let you have the last word. But let me also ask, is Vanta hiring? 

[Khush Kashyap] Yes, Vanta is hiring. And we have a lot of positions open, not just in the security team, but in [Inaudible 00:35:24] Vanta product, go-to market, finance, everywhere. 

[David Spark] Awesome. Excellent. All the way around. Thank you very much, Khush. Thank you very much, Andy. Thank you to our audience. I’ve said this before, I’ll say it again. I truly, truly mean it. I’m not blowing smoke. I call you a legendary audience like I call Andy a legendary CISO.


[Andy Ellis] Oh, gee, now you’ve just taken it away. They have to be something… They’re an epic audience. 

[David Spark] Epic audience? 

[Andy Ellis] They’re an epic audience. 

[David Spark] But if they’ve stuck with us since we started eight years ago, they are legendary. 

[Andy Ellis] Oh, they can be mythical, one step above. 

[David Spark] I’d be interested to know if anyone listening has actually heard episode one, which by the way, don’t recommend anyone go back and listen. 

[Andy Ellis] Oh God, no don’t. 

[David Spark] It’s embarrassing. [Laughs]

[Andy Ellis] Follow David around at the next conference and play it on the speaker. 

[David Spark] You know what? To get me to listen to it, we’d have to have like a Clockwork Orange scenario where you open up my ears and I’m required to hear my very first episode, and I’m struggling to deal with the pain of that altogether. I would not enjoy that one whatsoever.


All right. We appreciate our audience. We appreciate your contribution. Send me more What’s Worse? scenarios, please. Send me lots more What’s Worse? scenarios. I appreciate that and any other kind of cool segment or topic of conversation you see on LinkedIn or story, we love that stuff.

Thank you for contributing and listening to the CISO Series Podcast. 
[Voiceover]  That wraps up another episode. If you haven’t subscribed to the podcast, please do. We have lots more shows on our website, CISOseries.com. Please join us on Fridays for our live shows, Super Cyber Friday, our Virtual Meetup, and Cyber Security Headlines Week in Review.

This show thrives on your input. Go to the Participate menu on our site for plenty of ways to get involved, including recording a question or a comment for the show. If you’re interested in sponsoring the podcast, contact David Spark directly at david@CISOseries.com.

Thank you for listening to the CISO Series Podcast.