Commvault Urges Resilience for AI Vulnerability Surge
Mike Vizard talks with Vidya Shankaran, Field CTO for Cloud, Security and Emerging Technology at Commvault, about how frontier AI models are accelerating vulnerability discovery and exploitation. Shankaran explains why enterprises can no longer rely on traditional patching timelines alone and need resilience practices that include prioritization, immutable recovery repositories, isolated recovery environments and regular testing. The conversation also covers application security, supply chain risk, assume-breach planning, technical debt, critical application mapping and why cyber recovery must become part of the response to AI-era vulnerability pressure.
Transcript
Hey guys. Thanks for the intro. We're here with Vidya Shankaran, who's the field CTO for Commvault, and we're having a little chat about, well, what's going on with all these frontier models, the vulnerabilities they are discovering, and what we're supposed to do about all this stuff.
Vidya, welcome to the show. Thank you so much, Mike. It's always a pleasure chatting with you.
All right. I think everybody right now feels like the proverbial deer in the headlights. I think everybody's aware that these things are coming, that these things are discovering vulnerabilities more than ever.
There's more reports of vulnerabilities, and not everybody's not quite sure what to do about all this stuff. But, as you look at this, it seems like we have a new reality when it comes to application security, but what are we supposed to be doing about all this? Yeah.
In fact, to your point, it's definitely one of those unprecedented, I would say, industry-changing, pivotal moments that we are in right now. And one thing that definitely stands out at this point in time, that it is more of a process problem on steroids versus just a technology problem, right? Like when you look at the remediation methods as such, the patching, it has always been, I would say, an area of concern within enterprises.
And now when you multiply it 10X or even 100X, given the machine speed with which not only are vulnerabilities being identified and categorized and made aware of, but it's at the same pace that those same vulnerabilities are being exploited as well. So, at this point in time, I would say, it's almost a moot point to play catch-up. It's not something that we can ever play catch-up on.
But what can definitely stand enterprises in good stead is some of the very foundational best practices around resilience. Something which was also surprising because just last week I was at a security summit, and the recurring theme was resilience. There's no way that you can play catch-up and win with the kind of frontier models, innovation in this space.
To your point, yes, application security is definitely top of mind, but how do enterprises survive and sustain coming out of this experience? It comes back to having a strong foundation on resiliency practices. To your point about all of that, we are starting to see, or at least there's reports now, that the exploits are showing up even before the patches are ready.
Mm-hmm. " Which doesn't happen probably nearly enough as it should. Yeah.
So does that whole workflow need to be changed, and how does that kind of gunna evolve in your mind? So I would say the industry's trying to still figure out how to shrink the time to patching, because that is the scale problem that I was referring to earlier. Because this is a massively, I would say, amplified issue or concern that has always existed, because if you go back and look at enterprises, what is the cadence at which that systems are being patched?
Is it within every 30 days, 60 days, 90 days? The average sits somewhere between 60 and 90, to be honest. But now, do enterprises have the luxury of time to wait until the patches are applied and tested, and you can actually bless it and move it into production at the 60 or 90-day mark?
No, because to your point, those vulnerabilities, which have already been identified and flagged, are now wide areas of exposure that are waiting to be exploited, right? So at this point, this is where when we talk about patching as such, it is more of a proactive thing that you're trying to do, but the malicious actors are already looking at ways of exploiting the c****s in the armor. But what can you do as your systems are being prepped or identified for patching purposes?
How do you minimize your risk exposure is by being a lot smarter ahead of time. If I have to kind of break it down into top four elements, one is identifying and prioritizing the business functions, right? Which make up the core elements of your business, without which you can...
The definition of minimum viability pretty much distills it down to without these systems and processes and technology, a business is technically belly-up, right? So identifying and prioritizing and going after just those critical applications should be top priority for enterprises today. Once that is done, how do you go about ensuring that you're following the same best practices around having air-gapped immutable repositories?
Because to your point, as you're waiting for the patches to be rolled out, you still want to make sure you're recovery ready, you're recoverable. And that comes back towards having an isolated recovery environment, which is also kind of interesting because, Mike, this recovery environment that we talk about from a resilience perspective is pretty much the same as your sandbox environment used for patching. You would still want to make sure that you're not just bringing the data into that isolated environment, but also the systems that need to be patched to be rid of all those vulnerabilities that were identified 60 days ago ...
are being done within a more isolated network segmented space of sorts. And once that is done, building that muscle memory with regular testing, making sure that you are building that confidence, improving the confidence levels of recoverability and resilience, these are some of the best practices. When we talk about the COVID experience at large, it was actually the immunization episode was more of a scale issue.
So you went after what was core important, immune-compromised entities or children and seniors were the first ones to get immunized and so on and so forth. So you're now identifying what is core and critical. It's the same process, it's the same mentality.
And that allows you to streamline your processes in such a way that over time, you're able to encompass the entire population, you're able to inoculate the entire population, making them immune to future attacks. And even if that attack does happen, you are in a much better place to respond with confidence that the impact is going to be minimal. So there are a lot of similarities from our, I think, collective COVID experience and also what we are seeing with this current Mythos scale of vulnerability detection and addressing it.
So to your point, we should assume that something bad is going to happen and- Absolutely ... be prepared to respond. " But then we didn't have a plan for what would happen when those vulnerabilities were exploited, and we didn't start responding until there was an exploit, and by then we're talking about days and weeks, right?
Yes, 100%. And to your point there, I think the overarching sentiment that we've always emphasized on is assume breach. This Mythos or OpenAI's Daybreak or any of the frontier AI capabilities out there has definitely brought that even more front and center, that you just have to assume breach.
You just cannot rest on your laurels that you patched your systems 60 days ago, because that is no longer relevant in the current scheme of things. What is also interesting is now it becomes that much more imperative for enterprises as they are evaluating solutions, evaluating technology stack, for them to look into the software bill of material. Because that was, I want to say, three months ago, before Mythos was even a thing, it was a suggestion.
It was, you may want to kind of consider looking into the software bill of material, but now it is mandatory. Because without knowing what systems you're going to introduce into your ecosystem, it definitely amplifies your risk exposure that much more. So supply chain is definitely one of the core areas of concern that outside of enterprises securing their own systems, but if enterprises were unwittingly introducing something from the outside in through the ecosystem, it could be SaaS solutions, it could be a point solution that they are investing in.
Those are also ways that risk vectors could get in. So, having that understanding of software bill of material is definitely another important best practice recommendation. I think a lot of folks are assuming that Anthropic is behaving responsibly here and limiting access to Mythos.
5 does a pretty good job of discovering vulnerabilities, and we can assume that other open source models will have similar capabilities or other proprietary models. So at some point, everybody and anybody's going to have access to this capability, including all the bad people out there. And I think we need to make some assumptions today that if we're going to ship code that has a vulnerability in it that's known, that's just not acceptable anymore because it will be found, and it will be exploited.
Mm-hmm. But on the other side of that coin is that our new code is probably zero-day vulnerabilities that we don't know anything about, and we're unprepared to respond to that as well. So if I put all that together, is there a conversation that needs to be had between the security people and the application development people that is somewhat missing?
100%. I think those conversations, I would say it's definitely sparking those discussions now, but are they in a more mature place to have a very coherent, streamlined process where the handoffs are seamless? I would say that we need to wait and watch how that pans out.
But definitely it is taking place because I'm glad it is taking place, to your point. The same AI tools are available even to malicious actors. But are we able to get that one leg up over others, over malicious actors?
I think we do as enterprises because we know the landscape, or rather the customers or enterprises know their IT landscape the best. While the malicious actors are going to have to use trial and error methods, even if it is accelerated, automated with AI and all the fun stuff, they are still going to have to throw darts in the dark to figure out what sticks and what does not. So having, I would say, the blueprint of your landscape is definitely an advantage that enterprises have today over malicious actors.
But again, if there is a nation state sponsored attacker who's been dwelling within the environment, living off the land for several days and even years for that matter, that advantage gets eroded rather quickly. So It boils down to the bells and whistles with which you're constantly watching for anomalous behavior within your environment. And at the same time, how agile are the processes within your ecosystem that allow you to hit the ground running?
You're notified of a critical vulnerability. You know what are the systems that are likely to be impacted because there's the dependency matrix that gets pulled up because of that. And not just focusing on the CVSS score of the CVE, but looking at how that maps to the various critical applications that are dependent on that particular patch or a fix is also equally important because enterprises cannot boil the ocean expecting that patch to be rolled out en masse across all their systems.
So that prioritization, I know I sound like a broken record, but that is so important. Having a complete understanding of the lay of the land is important because that is the only advantage that enterprises have today compared to malicious actors. As we think this through for a half a second here, we can look at this and say the glass is definitely half empty.
But on the other side of this, and I get that there's a massive amount of technical debt that we haven't addressed, and we're probably going to experience some significant pain as a result. But at the end of the day, our applications wind up being more secure because we're finally going to be called to account for these issues, and we're going to get our house in order. Yeah.
Absolutely. In fact, if we have to look at the light at the end of the tunnel, I would say that is exactly that because you're now likely to be a lot more security-centric, more closed in terms of your application's ability to be airtight. And I would probably give the entire industry, I'm thinking probably two to three years tops to get us to a point that everything becomes so tightly integrated from a security perspective that it's technically waterproof, bulletproof, and all the proofs that you can apply to it.
But that, in my view, is definitely one of the biggest silver lining coming out of this. What is your best advice to folks then? What should they be doing today and thinking about, or do I just put everybody in a room and lock the door and hope that something good comes out, or is there some small steps I should take today that ultimately get me on the right path?
Yeah, the small steps, I would say, is getting that priority list out, the sooner the better, because many times enterprises believe that they need to do a proper business impact analysis. No, let's not wait for sunshine and get going with that exercise. That can be a good-to-have exercise in the long run, but start looking at all the data sets that have long-term retention today.
Anything that has seven years, 10 years kind of a notion, that automatically means that that is critical for your business. So it's an easy rule of thumb to follow the trail on and start figuring out what are those applications that are benefiting or that leverage that kind of long-term retention. So that is supposed to give you a kind of a shortcut to short-circuit your process of getting to your critical applications.
That's not the be-all and end-all. A business impact analysis is definitely a must-have. But without waiting for, like I said, that entire process to be complete, this is something that enterprises can start doing here and now.
And tying it back into the best practices around protecting those workloads, testing, validating it, and making sure that you are confident in the recoverability of those systems is where it boils down to. So it stopped being all about proactive a whole while ago. It's now about how smart and how amplified from automation perspective is your enterprise from a recovery and reactive perspective is what the game is all about now.
All right, folks. I think Ben Franklin once famously observed that failing to plan is planning to fail. 100%.
I love that. And it's never been more true than it is today. Hey, Vidya, thanks for being on the show.
Of course. My pleasure. Thanks for having me.
All right. And back to you guys in the studio.