Identity threat detection and response (ITDR) – not another product category!

What is identity threat detection and response? A brief history…

Whether you see it as a technology domain, security discipline, or product category, identity threat detection and response (ITDR for short) is an increasingly common term for industry analysts, tech vendors, and service providers alike.

Purists will argue that a taxonomy consisting of anything more than SIEM with UEBA is excessive (although this hasn’t stopped terms like EDR/XDR from sticking around), but product categories continue to multiply despite these protests. 

ITDR as a term has existed since the early 2020s. When it was first introduced, it focused on protecting identities in the context of more traditional identity infrastructure (e.g. Active Directory). The term has since been adopted by cloud-focused security vendors, but retains a hybrid lens, with AD still featuring heavily. 

It’s clear that an appreciation of identity-based threats is driving the need to protect user identities, with 74% of all breaches involving the human element targeting compromised user accounts via human error, privilege misuse, use of compromised credentials, or social engineering. 

Until now, the focus of identity threat detection and incident response efforts has been to protect “identity systems”. According to a Gartner press release in 2022, “Gartner introduced the term… to describe the collection of tools and best practices to defend identity systems.” In response to the increasing number of identity-based attacks, ITDR was included in Gartner’s hype cycle for endpoint security as an emerging technology that works to protect the identity infrastructure from malicious attacks.

Does this definition still work in 2024?

In security, endpoint has become synonymous with physical devices connected to a network. But in simpler terms, an endpoint is one end of a communication channel. Many now see the main endpoint as the browser, not the underlying device/OS. Google suggests that “browsers are more than just a portal to the internet: they are the new endpoint where almost every high-value activity and interaction in the enterprise takes place. Authentication, access, communication and collaboration, administration, and even coding are all browser-based activities in the modern enterprise.”

Equally, modern identity infrastructure is becoming more complex. It's increasingly problematic to think of identity as belonging to a centrally controlled identity store like AD (or even cloud-based equivalents like Azure Active Directory / Entra ID). 

Identity is no longer a concept that is applied only at the endpoint or core network level – it’s everywhere. This means that many identity solutions are becoming increasingly dated, leaving a gap that is being actively targeted by attackers.

Identity infrastructure is becoming increasingly complex

In reality, your identity ecosystem is made up of any system or service that holds your identities, whether you manage them or not. This can include:

• Multiple identity providers (e.g. Okta, Entra/Microsoft, Google, JumpCloud) 

• Apps acting as an SSO platform for connected apps (e.g. Atlassian Access, Adobe Creative Cloud) 

• SaaS apps using different authentication (SAML, OIDC) and authorization (OAuth) protocols

• SaaS apps with a local username and password

• Credentials and secrets stored in password manager and authenticator apps (which can be in browsers, on local OS, and in 3rd party apps)

The particular make-up of an identity can vary a lot. Depending on the app, it’s possible to have multiple authentication mechanisms for the same account – for example via SAML, social logins (OIDC), and via username and password. Whilst SAML requires that admins set it up in advance for a given app tenant, users can sign up for an app using OIDC simply by using the “sign in with Google” feature.

In effect this creates multiple identities tied to a single account, which can introduce a lot of confusion and complexity – for example, just because an IdP admin deletes that account, doesn’t mean the app/account can’t then be accessed by using one of the other login methods that’s been created. This can make it hard to know what apps are in use, and what identities exist in the organization.  

Importantly, these cloud identities are not accessed or managed from the endpoint (as in, via the underlying operating system, via locally installed apps). Instead, they’re accessed in the browser, over the internet. 

Cloud identities are in the crosshairs

Although “unsophisticated” identity based attacks are nothing new (some description of identity/phishing attacks have been the top attack vector since at least 2013), the landscape in which these attacks are occurring has changed significantly, moving beyond the compromise of digital credentials toward a broader targeting of the identity infrastructure. 

Crowdstrike’s latest global threat report tells us that 75% of attacks to gain access were malware-free, and that “cloud-conscious” attacks (deliberate rather than opportunistic targeting of cloud services to compromise specific functionality) increased 110%. Microsoft also notes around 4,000 password attacks per second specifically targeting cloud identities, while there are suggestions from Google employees that attacks looking to steal session cookies (and therefore bypass MFA) happen at roughly the same order of magnitude as password-based attacks.

Breaches in the public eye tell us the same story. Threat groups like APT29/Cozy Bear/The Dukes and Scattered Spider/0ktapus show how attackers are actively targeting IdP services, SaaS apps, and SSO/OAuth to carry out high-profile attacks against companies like Microsoft and Okta. 

It's getting harder to detect and respond to identity-based attacks

