Hi, everyone, and welcome to the Cloud Resilience Summit. Cloud resilience keeps your AI running. AI transformation is the biggest build-out in enterprise history, and it's running on the cloud. The world now spends over $140 billion on cloud infrastructure per quarter, and the fastest-growing part is AI. Every AI strategy is also a cloud strategy, and that means every cloud strategy is now a resilience strategy. But the risk is moving just as fast as the opportunity. AI is already causing real disruption inside organizations, and it's changing what attackers can do. Attackers are exploiting flaws before a fix even exists, and a patch isn't the end of the story because patched isn't clean. Yet when we look at where most organizations stand, confidence is running ahead of evidence. Most haven't yet proven that they can recover under real cybersecurity conditions.
The question for every cloud, security, and platform leader is this: When AI runs the business, what keeps it running when something goes wrong? Over the next few minutes, we'll cover what's changing, what's at stake, and the new rules for operating in this AI era. Then today's sessions take us deep into the three layers that power AI: the data that feeds it, the code that builds it, and the applications that deliver it. To explore this with me, I'm excited to welcome Marc Trimuschat, who leads go-to-market for analytics and storage at AWS. Marc, so great to have you with us today. Thank you for joining me.
Yeah, excited to be with you.
I wanted to start by talking about S3. I think a lot of organizations have a misconception that S3 is just a dump of people's personal photos or random files, and it's not actually the most critical data that powers applications today. But I know that's changing, so can you share a little bit about what you're seeing in the industry and where customers are really keeping their most important data today?
Yeah, it is super interesting, and on S3, the scale really surprises people. We have over 1 million customers active on AWS every month, and millions of them use S3. We launched S3 and AWS in early 2006, and S3 started with about a petabyte of capacity, which at the time was a lot. We had a petabyte, wow. Maybe that is when you had a couple terabytes or a couple gigabytes. Right now, today, and this fact is a little bit old, right now, we are holding over 500 trillion objects across hundreds of exabytes on S3 to kind of share the scale that we have and that we are running at. We have some of the largest customers on the planet are using and storing their data and their mission-critical data on S3. For example, Indeed runs a 100-petabyte-plus data lake with 18,000 datasets and over 190,000 queries per day.
BMW Group keeps over 20 PB in its cloud data hub and ingests over 100 TB daily. Financial services company BMLL holds 20 PB of trading history and projects 50 PB by 2030.
It sounds like what you are seeing is that S3 is now being used for far more than storage. Can you talk about what has changed and why has that changed?
Yeah. I have been fortunate enough to be with AWS for over a decade, and what I have seen is the evolution as we talk to customers about S3 as a storage platform accessible anywhere on the planet to now more of an analytics and data platform. Analytics, machine learning, and our AI are among our primary use cases today, and customers mostly use S3 as a tabular store. That is a big switch. We have exabytes of Parquet format files sitting in S3, and thousands of customers have moved to Iceberg, which is an open format for transactions, schema evolution, and time travel. When we stop treating S3 as just a place to store files, we want customers to store their data once, work with it directly, and with that, we built something called S3 Tables.
Customers also wanted to do things like semantic search, and had solutions out there, but they were expensive, and we introduced S3 Vectors for very large vector stores for things like semantic search, and for AI use cases like RAG. We also introduced solutions like S3 Metadata to that object store, really providing it now as more of a data platform. With S3 Vectors, diving into that for a second, customers have created over 250,000 vector indices, and they have ingested over 50 billion-plus vectors in just the last six months alone. Customers like BMW, employees take those vectors with Bedrock and AgentCore, and they query that petabyte workloads of data in plain language to arrive at good results for their customers and their internal use cases.
S3 also hosts tens of thousands of other data lakes with customers, including Cisco, Bristol Myers Squibb, GE, and Siemens. Again, customers are really using S3 as the foundation for their data.
What I hear when I talk to customers today is that a lot of the S3 data is actually unprotected by either versioning, replication, snapshots, or a backup solution like Rubrik. When do you think we hit a tipping point where customers stop treating protection of this data as optional?
Well, I think that shift is already happened and is happening today. We see customers like Indeed, for example, who moved fully into AWS after an ice storm, and that ice storm threatened its Austin data center, and its engineering manager said that a month-long grid failure would have ended the business, stopped the business entirely. IDC says enterprises create about 6.9 PB/s , and they expect it, again, with agentic workloads, to lift that to 17.1 PB/s in 2029. All of this data, and Indeed is a good example, but there are thousands and thousands of companies who are banking their business on running it on S3 and AWS, so it has to be protected.
AWS and S3, we will talk about in a bit, obviously offers 11 nines of durability, high levels of availability, but it does not protect against accidental or malicious deletion of data. That is where the combination of things come in, and that is critical for customers who are really relying on S3 and AWS as the foundation of their business.
Yeah, we are seeing those very same trends ourselves as we are talking to organizations, is that they are now really thinking about protection of this data as something that is critical. These are tier zero, tier one applications, and yeah, and they need to think about how they can maintain resilience of this data beyond just the durability that AWS provides. You have been a big advocate for open data. Can you talk to me a little bit about why does the open data formats matter?
Okay. Well, it is not just me. When we say I have been an open data advocate, it is AWS and our customers. As with everything, our customers led us there, right? Open formats are something that our customers have asked about, and they allow multiple engines, both first-party solutions like our solutions, partner solutions, or open source solutions, and they let several engines read one table without a copy per tool. That is one of the big things that has emerged is something called Iceberg, which is one of the most popular open formats. We heard our customers, worked backward from our customers, and said, "Really, we are going to invest in open data formats, in particular in Iceberg." As an example, single row update in Hive ORC, which is not an open format, forced Indeed into a full partition rewrite.
When they moved it to Iceberg, it gave it schema evolution, row-level updates, and multi-engine access. Self-managed Iceberg, which is really what customers were doing before we introduced S3 Tables, cost 1,000+ developer hours per year for Indeed that they invested in managing their own Iceberg infrastructure. What they did is moved it to S3 Tables, and now the maintenance has been reduced dramatically. Another customer of ours, Zeta Global, they run over 10,000 Iceberg tables for over 245 million US consumer profiles, and they process 2 TB per day on S3 Tables. These, again, with the combination of Iceberg and open table formats, which allows any engine and also future-proofs it for future engines and things, as you know, are rapidly evolving. You do not know what is going to hit tomorrow in terms of an engine or a new agent technology.
That's what open standards are about and open table formats like Iceberg. We now introduced the concept and the ability to have customers, instead of having self-managed, have us manage it for them in the form of S3 Tables, reducing their cost, reducing their engineering efforts, and allowing them to focus on their business.
You've talked a lot about how important Iceberg is for organizations, how they're using this as the foundation of their customer-facing revenue-generating applications. We have launched protection for Apache Iceberg. Can you talk about how protecting tables differ from protecting files?
Sure. Without getting into the weeds on it, certainly, we have the data itself, but then what Iceberg is essentially a metadata layer on top of that data. Because a snapshot's only a metadata pointer, if you delete the table, then the pointer goes with it. What happens is then you really don't understand the context anymore. What Rubrik does is it backs up the data and the table metadata, and then re-registers the table in the catalog so all the query engines can query it right after the recovery. Really excited about that partnership. What happens is if there's malicious or accidental deletion, it even gets worse when you're deleting the data under the metadata accidentally or maliciously, or the metadata, and then all of a sudden you lose reference to the data underneath.
That's where it's important to have a data protection scheme that manages both.
At Rubrik, one of the things that we're thinking about is how we evolve and what our customers need in the era of AI and agents. A big hypothesis that we have and that we're really seeing play out in the market is that with the rise of AI agents doing more work inside of organizations, and with the rise of threat actors using AI to breach organizations faster or to find vulnerabilities that are now easier than ever to find, both in open source and within proprietary code, organizations now need to think about two problems to solve. The first is assume breach. Assume that someone is going to be able to breach into your four walls. How are you going to respond and recover quickly so that your business can get back up and running?
The second one is assume agent overreach and assume that agents are going to do things that you didn't expect them to do, even the legitimate ones within your organization. We're solving this through Rubrik Security Cloud and something called Rubrik Agent Cloud. Rubrik Security Cloud is all about cyber resilience and cyber recovery, and Rubrik Agent Cloud is about minimizing the blast radius of agents within your organization potentially doing wrong things. Can you talk a little bit about why it's so important for Rubrik and AWS to be partnering around these opportunities, especially when we talk about large unstructured data?
Yeah. That's a good question, and I really think about this as a partnership and a joint responsibility model for customers, right? Again, and I think you hit it. We talk to customers all the time about when we talked about kind of traditional methods of bad actors. Now, with agentic, it's on steroids, right? How do you protect multiple layers? How do you make sure that the agents can access the data that they need to, but also provide the governance and the controls, to ensure that they don't access the data that they shouldn't, right? The way we think about it is we own the foundation. Meaning AWS owns the foundation. S3, as we talked about before, was designed for 11 nines of durability. It operated to be lossless.
That means that your data is protected, again, from any kind of failures, data center access, fiber cuts, et cetera, and everything, and make sure that data is not only is available, but also durable and not lost. On top of it, we do things like S3 Tables replication, where we keep read-only Iceberg replicas in other regions, and full snapshot history, usually within minutes of the source. That covers availability and locality. The customers, and this is the shared responsibility model, own the data inside. That's where we need solutions again, where they can protect the data at the customer data level. Customers, I think one of the things that we really care about at AWS is customers own the data, and customers trust that their data is their data.
What that also means that there is a responsibility to protect that data in the customer environment. If replication, copies change, or a bad delete, or an agent's wrong write, or a permutation changes that data, then that is going to basically follow the good data to the replica. Just because we have the foundations in place does not mean that it still prevents those malicious or accidental changes, right? That is where I think Rubrik fits in really well with the Rubrik solutions.
Yeah, absolutely. What we are seeing in the cyber landscape today is that a lot of attacks in the cloud start with compromise of identity, and the identity systems. Then attackers are moving laterally within the identity systems, looking for the crown jewels of data, finding data in cloud repositories, landing malware, or wipers, actually deleting, encrypting, exfiltrating the data. One of the things that Rubrik has been really focused on is, how do we help you with cyber recovery of your identity system and your cloud workloads so that you can extract and remove the malware and other indicators of compromise from your data and be able to recover back to a clean copy quickly?
That is where I think our partnership is amazing, because you are providing all of these capabilities to ensure that there is availability of the actual data itself, and we are working with customers to make sure that they always have a clean copy to be able to recover to quickly. I think that is really the power of what we are doing together.
Yeah, I agree, I think it is a dynamically changing time right now, right? We hear, first of all, obviously with the foundations that we have on S3 and increasingly agentic workloads, again, we do see lots of threat vectors, and the thing that you can rely on with AWS is that foundation of trust. We try to build everything in from the ground up, all the way from our Nitro hardware-based, making sure that nobody can access it is hardware-enforced security and encryption, all the way up, and all the way through our security layers.
But again, it's a joint ownership model with our customers, and I think what you pointed out is if at the authentication layers that the customers deploy on their applications, if that's an insertion point, then this combination is a really good combination to be able to identify, protect, and then restore the data back to a known state so that customers can keep on operating their businesses.
Well, Marc, thank you so much for joining me and sharing your insights. I think what the audience can take away from this conversation is that S3 and unstructured data in the cloud is absolutely critical. It's the foundation for customer-facing, revenue-generating applications, agentic applications, and the partnership of AWS and Rubrik together is helping people secure this absolutely critical data.
Great. Really appreciate it. Hopefully, you took away that we're seeing customers use AWS and S3 as the foundation in an open format for their data strategies, and data is really what makes the AI go. Without data, there is no AI. And these critical data sets, which are offered in open formats like Iceberg, really are the things that are powering AI, and it's super important that we have obviously protection at our layer, and then in partnership with you, allowing customers to protect their data to make sure that it's available to run their business continuously.
Next up, you're going to get to hear from a customer how they think about cloud resilience in the age of AI.
Thanks, Anneka. Cyber threats were already a top concern for IT and security leaders. AI is making them faster, more convincing, and harder to contain. What happens when something goes wrong? How do you build resilience in early on, not after the fact? Let's find out. Joining me today is Adam Page, CISO for Europe and the Middle East at Zurich Insurance Group. Adam, welcome.
Thank you. It's good to be with you.
Adam, let's start with the big picture. Zurich is embedding agentic AI into core workflows. What does resilience in the age of AI mean to you, and where does your role as CISO fit into that?
Resilience is not the ability to prevent every negative outcome. It's about how we adapt to disruption, how we respond with speed, which is a big difference, and then how we recover with confidence as these threats continue to evolve. In the CISO role then, oversimplifying it a bit, we need to identify, reduce, and communicate the risks that relate to the assurance of those capabilities.
Adam, from where you sit, how has AI changed the threats that you are worried about? What looks different from even a year ago?
The things that stand out the most immediately are just the sheer volume of vulnerabilities, the ability to identify those, and then the significant reduction in time to exploit those vulnerabilities. There is a lot more as well, right? Lowering the talent barrier for attackers, so there is more of them. This is lower cost for attackers, and it is higher cost for businesses. We have seen the maturity of deepfakes over the last several months in social engineering. I will mention again speed, as we have all been busy with patching critical vulnerabilities these last few weeks, and I certainly expect more of that.
Does that change how you think about whether an incident is a matter of if or when?
It is certainly a matter of when, and we all need to be prepared for that. We need to get good at making the impacts of these occurrences as small as possible and as brief as possible.
Thanks, Adam. As you embed agentic AI into core workflows running across a multi-cloud environment, what did that add to the list of things that you have to protect and recover? The AI models, the data feeding them, the agents themselves, and the cloud infrastructure and configurations they run on.
There's a long list, right? Such as the complexity of the ecosystem of the applications. That's something that has taken us a good deal of time, is just understanding what are our core systems, what are the dependencies of those systems, how do they operate, and even from one application to another, but also through the connectivity of gateways. We need to be thinking about backing up and recovering network configurations, permissions, both human and non-human, the LLMs and the connectivity. We also need to architect a place to do the restore, where we can test our work and we can prove out our capabilities before we can recover into production.
Zurich doesn't see AI as a standalone initiative, but as a capability embedded in business processes. How does that thinking carry over to resilience, especially in the cloud? What does built-in, not bolted on, look like in practice when you're migrating applications and standing up AI workloads across multiple clouds?
Yeah. This is another place where there's just a lot to be done, and you're never finished, right? There's different levels of resilience, like redundancy and failover. But from the beginning, you need architectural discipline, and that's while you're developing something that you want to deploy and build. We also need to be looking at it after the deployment, and did we build it in the manner that we intended to? Another piece here that's really important is being clear on responsibilities from the beginning. There's so many teams that are involved of builders. There's infrastructure, there's applications, and beyond. So, it's making sure that everybody is clear what they're accountable for in the realm of resilience.
That makes a lot of sense. I am curious just to dive a little bit deeper there. Most organizations still treat security and resilience as separate teams, budgets, and conversations. I am curious about how you think about them working together at scale and what has changed when you shifted from prevention alone to recovery.
Yeah. It is a good question, and it has been good to watch the partnership with the resilience teams. Initially, it started as conversations and planning around tabletop exercise, and they were another partner in the development of that, or another partner or facilitator or participant at the table of those exercises as well. We have been working closer and closer over the years. In fact, in my prior role within North America, the last few years or the last year or so, I was responsible for business resilience. So, they brought that responsibility into my team to work closer together. Some of the things that we were working on collectively are operational resilience. It is how do we think about this as an organization? What are the systems that matter most? Then a little bit back to that ecosystem that I talked about.
It is not just recovering one thing and you are back up, right? It is like the data has certain different ages within different backups across your enterprise, and how do those things recover or be resilient together? It is also, you are never done testing, right? You have got unit testing of an individual thing. You have got integrated testing of a collection of things. It is choose your own adventure a little bit, right? It is like, do you want to fold in SaaS applications? Do you want to go multi-cloud? So, never done testing, great partnership, and it is definitely something I recommend for organizations.
Yeah. That is a really important point, the importance of testing. Speaking of scale, Adam, you moved 160 applications to multi-cloud in 18 months and strengthened resilience at the same time. What did you learn about recovery when the environment is that complex?
I knew that we needed, in that migration to multi-cloud, one platform that was going to provide better security of our backups and the ability to orchestrate our recovery. We couldn't take this opportunity to be less secure, to be more fragmented. We couldn't have a singular solution across on-prem and then each cloud environment. That was huge for us, and having that one solution for visibility, for orchestration, and recovery.
Many watching are mapping out their own approach right now. What's the one piece of advice you'd give them and the one mistake you'd tell them to avoid?
On a piece of advice, I would be crystal clear on who is responsible for what. I'm not sure if everybody struggles with this, but there's always an opportunity in a large global organization with all these participants of who is accountable and who is responsible. That is number one, and you're working across security, infrastructure, application teams, and beyond. Certainly, you have to start there. One thing to avoid, we've been working on this for many years, and I think my takeaway probably is that don't wait until it's all sorted out on paper. Get started.
It's never going to all be answered. It's never going to be perfect. You're going to have more questions. There's going to be complexity, but you need to get started. Start with the big blocks and mature.
Adam, thank you. AI in the cloud runs on three layers: the data that trains it, the code that builds it, and the applications that deliver it. Over the next three sessions, our Rubrik experts will be joined by Google Cloud, Microsoft, and AWS to show how to make each of those layers recoverable across your cloud environments, starting with the data feeding your AI.
Hi, everyone. I'm Adam Rusho, Director of Cloud Specialists here at Rubrik. Most of my days are spent with customers talking about protecting their clouds, the VMs, the databases, the workloads they've moved, and lately, every one of those conversations turns into a conversation about AI. Teams are thinking hard about AI governance and the security, the model, the agent framework, the use cases, runtime security. However, what I almost never hear about is the layer underneath all of it, the data. That layer is what we mean by AI data foundations, the data lakes, lakehouses, and warehouses where enterprise data lands, gets prepared, and gets put to work. It's the data your models are trained on and the data your agents and dashboards read from every day. 10 years ago, the layer powered a monthly report.
IT owned it, object storage was a cost play, and backup was someone else's problem. Today, AI and ML pipelines run directly on it. Chief data officers set the direction, and leadership is asking what happens when it goes down. The data lake market alone is about $18 billion today, on its way to $52 billion by 2030. The investment has accelerated. The resilience strategy, though, hasn't kept pace. Here's why. This layer was built by data engineers for performance and scale, not by backup teams for resilience and recovery. So what protects it today? You have time travel and snapshots. Those are great for a mistake or a fat finger delete, but they're pointers living in the same account under the same credentials as the data they protect. Replication, where a bad delete replicates along with everything else, and scripts nobody wants to debug mid-incident.
Even when the raw data survives, rebuilding isn't recovering. Data is only useful with the structure around it, the schemas, the metadata, the views, the catalog that tells an engine what it's looking at. Lose that, and someone rebuilds it by hand while dashboards go dark. Enterprises put that downtime at more than $300,000 an hour. One customer we talked to described losing their lakehouse as a business-ending event. That exposure is growing. AI agents now read directly from the data, and some can change it. Attackers have followed the data into the cloud. CrowdStrike saw cloud-conscious attacks jump 171% just this past year, much of it through compromised cloud credentials. One compromised account can reach both the data and the snapshots meant to protect it. That's why, this past quarter, we launched Rubrik Cloud Protection for the AI data foundations.
It covers Apache Iceberg, the open table format the industry has standardized on, with support today for Iceberg on AWS Glue Catalog and Amazon S3 Tables. It covers Google BigQuery. Different architectures, same principles. An immutable copy outside of the blast radius, data and structure protected together, so it comes back ready to query, and one policy engine across your cloud estate. A recoverable data foundation so the AI on top is AI you can rely on. To go deeper on BigQuery, I am really glad to be joined by the Product Manager for BigQuery at Google Cloud, Nick Orlove. Nick, welcome.
Hi.
You spend your days with data engineering teams. For the platform and resilience folks here, what is BigQuery in a customer's environment today?
Yeah. Thanks, Adam. It is great to be here. The way that we describe it, BigQuery is often a complete end-to-end data to AI platform. It automates the data lifecycle from ingestion all the way through delivering AI-driven insights. Many customers first came to BigQuery as their data warehouse for BI, for reporting, for data analysis, and that is still all there. What has changed is what runs on top of that data. Teams build and run their AI models right where the data lives, with BigQuery ML and all the AI functions that are built natively within SQL. With the Agentic Data Cloud that we announced at Next earlier this year, agents are first-class users. For instance, our own data engineering and data science agents, as well as the agents that our customers are building themselves. It is not just where reports live anywhere or dashboards live anywhere.
It is where the analysis, the models, the agents, all are working off of the same governed data, and it is increasingly multimodal. Structured tables alongside unstructured data sitting in cloud storage, all available from one single platform.
That is the then versus now I opened with, out of reporting and really into that decision loop overall. When you sit down with data teams, what is at the top of their list, and what should the cloud platform and resilience leaders in the audience today understand about their partners on the data side?
Yeah. Data teams are measured on trust and freshness and speed. Is the data correct? Is it current? How fast can they get the data into production, whether it is AI or not? What usually is not on that list is, what if the dataset gets deleted, or what if it is taken out by something like a ransomware attacker? Not because customers do not care about it, but because it is easy to mistake things like durability for recoverability. Features like BigQuery Time Travel keeps the data available when someone makes a mistake for a period of time, generally seven days. That is not the same as actually recovering data from a malicious incident or any kind of big goof on a customer's perspective. At Google, we think of this as a shared fate model. It builds on shared responsibility.
Google builds and operates a trusted platform, and customers retain and remain responsible for their data and accessibility of who can actually access that data. It is not that we draw a line or walk away from it. It is an ongoing partnership with customers and with partners like Rubrik to make sure that the data is resilient. With agents now creating tables and running jobs on their own, the footprint is growing faster and less predictably than ever.
Yeah, and I think that point about growth is a big one. When data teams are first standing up these platforms, what are the things that they are not thinking about but they should be?
Yeah, so most teams are generally building for the next three to six months. But recoverability, if it's planned at all, is often a script or sometimes an assumption that you can rebuild from the data source. That works for specialized tables, usually a few dozen or something like that. But at the scale of thousands of tables or petabyte of data, dependencies that sometimes people haven't really mapped out end-to-end, at that scale, scripts and manual rebuilds stop being a recovery plan, more of a hope, and therefore designing recoverability, designing for disaster recovery at the start and not after the first incident.
I think that's the gap. The platform team assumes the data team has it, and the data team assumes durability has it covered, and nobody really owns the recovery until they have a bad day, especially not at a lot of the scales that these teams are heading towards overall. So my ask for the resilience leaders out there, find your data engineering counterpart and ask these three questions. What's our recovery plan beyond those seven days? Does it survive a compromised admin? Have we planned for what recovery looks like as that platform scales? Do we even have an actual RTO target? For the data engineers, this is your SLA too. When the dataset goes, the pipelines, models, and dashboards go with it, so it's really important to have this understanding about your data and how it's protected.
All right, Nick, let me put you on the spot as a PM. If you're writing the requirements for protecting BigQuery, what's on the list?
Good question. First, consider the architecture, which being protected, the whole thing end-to-end. A dataset isn't just rows and columns and tables. It's much more metadata associated with it as well. So schemas, partitionings, cluster configurations, views, routines, even access policies. So, if all of those things don't come back, you haven't fully recovered. You've started a rebuild that's in progress, but you haven't really returned to full production. Second, retention for compliance. Time Travel and BigQuery Fail-safe Recovery covers you for the last 14 days or so, but oftentimes audit requirements and regulatory requirements go beyond that into months, sometimes even years. Then third, make sure that you have a copy of your data outside of the blast radius.
So, separate from the credentials that you are running in production and separate from the specific region that you are already using, just to make sure that if something were to happen, you should be covered as well. Fourth, bring more value to what is being backed up. Beyond just backing up bytes that are never accessed unless you have an emergency or an audit, drive more usefulness from those bytes themselves too.
Nice. Well, that is great news, Nick, because that is something that is very, very remarkably close to what Rubrik launched with our BigQuery data protection in October. First and foremost, we protect the whole thing, the dataset level, tables, views, routines, and row-level security policies, and we recover that full dataset or even just a single table all ready to query. We have those long-term retention for those compliance use cases as well that the auditors need, and we archive that to lower-cost cloud storage tiers to save on cost. Then we are making sure that all of the backups are outside of that blast radius, that they are immutable and indelible by default, and away from the production environment. So even if there is a compromised admin, your backups are safe. We are also never competing with production. The backups run in their own slot reservations.
They are incremental, so they are only capturing what is changed, and it is a completely agentless solution, so we are relying on BigQuery's native APIs. I would add one more from our side. We also have a choice of recovery. So you can restore in place for speed, or you can export and restore to another project or another table or even another region, especially in situations where maybe that original dataset can no longer be trusted. All of this too, it is protected automatically, so we add a lot of automation into this protection under a single SLA policy that is mapped to the rest of whatever may be protected in that Google Cloud estate.
Yeah. What I like about that is how well it fits into the story of where BigQuery is going to. So, we keep making BigQuery more capable, more AI-built and integrated, more agent-capable, just with the number of agents that are running processes and running jobs against BigQuery and all the performance requirements and scale requirements that are built into that. But with the additional layer of resilience and a proven tested recovery plan, customers can feel more confident about leaning into their data platform and adopting more of these capabilities for building their mission-critical AI on top of BigQuery.
That's exactly the outcome we want. Nick, you mentioned tables alongside data in cloud storage. BigQuery is one-half of the foundation. For a lot of customers we talk to, the data itself lives in cloud storage. Object storage is cheap, scales without limits, and holds any kind of data, from raw files to training data, images, documents, et cetera. BigQuery is a data platform that makes it usable. Protect only one, and you've protected half your foundation. Today, I'm excited to announce Rubrik's protection for Google Cloud Storage, immutable backups of your buckets, protection designed by project, bucket, or label, archiving to lower-cost tiers, and recovery of a full bucket, a folder, or a single file in place or to a net new bucket. Same platform, same SLA policies as BigQuery, the data platform and the storage underneath, protected together in one place.
Full-stack resilience for your AI data foundations. Nick, thank you so much for joining us, and thanks to the whole Google Cloud team for the partnership. We built this together step-by-step, from Compute Engine to Cloud SQL, and now BigQuery and Cloud Storage, and it keeps expanding at a great pace.
Yeah. Thanks for having me today, Adam. The progress really has been remarkable. I'm excited to talk about our expanding relationship and the partnership and how we've been strengthening resilience for our joint customers. Rubrik and Google Cloud have built a very long-lasting and strategic relationship, with Rubrik deeply integrated across Google Cloud services and available to our customers through the Google Cloud Marketplace. This helps customers protect, govern, and recover their data across core infrastructure and emerging AI workloads, while also burning down their Google Cloud commitment contract too.
Thanks again, Nick. It was really great to talk about this today, but let's see it live and in action. Mike Preston, our Technical Marketing Architect, is going to show what happens when this foundation goes down and how it comes back. Mike, over to you.
Hi, everyone. I am Mike Preston, a Technical Marketing Architect here at Rubrik. As Adam just walked through, the data lakehouse is imperative to powering your business and AI initiatives, and protecting it means protecting BigQuery and the resources that feed it. Let me show you what happens when that foundation goes down and how Rubrik can get you back up and running with data that is ready to use the moment it is recovered. Here, we have an online storefront for our fictional company, Zaffre Fashion Group, running entirely on Google Cloud. The app itself runs on a Compute Engine instance, the customer, product, and order data lives inside Cloud SQL, and our product and brand images are served up from a cloud storage bucket. This 'Styled for You' functionality is provided through an AI model running against a BigQuery dataset that holds shopper behavioral data.
Now, I am going to flip over to Claude here, because we also have an agent that runs against that same BigQuery dataset. Let us go ahead and give it a prompt. Let us say something like, "Given everyone who has bought our royal gown in New York, what else should we recommend to them?" We will speed up the response here through video, but we can see that we have our answer. Of course, we also have Rubrik protecting this entire stack. Here, we can see our BigQuery dataset within Rubrik Security Cloud, and we have already assigned an SLA Domain to it, so we have a number of snapshots and backups available. SLA policies basically dictate how often we take backups, how long we keep them, and of course, where we would like to store them.
Now, we can assign these to our entire Google Cloud project, directly to an individual dataset, or we can have them auto-assign based on labels that are discovered within the projects. This is the same policy engine that protects all of your other workloads in GCP, things like the VMs and the databases. One platform, one model, all of it is protected. Now, let us simulate a bad day by executing this script here. This is going to go out and do some damage. Today it is a rogue script, but tomorrow it could be ransomware, malware, a rogue admin, a compromised identity. Either way, our BigQuery dataset and its subsequent tables are now gone. So if we move back to the storefront, we can certainly see some issues. The app itself is still up, but our recommendation engine is dark. We have no styling picks, no product images.
We will flip back to our agent, and we will run that same query, and it is also failing as well. So without our AI-powered recommendation engine running, Zaffre is at risk here of some major revenue loss. So let us head back to Rubrik and mitigate that. I am going to go ahead and select a restore point from before the incident took place, and we can see we have some options. We can perform an export. This lets us create an entirely new dataset, either in the same project or an alternate one. This is a great option if the production project is damaged beyond repair. Today, though, let us restore in place right back to the original dataset. I am going to go ahead and select all of the tables and kick off the process. Now, behind the scenes, Rubrik is restoring that entire dataset, including the tables, schemas, routines, views, and rewiring that catalog.
Our data is going to be immediately queryable once that restore completes. There's no lengthy post-recovery manual work that we need to do. Through the magic of video here, our restore has now completed, but let's head back to our storefront and actually prove it. I'll give this page a refresh, and there we go. All of our services are now reporting as functional, and we have our recommendation agent back up and running. If we flip back to our Claude agent, run that same query, we can see that we are getting answers once again. Zaffre is back in business, ready to serve their customers. BigQuery is the backbone of your analytics and your AI. When it goes down, the AI decisions built on it go right along with it.
With Rubrik, we brought back the entire dataset, ready to query on the same platform that protects the rest of your Google Cloud estate. That's Rubrik's BigQuery protection. That said, we also need to think about what feeds this dataset, the pipelines that move all of the data and deploy all the resources. As Adam mentioned, BigQuery doesn't stand alone. It's usually fed by multiple data sources and managed by multiple pipelines. We need to ensure that we protect that entire chain. Stay tuned, because in our next session, Courtenay's going to walk us through some exciting new features in Rubrik's GitHub and Azure DevOps solutions that you won't want to miss.
Here's a question I ask engineering leaders all the time. If your GitHub or your Azure DevOps environment disappeared tonight, what would you restore from? Most teams have a tested plan for their VMs or their databases or their SaaS apps, but far fewer have one for their platform where their code, pipelines, and infrastructure are built. I wanted to welcome you to our session, "AI Speed Up Your Code and Your Attackers: Rethink Recovery." I'm Courtenay Farquharson from Rubrik, and joining me is Andy Huang, Principal Partner Solution Architect at Microsoft. Andy, you've lived this from both sides, so do you want to do a quick intro for us?
Absolutely. Thanks, Courtenay, for having me here today. I did start my career in build and release, and that is a component of DevOps, and later on went to become a DevOps engineer and run my own DevOps team as well. DevOps is a space that I am very passionate about for myself, but also to help more partners and customers in those areas. This is also, due to my experience, a pain point that I have had, whether it's getting calls in the middle of the night or running into issues with pipelines. This is actually something near and dear to my heart. Even then, back then, before I joined Microsoft, I was actually a Rubrik customer as well. Looking forward to our discussion today.
I mean, if you're okay with it, I'd love to dig into it. When you started out, maybe let's go there, what did the DevOps platform sort of look like, and what does it look like today for you and your customers?
Yeah, I mean, when I first started, I had a build and release title, and it was just a subset of DevOps, and DevOps was definitely the buzz back then and starting to grow at that time. But I would say a lot of the components were very separated. You had one piece for the repository, another piece for the pipeline, another component for managing your projects. Today, we can find all of these and more in ADO and GitHub.
If you put your Microsoft hat on, how tied are those pipelines and all those commits to, say, the broader cloud estate?
Oh, they're very closely ingrained and tied together these days. Before, when we thought about build and release pipelines, we thought about just building the code and releasing the code, right? Now, we also have infrastructure as code, whether you're using Terraform or Bicep to deploy to Azure, as an example. That's now part of the pipeline. The pipeline isn't just building and releasing your code, it's also building out and deploying your infrastructure, managing your infrastructure as well. We see those as being very tightly ingrained and very close together.
Okay, that is super interesting. I mean, we also, chatting to customers, see similar types of things. The infrastructure as code repositories come up quite often, and sometimes at Rubrik, we refer to that as, I guess, the factory floor. The old-school factory floor where everything happened, now that's in the DevOps estate, and if it's down or compromised, can't release anything, you can't ship anything. Even that security fix you critically need at that point in time, it can't go out with the DevOps platform not functioning correctly. So it's a tier zero application. But in my experience, just chatting to customers, it's rarely protected in that way. Attackers also know that the factory floor, as we're calling it, is also the target. Andy, I'm curious, what have you seen in terms of attacks, and how are the bad guys getting in?
It's actually still the standard way, or actually the most common way, which is they actually get an identity and they actually log in. The Microsoft Digital Defense Report actually found that the majority of identity attacks are still password-based, right? They're just password spraying or brute forcing, right? Which is something that we don't think about anymore, but it's still the most common approach. The other thing that I like to add is that brute force attacks doesn't just mean, "Oh, let's try a million passwords in a second or a minute." It can just be, "Hey, let's try a few times now, and then let's try a few times later," and continuously go on, right? After a while, you might have just found your way through.
They do that to stay under the radar, but those are still password-based attacks, and that's the most common one that we're seeing, for sure.
Once they get in, they're not just doing one thing. Maybe three quick examples I had written down for this is around deletion. Earlier this year, attackers used one stolen token to wipe an entire release history of Trivy, which is a widely used open-source security tool implemented in many organizations as a package, and that affected thousands of downstream consumers of that package. In another case, another example, the exfiltration and extortion sort of point of view. In May, an observability company rotated its tokens after a supply chain incident, but missed one specific rotation of a token. The attacker came back and used that one token to steal the company's entire code base and actually held it for ransom.
Thirdly, from a persistence point of view, I had a note on a threat group, which was UNC6395, and they always have quite strange names, but they hid inside a company's code platform for months, and they quietly added their own account. As you said, they might try password brute force attacks, just slowly over time, in the same way we've added an account, nobody really noticed it, and they used that as a foothold to reach more than 700 other organizations. I guess, every one of these attacks centers on one identity, and only one is about deletion. Whether you run DevOps or cloud or IT operations, the first question after an instance is almost always the same, right? We're trying to figure out what the identity touched, everything's gone wrong, what was the impact, and what do we restore?
Yeah, no, absolutely. What's crazy is, the fix is rarely the hardest part, right? Now you have to allocate your developers and your teams to figuring out, hey, what happened? What's the impact? Like you mentioned, right? What did they have access to? What did they actually touch? That slows down all your development life cycles there.
I suppose, even this session, right, from an AI coding point of view, we can suggest, and we've all seen it, that AI speeds up your code, but it also speeds up your attackers, right? Is that accurate? Is that something you're hearing from the field, seeing in the field?
I mean, it's definitely true. I mean, the risks were already there. It's not like attackers didn't exist pre-AI, right? The risks were already there, and AI really just amplified it. It's kind of similar to how AI is increasing developer productivity as well. We're seeing it capable on the other side. AI is able to allow them to research faster, building their attack strategies faster. That's definitely something that we have heard about. Just to kind of reiterate how much is happening, to kind of show how it's amplifying it, there's a report sent out by Sonatype that showed that there was a 75% growth in malicious OSS software in 2025. Really showing how there's more malicious code than ever, and we think that that's all correlated.
Okay, that's interesting. So, what you're saying is these open source packages really contain more and more malicious code because it's out there, and then people are making use of these packages too. Then there's, I suppose, just coming back to what I was previously saying, on the other side, there's the AI coding tools themselves, becoming part of the attack surface.
Yeah, no, absolutely. Developers are using these new tools or extensions more than ever before. There was a recent report that showed that 97% of enterprise developers are using AI tools at work. So whether that's GitHub Copilot or any other tool. There's a lot that means that there's a new attack vector that these attackers have. Maybe it's tool poisoning, like you mentioned earlier, installing an extension that might have been malicious. While you're working with your agents, there might be prompt injection. You may not realize that when you copied something for a prompt, there might have been something else hidden within it. Now that can be used maliciously when you're running your agent. Or maybe just the poisoned agent supply chain. There's so many ways to interact with your agents.
If your instructions, like the prompt injection example, you had some malicious components in there, or your agent files, that can also be another example of the attack surface on your agents.
Interestingly enough, these identities are outnumbering people 82: 1, according to Rubrik Zero Labs. Teams are investing heavily in prevention, but identity and supply chain attacks are built to slip past that, because they're using the valid logins and the trusted components, as I said, so they look like normal activity. That's where Rubrik comes in. With DevOps Protection Foundation Edition, which we've already released, we've closed the deletion attack with immutable air gap backups. But the attacks have gone beyond deletion into tampering, exfiltration of credentials, encryption events, and persistence. Today, I'm really excited to announce that we have our DevOps Protection Enterprise Edition, our cyber recovery tier for GitHub and Azure DevOps. We built it on three pillars: detect, investigate, and recover.
For the detection part, we are using the DevOps platform's audit logs to surface suspicious identity attack and activity, and then surface options to investigate on a deeper level and recover accordingly.
All right. That is pretty awesome, Courtenay. Once the customer gets that signal, something has happened or maybe a breach occurred, what does the customer get afterwards?
That is a great question, Andy. That is our blast radius investigation, and it is the part I am most excited about. You see, you start from whatever you know. As a GitHub admin, you see your users, your PAT tokens, your IP addresses, or even your agent IDs in this case, with all this commit history that is going on with agent coding agents. Then you pick a suspect window in your GitHub or Azure DevOps environment, and Rubrik reconstructs everything that that identity did. It covers the pipeline changes, repository settings changes, for example, branch protection settings. The attacker could have weakened those or potentially set the merge without review or force pushed on the main branch and wiped that whole version history. The other thing they could also do is add a webhook that is quietly sending data out.
You can click into any of these particular events and see the difference before and after, and then export it out as an evidence pack for your SOC team or your auditors or your regulators or even your cyber insurer. What really makes this possible at Rubrik is our coverage. You can only show what changed if you capture the before, and that is where our backups are. Our coverage now goes well beyond the code and pipelines, which is what we initially released, and into settings, pull requests, issues, wikis, Azure Boards, the org settings, repository settings, as I mentioned, and the packages. We can use those same backups as a baseline for the blast radius that I was talking about to compare against, and then obviously, as the clean recovery points to actually restore from. That leads into the recovery part of this, right?
For every impacted object, Rubrik gives you a recovery recommendation. So, here's what was hit, here's what was changed, and here's what the last known good point is. From there, you can do a granular recovery, bringing back just the affected code or just that portion, the pipelines, or the specific artifacts, without rolling back everything that happened in that organization and without freezing everyone else's work, right? Because it could be loads and loads of commits, as we said, an increase in commits, like a whole bunch of other work that's changed. We're trying to really isolate what's going on there. Then when the damage is bigger, you can scale that up to a full project restore or restore into a different organization as well, and cross platforms.
You could even restore across from Azure DevOps to GitHub or the other way around from a repository point of view. Finally, a sneak peek of what we're building next, surgical recovery, which undoes only the attacker's changes and keeps the legitimate work your developers did in the same window. After all that, Andy, from your DevOps days and what you see with partners now, does this resonate? Does this match how your teams would want to recover? What does it mean for customers building on Microsoft?
Yeah, no, I think this is absolutely how I would love it. The biggest key component is the granularity in the only reverting back the exact changes, right? I absolutely think that it is a fantastic thing there. Partners and customers build and innovate on GitHub and ADO. Having this capability that Rubrik is providing is really ensuring that these partners and customers can continue running no matter if there is an attack that's happening or a bad deployment or just some other event that we haven't foreseen.
Cool. Well, thanks, Andy, for the great compliments. The DevOps platform, as we said, is a tier zero application, and one identity can touch everything. As we've seen as well, AI is accelerating both sides of that on the attack and on the building side of things. Recovery has to start with knowing exactly what's changed. Again, Andy, just thank you so much for joining me.
No, absolutely. Thank you for having me, Courtenay.
Only a pleasure, Andy. Thanks for coming on. Now let's see it in action. Over to my colleague, Mike Preston, our Technical Marketing Architect.
As Courtenay just walked through, AI is enabling your teams to ship code faster than ever, but it's also helping attackers move just as fast. When the identity behind that code is compromised, you not only need to know about it, you need to see and understand what it touched, see how far it spread, and of course, ensure you're able to recover anything that it did. Let me show you what that looks like for GitHub and Azure DevOps within Rubrik Security Cloud. Here's our GitHub inventory within Rubrik. We're already protecting this organization, and we can see that we've already enabled Data Threat Analytics. Rubrik is watching our audit logs, looking for various incidents. What do you know? We see a critical banner up top here.
A bot token that was missed in a credential rotation has been dormant for over 100 days, but it's suddenly now been leveraged from an unidentified location. Rubrik has flagged this right away, so let's dive into it. This same alert lands inside Data Threat Analytics, right alongside our cloud and data incidents, so your SOC can triage everything in one place. Opening the incident, Rubrik shows everything that this one identity touched, mapped out as a blast radius. We can see it cloned some repositories, created a service account, turned off branch protection, made a couple of commits, and we can also see that it created a webhook and modified some release YAML, which gave the attacker a path to exfiltrate data. We can also replay this attack, so this allows us to see exactly when each action occurred.
And we can see here, even with the attacker disabling audit logging early, Rubrik is still able to determine what was done just by comparing various snapshots that we've taken. From here, I can also create an evidence pack for our insurers, regulators, or incident response teams. This includes a signed manifest, the timeline, the blast radius, and the before and after diffs, as well as we can do things like open Jira tickets or share the incident if needed. If we select after recovery, we're able to see the actions that Rubrik will take to undo this attack, things like turning audit logging back on, removing the deployed webhook, deleting the service account. These will all be performed through native GitHub APIs. We can also see that we can undo the changes to the release YAML and the code as well by restoring the repository.
But we also see a couple things that are out of scope. Rubrik has no ability to unclone repositories, and also the narrowing of permissions for the release bot is another thing that's flagged that will need to be manually changed after the restore process. Let's undo this. I click recover changes, and Rubrik pre-selects the seven recoverable changes that tell me exactly what it will do for each one before anything runs. As for our code, Rubrik recommends that we issue a pull request, so your team is able to review the changes and everyone else's work stays in place. But we can change this as well. We can change the recovery point, the target branch, or instruct Rubrik to directly commit the data if desired. Let's just keep the defaults and move on. We can see those API actions that are going to be called.
Revoking the token comes first, so the attacker's locked out. Then settings like branch protection, the webhook, and the deploy key, they'll all be put back in place. Finally, we can review the ordered plan. Rubrik also warns me about two changes that it's unable to undo, so there's no surprises here. We can also see the impact of the pull request itself, basically what commits are going to be kept, what's going to be restored, and what will be removed. With that, let's go ahead and we'll kick off our recovery, and it's going to run in the background, and we can follow each step within our active operations here as it occurs, and there we have it. We've successfully bounced back from this incident. As the recovery finishes up, we can also see that Rubrik hasn't forgot about those manual steps.
We get a reminder here to let us know that the incident's going to stay open until we tidy up all these recommendations. That's Rubrik for your code. We'll protect your organization, let you know when an identity goes rogue, and give you the ability to see everything it touched and recover just the attacker's changes. As code's getting written faster, your recovery plan has to keep up. Thanks so much for joining us today.
Welcome, everyone. I am Jasmine Betthauser, and I lead our product team at Rubrik focused on Data Threat Analytics and Cyber Recovery. Now that we have talked about protecting your AI and ML models on data lakes and protecting your code, now we are going to talk about how to protect your cloud-native applications. Nowadays, every organization is racing to deploy AI in their apps, but in that rush, many of us skip an uncomfortable question. What happens when those apps are compromised? That is what we are here to talk about. I am joined by Jason Brown from AWS, who talks with customers about this every day. Jason, over to you.
Thanks. I am Jason Brown. I am a Senior Solutions Architect here with AWS. I focus on our resilience engineering, so I focus on helping customers ensure that they are meeting their resilience objectives and being able to prove that they can do it. When we think about the cloud, it is not only just the operational core of the business and not the infrastructure underneath it is tied to things like your revenue, your operational standards, and now your AI-driven outcomes that all run through those cloud applications. When there is the potential for downtime, whether that is through an AWS service event or maybe something that is self-inflicted, it is not just an IT problem, it becomes a business risk, and that is where we need to think about how can we improve these things.
Makes a lot of sense. Before we go further, I think that leads us to a question that sounds pretty basic, but when we say cloud application, what is that exactly?
It is a great question, and ultimately, it is not one thing, right? As customers build on AWS, an application is inevitably a collection of AWS services, right? So you can have your compute stacks, which are running on Amazon EC2 or EKS clusters, and those are all running your business logic. From there, you might be using your data tier, right? So you have RDS, you have DynamoDB, all of those kind of good things. Inevitably, where we find a lot of customers start to forget about things that they might need on their path to recovery is the configuration layer, right? So you have your Secrets Manager or your container images in ECR, and inevitably, there is also the network and kind of access settings that wire it all together. The complexity comes because this is inevitably spread out.
You might have multiple accounts and multiple teams and potentially even multiple AWS regions that you are leveraging. Now, as you have that, all of these teams have probably done the right thing for their own piece of that puzzle, but have they thought about it in the bigger picture?
Makes total sense. It could be something like a checkout system or a claims portal where it could touch EC2 for web traffic, RDS for orders, and S3 for documents. The application is the sum of those parts, and if we miss one during recovery, then the whole system fails. Because your apps are also now the front line for your AI experiences, that means that if the app is done, then your biggest tech investments are also unreachable by your users. That brings us to the core question every leader needs to answer. What is your minimum viable business? Picture your absolute morning, an outage or an attack wipes out most of your environment. Employees and customers are waiting. Which critical applications do you restore first just to get a pulse back in the business? That is your MVB.
It is your revenue engines, your core operational systems, and customer-facing apps. If one goes down, the business is hurting. Right now, can you name yours off of the top of your head? Can you do it today rather than an actual incident? Jason, from your vantage point at AWS, how often do you see customers who can define and test their MVB?
We have a lot of phenomenal customers that do a really good job with this, but inevitably, it is actually less often than you might think. That is due to the ever-evolving systems and dependencies and ownership models that you have across distributed teams. There is complexity with that, right? Inevitably, that change is constant. It can be a challenge to keep up when either a new service or a new feature could change where your revenue is actually impacted the most.
All right. Well, Jason Brown, let's think about the threat landscape. How are things changing there when it comes to the cloud?
Yeah. The scale and speed, and general accessibility, has greatly increased the attacks that are ever-growing in the world of AI, right? In addition to the metrics that we have on screen here, we've also seen things like your mean time to exploit go from 2.3 years in 2018 to five days in 2024, and now just to 20 hours in 2026. This inevitably requires shifting your security practices left, right? You need to automate your security checks and validations, and scaling your operations, and building a culture that really focuses on security and resilience, ensuring that it's a prerequisite, not just an afterthought.
Inevitably, as teams start to actually build agentic capabilities within their own business flows and critical applications, this brings about not only existing failure modes that maybe we have seen but are harder to diagnose, it also brings new and novel failure modes that we haven't quite witnessed in traditional software before due to the undeterministic nature of GenAI.
That's right. What's changing isn't just that attack speed, it's also the vector that we see these attacks. More and more intrusions are now leveraging cloud native APIs through compromised credentials. Although malware and traditional exploits haven't vanished, in the cloud, we see that when an identity is hijacked, every malicious API call looks just like authorized activity. That makes detection and investigation more complicated, and we're seeing this exact pattern unfold across major cloud ransomware campaigns. Do you want to talk about some of these common ones we're seeing, Jason Brown?
Absolutely. If we start with Codefinger, the attacks basically hold a stolen AWS credential, so it is using, back to your point of we are seeing more and more of that, where they actually use the security feature. The S3 service provides server-side encryption with customer-provided keys or customer-managed keys, which exists to really help customers protect their own data. The attackers used it, though, to re-encrypt the victim's buckets, and they held the key, the attackers, right? They set a seven-day deadline, which inevitably, this process misuses a security feature, not a flaw within the service itself. Because the attackers held the key itself, there was nothing the customer could actually do about it. The only way back was effectively a recovery plan that needed to be there before the attack took place in the first place.
Next, we have JadePuffer, and what is alarming here is who is driving the keyboard. JadePuffer has been documented as one of the first ransomware campaigns orchestrated end-to-end by an autonomous AI agent. It mapped the target, harvested credentials, and encrypted production databases with zero human intervention. When a step failed, it diagnosed the error and self-corrected in under 30 seconds. Attacks that used to take weeks to months execute now on the order of minutes and seconds. When that happens, recovery pretty much comes down to if you had a clean copy of your MVB that the attacker couldn't get to.
I think both of these really hint at the idea of the shared responsibility model, where AWS is going to provide the infrastructure and AWS services that you use, but restoring your apps, and therefore your business, ultimately require your own responsibility and your own plan of action. That brings us to the AWS shared responsibility model, where AWS security and resilience are our top priority for our customers. We want to ensure that we can provide services that are going to be as secure and resilient as possible for you. Within that, though, and by proxy, we are responsible for the security and resilience of the cloud itself. However, on the flip side, we trust that our customers are going to be responsible for their operational model and their ability to recover from security or resilience events based on their architecture needs and ultimately their recovery time objectives.
Now, with that, it kind of depends on what AWS services you might be leveraging, right? We have different tiers or different levels of AWS services that are tied to different levels of that shared responsibility. You might be using something on the EC2 front where we provide the basic function and infrastructure there, but a lot of the responsibility of securing that is landed to the customer themselves. There can be an inevitable amount of complexity that comes along with that.
Absolutely. That is really to the point of where we see that friction. Because a single enterprise application can often span all three service tiers, you could have an EC2, RDS, and S3 inside that same checkout workflow app. That means that operational responsibility changes component by component. That is why recovering a full application is much more complicated than just restoring a single database. If recovery is ultimately your responsibility, what does great look like? It comes down to four non-negotiables. First, it must be provable, measured against real-world RTOs, and tested regularly. Second, it must be automated, not just the restore process, but dynamically mapping your app dependencies as your developers push updates. These are not static run books that go quickly out of date. Third, it must be clean. You need the intelligence to isolate the blast radius and restore from an uncompromised state.
And fourth, as you have guessed, it must be application level, bringing back the entire stack in sync, not piecemeal infrastructure. Those four non-negotiables are the gold standard. But Jason, when you look at how customers are building their resiliency plans, where does that process actually break down, especially under times of pressure?
Absolutely. I mean, customers tend to face these hard choices at inevitably the worst times, right? It could be 2:00 A.M., where nobody has had the proper amount of caffeine for the day, and they have to make those decisions under pressure with a lack of potential understanding of the overall application, where things need to be in the recovery process in terms of having them run sequentially or in sequence to ensure that things are ready as part of that recovery. All of this inevitably leads to customers missing their recovery time objective, and where unfortunately we tend to see it a lot is actually in the decision factor of whether or not it is something that they do need to fail over to or make a recovery decision that is appropriate for the business needs. There can be a lot of time that is taken just in that decision period.
Makes sense. You might think that this is an enterprise maturity issue, but it is not. We have worked with several types of customers, and one including was a U.S. insurance carrier that targeted a sub-four-hour RTO. On paper, they look great. They had mature backups, updated runbooks, automated Terraform scripts, and this was across scale too in their AWS infra. But when they actually did a recovery event, they found that restoring that interconnected system did not take them four hours, but it still took them days.
We see that a lot on our side as well. It's never fun when you actually put it to the test, but it's something you need to do.
All right. From everything we talked about, it's pretty clear you can't rely on human intervention to manually stitch together your app architecture when the clock is ticking. You need Autonomous Business Recovery for autonomous threats, and that brings us to what's new from Rubrik. Today, we're sharing three major announcements. First, Autonomous Business Recovery for cloud applications is officially GA. We shared this at Forward earlier this year, and since then, we've been making it even easier to eliminate the chaos of manually assembling a recovery blueprint for your apps. It automatically discovers and maps every dependency so you can protect applications as single cohesive units and test full app recovery as part of your drills.
Second, we're expanding protection to more types of cloud architectures, from both your traditional three-tier VM and database workloads, like EC2 and RDS, to full-stack protection for cloud-native containerized and serverless applications running across S3, ECR, ElastiCache, and Secrets Manager. Third, we're compressing the time to identify and recover clean data. Near real-time deletion monitoring to flag destructive activity in seconds so that you can recover faster, a unified blast radius view to show exactly what system and sensitive data were impacted, and surgical recovery capabilities, which lets you carve out infected files with malware or encryption while restoring everything else. You can minimize data loss and downtime at the same time.
I really think that's amazing, especially the dependency discovery. We tend to see a lot of customers get impacted by that because they didn't realize they had either a third-party dependency or what have you, that they need to migrate over as well on the path to recovery. So having seen that happen firsthand quite a few times, I love seeing that. In general, I think everything that you're talking about here really speaks to the fact that you're making it easier for customers to achieve their resilience and security goals, which I think is great.
Absolutely. That's the goal. Before we move into our demos, I want to leave you all with three questions to think about when it comes to building your cloud cyber resilience strategy. First, what is your Minimum Viable Business? So what are those critical applications that you need to make sure are always up and running? Second, can you prove you can recover within your RTO today? So have you done a real-world rehearsal of what you actually need to recover before a cyber event happens? And third, how fast can you locate a clean copy under fire? So how does your team operate when under pressure to figure out what is clean? Thanks, Jason, for joining us today and the continued partnership with AWS.
We really appreciate how your team is helping our customers build securely and at scale on AWS while we help them in their cyber resilience strategy.
Absolutely. I think you guys are doing some great work, and I love seeing the fact that you're removing that undifferentiated heavy lifting that we're always a big fan of here at AWS, and we look forward to seeing what you guys continue to do.
Awesome. Let's go ahead and take a look at what this looks like in action. I'll pass it over to Mike Preston for a quick walkthrough.
Jasmine just had a great chat about how to define and recover your minimum viable business with our new Autonomous Business Recovery for cloud applications. I get the fun part. I am going to walk you through what ABR looks like inside of RSC and how to discover, protect, and recover your most critical cloud applications with Rubrik. At the end, we will take a quick look at some of the new cyber recovery features that were also mentioned during the presentation. With that, let us just dive in. We already have one application discovered here, but let us go ahead and add another. I am going to pick the source account where the application lives and a separate AWS account to host the recovered application. Then I simply add what is called anchor tags.
These are tags that we have defined on the resources at the heart of the application within AWS, and Rubrik automatically discovers every resource with those tags and then recursively discovers their dependencies. Here, we have tagged a load balancer and an RDS database, and Rubrik has gone out and found all the supporting resources, like the EC2 instances, VPCs, subnets, and security groups. That is really all there is to it. Rubrik has mapped out our PeerPoint banking application for us here, and it will keep this up to date. As new dependencies and resources are added to the application, Rubrik will pick them up and protect them automatically for us. All right, with discovery out of the way, let us shift our efforts to recovery. Maybe it is a rogue script, maybe malware. Either way, our production application goes down. It is damaged beyond repair. Let us begin that restoration process.
I will go ahead and click Recover, and we will ensure that we have the correct recovery account selected and continue here. Next, what do we recover to? Autonomous Business Recovery is fully integrated with Rubrik's Data Threat Analytics, so we already know that latest non-anomalous, non-quarantine restore point. There is no need to engage in any scanning or clean room activity. We already know what clean is. For S3, our bucket names must be globally unique, so we specify new bucket names to recover to. We also support prioritized recovery within ABR, so if you have petabyte of data, the most important data can come back first, while last year's holiday pictures just sort of trickle in after the application is online. For networking, we have a few options.
If we have a hot standby recovery account that already has been configured for networking, we can simply recover into those existing VPCs and subnets, or we can clone the source networking into that recovery account with the option of modifying our CIDR blocks to avoid any sort of addressing conflicts. Let us just clone as is here, and we can choose now to run pre or post-recovery scripts. These are executed as Lambda functions within the recovery account, and we can also update any Route 53 records so traffic is pointing at the recovered application at the end of the restoration. I will just give this a quick review, and I will click Recover, and through the magic of video, we are done. We can see Rubrik rebuilt that entire application step-by-step in dependency order with every resource group marked as recovered. That is really it.
Simply input a couple of tags into Rubrik Security Cloud, onboard a recovery account, and Rubrik automates the entire recovery process of your entire application from one account to a completely different account, allowing you to establish your minimum viable business with ease. As promised, something new. Let's start with the attack itself. In cloud attacks, we often see data deleted after it's been exfiltrated, more so than seeing it being encrypted or any activity that would flag an anomaly. Typically, it's a compromised identity with escalated privileges issuing valid API calls to delete data. To help with this, Rubrik can now monitor your critical resources in near real time for deletion. If Rubrik sees a critical resource being deleted, an alert gets surfaced, allowing organizations to quickly react and begin restoring their most important data immediately.
But what if the attack happens at the file level rather than at the resource level? Rubrik's new impact investigation can handle that. Again, often files are modified, added, deleted using valid cloud native APIs and a compromised identity, and this evades anomaly detection altogether. Impact investigation shows us just that, allowing us to see how our data's changed over time, pointing out the exact restore point we should use to recover our data, and makes it super easy and super quick to triage and respond to attacks. In terms of recovery, we've made a number of new enhancements there as well. Previously, Rubrik let you recover to a clean restore point, but that non-anomalous, non-quarantined snapshot, well, it could be like 30 days old depending on when the attacker entered your environment.
Now, with our new surgical recovery, we can restore the latest restore point, but instead of restoring all those encrypted files or any quarantined malware, Rubrik can search previous snapshot data to find clean version of those files. For example, if one file was encrypted two days ago, Rubrik pulls its clean version from three days ago. If another file had malicious code injected into it and was quarantined, say, seven days ago, Rubrik can just pull the clean version of that file from eight days ago. Rubrik then merges those clean files with the latest restore point. With surgical recovery, you still restore clean, but with the added addition of minimizing data loss. So, that's Rubrik, right? Know your application, know it's protected, and know you can recover it from a clean point in the right order.
And when an attack leaves no malware behind, you can still catch critical deletions in near real time, see exactly what happened, and recover with minimal data loss. That's your minimum viable business, ready before the incident, not during it. Thanks a lot.
Hi, I'm Steve with Rubrik. Excited today to get this conversation going with some of our customers about their thoughts and how they've implemented cloud resilience within their environments. Most conversations about cloud resilience are about architecture diagrams, but every board is now asking one question: Can you prove that you can recover? They actually don't care if you have backups. They want you to prove that you can bring things back to production across every cloud, with identity, including code repos, all of the data in scope. Today, we're talking with three Rubrik customers who can show us what it takes to answer that question.
We have Matthew from Citizens, Howard from LendingTree, and Cyril from TGS. Gentlemen, thank you all for being here today. Matthew, why don't we start with you?
Yeah. Matthew Apodaca, Principal Architect at Citizens. Cloud resilience, to me, is about having confidence and that ability to prove that recoverability of a critical business service, whether that is the data or the entire technology across multiple clouds or SaaS environments, but essentially returning all that capability back into a trusted or business-accepted state as quickly as possible.
Fantastic. Howard?
I am Howard Zeemer. I work for LendingTree in Charlotte, North Carolina. Resiliency, to me, really breaks down to how well we can deal with a bad situation, whether it is partial failure, full failure, whether it is regional or just a single availability zone in different cloud providers, and the ability to deal with those situations as they occur in real time.
Excellent. Cyril?
Yeah. Hi, I'm Cyril. I'm the Director of Architecture and Platform Engineering at TGS. Resilience for TGS, cloud resilience, it means protecting not just our data, but the identities, infrastructure, and platform behind it, so that we can recover cleanly, quickly, and confidently from any disruption. We're protecting the world's largest multi-client energy data library with over 100 PB of seismic data and a net book value of $1.2 billion, and it's now consolidated on AWS.
Excellent. Thank you. Thank you very much. First question, it's going to be for the group. I'll again call you to answer, and Howard, I'll start with you. I don't know if you guys have noticed, but the market has gotten a little interesting in the last 12 to 24 months. In my experience, boards are starting to dig into the details a little bit. They're wanting to know the nuance around security posture, cloud resilience strategies, recovery workflows, things of that nature. Ultimately, the question for you is, what questions are you getting now as a result of kind of the shift and everything going on in the market space? Howard, we'll start with you.
I mean, the shift in the market space has been pretty impressive. The things we used to have to worry about a few years ago are the still same things we really have to worry about today, but it's faster. A lot of the questions and things I've been dealing with out of our board and our management committee and things like that are more around how fast we can recover from things, how quickly we can detect, how frequently we're testing things to make sure that things still hold true the way they did, like you said, 24 months ago. The big impact over the last 24 months really, to me, has been speed.
Is that validation step of actually demonstrating recoverability something that's a bit more pronounced with your leadership today?
Yeah. We're definitely in a situation. I mean, you look at the news, and there's days when I wonder how dystopian it's going to get on the internet. Proving the ability to recover is a lot more what people are worried about, more so than even saying anymore.
Excellent. Thank you. Matthew, we go to you. What questions are you getting now?
Yeah. The questions and focus have kind of really shifted for us from showing or confirming that we have immutability or ransomware protections of our data to can we repeatedly demonstrate a full end-to-end recovery of an application stack or even an entire business service. You kind of combat this years of technological change, and it becomes more of like, do we have the data dependencies mapping in place, and then with that confidence to be able to bring a full application back up in its entirety.
You are multi-cloud, correct?
That is correct.
Excellent. That always makes it fun when you are getting the same questions across multiple windows. Instrumentation.
Exactly.
May not have been there. Excellent. Cyril, your thoughts?
Yeah. So, maybe a year, two years ago, the type of question we got was more, "Do we have backups?" You know, that was that simple. Today, the questions are more, "If we attack tomorrow, how quickly can we recover? And more importantly, can you prove it?" That is a different type of question. And it matters to us because we have this data library which really is a business, so we do not want that to be compromised. So our challenge was shaped by growth. We integrated five major business in roughly four years, and each came with its own security practice, backup technology, and cloud environment. To be quite honest, at very different level of maturity. Many were below where we wanted it to be, so fragmented ownership, inconsistent recovery standard, backups that could be modified, and not enough isolation between production and backups.
So, what we wish we had when we started the integration was one consistent standard, and evidence of recovery expressed in business terms, like customer deliveries or service interruption, and not just technical metrics. The approach we took is that we started with identity and SaaS application. We built on immutable backups, isolation, and then clear accountability and tested recovery. I guess the point was that it was not just about protecting more system, it was bringing very different maturity level under one standard and proving we could recover.
You talked about a lot of things that are very disciplined across, at least what I heard, a large number of people. It feels like this was a systemic cultural kind of shift in terms of the direction and the process and that discipline. Is that something that has manifested recently as a result of the changes in the market, or did something else bring everything together to make this initiative successful?
Yeah. There was two parts. As I mentioned, we have integrated multiple companies which had different level of maturity, some higher than the others. But clearly, what is happening in the market and the constant news about threats is triggering a lot of questions from the board, where before maybe they did not have those questions in mind. I clearly see a shift in the board attitude toward those questions.
For the next question, Howard, we will start with you on this one. But where did your earlier cloud resilience approach fall short? Were there gaps in coverage, recovery speed? Is it operational? Would love your thoughts.
One of the challenges in a multi-cloud environment has to do with every cloud does it differently. Best practices in one are still the best practices in another, but the setup is completely different. What you end up with is you have your AWS specialist for backup, your Azure specialist for backup, your Google specialist for backup, and trying to keep all those skill sets aligned is a lot of time and effort. As things change, making sure that you are doing that work three times. If an incident occurs, you have got to make sure that you have that specialist on call for that specific environment to be able to do that restore. It triples the cost and the time that it takes to do just about everything.
One of the things that we fell in love with the Rubrik product specifically, was that single pane of glass, that single set of processes. If we need to restore something in any of the clouds, it is, for all intents and purposes, the exact same process. Now I have a much larger team that is much better at backups, restores, and keeping track of that stuff, because it is three times as many people as opposed to previously, I have got one person here, I have got two people there, and you are chasing them around trying to make sure you are keeping those skills up and everything is in line. The amount of time and effort you put into it is daunting at times.
Have those efficiency gains allowed you to tackle other problems within the business?
Yes, without a doubt. It has allowed us to dial in a lot more on a number of different initiatives we have that relate to business continuity planning and a few other pieces of the business. Quite honestly, with the insanity of AI right now, it has really allowed us to try and get ahead of that and stay up front with it.
Yeah. I am sure you are not losing any sleep on that one at all.
No.
Thank you for that, Howard. Matthew, would love your thoughts. What changes have kind of made their way into things?
Yeah. Howard hit a point that I thought was really interesting, or hit a word, was this term insanity. I think that is what drove a lot of our thinking and trying to shift our more traditional DR mindset early on, just how quickly things can evolve and change, and how even our tools with AI can just attack ourselves with them. So, we needed to shift, and what we have found is that we fall back on those kind of core foundational governance elements. So we talk about enterprise resilience, enterprise architecture, risk, audit, change management. Just having those pieces in place has allowed us to have a set of standards and everything, kind of have a set of rules that we are going to play by.
I think as organizations, we often joke about those guardrails that keep us, may add friction, but in reality, it really challenges us to keep consistency across multiple environments, ensure that our protections are in place. It comes back to how do we work through and ensure that there's consistency. It really comes to practice. If you hone any skill, you practice, you train, you study your partners and adversaries. It's through this repeatable practice that you begin to expose the gaps, tweak your policies and your governance, and then refine your tools, and then repeat the process all over again.
You mentioned something there, practicing like you expect to go and play. I can tell you in my experiences, the customers that have that level of discipline tend to fare much better when the unexpected happens. Going to change directions a little bit, because there's an aspect, Cyril, that you had mentioned earlier. You guys undertook a very material effort to move a lot of data cloud-side. You're dealing with physics problems that not everyone has to ultimately go and deal with. I'm curious about your migration. Can you kind of walk me through how you planned protection of the assets you were moving into that migration process, as opposed to just bolting it on at the end?
Yeah. We moved a very large amount of data. We're talking over 100 PB of data into AWS. There was about 53 PB that was on GCP and roughly another 50 PB on legacy tape. The two key non-functional requirement was no interruption of client delivery, and obviously 100% data integrity. We took that in mind as part of the design, and we built an automated pipeline using Rubrik NAS Cloud Direct, Tape Ark, Ovation, and AWS. All of that was orchestrated through Airflow. The principle was fairly simple. It's verify before you delete. That sounds obvious. But we worked with Rubrik, and we achieved 100% data integrity, zero disruption, and we achieved a peak throughput of 180 Gbps over a 200 Gbps link. It's a saturation of 90% of the link, which is quite remarkable.
We were able to transfer those petabyte of data in a fairly quick time. We also looked at S3 Intelligent-Tiering to reduce our storage cost, and we saved about 70% there. When I look back and think about what I would do the same and what I would do differently, the automation was critical to the success, and verification at every step of the way. Things that we would do differently was probably better define the RPO and the RTO before the migration. I think that would help us. Maybe looking forward, our next step is to automate protection policy based on data classification and business criticality.
Excellent. With that volume of data, that has to affect how you think about recovery. Can you perhaps-
Yes
-give us a little color around the way you approach that type of scale versus when that type of scale wasn't a problem for you?
Yeah. When you have 100+ PB of data, resiliency isn't about backing up everything equally. It's about protecting the right data and recovering what matters first. You can't wait to recover 100 PB of data before you can get back to work. That's why we define recovery objective and retention by business criticality, and why we're moving to policy that apply automatically based on how the data is classified.
Fantastic. Thank you. Beyond your typical workloads, I mean, obviously in your case, unstructured was a very material aspect of what you needed to protect. But was there anything that you realized that you weren't protecting in your migration strategy? Did you uncover things that either weren't important when they were on-prem that became important in the cloud, or just weren't top of mind in the first place?
Yeah. I mentioned these data libraries. Obviously, we've always known that we needed to take care of that. But our biggest blind spot came from the system we assumed someone else was protecting. The first one that we found was identity, right? We were not protecting identity. So now we've got Active Directory, and Entra ID, and Okta that are protected, and we've validated recovery for those. The second was our SaaS application, so Microsoft 365, Salesforce, Jira. Having a vendor available doesn't mean your data is recoverable. Those are now protected as well. Then third was our Azure DevOps repositories, right? Backing up your Git repo, that was not done before, so now they're protected. We have further work to do to prove the recovery of that. What triggered this effort, it was the post-merger discovery work.
We ran a joint inventory with Rubrik across more than 100 systems, and it exposed gap in ownership, backup coverage, and recovery readiness. That exercise turned assumption into a clear list of things to fix. That's how we started the journey.
Excellent. You mentioned a couple of things there. Yeah, the fine print on those SaaS agreements are super important-
Yes
-to dig in and understand. Best effort is a real thing out there in the wild, and you're on the hook for it either way. You also talked about code repos. We are obviously seeing a bit of an explosion on that front. Organizations that weren't necessarily speaking Git every day are all of a sudden now super dependent on it as a function of how they're adopting AI and everything else. Has source code repos been a part of your organization and a piece that you've needed to deal with, or are you seeing an acceleration in that space as well?
Yeah, we're seeing an acceleration. The number of Git repos that we have keeps growing. We are also very dependent on those Git repos for our operational processes, right? So every modification we make to a production environment first goes through a pull request. So if our Git environment is not available, we can't make changes to production. So it has, I think, Git repository with a GitOps approach have changed from being a system that's used by developers that maybe is backed up once a week, and if it's down, the impact is not critical, to being absolutely critical for day-to-day operation of your production environment.
Fantastic. Thank you. All right, we're going to do some rapid fire questions. So Howard, I'll start bugging you more. Appreciate it. We'll start with you on this one. We'll just do one question at a time here. But how has your confidence and your ability to recover changed, and what is the evidence that you now have to support that? Howard, we'll start with you.
The confidence level, I don't know that necessarily the confidence level has changed a lot. What has really changed is the speed at which we can do it. The ability for people who are not just the specialists to validate things. Rubrik has really given us that single pane of glass that allows whether they're in InfoSec or operations or even engineering to go in, validate that we have systems backed up like they expect. And quite honestly, it saves me a bunch of time from generating hand-created reports that used to drive me nuts every quarter for my InfoSec team.
Back to your love of paperwork.
Love paperwork.
Completely get it. Matthew, as you guys moved from on-prem into different cloud environments, and if I recall, you are diversified, you are in AWS and in Azure, how do you keep both your recovery consistent and obviously governance was a big deal for you, how are you keeping that consistent across the different environments, and how are you maintaining visibility?
Yeah. I am always careful with saying my confidence is increasing because there is that humbling moment of correcting. It goes into that demonstration of recovery and testing through. It is not necessarily a dashboard or a report that brings it. While that might be metrics that others in the organization may use, it is more of that demonstration, executing those recovery scenarios, learning from them, closing gaps, and then that repetition. Just keep saying practice, so.
Practice. Yeah. Makes sense. Again, for all three of you, this is your opportunity to kind of share your knowledge. You have gone through the lumps over your careers. What is one thing you would tell a peer to do in the next 90 days? Howard, and I am looking at you this time, we will start with you.
In the next 90 days, validate. Proof's in the pudding. If you haven't gone in, you haven't tested, you haven't validated it, you can't trust it.
Awesome. Matthew?
I would say pick a critical business service and map everything out required to recover it. Not just the application or the data portion of it. Look at identity, your source code, your infrastructure, those integrations, third parties, and the people involved. Again, they all need to interact. I think a lot of organizations discover that the challenge isn't just backup, it's understanding all those interdependencies really make up that business service that we all rely on.
Excellent. Cyril?
Yeah, mine is very similar to Matthew. It is identify your tier one system, assign owners and RTOs, and then perform a real recovery test. It is more valuable than backup reports.
Gentlemen, I just want to thank you again for taking the time. It is not lost on us that you have day jobs and the list of things that you have to go and do is not getting any shorter. Certainly, people that are going to watch this are going to want to hear from you way more than they want to hear from us. So, on behalf of Rubrik, I wanted to thank you all again for taking the time, and I really enjoyed the chat.
Thank you, Steve.
Thank you, Steve. Enjoyed it.
You are very welcome. Thank you for having me.
You have just heard where cloud resilience is headed. Now, I want to pressure test it. Everyone has a take on AI and cloud, and not all of them survive contact with reality. So we have invited someone who has been calling it straight since before cloud was a buzzword. David Linthicum is a cloud pioneer, author, and strategic advisor, and the founder of Linthicum Research. David, welcome.
Thank you. It is great to be here.
Now, David, we hear things from customers, myths if you will, and I would love to just kind of get your take on them. The first one is, AI is just another application.
Yeah, I hear that too, and it's pretty scary. I mean, at the end of the day, AI is a very complex bundle of decoupled heterogeneous technology that work together to form a system, and many of the technology may be shareable among other systems. They're not just bundles of applications, they're bundles of technology that may exist across different silos, different domains for different purposes. AI is definitely going to be more complex. It has data, it has a model, it has RAG-based systems, it has security, it has resilience, it has all these other systems are going to be bound to it, and that's what makes up the system. AI, at the end of the day, it is much more far-reaching and complex than a simple application, and people need to treat it as such because there's many other components that you need to protect.
That makes a lot of sense. I'm going to throw another one at you. How about AI just needs more than compute?
Well, compute's important, but it's what's visible, and when you look at the AI system, people are always going to look at the GPUs and things like that. But at the end of the day, it needs data, it needs processes, and it needs IO systems and network resources. All those sorts of things are going to be just as important. I think we have a tendency to put too much emphasis on the processor end of it. In other words, we just want to throw GPUs at the problem. But again, if these things are very complex, loosely coupled resources that are bound together, compute's only one part of it.
You're going to need the data, you're going to need the security, you're going to need the resilience operating systems, you're going to need IO, and you need the ability to kind of put this into a zero-trust framework so you know how to secure it and how to keep it safe and take it to the next level and use it as a very unified bundle.
That makes a lot of sense. What I am hearing you say is that compute really is just the visible part of it. What AI really needs is data it can trust, systems that stay available, and the ability to recover quickly and cleanly when something goes wrong.
That is exactly right. When we are looking at AI, again, we cannot minimize what it is. In other words, it is way more complex than a simple data application kind of a program. It has models involved, it has RAG-based systems involved, and you may have different models at different times. I typically build AI systems that are tiered. In other words, there is a small language model which is connected to a large language model in the backend, which may be connected to another large language model, which may be connected to another query engine that is finding some other aspect of the system. All of that is my application, and it exists everywhere. My ability to kind of figure out how I am going to secure it and how I am going to put protection around it is a priority.
If I do not do that, if I do not plan how to do that, then I am at risk. I tell my clients that all the time. You need to figure out how these things are going to stay resilient over a long period of time. We saw a lot of cloud outages last year. The ability to, in essence, recover from those things, the ability not to lose time and not to lose data, those are higher risk now considering the fact that we have AI that is weaponized by the hackers and they are going after the systems. It is something that people need to put first and foremost in their thinking and their priorities. My biggest concern for 2027 is that that is understated, it is underthought of, and it is underplanned within the enterprises. We are going to see a lot of issues where they are just going to run into disaster.
Thanks, David. Have you seen a team that skipped the foundation? Curious to hear what happened in that situation.
Well, it's like skipping the foundation of a house. You just put it on the dirt, it doesn't work. At the end of the day, foundations are going to be core to your AI systems and how you're going to build them. Foundational models, the ability to have foundational code, and the ability to kind of put everything into some sort of a unified infrastructure that's going to support the application. We have infrastructure in supportive platforms. We have storage and compute and networks and things like that. AI systems need foundational infrastructure as well. If you skip it, you're not going to have a reasonably solid application. It's going to go into production, and it's going to have many problems, one after the other. One of the things I'm seeing right now is people are throwing AI systems into production.
We call it the happy path. In other words, they go directly from demo into production without having a solid foundation. If it doesn't have the core things that you need, resilience and security and governance and operations, it's not going to survive the month. Many of these things are being pulled offline a couple of weeks after they go live because they're not thinking about the core foundations and how they build these systems, because it's a different way of thinking. AI requires you to understand the core architecture, the dependencies, how all these things are going to work, and you have to put security frameworks and resilience frameworks around that with that in mind.
David, last month, two critical PHP flaws surfaced, and attackers were testing exploits before a fix even existed. But patched isn't clean. How should customers think about AI when the defender's window keeps shrinking?
Yeah, the real blast radius is the damage they can do with the available technology. If you went back in a time machine four years ago, the technology wasn't around to really kind of bother those PHP vulnerabilities. But the fact of the matter is, the hackers have new weapons, and people were able to discover how those weapons could be used and find the vulnerability. Our ability to patch it is something that we have to spend our time thinking about doing. Because at the end of the day, the attack vectors are getting bigger, and they're getting wider, and they're getting more vulnerable to things that typically weren't bothering us a few years ago.
Not only do we need to understand the vulnerabilities that we currently have, I think that's well and good, but the ability to prioritize those based on the fact that we have AI out there that has a tremendous amount of capability to be turned into a weapon. You need to think proactively about how we're going to protect the system. This PHP vulnerability was a good case study for that. But guess what? There's 20, 30 others that are out there if we see one.
Let me throw another one your way. What's the one question a CFO should be asking the cloud and security leaders?
Are you working together would be the big one at the end of the day, because I think the cloud and security leaders need to have the same sheet of music, and they have to have the same plan. When I find projects, in many instances, they're not. They're operating in silos. They may even have different profit centers that they're operating, cost centers that they're operating off of. The CFO says, "Listen, look, if you're going to provide the resilience and you're going to lower the risk for me to a reasonable level, I need you to be on the same page. I need you to be singing from the same sheet of music." And that often is something that doesn't occur.
I would tell them, and I would advise the CFOs and boards of directors, and I do that all the time, that you're going to need some sort of a master plan, and you figure out the roles and responsibilities for each of these individuals and each of the departments. But ultimately, there has to be synergy between them. I don't want to see separate paths for security, resilience, operations, all these sorts of things. They're systemic one to another. Architecture requires that you understand everything. I always tell my students, "You got to understand security, resilience. That has to be built into your architecture. Same thing with your planning." And it's something that I think many companies are missing right now.
They're seeing the importance of many of these systems and certainly the importance of some of the AI systems that they're building, and now they're getting into solid planning infrastructure.
I want to turn to what's next. Looking ahead a few years, how do you see cloud and AI evolving, and what changes for the teams who run them?
Yeah. I think that ultimately cloud and AI are going to be evolving together. They're coupled, one to another. If you look at what cloud is, it's become AI is going to be systemic to almost everything in the services. You can't separate them anymore. We used to have, I could say if we were working on a big public cloud provider or even a co-location provider, things like that, we could put AI in one bucket and data in another bucket, and even some of the application development stuff in another bucket. That's not there anymore. They're all synergistic one to another. I think it's going to be a good thing.
We're going to see more binding of these systems together where you can't tell where the AI stops and the coding begins, and the data begins, and the network begins, and the security and the resilience begin. They all have to basically be coupled and work together. Moving forward, as we're going to these different revolutions of cloud's basically in its 15th year right now as being something that we have to consider as an architectural option. It is going to be all about the use of these systems and the synergy of AI and how it really kind of touches everything. AI is going to be part of the entire infrastructure. It's part of operations, it's part of DevOps, it's part of security, it's part of governance, and basically that's where it's moving to.
So, centralized brain, centralized foundation model, centralized way of doing security, and the ability to store common best practices and services in ways that are going to be shareable amongst, not only people within your project, but people that are using the cloud provider. My ability to kind of touch a cloud provider and get their best practice in terms of how I am going to use these systems and how I am going to get the best performance out of them.
That makes a lot of sense. You are really speaking to the interconnectedness of the cloud data estate and the importance of having resilience across the entire platform. Give me one thing cloud leaders should do in the next 90 days and one thing security leaders should do.
In the next 90 days, they should, number one, figure out where FinOps works and how it is going to be deployed, and how it is related to security and how it is related to resiliency. In other words, I am always taken back by the fact that we are not putting numbers around resiliency and we are not putting numbers around security, because at the end of the day, risk is cost. I think the cloud leaders should really go off and figure out what that is, and the ability to kind of understand what the impact is going to be so we can have a business case for moving technology after it. It is extremely important. The FinOps stuff is widely understood, but very limited practice, and it needs to be built into the security and resilience infrastructure moving forward.
And for the security leaders, the ability to kind of look at some of the core systems they probably do not understand as much. There is the RAG systems for the AI stuff, the ability to look at the data dependencies, the ability to look at data training infrastructure, and the ability to kind of look at the things that are outside the AI model development stuff. That is where I find they kind of break down. In other words, they understand how to build and deploy and tune models because they come up typically from an AI engineering background. But ultimately, they need to look at security as something that is foundational to these systems. So, we are getting people that understand security and they are pushed into AI, and they need to understand the synergy between the two.
And that is something that I think they are not learning in getting their certifications and their education out there, and it is something I think more people need to teach. Security people understand how AI changes your models and how it is going to change your game, how it is going to change your responsibility, and how it is going to change your metrics in terms of how you are measured, and that is something that needs to go far and wide. Right now, we are living in a world where many people who understand security do not understand AI, and many people who understand AI do not understand security. That cannot exist any further. You have to have synergistic between those technologies. You have to have a core understanding. Learn that in the next 90 days. It does not even take 90 days.
David, what are you most optimistic about in the changes to cloud AI that impact cloud and security leaders?
I think I am most optimistic about the fact that I think everybody thinks and understands that strategic planning is the way to go. That was not a thing five years ago. People were not thinking strategically about leveraging resilience and security around their main systems. Now that AI is at play and the ability to have critical data systems are also at play, the ability to get those things lined up is a priority right now. People are spending their time talking to me and talking to other people about how to do strategy correctly.
It is something I worked on many years as a consultant, and the ability to kind of get this from the board of directors all the way down to the IT implementers to understand how security and resilience kind of work together and how strategically it fits within the systems, not only that they have, but the ones that they are building. So, we need to have a great strategic understanding of where we are going, not only in just a year, but what we are going in three years and five years, the infrastructure that we are going to need in play to make it happen. I think the long-term strategic understanding of where this technology is going and what needs to be put in place is what people are doing now, and I hope it continues.
Wise words for cloud and security leaders across the globe. David, thank you so much for your time and your insights today.
Thank you.
To everyone watching, thank you for spending the day with us. As you think about cloud resilience, start with one question: what does your business need back first to keep moving? That's your minimum viable business. Define it, protect it, and practice recovering it so you can move on AI with confidence. To see how resilience fits into your architecture, book a meeting with us and experience the Rubrik Cloud demo, or reach out to your Rubrik team to learn more. Thank you all, and take care.