Barracuda CISO Urges AI-Ready Vulnerability Management

Hey guys, thanks for through. We're here with Arvind Kajolan, who's the CISO for Barracuda Networks, and we're talking about all these vulnerabilities that are coming our way soon because, well, AI is discovering them faster than ever, and we're not sure we're ready to remediate them any faster, but we'll find out. Arvind, welcome to the show.

Thank you. Good to be here, Mike. I think I've been talking to some folks about this, and there's an interesting little trend here, where suddenly the overall size of the patches is increasing, the number of vulnerabilities addressed is increasing, but a lot of them even haven't been recorded or actually acknowledged to be vulnerabilities.

So clearly somebody has some inside info somewhere, but the end result is the patches are bigger, and maybe they're going to be coming more frequently. But as we look at AI, what's the impact here? What are you seeing?

Yeah, it is clear that the number of vulnerabilities is going up. I run a site called AI Hype, and so I track this daily. And we are now at a pace to get to 81,000 vulnerabilities this year, 81,000 issued CVEs.

Last year we were at 49,000, so it's a pretty big jump. And every week it seems like the projected number keeps going up, so we're definitely seeing the bubble. Is the way we're managing this changing?

Because back in, not too long ago, I was going to say the day, but that was probably maybe even six months ago, we used to wait and see who would apply a patch first and maybe see if they encountered any other issues, and then we'd test and validate this patch, and it could be six months between when the patch became available and we actually deployed it. And then now it seems like the bad guys are not only finding out about the vulnerabilities faster, but they're reverse engineering the exploits faster, and maybe even before the patch is available. How do we need to change the way we think about applying patches and managing patches?

That's an excellent question. So the traditional model for what we do in vulnerability management, at first we go and scan, and so we identify our vulnerabilities. Then we prioritize, then we remediate them, and then we go back and check, we validate and make sure that we have remediated them.

And when you think about it that way, it makes it sound as if the remediation is just this one-click button, right? You click this and everything gets remediated. But as you point out, often there's some testing involved, and it can take a while.

So one of the areas that many organizations, including ourselves, have been focusing on is how can we automate the testing so that when we apply something new, it just doesn't take us as long to figure out whether it's going to break something or not. So I think that is one way to address that problem. I think, too, our mindset has to change a little bit.

We used to not apply the patch because we were afraid that the cure might be worse than the disease. But it's pretty clear that if the bad guys can do the exploitation faster, that the disease is pretty lethal. And maybe we need to rethink our approach here, because I don't think that the patch is as big a problem as it once was if we can roll it back faster and maybe fix it faster in the age of AI.

So do we need to change our mindset here a little bit? Yeah, I agree with that. The organizations that are still using older technology or legacy technology that's been around for a long time and that have substantial on-premise infrastructure, they're still in a difficult spot, because they are just structured in a way that makes you apply patches, run for a long time, apply again.

Organizations that have more modern infrastructure and that have most of their environment in the cloud can do things a lot more quickly, and they really need to get to the point that you are mentioning. And there are a lot of good things happening behind the scenes. They're not always visible to those of us at the top and trying to look at the high end or look at the summary trends, but there's a lot going on in the development environment with automated dependency management, for instance, so that when you build something and you rebuild it the next week, it's using newer versions of all the dependencies.

So that's one example of how things are improving under the covers. We're all obsessed these days with Mythos and the latest version of ChatGPT, and they're only available to a select few, shall we say. But I can't help but wonder if this is a temporary pause, because I'm looking at all these open source AI models, and they seem to be getting better and better at discovering vulnerabilities, and this is going to be fairly, shall we say, widespread tool that anybody can use for good or ill.

Is that fair? Yeah, I do think that's fair. I've been beating this drum for a little bit, and I know if you look back at historical examples, even in our own field, when new technologies come out, even if you initially have national security concerns about them, those concerns get swept away because technology just changes so quickly.

I think last time we talked, we talked about vulnerability management in general, how that came about, right through this SATAN scanner and some other things. But there are other parallels. So for instance, back when encryption, when there was concerns about letting encryption being exported, you had cases where we thought we could clamp down on that, but that wasn't possible either, right?

And so strong encryption is available all over the world. And the same thing is going to happen with this. I don't think anyone who runs security infrastructure has any doubt that the exact same thing is going to happen with this.

These capabilities will be available, and now it's about how do we prepare ourselves best for that? Let's be honest, the relationship between application developers and the security team has always been a little, shall we say, fraught. Is that going to change in this era?

Are we going to kind of maybe come together and finally rethink our DevSecOps workflows and maybe work more tightly together? Because I think developers often view vulnerabilities as obstacles to get around rather than things to address. And of course, the security people, they would create these long list of vulnerabilities that lacked any real context.

So, everybody wound up kind of talking past each other. What do you think? Yeah, I think for a while it was probably even worse than that, right?

You could say to us, "I've been in security for a long time," and I could say, "Hey, it took me only 30 seconds to identify that vulnerability. " So I think part of the problem has been perhaps not always realistic expectations from the security community, but I do think things are changing, and I think they change for the better when we enable the developers. And so to your point, a vulnerability without context, that's not helpful.

Gathering as much context as possible helps, but also I think just in general with the pace of CDEs now, we are going to change, and many of us are working to change how the entire process works. So to what extent can I use LLMs to at least begin the remediation process? I think that's really the only thing that's going to be able to help us keep up with the pace.

