ResOps Powered by Commvault Cloud Unity

So we've done a couple of these, and we usually start it with a market trend. But because I have Bevill here, who is a recovering CISO, I thought we'd hear some words from not only his past experiences but also what he's doing at Commvault talking to security teams, CISOs alike, and even some of the AI folks. So we'll use that to kind of ground the conversation today, and then we'll talk about all the new recent things that we've recently released, and then we'll close the session with a hardcore demo on what is going on with threat detection and response.

Bevill? Awesome. Thanks, Michael.

So good morning, everybody, and really appreciate the opportunity. Again, my name is Chris Bevill. As you can tell, we went from the far northeast down to the south in Knoxville, Tennessee, which I want to make sure everybody knows it's the home of the real UT.

So I have to make sure that everybody understands that for all my Texans out there. Now, he talked about being a recovering CISO. What does that mean, actually?

It means that I got to go on July 4th to have a vacation with my family, and I didn't have to worry as much about the phone ringing. Did somebody click a link? Did something happen?

What are we doing? And had the opportunity to join Commvault, where I think I can make a bigger difference, and that is talking to my peers, talking to folks like you, and really talking across the board to our salespeople, our sales engineers, and really across the board of what is important today. Because that is where we're at, and it's all become kind of a transitional to it's about trust.

I know many of you in here. We got a compliance person in here, and trust is what we live every day. So that's really what we're trying to talk about and really why I came to Commvault.

As we get into it, some of the stuff that we really want to talk about is what's happening in the organizations today. What are we trying to do? When you think about-- We think about it as a whole.

This has become a board-level problem. I used to go to the board, and I was giving them, "This is how we patch. This is what we did.

" And the reality is they didn't want to hear that. What they really want to hear is: what is the business objectives? Can we recover sooner, faster, safer, and with trust?

Can we really get there? There's a discussion of really whether we talk to about does the CISO report to the CIO? Does it report to the board?

Does it report to the CEO? And there's a number of things that you look at. When you look at this slide here, as far as 75% of CIOs self-report, they begin to start thinking about it.

But their overall thinking from a IT perspective is kind of more holistic and global. Then you get the CISO who self-reports a little bit, but their thinking is now having to transition more into that CIO role. They're having to start thinking about who owns it.

So when we begin to think about our organizations in a whole, it's everybody working together. It's a resilience operation that we start from the beginning and we have to test. If the one thing that I say the whole time I'm up here is testing is critical.

If we don't test and we don't know where we are and what we're going to do, we're going to be in a very difficult situation. And that leads us to this. So many times we have disaster recovery.

Hurricanes come in, and I can tell you there's an organization in Hawaii, they can do disaster recovery better than anybody else. I tried to trip them with every tabletop exercise known to man. I threw the kitchen sink at them.

They were good to go. But we transition into the cyber recovery. How are you going to recover cleanly?

How are you going to know that your data is trusted when things occur? And that's where we have to begin to start thinking about things. Disaster recovery today does not equal cyber recovery.

It doesn't equal cyber resilience. There's a lot of things that are occurring and have to be accounted for when we look at it. And that is why Commvault, we're beginning now to talk about this thing called resilience operations.

And that is where we begin to work as an entire organization. I can tell you a quick story. I was working with a major retailer.

I was asked to come in and talk to them about security as a CISO, and it was the VP and CIO of the IT infrastructure. " Guys, I about fell out of my chair. How is my CIO and my VP of infrastructure asking me if their organization should have an instant response plan?

Why are they not working with their cloud people, their cyber people, and all working together and coming together as one to really understand? And that's what this is all about. When you hear Commvault talking about ResOps, this is a new methodology that we think about.

One, we all know we have to now assume compromise, but whose responsibility is it? Are we talking to each other? Are we having that conversation that is so critical that we understand where we're going to do and what we're going to do when that first 30 minutes hit?

You got to expect loss of trust. Look, the bottom line is this. If you look at healthcare and finance, as soon as you say ransomware or the word breach, trust is gone.

Trust is now what happened? What happened from an exfiltration perspective? What are we going to do?

How are we going to do it, and where are we going to go? So we have to expect that our reputation is going to be damaged. How are we going to minimize that?

And part of that is how do we get back to becoming a minimum viable company and get our lights on so we can function, but how do we do that in a methodology that we can trust the data? " But the reality is, where's the trust? I'll give you another story on that.

I was at a major conference two weeks ago, and an organization was presenting how they had partnered with another company where they had their pipe going to an air-gapped copy, and that air-gapped copy then, if something happened, they could spin up an IRE in about two hours. " Great idea. I love the fact that they were going to the air-gapped copy, then they were going to the IRE.

How did they know that what went through that pipe to that air-gap copy was clean? What were they doing to try to address that? And there were many conversations after that that I had with them to talk about where's the trust, where's the cleanroom, where's the different things that you're going to do?

So you have to design with clean recovery. You've got to understand that's what this is all about. And that goes to testing.

Again, good tabletop testing, not just at the executive level, but at the technical level as well. Again, I talk about compliance. We addressed that.

I was a PCI QSA. I was a high trust assessor. I've been in that world, and I've talked about it, and we have to have these people understand it.

And then finally, automate where humans cannot scale. Gosh, wonder what that kind of ties to. Maybe there's two letters, AI.

I don't know if we've ever heard of that or not. When you start thinking about AI, what that does is, that doesn't mean that that's going to replace humans. What that means is we're going to use the tools to compete against those attackers, and we're going to be able to find those things that we're looking for, more importantly.

And if you think about it in healthcare, they use AI now to look at X-rays to determine what a doctor may not be able to see on that X-ray. That's what we're doing here. We're making it real, and we're trying to make it really focused so that we at Commvault bring in the AI to make us that much better so that we have an entire story.

But it starts with IT. It starts with security. It starts with the cloud people.

It really starts at the C-suite, and it starts at the board as well. It all has to work together, and that's what ResOps is all about. We're holistically working together to really get to where we're trying to go.

