Thank you all for coming. I'm going to talk a bit today about how to actually apply Zero Trust for identity elements of your organization. I'm going to do this in three stages. I like to break this down. The first one is going to be foundation. We're going to talk a little bit about today's cyber attacks, not a lot, and then a bit about the Zero Trust principles as they apply to IAM. Second part is the main part, talking about application, how we actually apply each principle by using the right solutions to apply Zero Trust across our organization.
And the last part, aiming for excellence, is about the anatomy of an identity attack and how those solutions fit into that. And hopefully, maybe talking a little bit about the AI-enabled future. I have to say, I thought I had 30 minutes when I planned this session, but it turns out I only have 20, so we'll see how fast I can go. Let's go. Starting from the very basic foundation, we want to talk right now about how identity attacks look and then about the Zero Trust basics. Lots of statistics. Identity attacks are scary. Who here doesn't know that? No raised hands.
I'm going to guess you guys know about this, so I'll move forward. Basic five principles of Zero Trust. And you know, everybody has a different definition for principles of Zero Trust. I picked my favorite one, as it applies also to identity.
So first, always verify. Never automatically grant access. And when you think about identity, a lot of times, always verify is assumed to be do an authentication action and risk-based authentication before you grant somebody access. But I actually say this is not enough. We're identity practitioners. We should do this at the point of elevated privileges, at the point of action, not just at the point of entering a system, not at the front door only. So this is how I view always verify.
Second, least privilege. Least privilege is sort of obvious. Any grant should be done, although, with the minimal privilege possible. So that means in a lot of senses, do it just in time, not just standing privileges that are bigger than what we actually need. Third principle, assume breach. Always assume the attacker has some foothold in your environment. That means that they already compromised some account in your organization. They might even be on the computer the person is connecting from. You never know. Assume the worst as you're designing your solutions.
Fourth principle, continuous monitoring. Always monitor. Reassess trust all the time. Never grant and forget, going back to the point on the first principle because they overlap. And lastly, segmentation and isolation. Segment the environment as much as you can. And when it comes to identity, it's hard. Segmentation and isolation, they are concepts that come from the network aspects of zero trust. When we think about identity, we want to segment the access to sensitive resources.
We want to broker the access in order to actually create segmentation to a certain extent between different environments in our organization. So that was my very, very quick overview. I hope it went well so far. Let's talk about applications now for each of these principles. So starting with always verify.
As I said, always verify is about never automatically granting access, but actually checking signals like the identity information, the device, the risk, the context, and the behavior. How does it actually map to real solutions we can use? So there is always table stakes, right? We need to get SSO with risk-based access control. Nobody is arguing that. But where is the next step from there, right? Because this is just the least that you can do. You want to vault or control the elevation of privileges in your environments. Use a PAM solution that allows to actually control that.
You want risk-based not authentication, authorization. The risk needs to be assessed at the moment a user or an entity in your environment, maybe a non-human identity, is elevating privileges. This is really important and mostly neglected.
Third, MFA everywhere. It's not just a buzzword. The previous panel talked a lot about passkeys, and this is definitely important. But we also need the points of checking, right? Everywhere.
And next, this is what's really coming to our industry and what's going to really change it, in my opinion, AI authorization agents. This means we get AI agents that do the work that we would like a human to actually review at the moment of authorizing access. So when we talk about risk-based authorization, this is the next generation of it already. We haven't yet implemented it, but funnily enough, it's easier to implement an AI-based authorization than it is to implement risk-based authorization. So I really encourage you to research this area.
This is something that is really going, in my opinion, to change the way Zero Trust works in our industry. And lastly, for your non-human stuff, Spire and Spiffy definitely are the way to go. Second principle, least privilege. When it comes to least privilege, any grant should be done with the minimal privilege possible. What does it actually mean in solutions in our industry? First of all, it means just-in-time, right? You want to do just-in-time to ensure that the standing privileges are not there.
Second, just enough privilege. When we think about scheme solutions, we want to do rightsizing by use. Not rightsizing, hey, I did my best to reduce the privilege. Rightsizing that is derived from monitoring the way the users actually use these credentials and adjusting the role to minimize them to the way it's actually required.
Third, endpoint admin removal, obvious, but still very important. And application control on the endpoint is the last one in this area. And obviously there are table stakes, but the table stakes are important. Everybody should not use administrative accounts for day-to-day work, what's called the dash A accounts. Conditional access to applications in SSO, definitely required. The most basic least privilege controls that you can have are the table stakes. All of you should have them, but those are never enough. They are certainly not enough.
This is not enough to sleep well at night, from my perspective. Third principle, assume breach. Assume that attackers are already within the perimeter. You should assume that authentication, in this case, is compromised. When you think about identity, this is the tool to assume breach. Assume breach is not somebody is in my network. Somebody is in my network is if you're thinking about network zero trust. If you're thinking about zero trust in identity, somebody has already breached authentication. They have a working credential. And you need to rely on authorization control at this point.
What does it actually mean? It means automated key rotation. The key might be leaking. The password might be leaking. It has to be continuously rotated. This is an assumption that it's probably compromised. You need short-lived credentials. The credential might leak. We want to actually ensure that it's not still persistently usable.
You want, again, the authorization agents that will validate every access. A human can't validate at speed, but an AI could. And lastly, the table stakes. You have to have the audit trail in case something actually went wrong. Fourth principle, continuous monitoring. It talks about reassessing trust all the time. Never grant and forget. This is the base principle. What does it actually mean? It means we want to have privileged session recording, because we want to actually have those sessions reviewed and audited.
It means we want to have automated discovery of permissions, because permissions could be granted at any point, at any place. And we have to have this monitoring that tells us, hey, new permissions or new administrators or privileged identities popped up in our environment. We have to have identity threat detection and response, obviously, on the cloud and on the endpoint. And this is one of the blind spots that I see a lot. There is sort of an assumption ITDR is only for endpoints.
No, your companies almost certainly have a cloud footprint. You're using SaaS solutions. You might use identity providers in the cloud. You certainly have probably some cloud service provider, like AWS, Azure, or GCP in use. All of those also need to be monitored for identity threats. So ITDR is not just for your endpoint environment.
Kim, cloud, creates also good Kim solutions, create also cloud activity audit trail. This is really important for the continuous monitoring. It creates an audit trail of the continuous monitoring of all activities across these environments.
Next, automated AI session analysis. This is where solutions are going. We all know session recordings are not something that you actually review, right? By a raise of hands for a minute, who here thinks that 50% of the recordings in this company are reviewed? 20%? Anybody? 10%? Down to 5%? 5%? I got some votes. So this is my point. It's not possible to review session recordings at scale. What is possible is to let AI review it and flag it for you. And with the current advancements in AI, it's actually possible. There are solutions out there for my company, for others.
I highly recommend you research that. Because there is a lot of value to actually have this review happening, and raise to a human when required. Table stakes, obviously, log streaming to the sim, to the security environment. Last principle, segmentation and isolation. This is about segmenting sensitive resources and brokering access via audited channels. What does it actually mean when we want to implement this in our company? It means that we have privileged remote access for, for example, contractors.
It means that we organize properly the data and permissions to create segmentation between different environments. Usually it requires some data tagging or data classification to actually be able to do this. We want to vault and control sessions from the vault. We want to do access pass mapping, which allows us to understand the access passes and then ensure that we created the right segmentation. This is what we get with Keem Solutions and ITDR solutions that provide these nice graphs that show us the access passes. This is the true value of those graphs.
And obviously there is the table stakes. Do the network segmentation you need to do to split between the environments.
Do proper, not even, this is an old version of the slides, not RBAC. Any type of access control, right? Attribute-based access control, role-based, relationship-based, I don't care, policy-based, whichever one you actually like. Designing it right is just the most basic level of segmentation and isolation in identity-based zero trust. We're getting to the last part and we're still meeting the time.
Okay, so let's talk a little bit about the anatomy of a real identity attack. True story, this is what happened to MGM. So the MGM attack started with credential staffing. The attackers basically went online, found working credentials. Which maps to what? Assume breach, right? MGM should have assumed that this could happen to it from the get-go. And once the attackers actually found those credentials, they started trying different credentials for people from the IT department in MGM. And they found a set that worked on Okta. They were blocked by the MFA control, which is good, right?
Because MGM actually implemented this right. What MGM didn't do is have ITDR. So they couldn't actually know that somebody is trying to do a credential staffing attack, and therefore they didn't respond to the successful staffing that was blocked by MFA. Which is bad, right? Because we need this continuous monitoring and flexible trust based on the actual behavior. What happened then is that the attackers used probably a voice deepfake to convince the tech support to reset the MFA for that account. And once they did that, they got in. They got into Okta.
Now, this attack cost MGM more than $100 million. It's publicly documented, so it's not nice, right?
In Okta, there was again a problem of monitoring and controls. The user used the same basic account also as his admin account. So when it was compromised, they were in as an admin in Okta. And this admin could actually do something. They thought it was not a very strong admin account. But in Okta, almost every admin account can escalate into super admin under certain conditions. And in this particular case, they did it by doing what's called trust abuse.
They created another Okta tenant that is supposedly upstream and connected to it, and so it reconnected as a super admin by breaching basically the authentication mechanism. To my point earlier, you can't assume the authentication is working well all the time. Once they were in, from Okta, they could authenticate as anyone. So they basically authenticated as the global admin for the Azure Cloud, the super admin for Active Directory, and then they got greedy. The attackers installed password-sniffing malware to actually sniff the clear-text passwords of all employees in MGM.
That was their first mistake because up to now, they didn't have any physical footprint in MGM environment except through the cloud. And because they didn't have this physical footprint in MGM environment, they were almost invisible because MGM didn't have ITDR or Kim or any other form of monitoring that could have detected them. This was actually detected, and then MGM tried to get them out of the systems, ran some requests, they crashed the systems to the point people couldn't use elevators in MGM resorts in Las Vegas. They couldn't go into rooms.
That was the actual situation at the end of this attack until MGM actually recovered from it, which took quite a lot of time. So this is a true story, as they say, and the lesson here is that we should actually be careful. Last point, we are heading, and I said this before during my talk, into an AI-enabled future. That actually means we can actually have changes in things that we could not do before. We could not have a human review every request to elevate privileges, but we can have an AI simulating the behavior of a human.
Maybe not the best human, maybe just an average capability human, but reviewing every request now. And we can do the same on session recordings. Maybe not the best person at reviewing session recordings. Maybe the AI is not as good as I am, but hopefully it's still much better than not reviewing those at all. Those solutions are out there. They are not dreams, they are not mystics, they might not be perfect yet, but they are definitely better than not having them. So this is the end of my lecture, more or less. We can talk about how each of those principles maps.
This is sort of what I said earlier, but I'm about to run out of time, so if you want, take a picture. If you don't, don't. And if you have any questions, I have 30 seconds.
Yes, are there any questions you want to ask? All right, nobody. I think it's lunchtime. Everybody's hungry, so enjoy your lunch. Thank you very much.
