The Real Reason Attackers Love Your Identity Stack

Welcome to our KuppingerCole Analysts webinar, The Real Reason Attackers Love Your Identity Stack. This webinar is supported by BeyondTrust and the speakers today are Morey Haber, who is Chief Security Advisor at BeyondTrust, and me, Martin Kuppinger, I'm Principal Analyst at KuppingerCole Analysts. So we'll touch quite a number of topics and the flow of this webinar will be a bit uncommon for the webinars we usually do at KuppingerCole Analysts. So after a quick intro of both Morey and me, and I think an initial poll, Morey will start this time with his thoughts.

I will add some perspectives from the analysts, and then we will go more into a fireside chat. And during the fireside chat, we also will pick up your questions. So that's something I'll touch in a minute, but it gives you a great opportunity to raise your questions at any time. And with that, I go back to the deck. So having said this, a little bit of housekeeping. Audio control, you're muted centrally, we will run two polls. There will be a Q&A session, but in this case, given that it's a fireside chat, we will include your questions during the fireside chat.

And it's usually more questions you send in, more likely this entire conversation will be a great opportunity to ask Morey and me things you'd like to ask us. So by the way, when do you then go into the questions in which you find the lower right side of the window, you also have the option to upload questions, which helps us then to focus on the ones that are of interest to the most of you and the largest share in the audience. We are recording the webinar. We'll make also the slide deck available shortly after the webinar. So as I've said, the structure is a little different.

So it will be the intros of Morey and me, or me and Morey in this case. And that was beyond trust, but take this order, otherwise I would have been the second one being provided.

Anyway, then Morey will talk a bit about the identity risk landscape, detect vectors, risk surface. I'll bring in this perspective. And that's all the what's next, which is the main part of this webinar. Before we start, we already want to launch the first poll.

So, and when we look at identity-based attempts and ITDR, Identity Threat Detection Response, it's definitely one of these capabilities that is of significant interest and relevance. So what we are curious is what your organization plans for ITDR, did you already deploy something? Is it in an implementation process? Are you considering it or planning for it? Or don't you have any plans yet? And you will find a poll as well, like the questions area. There's an icon at the lower right edge of the screen where you'll find that. So take your time. We'll leave the poll open for a while.

And in the meantime, we go ahead. So quick intro of mine. I'll keep it very short. I think many of you have met, have seen me before. I'm one of the founders of principle, of career co-analysts and acting as a principle analyst, focusing on research. I'm in the space about entity management since the late 80s, starting with early network and Microsoft Land Manager, working also, having had some insight into Banyan wines for the ones who are long enough. You still know it, back in these days. So I'm really early around for a very long time. And with that, I think I hand over to Maury.

Maury, maybe you introduce yourself. Thank you, Martin, for the introductions. And it's a pleasure to speak to everyone today. My name is Maury Haber, for those of you that I have not met. I'm the Chief Security Advisor here at BeyondTrust. I don't have Martin's tenure, but I have been working in the cybersecurity industry for well over 20 years. And I'm the former CTO and CISO for BeyondTrust.

In my current role, I operate as a forward-facing partner for the organization, helping people understand privilege access management and identity security, and the challenges with modern identity threats. I'm also an author of seven books. The next book will be out in the middle of October called, Attack Vectors, A History of Cybersecurity. And it goes back to the last 40 and 50 years, documenting how we got to where we are today in terms of cybersecurity and the tooling we use.

The other books are also under the Attack Vector series, covering identity asset privileges and the cloud, and also contributing author to the great power competition written out of the University of South Florida. So it's a pleasure speaking to everyone. And Martin, let's dive right in.

Yeah, so at least I have the advantage that I don't need to put myself under pressure of writing new books because I'm still some 40 plus books ahead of you. That is true, that is true. I got a long way to go to get to 50.

Yeah, but maybe one day I come up with a new book or so. I still have it in my mind. So let's wait and see.

Okay, Identity Risk Landscape. Identity Risk Landscape, this is about attack vectors and risk surface. And this is your part, Maury. So you just say next slide when I should move to the next slide. So Martin and I want to present to you some of the risks around identity and identity infrastructure. We both have perspectives on this. In my perspective here, it comes from a book that was coauthored by Darren Rowles called Identity Attack Vectors. And what we represent is that your organization has an identity and access management foundation, a house. That's the top of the graph.