And that leads me to my next slide. When you look at it, why does it matter to leadership? Let's be realistic.

I could go through every one of these on this board up here. But the reality is this, when you're sitting there and the board is trying to say, "Can we recover our data? Can we recover it cleanly?

Can we trust it? " That's what it's all about. I'll leave you with one last story.

2021, I got my very own letter from the Conti Group. It was exciting, let me tell you. Nothing like getting your own letter sent to you from that perspective where I was actually the incident commander supporting another organization.

From that organization, this had nothing to do with Commvault, but the story really resonates. If they had practiced and done the things that they were supposed to do, it would not have taken them 284 days to recover. Now, here's the kicker.

284 days to totally recover, and six months later, because they didn't know whether the data was clean or not, they got hit again. And this was a cash cow for a Major League Baseball organization's owner. That's what this is all about.

That's ResOps. That's what the board needs to know, and that's what Commvault is here to do today. Turn it back over to Michael and let him take you through cyber resilience.

Awesome. Thanks. So I'll use this as kind of a frame to discuss many of the elements that Chris had just covered.

And there's a lot of subtle nuance in there that I think is really important for us to uncover because a lot goes behind the sheets. So sure, we're going to talk about features and functions. But more importantly, we're going to talk about how all these pieces are interlaced together to make sure that we can provide high-fidelity signals or extremely clean recovery or making sure that the data's secured in the back end.

So it all starts with our cyber resilience layer at the very, very top, right? That's our entire platform. Recently, we released Commvault Cloud Unity, where we span across SaaS, cloud, on-prem, and everything, so there's no exceptions.

There's no compromise there that you need. We then have this anomaly and threat detection layer. This is a complete substrate across the entire platform.

So whether you're doing backups, active directory, files, user logins, deduplication, storage, there's anomalies across the entire system, and they're very mature. I think it was probably a dozen, probably 10 to 12 years ago, we started down the machine learning path, and we've constantly refined our ability to do anomaly detection. And anomaly detection is really important for us to also provide scale and clean recovery.

The second part to that is our data discovery, and we've been doing that for probably 15 years. And that's on primary and secondary data. So it's not just what we back up.

We can actually do it on primary data. And we do it across structured and unstructured data. And then when we talk about some of the DSPM-like capabilities on a little later, we'll talk about some of the new add-ons that we added to the product to make sure we have the entire sweep.

But data discovery is really important because we need to know what's going on with the data. First, we got to find it, and then we got to know about it. And then we can apply the proper controls and policies that we do, either through our particular engine or what we'll talk about with Satori in just a bit.

As we get to kind of the middle stack, all of these things kind of work in concert to Bevil's point about how do we detect threats rapidly, how do we do it accurately, and then obviously, we want to provide confident recovery. So all of these things kind of work together in unison to deliver that outcome, and David's going to show you that from beginning to end in the demo. So he'll walk you through that entire sweep, and we'll talk about the products and things that make that happen.

And as Bevil said, going into an organization, they don't even have an incident response plan. What's better than an incident response plan? Something that you can do over and over again that's not manual.

So we'll look at capabilities that allow us to have runbook automation that you can completely customize for your environment. We'll talk about a couple examples that we do with Active Directory or clean recovery, and you can see how we can use these motions over and over again to provide predictable outcomes. And because we can do it in the clean room, we can do it without impacting production.

So as we were talking about before with testing and testing and testing, how do we do that efficiently? How do we do it without low cost, and how do we do it consistently without impacting production? Those are the things that we're going to talk about.

And then obviously, the complete substrate of the platform is highly secured. We have CIS level one hardened OVAs. These things work in unison together, whether you're on-prem or in the cloud.

And then, we provide these capabilities within the product to make sure that your data is always immutable, indelible, and obviously resilient against all types of threats, whether they're DR or cyberSo here's a quick flowchart, and we'll kind of step through this level, and then we'll talk about the thing in the very middle in detail. But from where we were just now to where we are, this is kind of our makeup of how the products and outcomes kind of fit together. So on the left side, we always talk about readiness, right?

This is all left-of-bang stuff. And we have these configurations and policies that we apply consistently across all your different workloads, all your different data silos, right? So that's kind of the bread and butter of how we do things consistently across.

And then we use capabilities like our threat scanning product to allow us to detect threats and make sure that our backups can always be recovered cleanly, and we can flag these things accordingly. And then obviously, we have the ability to do recovery testing, and we use clean room to do that. So as we talk about how do we continually do these motions of validating that I can recover, or for scenarios where we need to pass off to the SecOps team for forensics, these capabilities all work together to provide that particular outcome.

Then we get to this rapid and clean data detection area of the product, and this is where a lot of our new capabilities are. And we have a multitude of defense and depth type capabilities that allow us to not only have anomalies, but also third-party signals that come in. And we take all of these things together to kind of provide a high-fidelity viewpoint of what is going on in an environment, and then how do we react accordingly to it, whether that is account compromise, which we'll talk about in a little bit, clean recovery.

How do I empower my SecOps team with signals that are generated out of Commvault? So we have a lot of third-party integrations that are bidirectional. So any signals that we get within the product, we can send them into a SIEM and SOAR that exists outside of our product so that the security teams and the admins can actually have a single pane of truth that they can go through incident response with.

So here's just a laundry list of some of the stuff that we do there. And then some of the new stuff is kind of embedded in that middle layer where we talk about AI, YARA rules, signatures, and hashes, right? So that's our really quick way that we can detect what's going on on a machine.

We give the SecOps team the ability to go use YARA rules, or if they have custom rules that they want to add, you can now add that to the product. And again, we'll talk about that in a little bit, and then Cunningham will show it to you in the demo. But all of these layers allow us to build that confidence.

So when Bevil's talking about trust, how do we do that? We constantly have these signals that pile onto each other. They're high fidelity.

They're not noise. And as we get them and we can paint that picture, we allow you to have that really high-fidelity understanding of what's happening so you can respond accordingly and accurately. And then, of course, we allow you to use those signals to cleanly recover.