Are we going to get to the point where maybe the quality of the software eventually is better, but we might experience some short-term pain as we get to that whole outcome? But, it's not the best of all possible outcomes, but at the end of the day, is all of this good for us? Yes, we will get there.

I think what we don't know is how quickly will we get there. So if you think about the situation that we have today, the software that's already released, we keep finding vulnerabilities in that software year after year, right? And so it's clear that there are latent vulnerabilities in the software that's out there.

Now what's going to happen with these AI models is that we're going to find those vulnerabilities faster. So there will be a bump as we find those, but eventually we will exhaust those vulnerabilities, and we will have software that was scanned really well before it was deployed, and it will be cleaner, it'll be much cleaner than it is today. And so we'll have a bump, but the interesting thing is that at the end of that bump, whether that bump is a year or four years, we will stabilize at a number of vulnerabilities that's lower than what we have today.

So what should security people be doing today about all of this? We can see that there's this tsunami building, but it's like many things, until it lands, maybe we don't understand the implications or we don't get motivated enough about it. But I feel like at the very least, there's a conversation that should be had.

Yes, I think so automate. " is that it's only a little bit about what model are you using and can you get access to meet those and so on. I think as a security organization, you really have three options.

You can go with these security-tuned models like Mithos, you can go with some frontier model like Opus, or you can go with some of the publicly available models or the open source models like DeepSeek. But either way you do it, that is not the most important choice. The most important choice is, can I get some automation on the assignment of new if I find a vulnerability, can I automate how that gets assigned out to a team?

So do I have all of the asset management that tells me that this vulnerability over there belongs to this software team over there? So that's one important piece. And the other one is that regardless of which model that you go with, you are going to have a little bit of work to get it working, whether you're using GitHub or GitLab, get it deployed to all of your teams, and get the automation and the communication in place.

So I think the sooner you start planning, the farther you'll go. The model choice will be there when you're ready to make that choice. " So how do we assess their risk?

It's a very good question, and my view is somewhere in between those two extreme views. It's natural to start with the most critical vulnerabilities, and then to work your way down to less severe vulnerabilities. And as you work your way through, say, the medium-sized vulnerabilities, you are going to get to a point where if all you have are low vulnerabilities, you're going to need a lot of them to string those together to a critical vulnerability.

So we are reducing the overall risk. But it is true, and I've seen this, that you can get some interesting results by stringing together multiple vulnerabilities. But I've also seen instances where it was the humans who did that, because the humans were the ones that understood the business context, who understood, well, what is this product designed to do?

And so I've seen both sides of the coin, which is why I think there's some truth to both perspectives. The other thing I'm starting to wonder too about is people have been, at least nation states, have been kind of collecting vulnerabilities for years, and it's not always clear to me that they told everybody about these things. And I think in the age of AI, they might be aggressively collecting even more of them.

So can we just assume maybe that at some point, the application's going to be breached, and maybe the name of the game is resilience? Yes. I think that assumption is something that I think most security professionals take seriously now, and that is you can't put all your dollars into the prevent layer because it will break at some point, and then you have to have a response layer behind that and a recovery layer behind that response layer.

So I think that is definitely true. But something you said there- Mm ... was interesting because I think if you are someone who is collecting zero-day vulnerabilities, you have to look at what the vendors are doing to try to determine what you're going to do.

If I were an actor today, a threat actor, and I saw some software vendor just really piling on the LLM-discovered vulnerabilities, every vulnerability they're publishing, they're saying crediting Mythos, crediting Opus, whatever it may be, I would actually think about using those zero-days that I have saved up because I would think that they're going to find this problem soon. Right. Whereas I think your scenario would be more apt if you're dealing with a software vendor that is not doing that, or if the threat actor has the perception that the software vendor, they're not really taking this that seriously, and it's going to be a long time before they find this vulnerability themselves, then I think you sit on it a little bit longer.

So there's a little bit of gamesmanship here. Yeah, you just described the poker game that I've been in, but yeah, that's kind of where we're at. As you look at all this stuff, what should be the role of the government in all of this?

Is it up to each individual company to figure this out, or are there things that we can do with the government, or maybe with each other to circle the wagons? I, as an individual, would love to see the government focusing on encouraging sharing and using of these models that are available now. Because by holding them back, they're not benefiting someone in my position.

What that means is that if I don't have access to a Mythos or something like that, I have to go and build a lot of things myself. If OpenAI or Anthropic have already figured out a lot of things around how do I take the code, how do I chunk it up, how do I scan it, and how do I build that into a security-specific scanner, well, I have to spend a lot of resources doing that myself. So I'd love to see them rather than encouraging our frontier companies to hold data back, I'd actually like to see them do the opposite, and I think that will be helpful to all of us.

Well, folks, the one thing that's clear about all of this is we're all in it together, and sink or swim, and whether you like it or not, maybe we do need to share more information with each other, even if it is a little sensitive and even if it is maybe even downright embarrassing or something you consider a secret, because you'll probably get more than you give up. So, let's all kind of get through this together and win the war because the individual battles maybe are not nearly as important. Hey, Arvin, thanks for being on the show.

Oh, thank you, Mike. All right. Back to you guys in studio.