Zero Trust Identity Resilience: Prevention or Remediation?

Thank you very much. Hello everyone. Really good to be here. Let's get right into it. Identity is now the attack perimeter, so we're gonna have to ask ourselves where are we focusing on prevention or on resilience. And I think I will need the clicker here. That's better. The World Economic Forum estimates the cost of cybercrime at 10 trillion US dollars as of the year 2025. That is really an unimaginably large number. That is 10 million millions, right? So if you want to break it down a little bit more, that's roughly 19 million dollars per minute.

And with that increased cost, economic cost of cybercrime, obviously cyber security budgets are increasing as well. At the same time we're seeing that these budgets are spent at roughly 75% more on the prevention side, leaving only roughly a quarter for remediation, resilience and recovery. But we need to keep in mind that attackers have to be only right once. We as defenders have to be right every single time. So there is really a massive shift in identity-based attacks. A CrowdStrike report from earlier this year shows some interesting numbers.

They estimate that about 82% of detections now are malware-free. So attackers aren't deploying malware, they're living off the land, they're leveraging identity-based attacks, right? So that really highlights and showcases as well that we need to shift our focus on that end as well. There have been some really high-profile identity-based breaches and I'm sure many of you have heard of these kind of breaches at Marks & Spencer in the UK, Jaguar, Land Rover and many others. And even more, of course, do not even hit the headlines at the end of the day, right?

And very often these attacks, they take weeks or even months to recover. And especially that comes in the light of a shift in the workplace after the last five to seven years with remote workers bringing their own device, etc. So we all understand that identity is really a crucial part of the organisation.

I mean, that's why we are all here this week, right? And we need to basically consider four different types of identity. We have the workforce, that is really the true tier zero, right? That has an immediate impact on the bottom line on business operations if those are impacted. The second one are the customer identities, the CIAM, right? This of course comes with high visibility. It is immediately apparent to your customers if those are impacted and often that also involves sensitive data that is potentially breached. The next one are non-human identities, right?

And we've heard some very interesting numbers this week at estimating how those outnumber the human identities, right? It's not just one to ten, one to hundred, sometimes even one to thousands that are really staggering numbers that we need to keep in mind in terms of how do we ensure those are secured and protected as well. And the last one then are of course agentic identities and that is a bit more difficult to really grasp and understand in an organisation because often there aren't specific AI identities, they might assume another identity.

The user that spins up an agent, they might just go ahead and give them their credentials or they might have a service account that they are leveraging, right? And if we look at the last 30 or 40 years in terms of operational recovery and cyber resilience, we can distill this evolution into three distinct phases that I want to talk about a little bit. So in the 90s, maybe even into the early 2000s, it was more about operational recovery, right? Maybe I as an admin fat fingered some database and I have to recover it. Maybe a user accidentally deleted or changed a file we need to recover.

And at these times we even had to still convince an organisation that they need to protect and back up their data in the first place. These were more high likelihood kind of scenarios, right? Deleting some files or other. But at the end of the day, let's be honest, those were more low impact in terms of what they caused. Then came the 2000s and the 10s, especially in the post 9-11 world as well, disaster recovery became really the paradigm that had to be implemented, right? So businesses understood the criticality of their technology.

It was more widespread in the workplace across all the different departments. So disaster recovery from the perspective of how do I actually secure my technology when I lose an entire rack or even an entire data centre? There's a hole in the ground. Maybe there was a water or fire damage kind of situation. And these are or were hopefully low likelihood kind of scenarios. But at the same time, if they did happen, those were highly impactful.

And then over the last five, maybe even 10 years with the rise of ransomware with cyber attacks and then more and more regulations coming into place, it has become increasingly difficult for organisations to really secure their estate with cloud, with now also AI, energetic AI that also the attackers obviously have access to. These kind of scenarios have become high likelihood and high impact.

And by the way, many of these tools and measures that are still being used across organisations today in terms of recovering, they were born and built throughout that middle age when it was all about disaster recovery, right? They didn't assume that an attacker is inside our environment. So from our perspective, really a new kind of approach is needed here.