And that's not a manual process, and we'll show you how we've automated all those bits and pieces. And that brings us to our next bit, which is really how do we do clean recovery? And our new capability, synthetic recovery, allows us to take all these rich signals and understanding of what's going on on a machine automatically and provide a composite of your latest restore point so that you can recover only clean data.

And again, I'll show you a visualization in just a second. But uniquely, you don't have to do stepped restores anymore. You don't have to hunt through all of your different backups to find the latest copy of that data.

We do it all automatically, and we provide you with statistics right up front to tell you how clean that latest point recovery is going to be. So that only becomes one click away, which is truly unique from our standpoint. Then we get to the optimal recovery side of the fence, and that's really where a combination of these tools allow us to kind of validate what's going on, provide forensic capabilities, test the recoveries, and make sure that all of these things can happen together.

And what's important about that is with the capabilities that we have with something like Active Directory forest level recovery, we can go lift and shift that forest into a clean room. You can then restore your apps adjacent to it. So if you have dependent apps on Active Directory, you don't have to guess if you could actually recover that if something was really bad to happen.

You can simulate that entire thing into a clean room. So it's a really powerful way that we can reconstruct an environment and make sure that we can build trustworthy, confident recovery, even in a clean room, so that you can be very confident that you can recover that data. And then obviously, at some point, you're going to have to bring it back to production.

So again, by going through these testing workflows, you can have confidence that you can recover that data accordingly. Just curious about a couple of things. One of the things is when it comes to detecting the compromise in the backups, is it just signature-based?

Is it behavioral? Yeah. So if you look into the threat detection box under Threat Detection and Response, there's several engines that we use, and I think we're up to about 13 different anomalies that we could detect in addition to using YARA rules, hashes, signatures, and then we do have a deep scanning engine as part of the product, and that will detect polymorphic and even zero days.

So it does do that deep scan. It's a third-party engine that we use. So if you think about all these different layers, you have medium fidelity signals on anomalies and things, and those are kind of your hints.

Then when we cover the threat scanning part, we'll talk about how we provide hyper threat hunting, which is our quick way to determine, okay, we have these signals. Can you give me a little more fidelity on, is this really a problem and a threat? And then we have the deeper scan, which really gives us the checkbox that, yes, there's something really going on.

And then we take all those signals, and we provide almost like a score of, yeah, we're very confident that these are threats, and we provide that capability. And then what we did add was YARA recently. So we have all these different tactics, and one of the important things to your point is we provide these capabilities because we don't want to make any assumptions.

Right. We have customers that are all over a broad spectrum. Some have really mature security teams, some don't.

Some have just Commvault admins that wear lots of hats. So by us having the flexibility in the platform and how all these tools are integrated together, we provide all of the different broad spectrum personas that we play to, the ability to go do incident response and threat hunt and the things that they need to do to make sure that they can optimally clean. And that's really one of our main principles about meeting customers where they are.

And when we talk about some of the third-party stuff later in the presentation, that really applies to not only the organizations and the integrations that we do, but also the personas that actually use our product. So we look at it from both of those. We really want to facilitate the flexibility of the platform and make no assumptions so that there's no compromises.

So again, the magic of synthetic recovery and why it's different than some of the other solutions in the market. Again, this all becomes automated, and we'll show you what it actually looks like in the product when David gets to the demo. But basically what happens in the visualization that we have today, we have three backups.

A ransomware hit at backup two. We automatically flag that, and then we flag all the encrypted files. During backup three, that malware is still on the machine.

We still have some changes to some of the files that are there, and then other ones got encrypted. So with our synthetic recovery, what we do is we surgically flag the malware and then all the encrypted files, and then we restore automatically all of the clean versions of those files across the entire backup cycle. So that's a single button that's completely automated.

So as we're detecting anomalies, as we're doing scans on the machine, when the admin's like, "I've got to go do a recovery," we do this entire process all automatically for them. In the past, what you would do is you would do a stepped restore, or you would go back to the one that was probably the least compromised. You don't need to do that anymore with our synthetic recovery.

So this minimizes data loss. This provides you with the cleanest possible recovery based on the latest data across the entire machine. I've got a question about that.

Does it go back to find a known good copy of the file, or does it clean the infection from the file before restoration? It will look at the last known good version of that file. Okay.

And it's using file hashes or other secondary indicators to make sure that it's a good, clean copy? Yep, and it's based off of our index. So we're not physically and surgically removing anything from our back end because, again, it's immutable, it's indelible.

So because we have an indexing layer that exists here, we can do all of that surgery in there, and then when we need to go do the recovery, it will find the last known good version of that file. That's correct. Awesome.

So cool. Hopefully, this lands. And like I said, it's different than the other solutions that are in the market that are either moving back in time completely and then trying to do some post-surgery, or other methodologies to just go back to the last cleanest version.

We avoid all of that, and we really minimize data loss with this technology, and I think we have patents for it, too, so it's very cool. All right, so I talked a little bit about some of the changes that we made to threat hunting, and what we've done is divided it into almost two phases. And this is more of a logical division, not a physical division.

And Threat Scan has evolved over time to make sure that we can provide that really high-fidelity set of signals and a wide variety of signals because threats come in all flavors and shapes and we never know how these are going to evolve. So the hyper threat hunting is really your first line of defense that you're going to run consistently and constantly. It's going to give you pretty good indications that there's something going on on the machine.

And again, that's using hashes, that's using YARA, that's using signatures. We could look at all of these signals and use them to make sure that either the data's clean or we're finding some signals that there's a compromise. And then we have the deep one, which is what I was talking about before, which really allows us to do file-level analytics on these files.

And it's deep, and it will tell us if there's a compromise, if there's encryption, if there's polymorphic threats, if there's zero-days that look like other threats that are in the market that maybe there's no signatures for. This is our tool to do that. And we've had several customers call us up that their EDR didn't pick it up, but we picked it up in the backup with our deep threat scanning.