You have a front door where employees and contractors, vendors, customers, partners, anybody can come in and out. And there are certain things that you can see through the windows. This is a pure analogy to your websites, services that you provide, customer portals, you name it. Underneath it, you have various stakeholders that own the business requirements on the left-hand side. You have the business requirements. You have technology partners.

And then you have the tooling itself, which Martin explains later in great detail, covering everything around identity and access management that needs an ITDR solution to keep an eye on. Now, you may say this house, it only applies to employees. It really doesn't apply to other parts of the organization. And that's not necessarily true. Depending on your vertical, let's just say hospitality, the hotel industry, you will have privileged access management not only among your employees and contractors, but also your clients.

And people don't normally think of it this way, but all of the items on the bottom bar, from governance to access management to single sign-on, actually do apply. In the case of privileged access management, these could be customers that have status, platinum, A+, whatever the hospitality industry says that you are an elite user. That means that you may have privileges to get into a lounge. You may have privileges to use certain functions within the hotel, like getting breakfast for free.

When you think about it from that context, it's really a role that has more entitlements than the standard person that is staying there. And that's technically some form of privileged access.

So as we think about your organization, your house for identity and access management and all the capabilities that you have from single sign-on to MFA to various forms of access management, the security of all those tools plumbed together in your house is what's so attractive to threat actors because they can go after one discipline or another, or they can go after the entire workflow of how someone authenticates, how they access, what privileges they have, what they do, et cetera. Now, all that plumbing together creates an identity fabric. Next slide, please.

And if we consider, if we consider all of the different tooling that you have out there, you're going to find that you have a variety of systems that are managed by some, others being plumbed in together to a SIM, some doing privileged access management on the identity plane, some providing the actual identity providers, single sign-on, what you may be using in the cloud, and then even old school, as jokingly as it sounds, the servers that you would still have on-premise. So how do you keep an eye on all of that identity fabric and plumbing? Next slide, please.

You can have spot solutions that cover one piece or another, but really what you need to do is go look at all of it and say, you know what? I detect something in real-time happening in this entire workflow, or I would need to see that an admin logged in without MFA.

You need something that's going to cover that entire landscape, that entire identity fabric, and provide you real-time alerts based on known attack vectors or symptoms that may be a little bit odder, behavioral, something that AI can do, like seeing if a human is behaving as a machine or a machine account, machine identity, is behaving more like a human. And it's got to be able to talk to everything and plumb together.

And those are really what identity-based attack vectors are is that real looking at all of the things you have deployed in your estate and determining what's at risk and what's not and giving a score. Next slide, please. But it's not just about what comes apart in terms of what the real-time detections, it's actually the risk surface itself. Where are their configuration anomalies in any of the tooling that's out there? Where are things not put in place correctly?

Where is an account left over from an old proof of concept or a cloud environment that somehow got promoted from being the test environment to production because that's what was needed? You can think of this as almost like a vulnerability assessment for your identity hygiene. That house model talking to every component that's in there, almost like a cloud service posture management for identity and telling you this is wrong, this is misconfigured, here are your entry points and your potentially paths to privileged access that a threat actor could use. Next slide, please.

And what this builds is actually that path. When you think about the real-time access, when you think about configuration anomalies, that assessment, you'll tie it all back to an identity that has multiple accounts. They have entitlements, memberships in group, permissions to do certain things, rights in other places. That's the definition of an entitlement. And that if any one of those is abused, someone could move laterally through the identity infrastructure, through that fabric and gain high privileges, root, domain admin, or something else that could be leveraged against the organization.

So when you think about that house model that I just talked about, the hygiene issues from a vulnerability type of assessment, the real-time activity, and you build a map like this, we really find ways that identity is very favorable for attacks to threat actors because it's so much easier for them to log in than hack in. If they can get initial entry and determine this passive privilege, then it's real attractive for a threat actor to compromise your entire identity estate. Next slide, please. Yeah. And the next slide at the end is already our agenda slide.

So thank you for the introduction, Murray. And I definitely will come back to your final slide when we dive into the fireside chat. So when I look at our perspective, and so Murray, you already brought up the term identity fabric. That is something we brought up at Kubernetes Core Analysts several years ago right now. As a concept that there's really a paradigm for sort of constructing it. And I think what is very important is, yes, it covers all types of identities. And when we came first up, is that I think there are two drivers.