So across hundreds of conversations that we had with organisations from difficult, different industries and sizes, what really was striking to us is that there is this clear imbalance in focus between preventative tooling and then really having a way to recover and to be resilient when the unfortunately inevitable attack happens. If I'm just going to use the car analogy, we all want our cars to be as secure as possible. We have preventative measures, we have ABS, we have traction control systems, we have emergency braking, right? All this kind of good stuff.

But at the same time, we understand that sooner or later the likelihood increases for us to actually be in an accident and we want our cars also to protect us when that accident happens, right? That's the resilience. We all wear seatbelts, hopefully. We all want our airbags, we want our crumple zones, right? And the same kind of principle we should apply to how we protect our environment. How do we actually bounce back from a successful attack?

If we look at the anatomy of a cyber attack, the threat actor might use social engineering to gain access to maybe a low-level employee with not a lot of permissions and they might then use this to gain additional permissions to maybe access a vulnerable service account. So these are very, very typical TTMs that we're seeing across the board here that are being used and abused. Only actually when the actor strikes, when there is an impact, that is sometimes even the first time we are noticing that, right?

Because maybe the prevention tools have not really caught on that there is an incident here. But what do we need in this case actually to be able to bounce back from such an identity-based attack? First of all, we need to understand what is the last clean recovery point that we can recover to? How far back in time do we have to go and how do we understand that from a forensics perspective, right? Do we have a way to do threat hunting and have all of this forensic information within our backups available, right?

Not just to look at what we have right now and maybe to go through the locks, but also having that available across the historical timeline at the end of the day here as well. Ultimately, the goal is obviously to go back to a clean recovery point and to prevent that reinfection in our recovery environment from happening. If we look at this from a timeline perspective here, this is often after we have this breach, after we see these breaches, this is a long and cross-functional effort to restore back to operations.

Just to use the Marks and Spencer example as well here, they have obviously prioritized in terms of what is most critical to their operations and their click and collect system, right? Where clients, customers could just order something online and then have it or pick it up in the storage themselves. That was offline for, if I'm not mistaken, 15 weeks, right? So that is a very, very visible economic impact for them as well. But we have to think about what actually do we need to do after a successful identity-based attack if our IDP is compromised.

Imagine having to rebuild hundreds of enterprise apps and the relationships and maybe even having to update third-party external applications with the app secrets, et cetera. Do you have a way to export those? Do you have documentation, scripting, et cetera to assist with that? But even then, I would imagine this is an effort across hundreds or even thousands of enterprise apps that will be measured in weeks and not hours and days. And then Active Directory itself is breached as well. I'm sure some of you have had the unfortunate chance to go through a forest recovery, even if that wasn't 2010.

I can tell you it's still the same process. It's still this very complex and lengthy process across 150 pages, I believe nowadays, is the Microsoft Handbook to guide you through this forest recovery process. That's what you have to do when you have to rebuild a new single source of truth to start from scratch if your AD itself is compromised, right? And then we have the added complexity when we are looking at a hybrid environment as well. How do we restitch those relationships between sync users, between cloud-specific attributes and relationships?

So what we're often faced here with is this kind of hot potato. We have to balance between RPO and RTO, so the recovery point objective, how far back do we have to go, and the recovery time objective. How long does it actually take to recover here? So we might decide to go for a clean recovery. We understand from different signals that the clean recovery point was three weeks in the past.

Okay, great, we have excluded the attacker, but now the problem that we are faced with is what happens with all the good changes that have happened within these weeks or even months when we have to go back to, right? What about your chain of processes, your joiners, movers, levers, employees who have since left the organisation, they will have their users again. New employees, their users won't exist, and anybody who has had changes in their permissions within this time frame will have the wrong permissions at the end of the day, right? So there is still a massive impact here.