So we've seen many proof cases out in the wild with our customer base that there was some infection, and before their EDR or XDR platforms even picked it up, we were able to find it in the backup. And because we're using these methodologies consistently across the board, we're able to almost augment. We're not going to replace those tools.

They're still very necessary. But when it comes to backup and clean recovery, these are very important. And what's good about these tools working in unison with recovery is that all of these signals can be used both to drive clean recovery and also to provide deep information about what's going on in the environment to SOC analysts and other people.

So, us taking these risk signals and putting them into other systems, we're finding really provides that ground truth for people to really go through incident response beyond just what we're going to do from a backup perspective, because the world is much bigger than just clean recovery, but it's an absolute critical portion of how we play into this particular space. I have a question. Does that integrate with any other threat detection solutions?

So can that Is there a way to point in time something else detects a threat to trigger additional scanning or any additional- Yes, absolutely. So I wish I had the slide, actually. Maybe if we have some time, I'll dig it up.

We have a plethora of third parties integrations that are bidirectional. So we can... The demo video has CrowdStrike, right?

So if we're getting CrowdStrike signals into Commvault through our bidirectional communication, that can absolutely orchestrate these types of deeper scans. It could orchestrate a recovery. And for a lot of the SIM platforms, we have embedded recovery runbooks so that if you need to act fast, you could actually do it through that.

So we provide those different methodologies, but absolutely, third-party signals have their own characteristics within our product, and you can run all this different type of automation, clean room, forensic recovery, synthetic recovery based off those signals. So signals are super important for us. And we look at incident response as a team sport, right?

Cyber is a team sport, and we can't do it alone, and we shouldn't be doing it alone. So, I hope we have time so I can flash the slide, but we really have a lot of deep integrations with many, many different platforms. And sharing those signals, again, really provides that ground truth for both traditional Commvault folks and the security team to really act when there's an incident.

Great question. Okay, so that's all the threat scanning stuff. We'll talk about identity because identity's been the hot topic for the last couple of months.

I think all of our traditional folks in our space have been talking about identity. We all see the big bosses that talk about identity resilience, and when we think about identity resilience, this is the flowchart of all the different things that we're doing. And what's important about this is you'll see lots of similarities between what we just talked about from responding to incidents and identifying threats and identifying these things, and how it's going to work in concert with clean recovery, right?

So we look at identity as just another vector of things that we need to understand so that we can provide next generation recovery methodologies, and then ultimately clean recovery and making sure that it's not as friction-full as we all know identity could be because recovering an Active Directory forest requires a PhD, and it's like 200 steps or something. So, we'll talk about how we resolve some of that. What's important is probably our most recent announcement, which is now we support Okta.

So, Okta came out of nowhere, based on how long Active Directory and even Entra ID have been in market. And we had a significant amount of signal that people have been resorting to Okta for identity purposes. So we wanted to extend that capability.

And hopefully it's clear about when we talk about the product, doing things in a very consistent way is super important because, again, we make no assumptions on who's going to be using the product. So Okta is going to function just like our Active Directory or Entra backups. It's going to function just like our virtual machine or database backups, right?

The flows are very, very similar, and of course, there's going to be some subtle nuance. But at the end of the day, it becomes a very familiar flow for people to respond to. " So very purposefully designed so that it looks like everything else that we built, so that as people need to respond to incidents or even just run regular backups or recoveries, the flows are very consistent.

So what we found with Okta, admin error, some type of mistake, just like Active Directory or Entra, maybe not to the extreme, but recovering is really hard. It's not as surgical. And then, in identity systems that are very complex, where you have a multitude of these products, we found that administrators have a really hard time with point solutions trying to figure out how recovery is going to happen across these things.

And that's not just identity. That also applies to everything else that's happening in an environment. So again, that consistency that we build in the platform is super important, and we want to make sure that as people are onboarding these new pieces of the products, whether they're identity or AI workloads, we want to have that familiar look and feel, whether it's going to be the admin or it's going to be someone reading signals that we get out of the product.

So we built immutable protection for Okta. We're providing point-in-time recovery for Okta, and then it happens all under the same umbrella under Commvault Cloud Unity. So baking that consistency in.

And again, this is not just about us providing a brand new workload, right? This is another area of the product that allows us to generate really high-fidelity signals that are happening inside the identity space, and I'll talk about that in just a second. Quick question.

Sure. It's Shalika. So speaking about workloads and adding all the different things you can add, going back to the deep inspection.

So at scale, how long is it taking to run a deep scan? A deep scan... Can you answer that?

The time it takes for a deep scan? Sure. Yes.

Dave here. So deep scanning, it would depend on how much data you're scanning, obviously, and there's filters we have in, but you can look at, I think some of the numbers we're looking at was, in some of the simulations was 200 VMs in about 10 hours for a deep level scan. However, Mike touched on the hyper threat hunting capability where we can do an index onlyhash lookup and that's super quick.

We can look up millions and millions of files and check them against known threat hashes in a very quick amount of time. So that's where the layers to the approach come in. It's like the quick approach is good for that initial do you have a threat, and then the deep scan is when you need that extra kind of level of assurance.

So And then so are you able to prioritize workloads by chance, or? Yeah. So you do.

It's a plan-based configuration, so you can definitely prioritize workloads. We actually, generally to make it easier, we recommend just putting all the workloads in one plan because it's automatic the way we scan things. It's just a background incremental scan.

So just for the protection of the data, we just make it easy to onboard into one plan, but you can certainly stagger it. And we have our standard blackout windows and things like that to kind of prioritize when you want scanning operations to run. Yeah.

Oh, thank you. Yeah. I look at it as the quick scan is almost like your litmus test.

And then, the platform itself, he was talking about plans, they do support tagging, both Commvault-based tagging and cloud-based tagging. So if you do have a really sophisticated tagging taxonomy, we could use that as another indicator on how we prioritize and scale things so that they can happen at the rate in which you need them to happen, like tier zero apps or your AI apps or whatever. So, we do have all that kind of minutia that sits in the platform that we commonly don't talk about, but when you think about building a highly effective and efficient system, all those capabilities do exist as part of the platform.