The one was stepping a bit back and thinking about what is the job of identity management or identity access management. At the end, the job is to provide seamless yet secure access for everyone and everything to every resource system whenever it's needed. And only then. I think that that is the one thing. And we thought about what are the capabilities needed, how to map them into services, which tools are needed. And this is very specific. There are generic elements in that and there are specific elements who tailor it to the customer.

The other element is, that was the age of Azure when the first B2B identity management came up. And one of the things we thought about is, does it really make sense to have an identity management, a specific one for everything? So then whenever, when you go further down, okay, there's the non-human part, which again consists of many different elements, but it makes it over time a bit complex. And a lot of these things are, the capabilities you need are always the same. So we thought about how can you sort of build something where capabilities can be reused, but are well orchestrated.

So fabric in the sense of it produces and delivers services as a factory in that term of the meaning, as well as a mesh, which brings together the things. And I think that plays a role, but it also makes very clear that all these different elements of identity are related and it becomes even more clear. And so you brought up in your picture quite a number of elements for identity management. This is our identity management reference architecture. And there's quite some research available around that, which goes much more in detail.

And there are many building blocks and this doesn't stand still. So we've updated it early 2025 and there are definitely already one or two or three new types of technologies. We also sometimes retire some, but there are many, many different technologies and many, many different entry points for our attackers and attack vectors. And that is also the point where I, why I believe, because I, why I believe we really need something that helps in understanding what is really going on, where we can collect all that information from different services, from SAS applications, from the IAM.

So the Identity Fabric Services, the entire sort of core infrastructure around intra-IDM, AD, but also connects to these tools like SEAM, SOAR, XDR. And ITDR is at the end, a specific component. And I think it's very important to understand that ITDR is really different from traditional, whatever, EPDR, XDR stuff, because it has an identity context. It has some context of entitlement, of identities of accounts, of how this is used, access is used. So there's really a different context and meaning and looking at also the user behavior.

Okay, you could say cynically, ITDR is just a nice name for UBA because go to Germany Teleworkers Council, we introduce user behavior analytics and they will start shouting at you. If you say we do this great thing of ITDR, we detect identity-based threats, it's a much more positive story you tell now, but it goes beyond that. And it's a very important thing. So we need to understand it on one hand as broader, an element of a broader detect response posture, but also something that is really specific to the identity analytics side of things.

And this is, I think what we were right now, what we want to discuss. But before we really go into the fire side chat, I just want to quickly raise the second poll. So the question is then in this case, how should ITDR be implemented? Is it something which comes with your standard IAM tools or part of XDR or SOAR security operations and automation response? Something really standalone or is it a feature of attack surface management?

Again, the poll is open. You'll find it in the area of polls, lower right side. Have a look at it and looking forward to your responses. Aside of that, I think the first question already came in. So take your time right now to also think about what you want to ask us while we move into the fire side chat.

And so, Morya, I think there are many things we can discuss around identity-based attacks and why attackers love the identity stack. But maybe it's a good idea to, and you surely have a bit of data or sort of rough data, at least on IAM. Why is it so important to look at identity as sort of maybe the key thing when it comes to attacks?

Yeah, Martin, it's become an interesting change in the landscape. There are multiple reports out there, everything from Verizon to Sentinel One that cite that 90% of all attacks in the last year to two years have an identity-based component. And if you go back prior to three or four years ago, all of the tooling, almost all of the tooling we use is very much asset-based. If you think about AD structures or anything else, you manage the asset, you manage the user. We have ADR, we have firewalls, we're talking about communications. We're always focusing on that asset and resource approach.

But the user component is where we're starting to find the problems. Over-persuasioning, technical debt, sprawl in the cloud, all of these different things across everything that you broke out in the identity fabric, much more detailed than with the house analogy we use. Where can a threat actor find an entry point? Is it just the stolen credentials? Is it just the dark web? Is it an MFA attack? Is it a deep fake attack? All the flaws that we have in the fabric and that plumbing.

And that's why it's become so important today with the statistics like that 90% to monitor identities, hygiene, usage, appropriate behavior to ensure they are not your attack vector. Yeah, and I think it's also interesting to see that there are new types of attacks than emerging like session height checking. But when you look at session height checking, then basically it's about obtaining identity related information. In this case, sometime or frequently about more something non-human.

So, and using a GAM information like that for the attack. So, when we look at things like the entire sort of, it's a difficult term. I don't want to go into this non-human identity versus machine identity or circum conversation. That's a different thing. But at the end of the day, it means there are more identities and these identities also have secrets. They have entitlements. And they are also part of the attack chain.