The modern way of working means that applications are more often than not directly exposed to the internet – and the only thing needed to access them are identities. These exposed identities no longer sit behind another perimeter such as the endpoint or an internal network. Now, identity is the outermost layer for organizations working in the cloud. 

The data and functionality that attackers seek has moved onto cloud systems and SaaS applications, which companies are using in large numbers (tens to hundreds per org). In many cases these apps have replaced on-premise deployments of business critical apps, containing valuable sensitive data and functionality that is a lucrative target for attackers and can be accessed without needing to touch the conventional network. 

There are many benefits to this (no need to patch these SaaS systems!) but the trade-off is that the scale of the identity attack surface has increased significantly. It's much harder to stop credential stuffing attacks against 100 SaaS apps than the single centralized external VPN/webmail endpoint of yesteryear. 

Identity infrastructure is designed to be permissive and interconnected, but anywhere there is a handoff in the tech, traversing from one API, or service, or domain to another – there’s an opportunity for an attacker and therefore a risk. 

Our recent posts on identity threats such as Oktajacking, SAMLjacking, abusing SWA authentication, risky OAuth scopes, and stealing password manager secrets all demonstrate the art of the possible, while this index of recorded attacks showcases cloud identity-based attacks and SaaS attack techniques being used in the wild.  

OK, but… do we really need another product category?

Well, yes, we do. While initially skeptical, we're absolutely convinced that ITDR is a necessary product category and can't be achieved just by combining existing tools and processes. Consequently, the definition needs to evolve. Because:

• Identity is not something that is centrally controlled or localized to a specific identity “system”

• Identity doesn’t just happen at the endpoint/OS/network level. In fact, it is now mostly applied over the internet, connecting various third-party apps and services

Brace yourself – here come the acronyms… 

In simple terms, identity threat detection and response should be focused on protecting user identities by providing the telemetry and functionality to defend against identity-based attacks. 

Naturally, ITDR solutions should complement adjacent security solutions such as Endpoint Detection and Response (EDR) and Extended Detection and Response (XDR), for integration with Security Incident and Event Management (SIEM) and Security Orchestration, Automation and Response (SOAR) platforms operated by the security operations team. 

But the problem with seeing ITDR as simply an extension of EDR is that it really sits apart from the traditional endpoint. EDR (and now XDR) places EDR and the endpoint at the core of the detection surface. It’s not easy to find an XDR solution that isn’t built around EDR (and you probably wouldn’t want one that wasn’t!).

Hardening of identity-based systems is important. But, there are already more than enough categories concerned with this. It’s heavily debatable whether another category is required for ITDR if only an extension of the existing endpoint and network security domains. 

For ITDR to be a valuable category, we need to do better than focusing on AD, and we might need to expand our definition of the endpoint. 

The industry is beginning to recognize this. Vendors are now placing more of a focus on decentralized cloud- and SaaS-based networks whilst still claiming to be ITDR solutions. Although vendors are often spread-betting – referencing as many relevant categories as possible so they’re prepared when one takes off – and the actual products and services fall into a gray area.

We don’t need a “mini-SIEM”

Most of the emerging solutions (i.e. new solutions not focused on traditional AD security) in the ITDR solution space fall into one (or both) of the following categories:

• They take IdP and SaaS logs exposed via API/webhooks and use that data to create detections and monitor for malicious activity – kind of like a mini SIEM. Varying levels of automation workflow exist to prevent or respond to the detection use cases created. The alerts may be forwarded to a proper SIEM/SOAR/XDR platform for further integration with SecOps workflows. 

• They map permissions, authentication/authorization, privileges and entitlements in core identity systems and larger and more complex cloud apps to predict possible attack paths.  

In reality, the same outcomes could be achieved by ingesting the logs directly into an existing SIEM solution and creating detection analytics there. 

Relying on SaaS and IdP logs has big limitations

There will always be a limit to what is possible when relying on SaaS and IdP logs alone. Inherently, you’re limited to the events that the third-party deems suitable to log.

Out of the 100+ apps that we use here at Push, and perhaps the dozen or so that are security critical, only a fraction provide any useful logging. This means, naturally, that the majority of apps do not. Many lock these logs behind the premium tier subscription. This means complete visibility across the potential attack paths is impossible.

Not only this, but the process of extracting these logs and feeding them into your SIEM (or equivalent) is also not straightforward. The lack of out-of-the-box connectors for many apps means that complex custom architectures are required for collecting data. Some vendors place constraints on the format and mechanism for extracting logs which can make ingestion difficult to feed reliable detections – even before any meaningful analysis of the data can take place. 

