Veeam Security – Protect and Reduce Risk

Okay, so our next section is going to be talking about the securing of data. So last we spoke about the understanding. This is really a follow-on to that around how do we help our customers not only have an understanding of that data, but how do we enable them to secure or see the flow of that data, the lineage of that data as it moves through the life cycle management of that, but then equally coupling it with what Veeam's been doing, to what Emily said in the last session as well, around our security story from an integration point of view, but also what we've built into the platform already.

So I'm Michael Cade, Field CTO at Veeam. I'm Emily Taas, Field CTO at Veeam. Okay, so this is really about how do we mitigate risk, how do we reduce that exposure of good data?

And generally speaking, in that last section was many of our customers, or many companies out there today, haven't got a good grasp on the data that they've got anyway. So they haven't even got to this secure. They might have bits and pieces across their estate, but ultimately they don't have...

The analogy I use internationally is the garage at home, right? We store everything in our garage. We move house, bigger garage, hopefully, if we're doing good.

And then we move all of that stuff and we just, "Oh, we've got a bigger garage. " And that's my analogy. There you go, Tom.

But the analogy fits for enterprise data as well, right? We just store everything because we're humans, right? We love to store it.

And that's fine if you want to keep on buying the storage, whatever that storage may be, in the public cloud, on prem. Storage companies will sell you more storage, no worries. From a security point of view, though, who has access to that?

Because that posture is what's going to stop, or it's going to be the difference between someone taking that data, encrypting that data, or doing bad things with that data. So having a good grasp or a good posture against that is really where we're focusing on this. And then we'll go into how does that feed into the Veeam story as well.

So I mentioned around security being a data security posture management tool, but put a plus on the end around governance, compliance, and regulation. But from a security posture rule, who has access to what? Who does what?

What is the data? Is it an AWS 3 bucket that's open? What data does it contain?

And almost wrapping those policies, those frameworks around that data set so that you can protect it better, but also just have visibility of it. Like if you have an AWS S3, and this is just an example of a best practice in the public cloud that is very topical, S3 buckets being exposed to the world. Let's flag that so that you can at least do something about it.

So it's almost a, I would say, a lightweight ticketing system. However, it does link into the likes of ServiceNow as well, to be able to say, "That S3 bucket that you've got over there is open to the public. " But equally, it could be about data moving from one country to another.

From a, again, as a Brit on tour in the US, data sovereignty is a massive thing. It's not just where your data is located, it's actually the legal jurisdiction of that data and who has access to that. If you're moving data from the UK to Germany, and you're meant to be adhering to data sovereignty rules, that data from a legal jurisdiction, if someone's got access it from Germany, it doesn't matter where it's stored.

So there's a lot of different posture to consider there. Quick question. Shala here, known as Gifted Lane.

So what I'm starting to think about now is like when, say, something like that happens, is there like an alert or something that goes off and is it email? Can you do text? Is it Slack or Teams?

So yeah, great question. So yes, it can be. It can be any of those.

It can feed into ServiceNow or SIEM platforms. Also from a dashboard point of view. Now, I don't expect people to just live it-- Like we're not just going to have a DSPM human to look at this dashboard all day, every day, but it will be flagged up and visualized there, as well as the reactive reporting as well.

So really this is about having a good grasp on what that data is, where it's going, who has access to it. Also being able to get those reports or having visibility of when people have too much access into those data systems as well. It's very easy.

We've all been through the, you get God mode, you get God mode, and domain admin here, there, and everywhere. And it seems like potentially with agents, identity is going to be a massive thing that we're going to have to deal with from a resilience point of view, but also in enterprise IT. Who has access to what?

That agent has access to everything because it makes my life easier. I'm just going to unlock the world to it. No.

We have to have a good control plane to that. Let's say someone has God mode or an agent has God mode or something like that. Is it like weekly reports or something where maybe it gets flagged to say, "Hey, you may want to rectify this," or how is the customer notified?

So it's all based on a policy. So if you want it to be real time, whenever we're picking up that change, then we can see that and feed that into those systems to be able to get that. Feeding off Shala's question.