Like, I think when we go back a bit in the past and still existing, sure. In privileged access management, all the functional technical system service, whatever accounts were the same.

So, it is not that we just must think about the password and the username of a human. Identity based is bigger. It's so much bigger. And it brings up an interesting problem that I believe you probably see as well. Most organizations think account, account, account. And now they're starting to think identity, but they've made them synonyms versus really understanding the definition. An identity can be you or me. It could be a machine. It could be agentic. There's lots of different forms of identities, but you have multiple accounts.

And that's the relationship that we're failing to understand as an attack vector. We're failing to understand that you and me have accounts here. We have our personal accounts, et cetera. We've all been told not to reuse passwords across all of those accounts. But what are the other hygiene risks and attack vectors that could be used? Yeah. By the way, when you bring up this, I really like that. And you brought it up in a better readable form in your slide before, this identity graph, where you talk about identity to account, to entitlement, and then to the resource.

And what I think is that when we look at this entire non-human space, for instance, we're lacking this preciseness in terminology. I would add to your graph, I would add a secret. But at the end, I think we should do the same for every type of identity. So we should, and these relationships are super important to understand because this helps us understanding the potential pathways of attacks. When we know what is related, we know much better. We can much better identify what can happen.

We can, yeah, track things much better. Well, that brings up an interesting point because our identity providers today, whoever you use as a vendor, inherently know the identity account relationships. That's how those graphs get built. But the machine ones are trickier because it's up to the human to assign an owner or put an attribute or a trait in your CMDB, if you're idle compliant, to create that relationship.

And many organizations have not thought about that, leaving that machine identity, a potential attack vector with no one that's going to assume responsibility easily when that something happens. But honestly, Mori, is that any new thing?

You know, you're from the area of privileged access management. How many of your customers are really good in managing the ownership for all the technical, functional, et cetera accounts? Same story, but right now, I think the point is right now we have it on steroids. We do. You know what? I would have to tell you, and this is a really sad statement and I don't believe I'm going to say it.

The organizations that are highly regulated, the ones where there have been verticals that are regulated or under government scrutiny, those are the ones that have got a pretty good eye on it because they've been forced to. If they're in a manufacturing environment doing pharmaceuticals or something that has got someone going, you need to make sure all of that is correct, the answer is yes. But I'll tell you what, if there's been no oversight or nothing, the business generally lags.

So I can think of a whole mess of household names that the governments and verticals have been regulated and they do a better job than the unregulated, which is kind of a sad statement that the regulations are actually making it work. Yeah, which is uncommon, I would say, in cybersecurity. But maybe a quick note again to the audience. So we have the first questions here. You can upload questions. You can enter your own questions, additional questions. The more questions we have, as I said, the more interesting, lively it will be.

But back to what you said, yes, I think we need in this, I think something which is important for everything. I think the one thing is technology. The other thing is the culture, the hygiene, the processes, and the governance around, so the enforcement of that, that we not only put something on paper and say, okay, we should do that, but that we actually do it. So I think ITDR is good because it helps us hinting on things that are in a suspicious state. But I think it is also a hint that we need to get better in really the entire, let's call it culture, around it. I think so.

And I think there is, to the title of this, the real reason attackers love our identity stack is it's behind, way behind in security by design. We've gotten better, not perfect by any stretch, at better code, less vulnerabilities, improving our risk surface, but we have not improved secure by design for identities. And it is now the lowest hanging fruit. Everything from deep fakes, stolen credentials, info stealer malware, a wide variety of methodology to steal enough identity information that threat actors get in.

Look, yesterday and over the weekend, we had the Microsoft SharePoint attacks. That required the threat actors to be on premise. They already had breached the organization. I will find it very hard pressed if those threat actors in the thousands of companies that have been breached came in through exploits versus harvesting and then a coordinated launch against SharePoint. Yeah. I'll put that challenge out there. Yeah. And I think it's also interesting regarding coding practices.

We just, I think, last week on LinkedIn, there were a couple of discussions around AWS right now. One of the AI-related components, I forgot the name, allowing long-lived secrets while they, until then, only allowed short-lived secrets. And basically, the explanation for that was that developers don't want to sort of carry the burden of handling short-lived secrets. But the point is, yes, if we do it right, the developer should not be in this, never ever end up in a situation where a developer needs to think about handling this.