Here’s a few of the examples of the gaps that you might not realize exist:

• LastPass doesn’t log when items are moved or cloned from an enterprise folder to a personal folder

• JAMF can only export logs via the UI, in batches of 500 messages per export

• Salesforce has a 24-hour delay in log generation and outputs only to CSV via API 

Shout out to the creators of https://audit-logs.tax/!

So on the one hand, there are serious gaps in the logs available. But there are also some fundamental limitations based on the things that these logs can’t detect. For example, phishing attempts in general, including adversary in the middle (AitM) and browser in the middle (BitM) techniques designed to bypass MFA, or password sharing across apps and services. 

To summarize – it’s challenging to get any meaningful data for your identity infrastructure and network of Cloud/SaaS apps by taking logs directly from the source. This is especially true if you don’t have a way to discover these sources in the first place. 

Given the complexity, it’s easy to see how so-called ITDR vendors have emerged to streamline this process, but this doesn’t change the fact that getting more of the logs that are available isn't adding any new data. At best you have a SIEM data collector, and at worst you’re creating a shadow SIEM and disrupting the SecOps workflow. 

It’s clear that something is missing here. A bit like trying to do on-premise threat detection or incident response using logs alone, without an EDR agent. 

Permissions mapping is useful for prediction, but less so for detection

Because of the limited value in the logs available (creating high false positive, low value detections), many identity threat detection solutions focus instead on user permissions analyzed via application APIs. For the few apps that provide API access, this can be useful. However, this doesn’t really detect so much as predict what an attacker might do if they compromised the identity. This is valuable, but a much lower priority than simply making sure the identity perimeter isn't breached in the first place. 

This approach is typically applied well in complex environments, but is less effective at managing the sprawl of access and permissions across cloud apps and services. Not unlike their logging limitations, the vast majority of cloud/SaaS applications are not deeply configurable. Equally, cloud IdPs are much less complex than their legacy counterpart, Active Directory. Unlike AD, there aren’t a million ways of doing privilege escalation. 

There is undoubtedly a legitimate use case for this kind of solution. For example, securing underlying cloud infrastructure, workloads, and ephemeral resources. But this is much more useful to developers than security teams in its current state.

EDR for cloud identities?

Clearly there is an issue with both the telemetry available and what ITDR-aligned providers are opting to do with it. 

What's missing is an EDR-equivalent data source for online identities. 

It seems obvious at this stage that the browser is key to the solution. Let’s think about it: Apps are accessed and identities are created and used pretty much exclusively in the browser (even local clients typically redirect auth and account management here). It’s the perfect place to detect and prevent identity compromise by intercepting users at the point of impact – for example, when they are about to enter their credentials into a fraudulent login page, use an unapproved app, sign-up using an unapproved login method, or use an approved app in a risky way…

The level of visibility into user behaviors possible in the browser is pretty much limitless – every page loaded (and its source, javascript state, local storage), every button clicked, every password entered can be observed. 

Equally, the capacity to respond using a browser extension is more like an EDR agent running on the host than a monitoring-only solution. 

At Push, we’re bringing something different to the table, a net new capability that isn't provided through existing security tools and controls.

Using our browser-based agent, we can for example: 

• Prevent credentials being entered into any webpage other than the legitimate login page

• Detect and block AitM tools like Evinginx or BitM like EvilnoVNC 

• Actively modify network requests (and through that, log events) to tell if a session has been hijacked

• And much more.

But this is only the tip of the iceberg – and we’ve got big plans. 

Closing thought – what is the future of ITDR?

It’s pretty clear that the definition of ITDR as focused on core “identity systems”, is increasingly dated. It’s also clear that trying to detect and respond to identity attacks in the cloud is made more difficult by the lack of an EDR-equivalent for identity attacks against cloud services happening over the internet. 

A new platform for detection and response is needed. That is, something that sits apart from (and at the same tier as) traditional EDR in terms of its role in the security stack. 

So if your cybersecurity strategy includes looking for ITDR-focused tools and services (and if not, maybe it should), hopefully this has given you some valuable insights as to what you should consider. To summarize, it must: 

• Play nicely with your existing toolset and feed into, rather than attempt to replace or duplicate (not another single pane of glass…) 

• Be designed for the sprawl of cloud identities and focus primarily on the security controls implemented prior to identity compromise,

• Bring new data to the table and not simply repackage or enrich the patchwork logs from existing sources

Final thought: if it's EDR, shouldn't it just be IDR?

Edit: If you want to learn more about this topic, check out the recent Cloud Security Podcast episode with our co-founder and CEO, Adam Bateman. See what Anton and Timothy had to say below!