If we go the other route and just decide, okay, we're going to restore from the latest snapshot that we have available, we're obviously at the risk of reintroducing the attacker. We might want to take measures to take them out, but often we're stuck in a loop of iterative restores until we find out how to properly exclude that attacker at the end of the day throughout this recovery process. So that's why we at Rubrik, we see a new way, a new approach to actually tackle this. We call that the role forward recovery, which combines best of both worlds, right, from an RPO and RTO perspective.

First of all, yes, we need to restore to a clean recovery point, right? We want to actually remove persistence. We don't want to run the risk of the attacker being in our IRE, for example, right? Let's go back to the example. We have to recover from something from three weeks ago. We understand, based on different signals, that that is before the attacker was in our environment. Great. But now what we're actually doing also is we are taking multiple signals to roll forward wanted changes.

So this could be, for example, based on a list of users that you provide, or this could be based on your HRIS data, right, in terms of who are actually the people who joined, who left, right? Your JML processes can be directly fed into that roll forward approach, so we will only roll forward these changes that are sanctioned, while at the same time, we will be able to ingest your signals from other sources like your ITDRs or from your SecOps teams, any compromised users, so we specifically exclude the changes that came from these affected users.

So what this gives you at the end of the day is really the combination of RPO and RTO in an optimal fashion while you're moving the persistence, right? The goal here really is to massively reduce that downtime that we can bounce back from from such an attack in the best way possible, and the great thing here is also that, and this is what we're often seeing as lacking in many organizations' tool set, is a way to properly test that approach end-to-end, right?

So your business continuity management can be properly tested, including your IDP, from the forest recovery, to entry ID, to the hybrid restitching, and all that kind of good stuff. So we have built this all on a zero-trust architectural platform that has been around for a long time. This is really the foundation of what we're doing, right? We were born in this new era where it's all about making sure that even if we assume that a breach can and unfortunately will often happen, our backup data is not impacted as well, right?

So if our threat model includes a potential AD breach, we cannot architect a solution that relies on Windows and AD-based authentication to perform that recovery, right? That is going to be breached as well. So instead what we have built, we have built completely logically air-gapped environments with our own proprietary file system that is append-only, so any new data will only be attached at the end. Nothing will ever be changed within the backup, so even a full admin within this platform will not be able to negatively impact your backup data.

This is really at the core of it how we ensure that you have 100% recoverability, right? And this is not just theory, this has been proven across thousands of customers and we actually have our own ransomware response team that guides customers throughout these ransomware cases and over the years we have seen and accompanied hundreds of different ransomware recoveries and not a single customer has lost data to a cyber attack that was protected with Rubrik. And built on that platform already we have provided tools to protect AD and EntroID for quite a long time with our identity recovery.

We have expanded that to go into the hybrid space, multi-IDP with AD, EntroID, Okta and more and then with identity resilience that is then really the full platform that provides you a way to have this posture management in terms of understanding what risks do I have in my IEM that I might proactively reduce any kind of misconfigurations or configuration drift with near real-time alerting in case of any of these unwanted changes that we can manually or automatically roll back, right?

Think of your classic GPO changes that are really really hard to track and then at the end of the day that also really includes that roll back and roll forward capability that is there to assist organizations with bouncing back from an identity-based attack. So yeah, that is it from me. Thank you very much. I'm looking forward to connect with all of you over the coming coffee break. Thank you very much. We have one question here. You argued that organizations need to think beyond prevention towards and going towards resilience and recovery.

In practice, what is the most common weakness that you see when organizations try to restore trusted identity operations after a major compromise? Yeah, really interesting question. So the big gap that we're often seeing in these conversations is that there is often a lack in a testable process. There might be single components that are properly tested, right? Maybe an isolated forest recovery test, but really this end-to-end test is often something that they don't have the capability to properly perform, right?

And if the board eventually comes and asks how long does it take for us to recover, they will not have a reply, right? Because they don't have the tool set to properly do that test and give an estimate.

Test, test, test. Once again for Søren Osterfeld.