And we do encourage folks that do have a tagging taxonomy to just marry that into Commvault so that it provides very good predictability on how the platform is going to respond, especially when we're doing auto-scaling and scaling of resources to do things like scanning. I do have a quick question on the Okta integrations. So obviously this is the identity engine side, so your identities.

Does it also support recovery of the customer identity that they bought when they bought Auth0? I do not know. We will need to take that question, but I'll get you an answer on that.

It's a great question. Cool. So that's Okta.

And, as we've been talking about that this is a team sport, we made an investment in CloudSEK because we really believed in their technology. And there's a lot of different pieces that are part of CloudSEK. So this is just one example.

But when CloudSEK detects that a external identity has been compromised, again, talking about how we collect rich signals and action on them, we take those signals from CloudSEK, we're able to identify the impact of those identities, and then we can action on them directly in the product and start to kick off workflows that can force MFA. You could reset the credentials, you could revoke the credentials, you can kill the tokens. " And that allows us to action on that in almost real time.

Right? So we get the signal in, that's a really high fidelity, high severity signal, and if that credential's being used in the product or we see it being used, in other areas, we can then action on them. And for those that are here, feel free to look at any of these things that we're talking about today, with the exception of the last thing that I'll talk about with Microsoft.

All these things are available in the booth as demos. So if you want to actually see these things operating in the product, including the CloudSEK piece, I absolutely encourage anyone who's at RSAC, this week to certainly check those out. Because it's one thing for me to stand up here and say it, it's another that we can prove that these things all happen as I'm describing them.

So, please check me. We're really proud of a lot of these innovations and thinking about new ways that we can provide signals and incident response so that we can minimize blast radius and ultimately cleanly recover, and understand how threats are evolving. So, certainly check them out.

So after identification, we can do those particular things. And again, us understanding through backups, understanding the identity, being entrenched in Entra and Okta and AD, and looking at the applications that we support, it almost allows us to build a timeline attack chain. Right?

So we can put a bunch of pieces together, again, through what we know in Commvault, and we can send those signals out so that we can almost provide a mock report of, "Hey, we know that these signals are here. This account compromise was here. This is what it has access to.

This is where it was being used in Okta or whatever," through understanding through the different backups, and we allow you to roll back those changes. So, if an account was compromised, there was lateral movement, they were added to the domain admins group, we'll see how those bits and pieces unfolded by looking at that account and the backups that we have across those identity servers and provide the ability to roll them back. So no more having to do a full recovery of these objects.

We can surgically do that. So again, these themes of looking at how we take signals and do surgery upon things so that you could do nice clean recovery without having to bring everything back, you can see how all of these things are kind of working together. So, we use CloudSEK signals for that.

SoAgain, we'll pull signals from any third party in this particular case, and CloudSEK has a really good way to detect these things, and this is what we're bringing in so that we can provide those responses. And then just like every other signal that we get, we can go send that to a SIEM and SOAR, and if the SEC team needs to do something or we need to bring it into the clean room and understand what's going on, we have all those as options, too. Similar to the question I asked earlier about signal sharing, do you listen for if somebody's deployed ITDR solutions, like honey accounts and honey tokens for those getting touched?

Yeah. And use and trigger any of this through that? Yeah.

So we recommend that those configurations are purposefully built so that we can get those signals, and then obviously action against them. So, our recommendation is always understand that we're not going to randomly discover it, but we do want to have that configuration so it's like, hey, we know that this thing is happening or may happen, and then we can action on it appropriately. Awesome.

And then, as I said, it's not just about we're protecting Okta now. We look at all of these bits and pieces as ways that we can identify what is going on in these systems so that if there is account compromise, if there's backdoors being built, if there's other things that are going on that are anomalous, we can detect them, understand them, and then provide quick rollback capabilities so that we can do the surgery and do all of the heavy lift on our end and not have to burden admins with staging it somewhere else, extracting only the changes, and then pushing it back in, which is what we've seen historically. So, these things are much bigger than just backup.

This is all about really understanding what's happening in these systems. And in this particular case, we're talking about identity, but these are principles that we're building across the infrastructure and our platform to make sure that whether it's a database, identity, files, VMs, that we can provide a very consistent path to recover from traditional DR scenarios or cyber, or any of the other threats as they evolve, especially with AI kind of looming behind the scenes. Cool.

20 minutes, okay. I think we're making some good progress. So another investment of ours, but this one was an acquisition.

A couple of months ago, we bought Satori Cyber, and Satori Cyber was a awesome piece of technology that we added to the platform, and there's bits of that thing already baked into the core platform of Combo Cloud Unity. So that was a very quick acquisition to be merged into the main product. And what that provided us was the ability to augment our risk analysis product, which is what we talked about earlier, which allows us to do deep data discovery and classification and add all the new workloads that it does data discovery and classification on.

These are the Snowflakes, these are the Amazon RDS databases, structured data. So we take what we had with unstructured and structured data, we added the structured data from Satori, and now we have an AI-heavy product that we can understand where the data is and what's going on with that data so that if we need to provide data risk analysis, if we need to provide just even visibility of things, it allows us to have a much wider sweep of what's going on, especially as these applications are starting to be used by AI, and that's what we're seeing as kind of the hotspot. So this filled a really important gap in the risk analysis product so that we could provide that across the scenes.

And again, this allows us to do just deep understanding of where there's PII, passwords, and secrets. And look, these things leak in. They just happen.

And although we have a policy that we could apply across all of the different applications, that provides us, again, this consistency across the platform that you understand we're looking for these particular things. It doesn't matter what workload it is, it doesn't matter what database it is, it doesn't matter if it's Databricks or Snowflake or Amazon or an old school Oracle database. We do it consistently across the board.