That should be just a service which is provided by the identity fabric at the end of the day, or your identity security or your cyber security fabric, name it however you want it. But that must only be a service because I think there are enough proofs. Take OPA or policy agent. A lot of developers adopted it because they don't need to care much about authorization anymore because they can externalize it.

Martin, you just literally made the case for secure by design. If the service is not provided to the developers, can protect secrets in their workflows and their code, whether that's a secrets management or a privileged access management behind the scenes, and then they code long-term secrets in the solution without being provided those services, we run into that exact problem. It's another reason why identity is an easy attack vector. And then you tie the ownership of that secret and that API or the account behind the scenes to no one, then you basically almost have shadow identities.

It was put in at one point, but it's got no ownership, no longevity, no review cycle, no nothing. And if a threat actor finds it, no one really knows what to do with it.

And again, it's not new. It's not new. We have the same problem since the invention of functional or technical accounts. And so I sometimes tend to say, when you develop and use a functional account, it's just bad coding practice. So we could, for decades, for instance, if you have a database access, a lot of database access happens by using a functional account. So you have an application, the users then use the application, and then the functional account is used to access the database.

And then you usually need to add some code that helps in sort of restricting the result set to what the specific user is allowed to see. So you're putting authorization in code, hard-coded authorization, hardly unmanageable and not audible. And you have this functional account. You could also use end-to-end security by provisioning to the end system, to the database. You just would need to do a more proper, better job here. So at the end of the day, yes.

I think that the huge challenge we are facing in these days is, also when you look at all the different workloads that are, this thing is on steroids. It's a totally different scale than we had in the past. Also because, and that's another interesting topic we may find time for or not, but I'll just want to first take a question from the audience.

But I think one of the interesting things is also, we right now not only need to look at long-term or long-lived versus short-lived for Merrill, we also need to look at what is more static and what is dynamic, what is popping up and disappearing maybe with an instance of a workload while what is static to a workload? So I think there are some interesting points we can pick up if time allows a little later.

Right now, I'd like to look at the first question here. Certainly. And the question is, how do we approach the challenge of making identity-related threats and misconfigurations clear to the detect and respond teams? When there are challenges amongst us, the practitioners to get a proper grip across the IAM pillars and modern IAM. So basically the question is about if we still struggle in defining identity management or handling identity management as a holistic thing, we're still having our own different pillars and silos, how should we really successfully talk to the DR teams?

Well, I found the most successful approach to go to that regulatory compliance and security. And actually, whether it's a GRC team, Governance, Risk and Compliance, or the security professionals that own identities. When you're able to sell a risk management team, we've identified risks in passwords, secrets, reuse, and no MFA.

I mean, all of the things that we're talking about from a detection and recommendation standpoint. And it's why threat actors love our identity stack is because we make mistakes and have legacy technology that has tons of mistakes. When you can put it in terms of the business, in terms of risk management, then you can communicate it to the appropriate business owners.

Now, where that actually lives in the identity team, the security team, the team that owns vulnerability management can vary within an organization. But it starts with saying, I am going to do that risk assessment. I am going to do that identity-based vulnerability style assessment, getting the results and then demonstrating, we have all of these attack paths that we know statistically can be breached. How do we plan to remediate them in the future?

Now, some businesses may say, you know what, we'll accept the risk. From a practitioner standpoint, that's us to make the business case. But realistically, when management knows that there's that risk, they then assume the ownership and generally you can get things moving.

Yeah, and I think another element is that these threats are also sort of an important source for the IR team. So at the end of the day, we can enable them, we can help them in having more and also in that sense, recompiled or pre-analyzed information on hand. It helps them understanding what is going on, where are the things they need to look at and also to put them into the context of other incidents they are observing. I think this is a very important element to look at when we look at this entire scene.

I personally, by the way, maybe as a little excursion, but it also may lead, there's a question around preventing deepfake attacks. So one excursion I'd like to make is, I think we must even go beyond the IR team. So my favorite example is currently this incident that happened, I think it was in Korea, where after a video conference where deepfake CFO was in, some 25 million were transferred. And that means we also need to relate not only identity events to network events, to other types of events. We also need to relate them to business signals.