Sky Fugate. I know that you mentioned agentic identity or AI identity, and finding what has access to the resources across your environment. How are you making those determinations?

How are you saying, "You should have access to this. You shouldn't have access to this"? So that comes down to the policy.

So we can bring in policies, frameworks, but we're not deterministic to who should have access to that. So we're just going to flag up who has access to it, and then it's down to the data system owner, the app owner, to determine, like, actually, they shouldn't have access. That group shouldn't have access.

So we're not doing anything to say you shouldn't, but you can be quite granular. I'll bring up the sovereignty story again, is that if you've got a user that is based in Germany that's accessing data in the UK, then we can flag that. Again, the user is going to put that logic into the system because in some companies, Germany to UK, accessing data is going to be absolutely fine.

In financials, that's not going to be fine or another industry. So a lot of it, the building blocks are going to be put in place from us, like as out of the box, and new ones can be built as well. So if you've got your own regulations or compliance rules that you want to bring, then you can create custom ones, but out of the box, we're going to provide these ones, and you choose what ones you want to use.

So this gives me a framework that I can then go enforce my own policies and internal memos. Correct. Okay.

Exactly. If a country doesn't maybe have to adhere to GDPR, but they like the idea of GDPR, but they like the idea of the EU AI Act, they might merge those and create their own custom regulation that they want to adhere to, to be more hygienic from a data perspective. Yeah.

" And so from our perspective, it's more just providing that contextualization piece and pulling in all of those different types of frameworks that an organization can utilize. But then up to them to take action on the actual ownership of that data. " It's more so we can make sure that they're fully informed of everything that's happening within that environment.

Thank you. Mm-hmm. Yeah.

Was there another... Well, I was just curious if you partner with any IAM providers, companies, things like that, that actually can do remediation. So in other words, you do the reporting, you say this is, okay, HIPAA, you've got a bunch of HIPAA violations, and then your partner product, you can feed them, and they'll do the remediation.

Because there are products out there that'll do that- Yeah ... on the remediation side. I don't know off the top of my head is a good...

We integrate into the Entra IDs, the Optas, the et cetera. Okay. I just don't know whether we integrate enough to tell it to revoke access.

Sure. That'd be a very good follow-up to come back to. I mentioned about this as well, about redundant, obsolete, and trivial, or if I've mentioned ROT data, that's the acronym that I'm using.

And there's two areas that this is important to, and it resonates with our customer scope at the moment, is one about reducing cost. There's not a company out there that doesn't want to reduce cost or mitigate risk, right? That's number one bullet point.

If you can help them do that, then we're always going to have a conversation. But reducing cost of, to that garage analogy that I used, you've moved all of that data from garage one to garage two to garage three, enterprise storage, enterprise storage, and you're just adding more data to it. If we can help the customer understand duplication of data, but also just old data, what's not been touched in the last six months, what's not been touched in the last six years?

Is it sensitive? Do we need it? Make that decision tree so that they can reduce the cost.

Now, I'm not saying delete it. That might be an outcome of that. We're not going to delete it.

We're just going to flag that up. We're just going to visualize that for them so they can make that decision. But equally, how can we help them tier that off into a cheaper, deeper type storage plane as well?

And on top of that, from a security point of view, if we get rid of six-year-old data, six-year-old sensitive data, we're just reducing the attack surface. But also, we're not muddying the water. If you've got the same document repeated every year that contains the same data, or differing data, like reports, et cetera, then you're getting rid of that muddy garbage that could be influencing what we're going to get to later around being able to leverage and use and unleash that data.

So there's twofold to redundant, obsolete, and trivial. One is being able to reduce the cost, but also mitigate the risk. If you don't need it, let's get it out of that.

Oh, and bricks. But yeah, what does that look like? In terms of visualization, how do we show that?

But that's across all of your data systems as well. So I keep on referring to the data command graph as a social network of data. So you've added in all of your data systems, structured, unstructured, databases, NAS, et cetera, and your identity systems, and your cloud, and all of this is building up this social network of all of the data that you have.