So we're finding a lot of customers are starting to, especially with RAG workflow pipelines, they want to better understand what is going on and what's going into these systems so that they can remove any PII or sensitive data, so that they don't get inadvertently surfaced. And there's lots of other controls that we've seen out in the market, and anyone who walked the floor in the last day or so can see there's a huge amount of startups that are trying to solve these particular problems. But again, we're doing this in a very unified way with our platform and with all the support of the databases that we've traditionally done.

So you kind of get the best of both worlds that it's not only AI focused from our end, it's also traditionally focused. And as we think about the wide breadth of customers that we have, that allows it to be really full service for them. So if there's any consolidation with all these point solutions, our platform becomes pretty key for them to do that consolidation with a very robust platform.

And there's all these awesome charts and things that you can see. And like I said, if you go downstairs to our booth, you can certainly see how we put all of these threat signals together so that you really have a wide understanding of what's going on inside of your infrastructure, whether it's structured or unstructured data, primary or secondary data, to really have good data-driven decisions on what's going on from a risk profile standpoint with your data, especially if you're doing stuff like RAG. A quick question.

Sure. Good morning. Sky Fugate.

So with getting those data insights, how are you gathering that? Is that based off of the data that I'm already protecting and you're just pulling those insights out of that? Or is this something else that I have to go put as an overlay across the rest of my environment?

Yep. So we provide optionality, just like everything else. A process that will sweep it on the live data.

So if you don't want to protect it, say you have a massive database that you just don't want to protect it and do this on, we could do it on your live data. And then the alternative is if you do want to do it on your backup, we can facilitate that too. So we provide that optionality and, as we've seen, again, it's a mature product we've seen over the years that customers are pretty split.

Some like to do it on primary data, so they're not doing massive data movements. " If you could do it off of the backup as a secondary data use case, we provide that facility to do that too. And does this also give me the ability, if I wanted to see was...

Let's say it's PII. Can I see that there was still this record in all of these backups, and then this is when that rolled off? Yes, absolutely.

So, the product not only is a detection capability, but it also allows you to remediate it. And we could also do redaction as part of that. So if we do discover some data that we find some PII in it, and you still want to use that for RAG or whatever your data use cases are, we could redact just that sensitive data and then serve it into these systems.

And there's a whole other thing that we're not going to talk about today. It is downstairs, though. And that's how we serve data up into AI applications.

We can do all the data discovery and redaction and then provide the redacted data into these systems so that you don't have to worry about those things if you want to use the rest of the data that's around it and just obfuscate the redacted data. So we do provide all those capabilities, too. Thank you.

Awesome. Thank you. And then that gets us to the final part.

So now we've done all this deep data discovery and classification, and now it's like we have to do something with that data. So, Satori also brings to us data access governance. And I'll give you an example where I think it's a really strong case, especially with the AI as kind of the frame.

What it does allow us to do is the Satori Data Access Governance capability allows it to sit in an AI workflow, both in the beginning and at the end of the workflow. And why that's important is you don't want PII going into the LLM, and you don't want the data to be returned out of the LLM. So Satori can sit on both sides of that fence.

Not only will it block the PII from escaping, it also provides a signal for us to then push back into the thing we just talked about with the DSPM-like capabilities so that we can refine the policies on how that data got in there to begin with. So again, same type of theme. How do we start generating high-fidelity signals to action on and improve your security posture, and then ultimately drive to clean recovery?

These things all start to work in unison together. So, these capabilities allow us to generate really high-fidelity signals, and then we push it back into these policies. Why these policies live in Commvault?

Because we could apply them to across all of your workloads consistently. So we get questions all the time, "Hey, I can go do this through Unity Catalog. I can go do this in Snowflake.

" Because I could apply that policy to all of these different workloads that we support instead of just Databricks, because we all know that not all of your data that you're using for all these things live in Databricks, right? It's just the reality of how people are building applications today. So the big advantage for us is really we could apply that consistently across the board, and then as we start to take in these signals, we could then refine the policies and make sure, and we can clean these things up so that they don't continue moving forward.

So it's a self-reinforcing loop on how we prevent data leakage and things, especially when we start talking about AI and GenAI. But just quickly, is that a real-time redaction? So is that- Yes ...

basically in real time while it's being pulled in through RAG or whatever it leans into? Yeah. So you send the query, the DAG will pick it up, it will immediately redact that data that you set the policy for, and then it'll go hit the LLM.

So it doesn't require time to have- Nope ... scanned and identified that previously as- No ... PII or something sensitive.

No. And that's why that use case is really important, because when that generates the signal that someone actually tried to put PII in it, it's like, how do I prevent that from happening moving forward? Does it also integrate with data classification?

So could we say instead of just looking purely at the content of what's in the file or in the data, can it be data that's classified, restricted, or something like that? Absolutely. So that's why the deep data discovery and classification is part one.

It doesn't have to just be sensitive data. " I guess more specifically, does it tie into data classification policies that might already exist? com or something like that with their data classifications- Uh ...

will it tie into that? Yes, with exceptions. Not everything.

But I know we do it with Fabric, Microsoft Fabric. Cool. Okay.

Very last thing. Super awesome. So I mentioned before, we have lots of rich partners for how we go about incident response because, again, it's a team sport.

Cyber is a team sport. And this is our latest integration that we extended. So we used the Microsoft Sentinel part one, using some older technology on their end.

We had an integration that was bidirectional. We had recovery runbooks. That was all good.

Microsoft came to us as one of our favorite partners, and they said, "Hey, we're making updates to Sentinel. It's going to have a data lake back end. " We reconstructed the integration, and then we added all the ability to have a Copilot run on top of it, Security Copilot specifically.

So that allows us, again, to kind of break down these silos of, hey, we're generating alerts and things in our platform. And then we want to make sure that we use all the tools at our disposal that now are bolted onto Sentinel Data Lake so we can remove all of that churn from all of these different signals that are coming from all these places. We can send our high-fidelity signals into this, and then you can carry on with incident response.

And again, these threat signals can be third party, they could be from risk analysis, they could be from Satori, they could be from Threat Scan, they could just be from the platform's anomalies. So this allows us to have really high-fidelity data to go into Sentinel Data Lake and then provide that recovery layer, again, through a runbook that someone sitting in Sentinel can go, "Yep, there's a problem here. I need to kick off a forensic recovery.

