Name: Rubrik Workshop: Amazon Web Services (AWS)
Uploaded: 2025-10-21T18:31:32.806Z
Duration: 1 h 1 min 20 s
Description: Rubrik Workshop: Amazon Web Services (AWS)

Transcript for "Rubrik Workshop: Amazon Web Services (AWS)": Hey, folks. Welcome. Thanks for joining us today for this Rubrik workshop. My name is Chase Macri. I'm on the marketing team here. I'm here the producer for this webinar that we're doing. Again, thanks for joining us today for the course covering Amazon Web Services and Rubrik. We appreciate you making your time, for us today. We know how valuable and, important your time is, so thanks for spending some of that with us. You know, our our goal here today is to deliver valuable technical content that is useful to you and and your work. And so we ask that you would ask questions of us so that you can get the most out of your time. You know, the in engagement in the q and a section here that we have on the side of our Goldcast window is the best way to submit your questions. You know, we're really interested in knowing how we can help you during the session, so feel free to use that q and a box there at the right of our window, and to submit your questions, and we'll answer them as we go. Again, we appreciate you spending some time with us. Next to the the q and a box too, there's also this docs tab. That's where you'll find the guided lab, which we'll run through towards the end of the session today. Again, thanks for joining, and I'd like to bring up on stage our presenter for today, Mike Preston. He will be leading us through the content, showing us a bit of the back end, and, leading us today. So hey, Mike. Hey. How's it going? Thanks, Chase. Cool. So yeah. Like Chase said, thanks everybody for showing up. We'll consider the first two items here done, the the introduction into the house housekeeping items. But, I do wanna reiterate, if you do have any questions, please please stick them in there. I find the more interactive, these things are, the better value both you and I actually get from them. So, anyways, my name is Mike Preston. Work in technical marketing here at Rubrik. And my main responsibilities are around cloud, little bit of SaaS protection as well as automation and APIs and SDKs and all those fun, DevOps y type, tools and processes that, we're all trying to implement out there. For today, we try to keep these as technical as possible. So I'm gonna go through a few slides, which are more, you know, like, why we need to have cloud backup and what Rubrik does differently. But from there, we're just gonna dive right into sort of how Rubrik and AWS work together, how we provide, backup for AWS, how we, how our preemptive recovery engine does a lot of the scanning and prescanning ahead of time so you can recover quicker and faster from things like cyber threats and whatnot. And then we have a a guided lab link that you can click through and walk through. I'm super excited for this one because we kinda redid everything. Previously, we had some labs. You know, this is how you onboard Rubrik. Click here. Click here. This is how you protect an e c two instance. Click here. Click here. We've revamped this one to be more sort of use case. We're actually protecting a a real world application, and hopefully, you know, you're you're gonna be working for a fictitious company, and actually onboarding Rubrik and protecting their e c two instances, their s three buckets, you know, EKS instances, things like that. We're gonna walk through an actual cyber attack and just some some day to day operational recovery. So, hopefully, you guys find that a bit more engaging. And if you have any feedback, please reach out. We we'd love to hear anything, any feedback at all that you have. Was it good? Was it bad? Do you want more of this, less of this? You know, things like that. So to kinda dive right in, we just have some stats here, and and these come from our Rubrik Xero Labs. So if you haven't heard of of Rubrik Rubrik Xero Labs, this is basically, an internal organization that we have here at Rubrik that goes out and surveys CISOs and CIOs and does a lot of industry research, to kinda get a a a handle on what's going on out there in the industry. You know, and the latest sort of stats we have is obviously, data's growing. It has been growing ever since, you know, data was a thing. But we're looking at growing, you know, up to two times for our sensitive data and just standard data 1.5 times. So as we're getting more and more data, and we'll see how this plays into the next next slide, we're actually seeing more and more cyber threats and attacks and things like that. I've been at Rubrik for just about eight years now. And when I started, you know, ransomware, it it was a thing, but it wasn't so much of a concern. Yes. We paid attention to it, but it wasn't like it is today. Today is just, you know, wreaking havoc across the world. And that's why at Rubrik, we've really shifted our our process to really assume breach. We basically want it's not a matter of of if you're gonna be attacked. It is really is a matter of when. And I see customers that are going and walking through sort of cyber threats. Customers are very, very small school boards. I'm Canadian up here in Ontario, and and very, very big and large customers as well. And, you know, this has really brought with it an increased spend in things like, you know, infrastructure security, edge security, and stuff like that. And that's super important. Right? We really have to try and block these things and stop as much of it as we can. But at Rubrik, we really take the approach that, yes, these these are gonna happen. So let's give you tools to mitigate the impact of that before it does. And then more importantly, let's ensure that you can actually bounce back from the attack and restore your data, restore your identities, restore your services and workloads after the attack takes place. And we give you the tools to kinda do this as quickly as as possible and really minimize downtime, minimize revenue loss, minimize things like that. So if you're interested in more of these stats, you know, if you head to 0labs.rubrik.com, there's a number of of different white papers and guides that they're putting out, and they're constantly coming out. You can download them. They're free resources. They're they're great reads if you're interested at all in sort of the current trends on on everything. So to quickly move forward there from that, the idea is, you know, our it says our cloud is under siege, but our organizations are are under siege. Right? And when we look at this slide, it probably looks pretty similar, to people. Like, when people look at this, they think, wow. That's that's super complex. But that's reality out there today. Right? We have data all over the place, whether it's delivered through PaaS, whether it's up in the cloud, whether it's SaaS data like m three sixty five or Salesforce or, you know, everything that we still have on prem. We have this sort of interconnected spider web of data. And when we look at this sort of middle row here of all the people that are responsible for that data and responsible for making sure that, number one, it's secure, it's protected, it's backed up, it's available, You know, it has data integrity. There's a lot of different, you know, parts within our organization, that are responsible for that. And, you know, again, to an IT guy or a cloud operations, cloud architect, you know, this definitely looks like complexity. Right? But to a threat actor, when they look at this, they don't see complexity. Right? They see a ton of different entry points into our organization and a ton of different paths where they can do things like elevate permissions after they sit inside your environment for a few weeks collecting data, expand their footprint, move laterally, move east west, you know, gain access to two different environments that you have and basically compromise and encrypt or destroy as much data that they can, including your backup data. Right? They wanna target and gather as much information as they can before they unleash that attack because they wanna increase their chances of being paid. Now I wanna walk through just a couple of examples quickly before we get into the technical portion about, you know, what causes us to need sort of data protection, data security in the cloud. And number one is just misconfigures misconfigurations and cloud failures. And and we probably you know, this was very, very recent. I don't know if you heard, but there's a billion dollar pension fund out there that essentially had, I believe, it was a blank parameter. Basically, a misconfiguration into their application or into whatever they were deploying into their cloud provider, and that cloud provider actually read that and completely removed their entire cloud account. So this is, you know, billions of dollars, people's pensions, people couldn't log in to see their account or see the status of their accounts. And, you know, day one, they had the outage. They did their root cause, found out it was that blank parameter, and they didn't get restored. You know, mission critical stuff was not restored or back online until day eight. So that's over a week of downtime, over a week of, you know, lost revenue, over a week of essentially, you know, lost brand reputation, like brand tarnishment. And then finally, you know, two weeks before they were fully recovered. All because one parameter was blank. So that's something you don't think of ever happening. But, you know, it's very much a possibility. And when we look at shared responsibility models, you know, obviously, cloud providers are there to ensure that your data is available, ensure those services are available, but but they're not responsible for the data yourself. Right? That's something that the customer takes on, in that in those shared responsibility models. Another one, which is, you know, again, very recent is CodeFinger. And this one was a bit different because it didn't even look like a cyber threat. They essentially took, you know, some of the Amazon Web Services features and used them against themselves. Right? They were re encrypting data on s three buckets and then tossing away the keys, from Amazon Web Services, leaving that data just basically unreadable. And again, when you looked at all the news articles about this, it was just like without the key, it it was unrecoverable, which I get what they're saying. But if you had air gapped immutable backups, you could easily, you know, restore this information back into another cloud account or back into the same cloud account. But the idea here is, you know, it's not just major ransomware attacks that we're we're having to protect against. It's misconfigurations. It's things like using, native cloud features against us. And this would've looked, you know, just like normal put object, API logs in CloudTrail. So it's not something that would really jump out at you as, you know, a SOC analyst or something like that to say, hey. What's going on here? Right? It's just normal activity that's happening. And and then, of course, I mean, there was yesterday. Right? We we all know what happened yesterday with with AWS and US East one. So, not much we could do per to protect against that, just kind of the way AWS was architected, I mean, even some of the cross region or cross account, replications really wouldn't have helped in in that case as, you know, there was rate limiting happening and things like that. But the idea is, you know, this is happening more and more, systems. As they get more and more complex, they obviously begin to fail, more and more often. So it's no wonder that if your cloud's breached, whether it's misconfiguration, whether it's, you know, something that happened on the cloud provider's end, or whether it's a full out cyber attack or malware, you know, how long will your business be down? And when I pose this, you know, when I go out to different conferences and and talk to people and talk to customers, you know, a lot of their answers is, it's no big deal. I have, you know, cloud snapshot or I use native backup tools, and things like that so I can just recover. And while native backup tools and cloud snapshots, these are great for your operational day to day type recoveries, they do very little in terms of cyber recovery because recovering from a cyber attack is inherently different than just, you know, restoring to last night's backup. And I I kinda wanna walk through four reasons why that is. Number one is zero days. So these are exploits in our environment that we don't even know are there. Right? The the exploits haven't been haven't been published. There's no fixes or anything like that for them. So they're they're they're they're very, very hard to protect against. And when you think of cloud snapshots, and even Rubrik in this case, as a data protection solution, it's gonna back up those exploits. We're gonna back up those zero days because that's our job. Right? We wanna give you an exact point in time copy of your data. But the problem is is if one of these zero days is used for a bad actor to gain access into your environment, and then we go ahead and restore that zero day after we fix everything up, we're just basically opening the front door again. Right? So it's not necessarily, being able to protect against them, but it's really all about being able to find them within our backups, within the snapshots themselves, and quarantine that. So that includes zero days and things like ransomware and malware. Right? So ensuring that we're not just recovering, you know, the front door to the attack itself when we actually restore. So that's, you know, the first two big ones. The second one is or the third one's gonna be assessing our sensitive data impact. Because as soon as the attack starts, the clock really starts ticking. So when we think about sensitive data, that's usually, you know, the first question that's being posed by our boardrooms, by our legal teams. They wanna know that I mean, they understand that there was an attack, but they really wanna know what data was affected by the attack. Was customer data affected? Was it financial data? Was it personally identifiable information? Do they have any regulations where they need to start notifying customers? Because, again, it's quite often they have, you know, twenty four or forty eight hours to react. So being able to ensure that we can quickly give them those answers is crucial. And you may have data classification tools already in place, that look at our production environment, and that's great. But the thing is, you know, if we're under attack, quite often the first sort of action from SOC from our SOC teams is, let's quarantine production. Right? Nobody in, nobody out. And that includes your classification software. So maybe you can't gain access, to get in there to actually classify or discover that sensitive data. So being able to understand from a backup point of view what actual data was impacted, is crucial as well. And then finally, once we get all these answers is ensuring that we're actually restoring a clean recovery point. So what a clean recovery point is, you know, in Rubrik's definition is one that, number one, does not contain any anomalies. So it doesn't contain any of the residual damage from the attack itself, so encrypted files, attacker tools, things like that. And then secondly, it's free of the the malware and the front door, basically itself. Right? So we can we can really guarantee that we're actually restoring a clean, copy of our data, and we're not gonna get into this sort of Groundhog Day scenario where we have to recover over and over again just because we're restoring the malware and everything itself. So it's sort of these four things which really slow down what we like to call your cyber RTO. And, obviously, it increases your downtime. It increases your revenue loss, you know, things like that. Because quite often, this process in itself, you know, especially with cloud snapshots, involves having to maybe mount these things into a clean room, perform manual lengthy scans on all of this stuff, ensure that, you know, we've cleaned it from malware. Is it this restore point? No. Let's try the one before that, and then so on and so forth. So it's these processes which really take an awfully long time to do. So it's no wonder when we're down, you know, we're we're down for weeks at this point. And you could look at Xero Labs. I believe the average downtime of a cyber threat is somewhere between, two and three weeks. So if you can imagine your business being down for two weeks, for three weeks, for a month, you know, how's that gonna make your business feel? Can your business withstand that? You know, things like that. So this is where Rubrik comes into play. Right? This is the approach we've taken from day one is to sort of combine both backup and recovery processes. So your traditional backup and recovery with cybersecurity. So the approach we take really involves, number one, ensuring that those backups are always gonna be there as your last line of defense. Because as I mentioned before, attackers will often target the backups as well. So with Rubrik, we ensure that they're immutable either via, you know, cloud native tools like S3 object lock or, you know, a custom, file system if we're dealing with data on prem. So it's an append only file system. The backups themselves are immutable. They cannot be changed, and you can air gap them, get them out of your identity domain. Basically, make sure that they're there as your last line of defense. It's sort of that defense in-depth approach, but we're just guaranteeing that those backups are gonna be available for you when you need them. And then combining a number of cybersecurity features on top of that to ensure that you can recover quickly without having to do this manual sort of process of restoring to a clean room, mounting it in, you know, doing your scans, things like that. So we basically do this all, with what we call precalculated clean recovery, or our preemptive recovery engine. So what I mean by that is as the data is ingested, we're gonna go ahead and we're gonna prescan all of those backup images, and we create a wealth of enriched metadata. And it's really that metadata that we create, which really powers basically everything else. So as a data protection vendor, you know, it's it's evident that, you know, we have access to your cloud data, your SaaS data, your on prem data, probably one of the only vendors in, your organization that has access to all this, and as well as we can see how it's changed over time. So we can really start to glean a lot of insights around how that data is changing, what's going on, and start to predict things, that are happening within the environment and things that can really help you actually recover. Secondly, is we provide threat hunting, threat monitoring capabilities. So we're gonna hash every single file as it's ingested and then allow you to search against that. So you think of things like, zero days. We could allow you to find them very, very quickly if you have the file hash. We also get a feed from Mandiant that contains, you know, a number. I think it's over 6,000 different malware, families, as well as, you know, common attacker tools that we're automatically scanning your backup data for and alerting you if we find any information or any matches, and then allowing you to quarantine all of that. Same with discovering your sensitive data. Again, we do this on the backup data itself. So if production even if production is gone, you know, we still got that information for you. We scan that against, you know, there's over a 100 different analyzers, things like PCI data, credit card data, passport numbers, financial data, personally identifiable information. Cloud access keys is another big one because quite often they're sitting around in plain text files. And as we all know, when attackers are performing discovery, that's their number one way is to find a script with a with a secret key in it, and all of a sudden, boom, they're also in your cloud as well. And then giving you basically the last known non anomalous, non quarantined restore point that you should recover to. And this all happens before you even log in, before you even think about recovery. So when you come in the next day and people are like, you know, something's happened. We're under attack. We need to restore. All of this information is right at your fingertips right away as soon as you log in to the Rubrik platform. So with that, you know, we can we can give you up to a 100 times faster recovery from cyber threats without the need for a clean room. Obviously, still use a clean room if that's what, you know, your SecOps teams wants to do. But, really, a lot of that functionality has been already completed by Rubrik for you. It's done through sort of this unified platform that protects all of your data, you know, whether it's in your data center, whether it's in the cloud, whether it's SaaS, whether it's unstructured, even your identity systems. Right? Because, you know, this has been a big focus as of, you know, in the last year for us is that the attack surface is no longer they're no longer hacking through firewalls. I mean, it's still happening, But quite often, they're just sending an email, phishing an identity, compromising someone's account, and then, you know, performing discovery for a few weeks, finding other accounts that they can get access to, seeing what those accounts have access to, and really expanding their footprint through identities. So we've also started to provide, obviously, backup and recovery around your identities, but resilience features around your identities as well, scanning all those identities for things like weak passwords or, you know, maybe stale accounts that haven't been used. Maybe you set up a service account for some sort of POC and you've never gotten rid of it. If that identity is still sitting there, it's a risk. Right? So, really, we're all about defining risk within your environment and giving you tools to remediate those, you know, right off the hop before something bad happens. So number one, it starts with data protection, and then it goes through through the threat hunting, the threat monitoring, like I mentioned, quarantining, the malware through our data threat analytics engine, as well as sensitive data discovery, classification, you know, assigning, risk to your data itself. Do you have publicly accessible data? These are all part of our data security posture management modules, and then, obviously, recovery, on top of that. That's giving you options in terms of quarantining the bad stuff, recovering the good stuff, and recovering that to wherever you want. Underpinning the entire platform, complete API first, approach. So for our cloud operations team, this is super exciting because they don't even really need to use Rubrik to protect their data. They can integrate it into things like Terraform or their CICD pipelines, without ever having to actually log into the Rubrik UI if they don't want to. Right? We have a number of SDKs, a number of prebuilt integrations in, like, a Terraform provider, Ansible modules, things like that, as well as integrations into the security features that we have out there, the Palo Alto Networks of the world, the Zscalers of the world, being able to perform threat hunts and different things like that, directly from, you know, the the solutions that our security teams are are used to, without having to actually learning, you know, within the Rubrik UI. So with that, that's kind of a an overview of, kind of who Rubrik is, the approach we take in terms of cloud. And I do kinda wanna get a little more nerdy now in terms of of how we actually do all this stuff in AWS. I can't go through every single workload, because we, you know, we provide, you know, solutions for e c two, for s three, for RDS, Dynamo, EFS, FXX, to talk about how each and every backup, and and restore and everything like that works. We'd we'd be here quite a while. I don't think you wanna listen to me that long. So I'll I'll focus just on e c two, for some of the, you know, how it works type slides. But if anyone has any questions about any other workloads, I'd be happy to either take it offline or, you know, we could set up a call. I'm I'm happy to run through any of this, with anyone at any time. So we'll start sort of with onboarding. And, again, I do wanna highlight that we're showing screenshots of the UI here. All of this can be accomplished through the Terraform provider as well. All this can be accomplished through a PowerShell SDK or a Python SDK, things like that. So, but we will show the UI. So the idea is this is first how we let Rubrik know about your AWS accounts. The first thing we're gonna do is we're gonna add our account information into Rubrik Security Cloud. You can do this one by one. You can, you know, apply this, upload a CSV with your account information. We support AWS organizations. So if you have a number of accounts within the same org, you can can you know, you can configure this through your org admin account, and just select what ones you wanna you want to, onboard. I see a question there from Daniel about, do we offer also offer this service with Azure? And the answer is absolutely yes. We're inside, really the four big cloud providers now because we just announced support for OCI. So we're definitely AWS, Azure, GCP, and OCI. Now the the way everything works is obviously slightly different with each each each hyperscaler. But, you know, the gist is it the the story is basically, the same. So we enter our account information into, what we call Rubrik Security Cloud. Rubrik Security Cloud is gonna go out, and it's gonna deploy a CloudFormation stack into your account that creates essentially the pieces that we need in your customer in your account to to actually, you know, perform backups and recoveries. So those those pieces are number one, a cross count role. So we actually have a a Rubrik account that we're gonna have a customer specific user in. And, basically well, I might as well load that up. A Rubrik account that we have a customer specific I'm user in, that user assumes that cross account role in in your account, and that cross account role also obviously has a a number of different policies and and permissions attached to it that allow us to do backup and recovery. One interesting thing is you can we've you can leverage what we call true least privilege. So you can give us just permissions to do the backups. And then when you need to do a restore, you could actually elevate those permissions temporarily so we can go and do the restore if you're really security conscious and you don't want, you know, Rubrik having, different write permissions to some of your workloads. So, the whole idea around Rubrik is off giving you, options. I see another question about, is this for the whole world or just Pacific areas we support? I mean, there's a a lot of it's global. I'll just leave it at that. It's global. Some of the gov clouds, you know, it really depends on the type of cloud and what regions we're talking about. But, you know, certainly for The US, for Canada, for for EMEA, we support essentially almost all the regions that AWS, that Azure, that GCP has. Sorry. Another resource, that we deploy is an EKS cluster, and this is really what we use for Rubrik compute. So there's short lived pods, that we'll pull down to do things like perform file hashing, perform indexing of those snapshots so we can do things like file level recovery and whatnot. So this is an EKS cluster that gets deployed. You'll hear me refer to that as exo compute. It's kinda what we call that, Rubrik exo compute. That way we just simply say that so we can talk about exo compute in Azure, exo compute AWS, you know, things like that. And then that notification gets sent back to RSC, through SNS, and your account's onboarded. You're good to go. Rubrik will go ahead and discover essentially all of your your workloads within that AWS account. One super cool thing is, you know, the sensitive data classification, stuff like that, that's part of our enterprise edition, that we offer. But we do give you pieces with just the basic addition to let you know, hey. You have sensitive data in this s three bucket. You should probably protect it. We just won't tell you what exactly that data is. So we could really give you some sort of risk analysis of your environment just with our basic, our standard edition of Rubrik Security Cloud. From there, we gotta protect our workloads. With Rubrik, we use what's called an SLA domain. So the SLA domain essentially, it bundles up all of those data protection constructs that you're used to, things like how often do I wanna back up, how long do I wanna keep these around, whether or not I want to archive the data. Maybe after thirty days, you want to archive the data to some lower cost tier of storage, think like, Glacier or, you know, maybe like a infrequently accessed, you know, things like that. And maybe you wanna keep your most recent backups on a hot tier, so you can restore them quickly as well as replication. Maybe you wanna this happens on the other side of the chain. So instead of archiving older data, we replicate the newer data. Maybe you wanna take the most five recent backups and replicate them to another region. So if US East 1 happens to, go down, couldn't see that ever happening, you know, you have that data also sitting in maybe US West 2 or something like that, and that's your most current data. So all of this gets bundled up, sort of your desired state into an SLA domain, and you just apply that policy to the workloads that you wanna protect. So you can mix and match. You could apply the same SLA to EC2 as you do to RDS, you know, things like that if you want to. You can create as many of these or as as as small, amount of these as you want. One interesting thing is the hierarchy hierarchy at which you could apply these. They basically inherit. So if we think of the parent object here in terms of cloud, that might be your entire AWS account. Maybe you set up an SLA that takes one nightly backup, and you apply that your to your entire account. That means these child objects, these EC2 instances, they'll automatically inherit that. Right? And any newly created EC2 instance, again, automatically inherit that. And all of a sudden, you know, data protection's no longer an afterthought. I was a backup admin for for years before I joined Rubrik. And, you know, one of the things that always happened to me was I'd have an application owner call me, and they'd be like, you know what? I need you to restore, you know, this this application. I'd be like, well, I don't I don't have backups for that because they never told me about it. Right? So the inheritance is nice if you wanna have sort of a blanket level of protection, and then you can go and and assign SLA domains directly to, these workloads. Maybe if this one's mission critical, you know, you could assign one that takes a backup every six hours or something like that and sort of break that inheritance. And, of course, you can assign them not to in to inherit it at all, things like that. Another unique way is through tag rules. Right? So maybe you have hundreds of AWS accounts managed by, you know, different teams. Everything's kinda set up differently, but you have a common tagging strategy, you know, around the ball. And this is something we see quite often. You could set up what's called tag rules. So here we have, essentially, what a tag rule is in Rubrik is it looks for a certain AWS tag, like, key value pair. So maybe, a backup with a value of gold or a backup with a value of silver, backup exclude, and it maps them to specific SLA domains. So this is set up inside Rubrik. And then when you go ahead and tag your workloads within AWS, whether that's manually, whether that's with AWS CLI, whether that's through Terraform or your CICD pipelines, Rubrik will go ahead and automatically scan that environment every so often and assign those workloads to the SLA domains so they're, you know, protected accordingly. As those tags change, Rubrik constantly monitors, you know, moves them around, changes the SLAs, does things like that. So this is a very cool way to actually, number one, sort of automate data protection so we don't get that, you know, afterthought of, like, I don't know what that application is. You never told me. Another unique thing about these SLAs is there's no concept of jobs. So in a lot of legacy backup software, we have a job that's gonna back up. We have a job that's gonna run indexing. We have a job that's gonna archive, a job that replicates. And, basically, you know, if one of those jobs fails, they're all gonna fail. Right? The whole entire chain fails. So instead, Rubrik takes that policy based approach where everything's wrapped up into that SLA domain policy, and we just apply that to the workflow. So in terms of actual protection, how this stuff works, number one, you know, we're gonna authenticate as that customer specific user in the trusted Rubrik account. It's gonna go ahead and assume that cross account role that we deployed during the onboarding process in the customer account. And then we're just making those regional API calls adhering to those constructs in the SLA domain to create and expire and perform all the data life cycles of those snapshots. If replication is set up, we can obviously replicate those snapshots either cross region or even cross account. So this is, again, another a lot of customers that we have, and I'll hint I'll talk about this more, near the end. But we have a lot of customers dedicating account just for recovery. It's called what they call their minimum viable recovery environment. They ensure that, you know, their data is replicated, especially for the most mission critical applications, into that account. It's outside of their entire identity domain. If a user gets compromised in one account, they won't have access to this other account. And then Rubrik sits out of BAN, so it's able to to basically replicate that data, as needed. And then finally, if file indexing is enabled or you want to run, anomaly detection or you you have sensitive data classification, all that stuff turned on, we're gonna instantiate exocompute. It's gonna pull down the proper pod, crack open that snapshot, scan it, and do all that work, you know, right after the data has been ingested, right after that backup completes, generate a wealth of that metadata, and then ship that up to Rubrik Security Cloud. So it's just the metadata that's going up to to Security Cloud. It's not your actual backups. We do have options if you want Rubrik to fully host your backups. It's called Rubrik Cloud Vault. By by all means, you can you can you can take advantage of that, or you can set up your own backup storage in the cloud, whether that's in, you know, the same account or a completely different account. Restore wise, we'll walk through a few. There's a number of different restore options. This is essentially gonna be your traditional restore where we're actually gonna overwrite, you know, the production instance. So what happens is we make a call, to go ahead and create, EBS volumes from those snapshots that we have. If they're already replicated, we can make we obviously make the calls to copy the data cross region if we need to. If they're already in the same region, we don't have to do that, things like that. So we create that EBS volume from those snapshots, stop your production instance, detach the volumes that are on it currently. Obviously, attach it to the new instance and power it on and restore, restore, you know, all the metadata around that if there's any tags or anything like that that have that has changed. So that's your traditional, like, in place, I want to recover, my production instance. I don't want anything to really change, with that production instance. We also have export. So export's going to give you the ability to restore an e c two instance to a completely new e c two instance. Right? So maybe you wanna restore it to a different account. Maybe you wanna restore it to a different region. Maybe you just wanna make a copy of it or a clone of it for, you know, dev developers to use or things like that. So the way that works is, you know, we obviously when when we take the backup, we actually create an AMI of that, you know, all the metadata around that e c two instance as well as the root volume. So what we'll do is we will we will make a call to create a new instance from that from that AMI, then we'll actually restore all of your, EBS volumes that that belong to that instance. So that's including the root volume and any data volumes that you have. And then, obviously, again, we'll detach that default root volume that was that was deployed when that AMI was was recovered, attach it to your true root volume, that we restored as well as your data volumes, and, obviously, clean up after ourselves, and get rid of that root volume that doesn't need it so you're not paying for any more space than than you actually need to. So, again, this can happen in the same region, same account, different account. And then the options are really, really endless there. And then finally, file level recovery. Right? This is this is a pretty cool one. Why do we need to restore an entire e c two instance if we just need access to a few files? So number one, you're gonna search for those files on Rubrik Security Cloud. Since we have the metadata up there, we can we can find that data really quick for you. We could show you all the different versions of the same file. You select the point in time that you want. At Enroot, we're just gonna go ahead and create an EBS volume from that snapshot. We're gonna spin up exo compute, crack open that volume, find the exact version of that file that you're looking for with with Exo computer, with that that pod that's running on your EKS cluster, and then we're gonna restore that, into an s three bucket so you can go and grab that and do whatever you need to do, with that file for retrieval. And then, obviously, again, clean up after ourselves. So that's essentially restore, and that really covered off sort of everyday protection. Right? But we talked a lot at the start here about cyber recovery and what that meant and that just restoring, you know, isn't enough. So I wanna walk through a little bit about, you know, what we do on top of just the backup and recovery piece. So what we call, you know, all of these features, these cyber security features, they're really all powered through what we call the preemptive recovery engine. It really helps you do we can see four different things here. Just determine the scope of the attack. Super important because when an attack happens, we often have no idea, you know, what was actually affected. Sure. Any mission critical stuff we'll know about. Our end users are gonna let us know what's down, but, you know, how far did that spread? Did it move from on prem to cloud? Has it affected any of my SaaS data? You know, is there some tier three, tier four workloads that, you know, I don't even use that often? Have they been affected? Because we need to we need to basically recover, you know, everything that was impacted. So number one, it's gonna help you determine that scope of attack. It's gonna help you assess a sensitive data impact. So what types of data was hit? What types of data was maybe encrypted or exfiltrated or deleted, as well as find those threats, quarantine those threats in the backup so you're not just recovering them and going through this crazy process again. And that'll allow you to actually recover wherever you think that, wherever you want to. So the preemptive recovery engine really works, you know, from that time series history of data. So it starts with backup. It starts with those immutable backups. We ingest those, and then we start to hash and analyze some of that data. Right? So, in terms of what happens here, the first one is anomaly detection. So anomaly detection is actually in a machine learning model. It runs up in Rubrik Security Cloud, so you're not actually paying for, the compute for this. It runs on just the metadata that that is sent up to Rubrik Security Cloud, and it really looks for anomalies within your environment. So since we have that time series history of data, we could start to see how that data has changed, how many files have been added, modified, deleted. Right? And if that number gets up pretty high or out of the normal, we can bet that, you know, something weird is probably happening in your environment. So that's sort of stage one where we look at that file system behavior. The stage two, actually takes that a step further. So a lot of vendors will stop and say, hey. You've had 300,000 files have been added to this workload. That's an anomaly. Rubrik will continue along that path and actually look for signs of encryption. Right? So stage two actually uses a model that's been trained by simulated real world ransom attacks, to actually look at what's happening to the data itself, and that's really how we eliminate a lot of false positives. So to take a look at how this works quickly, phase one, we can see what we call these FMDs. These are basically file system metadata. That's that's the enriched metadata that we create. We take the current backup, compare it to the previous backup's metadata, and from there, we generate that diff. That diff gets uploaded to Rubrik where it goes through that machine learning model that looks for all those anomalies. So how many files have been added, deleted, modified, and we'll point that out to you. And you can actually browse in Rubrik to see, like, right down to the file level. Like, this file was added. You know, this this file was deleted, things like that. So we'll generate that anomaly list. There's some Gen AI Gen AI there that that goes through a little bit to to try and get rid of any false positives that we can there because, you know, you don't wanna get signal noise and alert noise. And and when you get too many of them, you start to ignore them. So we wanna make sure that we're actually only reporting on real threats at this point or real anomalies. Second stage kicks in where it actually looks for signs of encryption, looks for signs of entropy in that data, updates what we call our ransomware SS table, and then basically feeds that through the encryption detection machine learning model, which at the end, you know, detects if there's encryption in your environment and then can point again point that out exactly where that is across all of your workloads. So it's not just cloud. We're actually doing this for on prem. We're doing this for cloud. We're doing this for some SaaS data as well. So what you could see at the end is essentially, you know, what that blast radius was, where my anomalies were, what do I need to target for recovery. Before we actually recover, though, again, we wanna make sure that we're not recovering the malware or the ransomware itself. So that's where threat hunting, threat monitoring comes in. So you could see on the left here, we have a threat feed. You know, some of this comes from Rubrik Infosec. Some of this comes from Rubrik Zero Labs. But the major chunk of it comes from a threat intelligence feed that we get from Mandiant. So when you buy Rubrik, you actually get the the Mandiant threat intel Mandiant threat intelligence feed as well. And, again, this is over 5,000 known malware families, over 600 attacker tools that that are commonly used, and we're automatically scanning the backup data for that and giving you the ability to actually quarantine that so it can't be recovered. And quite often, you know, if it's, an attacker tool might get dropped before the, actually, before the attack takes place, we might see that in the backup data before the attacker has even unleashed the attack. So sometimes we can help to, mitigate and, you know, fix things before the actual attack takes place. If it's a zero day exploit or something like that, obviously, the threat intelligence feeds won't have that information. That's where what we call turbo threat hunting comes into play. Again, the preemptive recovery engine will create all these file hashes as the data is ingested. You can gather that file hash and quickly search across all your restore points. And I mean all of them. Right? It it's not enough to search just last night's or just the previous weeks. Quite often, attackers are in your environment for many, many weeks performing that discovery. And you could search, you know, back thirty days, a year's worth. And we could do this very quickly, just due to the fact that we have those precalculated hashes. So I think our latest, latest stats were something like 60,000 restore points in ninety seconds. So we're we're not waiting at all, for a lot of this to to complete. So, again, you can go ahead you can quarantine those so they can't be used for recovery if you want. This is useful beyond cyber threats. We think, you know, Log four j was a big one. Having to understand where Log four j was in our environment because it was everywhere. Right? We have Java everywhere. But we you could easily use Rubrik's turbo threat hunting to search within the backups for Log four j and point to you, you know, within production right down to the file level, where that existed. And then finally, sensitive data discovery. This is pretty straightforward. Right? We're gonna scan that data. We're gonna classify it. We're gonna tell you where PCI data is, where your HIPAA data is, where those secret keys might be hiding. We'll even go further and look at some cloud operations. Right? Maybe you have publicly accessible S3 buckets, things that you can information that you can use to mitigate the impact of an attack before it happens. Right? So where's my sensitive data? What types of data is it? Who has access to it? What they're trying to do with that access? You know, things like that. And then lastly, we get to recovery. Right? And we have some of those recovery options we showed you, but you can bundle all these up into what we call recovery plans as well if you wanna automate this entire process. You know, you can have specify the boot order. Maybe you wanna recover these three AWS EC2 instances, then this RDS database, then this workload, then run the script, then recover this workload, attach them all to different networks, things like that. All this could be set up ahead of time so you're not having to do it, you know, in a moment of of chaos, when when everybody's kinda got their, heads over your shoulders, wondering when things are gonna be back up. I did say I'd mentioned a little bit about the minimal viable recovery environment. This is really a best practice that we're seeing a lot of customers take as of late. And in the cloud, this would really involve having your production cloud account as well as what we call an MBRE, minimum viable recovery environment, another cloud account, completely separate identity domain, so you're not sharing users between the two because, again, identity is that new attack service. Right? We don't we don't wanna have, one user with access to, another account if that's just gonna let the attacker move laterally to it. Really, this is the main focus of an MBRE is focused mainly on your most mission critical stuff. What's making you money? What sets you apart competitively? Things like that. And let's get that data replicated into that identity domain, or that MVRE. Or you could actually store those backups on Rubrik Rubrik Cloud Vault, which is, again, gonna give you a separate spot, that's not accessible from your production environment so the attackers won't see it. And then when push comes to shove, you can restore that data from Rubrik Cloud Vault into that MVRE. So with that, here's kind of the workloads that we support on each cloud, as it as it stands today. Our engineering teams are going hard and heavy on sort of our cloud protection. Like I said, Oracle Cloud was just introduced this year, so so it's kinda last place at the moment. But you could see AWS is is in the lead with Azure as a close second, and, obviously, Google Cloud's been getting a a lot of attention as of late as it's growing in popularity. So now I can see, like, my wrap up time counting down. But, so now it's time kind of for you guys to, sort of take the wheel here and, and dive in. And, I just wanna go quickly go through kind of the gist of the lab because it is, again, a little bit different. If you've if you've attended one of these workshops before, you're gonna you're gonna notice things difference. But first things first, congratulations. Everybody's now an employee of our fictitious company, Zaffre Fashion Group. So, basically, you know, you've been you've been brought on to help Zafra sort of provide cyber resilience in their AWS environment. So Zafra's, you know, previously went through an attack. You know? I I think it was, like, six months ago, something like that. They had AWS backup, and they really saw some gaps, in how that can support them moving forward. So you've been hired to specifically walk through deploying Rubrik, onboarding Rubrik into Zafra's AWS environment, protecting their flagship app, which is an online storefront, which has been built with e c two, EKS, RDS, DynamoDB. S3 is also involved there as well as parameter store. So, they have a number of services to power this this online storefront. And what you'll walk through in the lab is a number of recoveries. So day to day type stuff, maybe a rogue script goes out, deletes some files. Developers want duplicate copies to to do dev tests. So kind of the standard stuff you'd be doing day to day with Rubrik, as well as walk through a full fledged cyber attack. So we'll see how you can run anomaly detection, how you can perform threat hunts, as well as cyber recovery in general. So before I unleash you to the lab, though, I do wanna walk through a couple of things. So this is the application you're protecting. It's an actual real application. Just so you know, we're not, we're not just budget things here. I mean, it's pretty basic application, but this is this is what we're gonna be, backing up and recovering today. To kind of explain the architecture, we have our front end runs on e c two. That runs NGINX, has an API there to connect to Postgres. Postgres provides things like all those product details. Right? So this is a scarf. It's $10, things like that. We also have a dynamo d DynamoDB database, which hosts all the customer reviews, and whatnot. And all the images, branding, assets, stuff like that lives on s three. We also have an EKS cluster here that we're we're gonna need to protect and recover. And what it does is run some sort of recommendation engine. So, you know, when you click on a scarf, we might recommend, I don't know, a toque. I guess I'll I'll show my Canadian there or a beanie. We might recommend a beanie as well. And, again, everything's controlled by parameter store. So, you know, if you restore, you know, an RDS database to a different region, it obviously gets a different endpoint so we can quickly update the parameter store to, to suffice. And when we throw Rubrik into the mix, this is kinda what it's gonna look like. Again, we have that customer Rubrik account, customer specific user, for e c two, for RDS, for DynamoDB, and for s three, we use sort of cloud native. We're gonna assume that cross account role, use exo compute, to gain access to all of this stuff. So that's how it works for those. EKS takes a bit of a different approach. We use what's called cloud cluster, and that's basically Rubrik software that runs, within an e c two instance in your environment. It's not required to back up e c two to protect our, RDS, all that stuff. It's only required, at the moment for EKS protection. And then, of course, you'll have access to Rubrik Security Cloud. And then, you know, Zaffre has a number of other, applications they use, like m three six five, Salesforce, some on prem hypervisor, Azure, GCP stuff. We'll have other Rubrik workshops, that you could sign up for if you're interested in some of these other workloads. The lab itself is just kinda what it's gonna look like. I do recommend, you know, maybe, like, having your volume on because there are videos, you know, where we we quickly walk through sort of what's going on. I go into a bit more detail as to what I just said. You could just follow the prompts with your next things like that. If you want to, jump around, like, maybe you're not interested in assigning SLA domains, feel free to. I recommend going through it, you know, in parallel. But you can jump around with the product tour here. A couple times, you'll see you'll have some options. Right? So maybe for onboarding, you wanna use the UI or maybe you wanna see how it's done with Terraform. You know, you have some options. You can do one. You can do both, things like that. So the way it works is you just kinda walk through, read, click where where it asks you to click. You could also use the arrow keys on your keyboard if that's gonna be easier for you. So it's really, really up to you at that point. So that's the lab. I believe the link is in the dots there. And I also believe Chase, I'm not sure how long we're sticking around. But if there's any questions, I can definitely stick around for, you know, the next five minutes or so. But other than that, you know, please feel free to drop us any feedback that you have at all, for sure, what you think of the lab, things like that. So that's really all I have for you. So, again, thanks everyone for coming. Everybody sees the, link in the docs there. How long is the lab good for on time? I the lab will not. I don't think it'll go away, to be honest. So it's good forever. Yeah. We've got the link there in the docs tab. I think I dropped it there in the chat too. So if anyone has any trouble, just drop us a note here in the q and a. And like Mike said, we'll stick around stick around for a few more minutes, answer any questions, make sure everyone's all set in the lab. Thanks for spending time with us. Appreciate it. Yeah. Definitely. Thank you very much.