What is redundant based on the characteristics that you want it to be. But everything has been fed into this graph database, the data command graph. So you can then run queries against that data to be able to give you an outcome of that.

Maybe you just want to see what that looks like, how much data do we have that's six years old. So this is where I want to marry up the two between what Veeam's done over the last, feels like 10 years of security integrations and security advancements within the Veeam product, but then also that access suspension that I touched on. So if you think about the production side and all of those different data systems, let's understand the entropy of that data.

What is that data? What data is contained in there, sensitivity of that data. We're going to have a good understanding of that data, which then allows us to flag up anomalies, who's accessing it from that country, but then two hours later, they're in New York, and that is not possible, and they're making changes.

It is possible for VPN, but yeah. But you get my point is that, it gives us a good understanding of the data, the securing of that data, the flagging of when bad things could potentially be happening, and feeding that into other systems to be able to act upon that. Which then leads us into some of the stuff that Emily just touched on, but then more so going into the security integrations that we have.

Right. So when we thought about building a lot of our security-based integrations from a Veeam standard, right, we thought about it in terms of, okay, well, we have access to the data as it lives in a backup. So really when we think about this, we're marrying the two of what can we do with the primary data and where it lives at source, and then what can we utilize that to make better decisions on the secondary data or your backup data itself.

And a lot of the tools that we've integrated into the backup data portion of it is really what helps us to create those better outcomes. So if we think about it in terms of threat scanning, well, now I have the capability to do inline-based malware detection. Now I have the ability to leverage ER rules that are provided for me from my security team.

Now I have a capability to search for indicators of compromise and what those tools possibly look like. We could do file system activity analysis, right? Understanding when data becomes encrypted or when there's large changes that are made that are symptoms of encryption.

And then we can also leverage our security partners or that broad ecosystem to pull in what it is that they're seeing from a production side and be able to flag that data that could be seen as malicious inside of the backup data, so that way our teams, from an IT operations standpoint, know that that data is not going to be ready or clean or verified to be able to perform a recovery. It makes them do an extra level of due diligence. So our ecosystem is pretty large.

We add a new vendor, or a new sticker, I would like to say, almost every couple of months. Actually, our head of product management is here at RSAC, and we have probably 16 different meetings set up with all of these broad vendors, right? So when we can talk to organizations and integrate to their SOAR platforms, we can leverage SIM, we can integrate with ITSM, we could do things around KMS, and then even storage integration.

I think I will say that from a storage perspective, I think that's my next one, this is brand new. This just GA'd a few weeks ago. So this is actually with Pure Storage.

So essentially we have this capability here where essentially what Pure is doing is that they're understanding from a storage perspective of where those virtual machines are living. They've identified a potential anomaly that is happening within the production environment. And because we've created an API in which you can flag those potential systems from a backup perspective of having something malicious or anomalous onto it, they can also leverage those APIs from with inside of Veeam and go through and flag those backups as well.

So you can see here, even from an ecosystem perspective, those companies that weren't in the business of security are making some very large strides to provide additional information around risk mitigation for customers, right? And so this anomaly and awareness workflow is one of those next frontiers that you're seeing from a production storage use case. " And then now we can make better decisions in terms of quarantining this data, cleaning this data, and coming up with a more effective response.

It's all about just creating those signals, so that way the security teams that are in charge can actually make more informed decisions. Just on the Veeam incident API, so that's a public API that is exposed from a Veeam perspective. Just because that previous slide has loads of logos, if there's something that can trigger an event to say something bad is happening, weather's come in, it can hit that API, and it can enforce that backup, that point in time copy of that data.

Yep. And so even on top of that, right, so we have purpose-built applications that are built within each one of these security vendors' marketplaces. So they could go, and you could download a specific Veeam app for Palo Alto, for CrowdStrike, for Splunk, for Sophos, whatever it may be.

But Veeam still integrates through just standard Syslog. The beauty is, is that you have both options to kind of leverage this. And then what you're seeing that's being scrolled over on that side next to me is these are all the different types of events that Veeam is actually categorizing.