I need to kick off a synthetic recovery. " We provide those capabilities for them through the runbook. So again, kind of bridging that gap and allowing everyone to move in unison.

So, really cool. And this is one of the many announcements we're going to make with Microsoft this year. There's a lot of cool stuff coming, and stay tuned, because lots of exciting stuff coming with Microsoft specifically.

Okay. Me again. My name is Dave Cunningham, the product manager team at Commvault.

I work on our cybersecurity solutions at Commvault, including our integrations. So what I'm going to do here is I'm going to show you a demonstration of our cyber resiliency solution, and I'll give you the gist of what we're going to do. I'm going to simulate a malware event where it's going to have some data corruption encryption, and then I'm going to show you how you can investigate that within our dashboard, and then ultimately hunt for threats using hashes, and then ultimately get to a clean recovery.

One thing I want to point out, this is a simulation. Everything's real that I'm showing you in the demo, but cyber incidents come in all different shapes and sizes. We've had customers and organizations that had to rebuild entire environments and some that had to put pieces together here and there when a cyber incident occurs.

Ultimately, what we want to be able to do is help our organizations get to clean recovery as fast as possible while minimizing the data loss and rollback. So I'm sitting on a file system, and what I'm going to do is I'm just going to show that I have some data here that you can open up and read, some security documents. This is being protected by Commvault.

We're already backing it up, and I'm going to run this script, and it's going to encrypt the data. So like I was saying before, you can look at the data, you can use a lot of different sources to look at dwell time, how long it takes to detect cyber threats. The numbers are all over the place.

I like to use the Verizon data breach report. Nonetheless, if it takes days, if it takes weeks to detect a threat within an environment, there's a risk of data being protected from a data protection perspective. Right?

We're continuously protecting the data. We're making copies of the data in the backup repository, and this data is going to get protected. So I'm going to move over into our Threat Scan dashboard, where we'll start the investigation.

So let me pause it right here and talk through this a little bit. So number one, I was briefly talking about this before with the question, how long it takes to scan data, to do deep analysis, whatnot. So let me explain this a little bit.

So the default capability in the product is make it easy as possible for customers to scan their data and protect it. So we incrementally do this in the background. You onboard your resources into a plan.

We will incrementally scan it using various different scanning methods, signature-based. We have a machine learning engine for detecting encryption, hashes, YAR. There's a lot of different signals.

We'll dig deeper into it. So we make it as hands-off as possible. Now, keeping in mind, the persona that's using this dashboard may or may not be a security persona.

Right? So right now, we're talking about cyber recovery, and this dashboard is helping the persona that's going to do the recovery process, find the clean data, get to that clean data, and recover as quickly as possible. So number one, what we wanted to do on the left side is make it super easy to understand what you need to look at.

We do this by correlating the signals. So we have different layers of signals, anomalies, higher fidelity signals, such as detecting the malware. And depending on how many signals are being detected and what level of signal is being detected, we can classify them in these different risk levels.

So first of all, critical resources will be ones that have malware detected. " But any resources that have multiple signals being triggered at the same time, like maybe you have an anomaly, or maybe you have partner signals telling you something's happening on the resource, we'll designate that as high. And then moderate would be one signal, like an anomaly.

Right? Our anomaly detection is detecting changes as we're protecting the data. It may not necessarily mean there's a threat, but it means that something has changed in an unusual way and you should look at it.

But that's a moderate risk. Combine that with another signal, now you have a higher level of risk. So number one is identifying which resources you want to focus your attention to.

Then you got the right side, which is our outcomes. So we're continuously scanning the data, and we can tell you that we detected this amount of data is clean, we can detect how much is malware infected, how much is encrypted, so on and so forth. So we're providing you with the results on the left side.

And if I scroll further down, these are operational type components on the dashboard, so you can see where your scanning gaps are. Do you have resources you're not scanning? You can true it up.

You can get it onboarded as quickly as possible. So let's dig a little bit deeper in here, and I'm going to take one step further, double-click here, and we're going to go to the critical resource list. So these are the resources that are in critical status.

And you can see from the columns that are multiple different signals being triggered. I got some anomalies. I got partner signals.

I have threats. I'm going to dig into each one of these in more depth, so don't worry. You could do a threat hunt using a hash, you can use YARA rule.

So the first thing I'm going to do is show you how you can do that. And what I'm going to do is I'm going to modify the plan. And so the plan is basically a set of rules that you're going to set up.

You're going to associate all your resources to the plan, and it's going to tell you what the scanning schedule is going to look like, if it's automatic, what intelligence you're going to use. And then you could also provide your own IOCs. And you can see here I have a list of IOCs, like YARs and hashes, and I'm going to bring over my Google Threat Intelligence platform just to get some more IOCs.

So I'm just going to look up LockBit as an example, and I'm going to look at the LockBit campaign here. Of course, Google provides a whole bunch of information, but for this demonstration, I'm just going to grab some hashes here and download this, and I'm going to inject it into the plan. So what I'm showing you is how you can manually do this.

We've had customers tell us before that their security teams would come to them, like as a backup admin, their security teams would come to them with a list of hashes, scan the backups using these hashes, or scan the backups using these YARA rules. That would be the process here. In addition to doing it manually like this, we also have SecOp APIs, where you can automate this.

So your SOC analyst can automate the import of these IOCs into the plan so it's more streamlined. So you can see here, I imported the hash, and now here's my hash list. It's a JSON with a bunch of hashes in it.

I also have YARA rule in here for a different threat, Brick Storm, a YARA with the various different rules in here. So now that I've imported these IOCs and rules into my plan, my regular scheduled base scanning will use these IOCs as part of the scanning intelligence, or any threat hunting operation or on-demand scan will also use this. So if I go back over to my dashboard, what I'm going to do is I'm going to re-scan my resource, essentially perform a threat hunt operation.