So we need to think about how do we bring our CCM, our continuous controls monitoring that observes the business processes. How do we relate this to events we see on the technical end of things? Because at the end of the day, frequently the target, not always, but in many cases, the target of the attacker's idea is at the end of the day, some sort of a business compromise. So I think we even need to take a broader perspective than we do for now, which is a huge thing because it's really then preaching to very different worlds, even more than identity people to security people.

Martin, I think that's very quite fair. And the question that did come up is, how do I protect against deepfake attacks in the identity? And I essentially have five very quick recommendations. The first is a multimodal approach, which means you use third-party validation to verify the request, regardless of who asks for it. And it's almost like MFA, but you're calling the person, you're using an authorized communication channel, you're using a passcode to verify the request. The second is to use AI versus AI in the deepfake technology. And this can be plugins.

This could be a Teams or Zoom plugin that looks for deepfake video. But it also means that any requests that come outside of authorized channels should never be honored. It really comes from another way. Deepfake education is key as well. You need to train people on deepfake technology and what to look for.

Well, if you looked at the promo videos of myself, this is really me, I'm not AI this time. My hand does this a couple of times. Just ask the person on the other side, can you blink your eyes or clap your hands? Most of the time today, AI can't keep up with those requests fast enough. Now that's gonna be a short-lived answer, but AI impersonating someone else in real time still has a lag. And those are really simple ways of looking for it.

Sorry, I think we're already responding to this. How can I prevent a deepfake attack within my organization? But by the way, Maury, I'm not sure whether you are the real Maury here, because the last time I have seen you face-to-face, you didn't have a beard.

No, this is me being lazy, but thank you. It does come on and off for different things.

So yes, and the video was trained in the same office, actually using a commercial program, as silly as it sounds. Digital signatures are quick and easy. Make sure everything that you're requesting is signed. And the key one, especially for your executive teams, and the other question that just came across about BEC, business email compromise, limit your executive's exposure in full-length video. I'll tell you what, it only takes 60 seconds to train an AI engine to mimic somebody.

Keep the clips short, keep them varied, limit your public exposure, and that'll help, especially your executive team from exposure. But I think, going back to deepfake, maybe quickly, and I had some interesting conversations around deepfake with various people. I still have a bit of perspective that deepfakes are, in that sense, a bit more to the favor of the defenders than cyberattacks usually are. So we have the saying that you need, as an attacker, you only need one working attack vector. As a defender, you need to defend against all attackers.

For deepfakes, I dare to say it's a bit different in the sense of, you need a perfect deepfake as an attacker, while the defender only needs to spot certain small weakness. And we have many, many things we can look at. This is whatever speech-to-text, so speech-to-video synchronization, the blurring, the lip movement, and all the other things we have. So we have many, many elements we can analyze. We can use a lot of different detection engines in parallel to look at certain things. And if there's a little bit of a risk appearing, that brings in the human again.

If you have a, whatever, have a call, and then the picture of Murray, there appears an exclamation mark, a risk signal, something else, then everyone will be super, super careful with that. So I think for deepfakes, we have a better chance to succeed than maybe for several of the other types of attacks.

But yes, we need to be alert, and it's a learning curve for the humans. I think this is something which is really important to do, that everyone has sort of a, yeah. So we must learn that we don't blindly trust what we see. Agreed. It's trust, but verify, using alternative verification methods, just like we use MFA, look for the odd symptoms. And if you have processes that are single person, like large wire transfers, then we go back to Martin's comments about the business, look for business compromise where something is sent by one person that's outside of the norm. Yeah.

And I think that that's an important thing. So we have another question that came in from the audience, which is, I think there's a risk that we consider the ITDR stack in isolation of broader fraud risks. As no one steals an identity just to steal an identity, it's used to defraud something else. So do you agree to re-agree that effective ITDR should be considered as part of the broader counterfraud defense capability? Great question. And the answer is, I don't know, to be fair. My answer would have been yes and no. ITDR today does exist as standalone technology.

It exists in privileged access management vendors, hence why we're supporting this webinar today. BeyondTrust does have a ITDR solution that you can trial for free, but we also see it exists in other places as well. The ownership within the business is what's really kind of messy because it can be in the identity stack. It can be in fraud detection. It can exist within the security team. And depending on your organization is where it will truly live. And especially what your organization does in terms of a vertical. Is it always fraud?