So we sit down and we looked at, okay, well, before backup happens, this is what generally happens, and this is the information that you should be aware of. And that document was actually generated with working with a cyber lead defense architect for a customer of ours in which she said, "Hey, I don't actually want to know your guys' platform. " So I said, "Fair.

Fair point. Let's get you an actual documentation of every single event, how we're categorizing it, how we're mapping that to the MITRE ATT&CK framework, and then also we'll provide you guys with some outcomes. " So she actually took that information, she integrated it with her Splunk environment that she has.

She built an app that'll correlate all the rules from everything else that's being fed into Splunk, and then she forwards that as a sev one alert into Palo Alto Networks XSOAR. So if everything flags as a sev one, meaning we see some anomalous activity, we're seeing from a data perspective from the backups that we're flagging this as suspicious or malicious. She has an incident response playbook that runs inside of Palo Alto Networks that creates a war room.

It highlights all of the application owners for that specific machine that has been flagged, and it starts what we call as an incident recovery. And it starts to run that inside of an isolated sandbox, and starts performing regular scanning, even if it's just AV signature scans. And then it puts everybody inside of a Teams chat and says, "Go start investigating this particular application, because we're seeing EDR tools flag it, we're seeing Veeam flag it.

" And so she actually built that as part of a community project. So if anybody is a Splunk, Palo user and Veeam user, you can actually find that information available today. Quick question.

So this is making me think back to, so with the right reduction, is the sentiment that it's helping make recovery, improving recovery confidence or speed? What are your thoughts about that? I will say that-- So I'll let you answer from a ROP perspective.

Yeah. You go, and then I'll- Okay. So for us, it's not about speed, especially from a ransomware or a cyber breach incident.

Speed used to be the biggest factor from an operational resilience guideline, right? We had data center failure, we had hardware failure, need to recover fast. Right.

Cyber, you don't want to recover fast, right? We want to recover and make sure that we actually know the data that's there, it exists, that we're recovering the right data, that we're not risking reinfection, right? It's a lot more of a staged response.

This particular integration with what we're trying to do with bringing all of these components together is trying to make that more informed decision on how do you correlate an effective response without impacting a speed of performance, meaning that, well, once we have all the things in place, we can click go and we know all the teams are going to be doing what they need to do. And then how do we actually validate that it's going to be clean recovery? So for us, it's more about making sure that we're providing all of those essential elements so that way they can make a more informed decision.

But from a ROP perspective, it's probably more so leaning into that understanding and contextualizing the information first. Yeah. I guess from a cyber resilience point of view, you don't want to recover too fast because that's how you're going to fail even quicker if there's something reinfected back in.

But if we think about the understand and the secure side, if we've got a good grasp on that data, our customers have got a good grasp on that data, and they can tier that. I'll simplify it into gold, silver, bronze. We can protect that data.

We know that that's been impacted or maybe it's just silver. You know you've got a better idea on what needs to be recovered as well. So it comes down to, it depends how fast that needs to be, but also how can it be safe?

But equally, if we know where the gold data is, we can bring that back faster. We can get that up and running, get it scanned so that we're not reintroducing bad things into the environment. But at the moment, we're just backing up everything, and we're just going to bring back everything, because every app owner is going to tell you that their app is the most important and their data set is, right?

So this is about the understand and secure on top of what Emily said, is going to give you a good viewpoint of what's the most important, what absolutely needs to be clean when it comes back into the business. I think that would be my answer on that. Perfect.

That's fine. Yeah. So this is just a quick show and tell of one of the integrations.

So this is one of our latest ones with Microsoft Sentinel. So customers that are leveraging the Sentinel platform, right? We built two purpose-built dashboards.

One that actually does data platform monitoring, meaning now you can actually be informed on what IT operations look like. Do we have backups that are running? Are they hitting SLAs?

Do we have missing backups? Do we have failed backups? So this provides that additional context for those that are sitting inside of the security space to know, okay, what does our backups actually look like?

And then from a security activity side, we can pull all that information that we're contextualizing. So meaning we see potential backups that are seen as malicious or suspicious, and we've marked them as possibly infected. So that way they need to take a secondary look before they just go and run to recover them.