And when I do this, I have an option of doing full and incremental. So I could incrementally scan this resource, meaning that only the data that's changed since my last backup, that's the only thing I'll scan. Or I can go all the way back in time, scan all the backups for that resource, which is particularly useful if I have new IOCs, new hashes, new YARA rules, where I need to go back in time just to make sure that the backup is safe.

So these are my two options here, and I'm going to run a full, and I'll submit this. And I'll pause after I do this just to see if there's questions. Okay.

I'll pause up to this point. So I submitted a threat hunt. It'll use everything I have configured in my plan, including the new IOCs, and it's going to look through all the backup data, for that full cycle.

Any questions up to this point? Self-explanatory? Okay, good.

So let's move along here. And what I'll do now is I'll show you the details of what was picked up from a threat perspective on the resource. So what's interesting is, we have a mix of personas here.

So typically, the user that's using this dashboard, they may not understand all this data. But then we have security teams, CISOs, management, that want to see the details of what's happening in the backups. They need to see the threat details that we detect.

So we have these various different trends and charts on here. So you can kind of see when the threat first started. You can see the list of anomalies that occurred, and this will give you a full list of files, which is great for an investigation, and for understanding what your impact is.

These are all the anomalous files that were protected, and you can see what type of anomaly occurred on it, such as they were modified, or if there was unusual amount of deletes, or a MIME mismatch on the file, or even a change in the dedupe ratio and the size of the backup itself, which could indicate that there was some sort of a mass encryption that occurred on that system. Next is the Threats tab. So the Threats tab is really interesting because this is a culmination of our quick hyper-scanning, where we're looking at the hashes on the backups.

Or this is also a combination of the signature-based scanning and machine learning-based scanning, as well as the encryption-based detection as well. So what we have here is a list of files that were detected by our machine learning engine, that they were encrypted. Now we have a model that we've built that will actually look at the file and it'll determine whether that file is encrypted or not encrypted.

Right? And it's based on, we've trained it against encrypted data, like real ransomware samples and things like that. So we can detect that with a relatively high level of accuracy.

So you can see here I have a bunch of files that are encrypted, and then I have a malware threat detected. And you'll notice that my executable was detected here. So I'm going to click on this, and number one, you're going to notice that on the right side, our generative AI solution, we call it Arli, which is, I think it's OpenAI based on the back end of it.

And this is our gen AI assistant that's going to give you context, which is super important for this persona, because making the data really easy to consume for a person that may not be so adept to security is very important. So I'm going to go ahead and scroll down. You can see a little bit more context below.

We have the hash of the threat itself, so you can use that for additional threats. I'll move along to the partner signals, which is another insight that we have, and this is where you can see CrowdStrike providing us input from the CrowdStrike XDR platform. They're one of the partners that we integrate with.

Any unusual behaviors we detect on the live system, we correlate it to the backup, and we use that as a signal for correlation purposes and to give you a higher level of indication that something is happening on that system. And if you don't understand the CrowdStrike info, you can use Arli once again. All right, so now I'm going to get to the outcome here, which is going to be recovery.

So two things I'm going to show you here. Number one is the calendar view. So we have a threat-aware recovery that we've implemented into the product, meaning that all these recovery points you see on the calendar here, we will tell you if there was threats detected across those recovery points.

So it makes it super easy for the user to see which recovery points were impacted across the period of time. You can see I have quite a bit of impact here. I could recover off this.

I could go pick a time date on here and just do a recovery, but the one thing that it's not going to do for me, it's not going to intelligently roll back my data in an intelligent way and get the latest version of my data. I'm literally going to pick a point in time and roll back to that point in time, and that's where the synthetic recovery option comes in. So if I scroll down, the synthetic recovery option is the automated clean option, and you can see here, I think as Mike explained before, we will programmatically look at the files, because every threat that we detect, we track it in our index.

We'll programmatically look at the files. We'll find the last good version of that file across all the backups, build that curated recovery point, and send it off for the recovery. So you can see here we're also telling you the level of impact as well.

5% of the files coming from the latest backup set, but then some of the files are being pulled from previous ones. So it gives you a really good indication of the level of impact when you do that recovery. Below that is forensic recovery, which is like the inverse.

It's like the opposite. This is for security use cases where maybe you want to recover the infected data, but in a controlled way. If you pick that option, you could only go to our clean room solution, which is our isolated recovery environment, to pass off to a security team.

So it's a secure way of doing an investigation. So I'm going to pick the synthetic recovery option, and I'm going to click Next, and one of the new options we added into our product is integrated clean room recovery destination. So in place would be I want to recover back into production directly.

Out of place would be I want to recover to not the same production system, but another production system. And then clean room is our isolated recovery environment, and that's a great way to test your data before putting it back into production, just to do that one last bit of validation. So I'll pick that option, and then I'll submit this recovery into the clean room, and then it rebuilds the operating system using a clean image.

It puts the data back on, and then I can remote into the system and look at my files back in the recovered state. So that's the end-to-end process of detecting threats using the layered solution that we have, threat hunting for specific things, specific IOCs, getting all the way to clean recovery while minimizing rollback. In that recovery scenario, did it recover the entire VM itself, and was that a downtime hit, or was that actually just going in and putting those back on the file system?

Yeah, that was a full system recovery. So the synthetic recovery is meant to be simple. So in Cobalt, you can be very granular with your recovery.

You can pick certain things you want to recover. " So in this example, I put it out of place into the clean room. I didn't go right to production first.

I could do that if I wanted to, though. Yeah. So I'm kind of curious about Arlo's integration.

Does that extend into any of the partnerships that you have with other tools as far as the data that you're bringing in there, or is it really just going to show you what's on system and in your environment? Ask me in three weeks. Okay.

It intelligently pulls the data off of some threat sources on the back end. So it does do that pull. It's more of like an internet pull, and we curate that.

Got it. That's how it works. Yeah.

Right. Okay. In other words, we're not training the model to pull back the information.

It's doing a search. Perfect. Thank you.