The answer is technically yes, because you don't steal an identity as you stated just to steal it. It's not a novelty. But the type of fraud, whether it's an insider threat or external, et cetera, may make the ownership different in various organizations. So there's really no great answer for that from my perspective. Martin? I would say it's a two-layered thing here. The one thing is ITDR should integrate with the broader DR. Yes. Because it's an important element and adds another perspective, another angle, and also some specific depths in the analyzer. So we need that integration.

But it is also more. It also has some direct impact when we look at access governance and stuff like that. So when we start looking at behavioral anomalies, but also just what is used. What is used is a super important information for everything we do in IGA. So an access entitlement is never used. It's not needed. Or in team or wherever else, cloud infrastructure entitlement management. So there's an element in that, I dare to say, which is very specific to identity and also requires, I would say, a deep identity understanding.

So I don't think it will work that ITDR is just part of the XDR team. It doesn't make sense to have it just as an IAM element. It is both. And I think this is how we should look at it. It helps us with really a different level of insight, which is when you look at, so the entitlements behind it, what does it mean to entitlements? And this is really going quite a bit beyond what we commonly see in IR tools, which are looking a bit more and more technical. So on the other hand, when something happens on the network, that also is in context of an identity.

Something or someone is doing something when packets travel over the network. And so I think this is probably a way to look at it that it's, that goes back to what you said. Organizationally, we can place it in different areas but also very clearly a good ITDR has an understanding of entitlements of access. It really goes into the identity specific details well beyond just authentication and authentication related fraud detection. It looks at what is done and is this what is expected to happen.

Again, which can then bring us in a good ITDR close to business systems. When you understand what is happening in the SAP system and this is the usual behavior. It enforces the concepts of least privilege and zero trust. And it is the real reason attackers love your identity stack. It's because threat actors are not lazy. They're gonna find the path of least resistance for the maximum success. And truthfully, vulnerabilities and exploits cost money and they have a finite time. When they're patched, they're gone. The cost to develop it and weaponize it is substantial in modern day attacks.

But if I can compromise your identity and to Martin's point, the entitlements are over provisioned. We didn't do least privilege. We haven't implemented zero trust. It becomes the lowest hanging fruit for a threat actor to go after. Some form of identity based attack in that identity fabric with all the different tools that you use to manage, authenticate and access management and you name it. That's why attackers are coming in. That's the problem that we're looking to solve.

And that's where ITDR as a separate solution helps to do that hygiene, that assessment of where those risks and flaws are, not only from a static assessment, but also a real time detection. And where it lives is role-based for your organization. Who owns it? Who cares? Most of the time it's risk management and GRC. They are the ones who care, but not necessarily the ones who own it. And that's why it can live in a privileged access space. It can live in various entities throughout the organization.

And something that we believe very firmly is why identity based attacks are on the rise and something that you need to consider to manage for the future. Yeah. And I think I'm absolutely with you and we need to really become creative and understanding handling this. And that's what I think the nice thing is when we look at ITDR and do it well, then there are so many relationships to other areas. So there's this logical relationship of ITDR to the other DRs. There's the relationship to IGA, to fraud detection. There's the relationship to clearly the entire non-human identity space.

So especially in that area, we can't, I would even say we can't live without ITDR because when we look at a world that is at scale, highly automated, highly volatile, then we need something that looks at, that spots anomalies and raises alarms, puts it into the right types of system. And I think for that area, it's absolutely essential that we have an ITDR capability in place.

So, and then it's really a central, a bit of a clue I would even dare to say between different elements we have in our entire identity security, take this broader term, and even business fraud. Fully agree. Infrastructure.

Martin, I think this was the first webinar where we actually agree on most everything. Okay, so maybe we should look at something where we disagree. Go ahead. So I'm looking for questions from the audience. Maybe someone comes up with a good question from the audience. In the meantime, maybe, we looked a little bit at back already, so business email compromise. So that's one question. What are your recommendations for cleaning up an identity after an incident like a business email compromise? We may disagree on this one. We actually might.

Anytime an account or an identity ownership, the account is compromised, and it does traverse through the identity to other accounts. My opinion, and something that I've written about is there is no recovery. You delete it and start that person, that identity fresh in your join, remove, or leave cycle. Just like if a domain controller is compromised, you never know the full depth. When you do have a compromise outside of just the isolated account or any suspicions that it's gone through that path to privilege, you start over with it.

That is radical, but I love it because I think it's the consequent way to do it. It requires that you are super, super well prepared for that because it means if it was a business email compromise against your CEO, you need to bring your CEO back to work in a very short time. And that also means at the end of the day, I would say then you need a well-working identity fabric, which allows you to really handle things in an integrated manner, not two silos. I think that also brings us to the discussion, can we really keep whatever SAP access controls in a silo?