So this is very important from a security point of view, because again, we're providing information of something that maybe used to be a black box that didn't exist inside of their world. "Well, now they can actually see that in the platform that they utilize, that they know, that they trust, and they can see that information in here, and they can take additional looks without having to go and drive directly into the platform itself. " Well, now I have these automated playbooks that I can create, that I can generate.

We have ones that we built for some of those customers already, so they have a standard template that they can utilize and that they can go ahead and clone and make changes to. But these are some of the ways that we look at customers that have already invested inside of their SIEM or SOAR tools. " No, we just want to plug into your multimillion-dollar investment that you've already made and make sure that your teams have all the right information so they can make better decisions.

I just want to make a comment. Shala was onto something about rot data, and it makes other things better, like disaster recovery. Just like that much to the garage analogy.

A lot of orgs struggle to keep just basic blocking and tackling. Imagine if it was the correct set of data, and then people end up understanding explainability- Mm-hmm ... of what they have as a kind of a hidden benefit downstream of rot analysis.

Yeah. And I give a perfect customer example. There's a customer I worked with that has, their dev environment alone was over 10,000 machines.

And they're like, "How do we even start with an orchestrated response? " So the fact that they'll be able to leverage some of these tools to get that contextualization first, so that way they can make those informed decisions about building out those workflows, is pretty large from a customer standpoint. That makes me think of another question.

So are customers able to, whether it's set up a cleaning room or whatever, do a dry run of their DR, like what they think they're going to do, so they can actually test it and not test it on the day that something actually happens? Absolutely. So in some of the sessions, well, we didn't get a chance to really get into it too deep, but we could do three different types of reporting, but also three different types of testing.

One of those is the readiness check of just saying is all the underlying infrastructure and what we've actually put out in this plan actually going to work? Meaning, do we have backups that are meeting the RTOs and RPOs that we've already set up and that we've classified from the customer standpoint, or from the business? Does the infrastructure that we're writing to, meaning if we're sending it to VMware, if we're sending it to HyperV, we're sending it to Azure, do we have the right access credentials in there?

Do we have the right CPU, RAM, storage space that's needed in order for us to perform these restores, or is it going to fail? Do we have the right network or credential access as well if there's specific applications? And then on top of that, we can even inject different types of scripts as well as steps.

So my example just showed performing a restore of that virtual machine into another hypervisor platform. But we could also take it a step further and say, this is a SQL database. Scan those ports that are available within that SQL database to verify that they're going to be up and running and make sure that services are coming online before you start the next restore of this next machine.

Because this machine needs to be online and active before this one can talk to it. So we could run those readiness checks to validate that that underlying area is going to work, and then we could also run it inside of a test, which is with our data labs that we've had for close to 10 plus years. " And knowing that it didn't actually run inside of production.

So Jack Palmer here from Paradigm Technical. So for things like the readiness checks, are you requiring the user to tell you what needs to be done, or are you inferring that from your knowledge of the environment? Both.

So we're pulling in from the backup policies that they've already created. So that's how we're creating based off of the RPO and RTO. " And then we go and look at the backup policy and we say, "Well, you just put a machine in there that doesn't get backed up once a week.

" So we're using the intelligence of what they've already put in from a backup policy perspective, and then we're referencing that back based off of whatever the customer put as what they think their RTO and RPO should be, and we're showing them discrepancies there. So I'm thinking more of the example that you said, which was, this is a database server, so it needs to come up before the client machines that are going to access it. So are you also requiring that level of input from the user, or are you able to infer that from the data graphs that you have?

We can infer from the data graphs of us pulling in that information. Actually, that would be more of a where we're seeing these integrations kind of going, of taking it in with this newest acquisition and pulling that information in. Because right now it's up to the user to go and actually put, okay, this SQL database needs to come online first, so that's up at the top of the list, and then these ones follow it.

So right now it's more of a manual process, but with our integration of this piece of the data graph, it'll make us do more informed base policies. So thank you everybody. With that, that ends our session for the secure pillar.

Stay tuned, we're going to click on resilient next.