Identity Threat Detection and Response is a big focus for me this year at the bank, forging a really important new partnership with our security operations center. I'm going to go into the importance of that in a little bit. Most everybody here has got IAM systems nailed down.
Now, most of you are also using MFA, hopefully non-phishable MFA. Some of you have even gotten way down the road on your zero-trust architecture. But increasingly, our attackers are also modernizing their attacks. They're increasingly also not, whereas they used to come in to drop malware somewhere, and that was going to be the way to get in.
Now, they're using legitimate identities that they've stolen. They're using tokens that they've stolen. They're using trusted access paths to leverage those on.
So, it requires us to come up with new ways to try and detect those, and more importantly, to isolate those incidents and box those threats in as quickly as possible. I'm also going to give you a warning. Most of my presentations in the past have involved AI-generated Dungeons & Dragons images that represent metaphors for, in this case, a group of people from disparate departments who are all trying to figure out how to keep all the monsters at bay in the background. But that's not this deck.
This deck, I found out you can also use AI to feed it a giant Word document full of bullet points and tell it to put them into really pretty slides. So, if I ever want to start my own company, I now have vendor slides that I can use. My big thesis for this entire presentation is that ITDR is not just a security tool, despite what everybody outside these doors is going to tell you. It's an operational layer that you need to build and you need to enact within your own organizations.
You've got IAM systems that are producing telemetry from your IAM systems, that are authenticating users, that are assigning roles, that are enacting policy, and you've got identity defense, where you're trying to protect all of these accounts and everything. In the middle is this new ITDR operational layer. An ITDR that's going to take all of that telemetry information, it's going to correlate the information, it's going to analyze it to detect anomalies, it's going to contextualize that story, and then it's going to respond by trying to come up with actions to contain those threats.
I've had the honor of working with, for a number of years, Daniel Hedrick, who some of you might remember at the 2012 Cloud Identity Summit actually coined the term, identity is the new perimeter. But what even is a perimeter now in our organizations? Identity is certainly now the primary attack surface. Speed of detection is the new perimeter. It doesn't roll off the tongue. I'm workshopping it. Why IAM alone isn't enough anymore?
Again, attackers are increasingly leveraging legitimate identities through credential theft, through token replay, through MFA, fatigue, OAuth, token abuse. When we introduced MFA, MFA certainly caused attackers to change their tactics, but it didn't cause attackers to change what they were after. Now they're using different sources, again, like MFA fatigue, like man-in-the-middle attacks. Tokens and federated trust are now ways to keep those sessions alive.
Now attackers, if you can get past the authentication event, if you can get past MFA, you now have additional ways that you can keep what is now a valid session alive, and you can exploit what we've always considered to be a trusted access path into the organization. And while you may be introducing successfully zero-trust protocols, that's really reducing your blast radius. It's not identifying misuse. The biggest thing about this is you can't fight what you can't see, and identity threat detection and response is the way that we're going to try and save it.
So let's look at a modern identity, some of these modern identity attack paths. So MFA fatigue, it's literally attackers overwhelming users with push requests, push requests after push requests, hoping that they accidentally accept one, or just through sheer, I'm tired of hearing it, will accept it. Stolen tokens now bypass traditional authentication events. You can bypass your MFA challenge if you can get hold of a token. Session hijacking, much the same thing, steal the cookie, gain authenticated trust.
Conditional access bypassing, if somebody is able to get to your conditional access policy rules, they can look for gaps in those rules that will allow them to come in, or find ways to exploit your traditional endpoint definitions. And then privilege escalation chaining, once you've gotten an identity in place, use kind of traditional hacking privilege escalation channels to either exploit overprivileged identities that you've got, or to just high-impact privilege abuse. So what does real identity threat detection and response look like?
Again, the first thing we're going to need to do is we're going to correlate our IAM, our EDR, our SIM, our cloud stuff. We're going to pull all those signals in. We're going to put them into an ITDR platform. This is where we're going to ingest the information. We're going to correlate and analyze it. We're going to detect the anomalies and prioritize risk. And why are we doing this? We want to do this because we want to partner with our security operations center. And you're going to hear this about 15 times as we go through this presentation.
Security operations center is going to become your best friends. They're going to become equal partners to you in this effort. Your success will be their success. What the SOC brings to this is their tradition of being able to collect playbooks and things to respond to anomalies and threats like this. But they don't always have, if they have identity information, it's usually, well, we've got independent logs from this IAM system and this IAM system and this IAM system. They're not correlated. They're not pulled together to define entire event chains.
And the purpose of all of this is to focus on containment speed. Our goal is to make sure that we can very quickly detect before we've had an incident, that we contain it before it's allowed to spread, and that we remediate it and get things back to a working condition as quickly as possible. So let's talk about what some of those ITDR telemetry things are. Because the most important thing to get out of this slide is your ability to have quality detection and speedy detection and speedy containment is entirely based on the quality and the correlation of your IAM telemetry.
So I'm not going to read all the bullet points, but it comes down to something like wherever you're doing your authentication or role assignments, could be Entra, ID and Active Directory logs, your endpoint EDR telemetry, I can't even read that, it's purple on black. Your correlation from your SIEM, which creates a lot of cross-source visibility. Your conditional access events, which provide policy and risk. And PAM activity to give you insight into all your privilege.
Access information and then cloud API activity, which can help unearth activity that's going on with service principles that sometimes fall through the crack. But again, the whole point of it is to be able to use all of these things to respond faster. Let's look at one such detection event. Now that we're correlating all of these events together, we can start to create timelines of attacks. Let's look at this one. A user signs in from Seattle at 9.02. A couple minutes later, they get 10 MFA push requests that are sent with no approval.
We see just after that a sign-in attempt from an unknown device. And then 12 sign-in attempts within 90 seconds after that. We generated a brisk score. We got all this because we were able to correlate information from a number of different indicators. We got repeated push requests from MFA. We were able to define a geographic mismatch between the two sign-ins, a device mismatch, and abnormal sign-in velocity.
All of that allowed us to generate a risk score that was based on new location, MFA fatigue, unfamiliar device, high velocity, and allowed us to generate, because we had playbooks already in place, a response to quickly revoke the session, do a conditional access lockout on the user, forcing them to MFA authenticate again and do an out-of-band verification to confirm their legitimacy. You can also put in other things, too. It's like maybe it's serious enough that you have to put in a more rigorous physical review of the user activity before you. Go ahead. Another one.
Here's one for token replay. 10.02, someone signs in successfully from New York. They get an access token issued, perfectly valid, for an hour. About 40 minutes later, the same token is used from Singapore. And then your ITTR system detects that token replay anomaly. So we were able to get the token reuse across endpoints, define impossible travel patterns, and there was a device fingerprint mismatch between the two.
Again, high confidence that something terrible is happening, responses from the playbook, all of these automated, immediately invalidate the token, force re-authentication of the user via MFA, and isolate the endpoint that we didn't understand from Singapore. So here's kind of what the reference architecture looks like for ITTR. You've got your data sources, IAM, EDR, sim, cloud, and behavioral analytics also. All of those feed into our detection logic, whose goal is to start generating risk scores and context out of those events.
Again, with the SOC, your partners, the SOC is going to have their triage and investigation, usually built on the standards that they've already been using for work that they've been doing in the past years, all of which to do automated containment using any of the things that we've been talking about. So how do you do it? Fortunately for us, you can start small and work yourself big. The biggest enemy of getting this done is to feel like you have to get everything done at the same time. Start picking certain events.
The biggest benefit that you can do, the biggest thing that's going to have the biggest bang for the buck, is going in and inventorying where all your identities and entitlements and IAM actions are, because I guarantee you, you've already got them. They're just probably in silos that are all over the place.
Maybe this means creating, like we did, a data lake, a security data lake, where we collected all of these, normalized them all, put them all into one place, so that we can move on to level two, which was to start correlating those and be able to detect attacks in real time and start to reduce the noise, because the first thing we did was detect attacks everywhere, and they weren't really, but our thresholds were so low, we were so excited finding anything. That's a process that, again, your SOC is going to help you with.
Level two and level three, these are things you do with your SOC, because, again, they've got the experience in setting those types of thresholds, and a lot of the better experience with that wheat from the chaff thing. You're going to start to build your automated playbooks for how you're going to deal with, not just the response to communicating about the alert, but what you're going to do to automated actions to contain. Then level four is resilience.
Resilience is constantly going back through, taking all of those policy rules that you're setting up, constantly going through and running them through additional simulations with new information that you've been able to gather, building new thresholds, and putting it all back into place again. ITDR maturity, your operational maturity, it's a journey. It's a journey from visibility to resilience. The SOC that we've talked about, here's, again, all the things that the SOC brings with them. Identity-focused detection engineering, really good at mapping out identity attack paths.
Turns out this is something our red team has been doing for quite a while, but they hadn't been doing it with our information. So that was a big win with something that already existed. Identity incident response playbooks, this is kind of the most complicated piece of it. This is what we're working through right now. Threat hunting, this has been particularly valuable for us in finding dormant privileged access accounts.
And then, of course, one of the biggest things is the automated response. How do we automatically contain? So I don't know everything about this, but here are the lessons that we learned. Your identity telemetry is fragmented, but it's not that it doesn't exist. You just need to bring it together. Detection logic matters more than tooling. I don't care which tool detects it. The more important thing is tuning that logic to reduce noise and false positives and get that context, that baseline down. The SOC and IAM teams have to converge.
And if you don't take anything away from this presentation other than this, the SOC has to be, you have to be equal partners in this. It's no longer we have events and we hand them off to the SOC, and the SOC does their monitoring and logging. We are hand-in-hand in this now, and our success is their success. Fast containment beats perfect prevention. Contain first, triage everything later. I did want to give a shout-out to the OIDF shared signals. We have the co-chair here with us.
One of the biggest operational problems that we have in IDTR is that those signals are inconsistent across platforms, just like our identity stuff is fragmented. The shared signals framework is a boon to anybody who's trying to sanitize, not sanitize, to make sane the chaos of what exists in that signal framework. So the OpenID Foundation is doing God's work in that. Yay! They put together an ITTR program that is saving the castle. I have two seconds for questions. No? Good. All right. Thanks so much. Our next speaker hasn't arrived, so we have got more time. We've got time for questions.
We can go in yet. Many organizations already collect large volumes of identity telemetry, yet they still struggle to detect real attacks. In your experience, what separates organizations that achieve actionable ITDR and those that remain stuck at identity visibility? It's not easy, but it is absolutely that correlation event where you have to go through.
We actually incorporated the use of our data scientists that exist in other parts of our company to help bring them in to help us normalize that data, and they were the ones that actually designed and built our security data lake that we populate, and also were our partners in the feeds and the transformation of that data as it goes into the data lake. Okay. I was going to say, if you guys are having just concentrate.
Steve, stop talking. If zero-trust controls often fail to detect subtle identity misuse, where do you see the biggest gaps in current zero-trust implementations when it comes to identity-based attacks? I don't think asking zero-trust to identify identity misuse is really using the wrong tool for what you're trying to do. The whole point of zero-trust is to use identity more as a traditional network parameter rather than a secure, anomalous security activity tool.
It can do a really good job of applying identity policy to whether you're allowed to get into certain enclaves within your group, but it's not designed to say, oh, did it get this identity from a legitimate source? And a lot of times, it bypasses the zero-trust because it stole a token or it stole a session, and it's like, oh, I've already authenticated. I don't need to authenticate again. Your zero-trust, if you've got it in the cloud or something, will go, oh, sorry, I didn't see.
Yeah, you're good. Go ahead.