We at least need integration so that setting up a new account for a reinstalled identity can happen extremely fast and without any disruptions. So I think it's not easy to do and it clearly raises a ton of questions. So take all the accounts that are, related to the email address. What do we do with these accounts? So changing the email address might be tricky. But you don't know- Resetting the password.

You don't know if there's a persistent presence and that's the relationship problem that I always advocate that if a system is compromised and you cannot definitively say it was contained perfectly to this account or to this system, you have to redo it. Especially something like email because if the threat actor had any dwell time, how much information did they extract from his email box? You almost have to treat it like the CEO, if we're making that as the summary. First case scenario. He's being replaced. He's fired and we're bringing someone in with the same name.

He's got a brand new mailbox, brand new accounts and everything and everything else gets archived because if there is any persistent presence that you are not aware of, zero day, a token, you name it, you're just going to go revisit this problem again. Especially if it's based on SIM jacking or something else. Couldn't ITDR be something which helps us to take a smoother path? And I take an analogy which is not unproblematic. But so the attack is a bit like cancer.

You put on the therapy and then you monitor it very, very closely to at least ensure that you, as early as possible, spot it when it comes back. So ITDR could, in that sense, play a role for a much closer, denser monitoring like you do in GRC when you add, so to speak, compensatory controls. In a situation where whenever you can't avoid sort of a segregation of duties conflicts, you have compensatory controls. In that sense, you would also say when there was something, I tried to clean it up and I put, using ITDR and other DRs, very close controls.

I agree with that except for the executive team or other high profile. If it's a regular rank and file employee, I think ITDR can help you be that surgeon to remove that piece. But when you have a high profile, already a high risk account that potentially, hopefully was not, overprivileged just because they were an executive and said, I want admin access. I don't believe that ITDR is sufficient. I think that your incident response has got to be more of the surgeon taking a larger scaffold to the area. Have you seen organizations taking such radical accounts?

Have you seen organizations taking such a radical? Yes, I have. I have. When they are unable to verify logging of all of the activity, they don't own Salesforce. I don't remember what the feature is, where you get detailed logging from Salesforce to prove something was downloaded. Where there are gaps, then there is the unknown and then the scalpel is required. If you have good log coverage, if your ITDR is looking at everything and you can say for certain, there was no additional authentication, there was no lateral movement, then the ITDR can help support the non-surgical removal.

But I've found very few organizations that have the SIM capabilities, the log capabilities to be able to do that. I found very few. I would fully agree that usually there are gaps. For virtually everything, there are specialized solutions. There are solutions that help you tracking which documents are leaving your SAP realm. But many of the organizations haven't implemented, most of the organizations haven't implemented this. I think a lot of organizations don't have DLP still implemented even while it's coming back as well as email security and other things. So I would say I agree with that.

So we're already, I would say- Mark, can I just add one piece? Yes, yeah, sure. When we did the introductions, I mentioned I'm a former CISO as well. My policy for any account compromise was the surgical approach. Whether it was SIM jacking or anything else or a stolen device, that was always my approach because it left no stone unturned, even though it was harsh, it was the approach.

Now, if someone needed to migrate data from their own system back, that could be then vetted and moved back over whether it was cloud share files, et cetera. But I prefer to take that approach even if it was inconvenient of them for having a few days lost work and have it absolutely cut as a CISO.

Now, it doesn't happen frequently, period. But every organization does have account compromise at some point. It's just a matter of fact. And I'd rather take the harder approach as a CISO recommendation than trying to be monitor, monitor, monitor, and they get caught by that zero day or something that I missed. And if the board says, don't take the surgical approach, then they are taking the risk. That's the advantage of being a CISO. Then they are informed and they're aware of the risk, yes. Exactly. So we are at the end of the time.

I think we could continue for easily another hour or two or three. Thank you first to the audience for also checking and bringing questions. Thank you very much for BeyondTrust and supporting the Scope and Call Analysts webinar.

Thank you, Maury, for all your thoughts and opinions. This was very interesting. And as usual, I learned something in the conversations with you. So thank you very much to all and hope to have you back soon in one of our Scope and Call Analysts webinars or our other events we are running. Thank you.

Martin, pleasure as always. Be well. Take care.