Like many of you reading this, I tend to view problems through a technical lens. I’m a solutions consultant, so when I look at a problem, I am typically thinking in terms of solutions, capabilities and features.
It is through this lens that I first viewed Identity Threat Detection and Response (ITDR).
This post we will dive into what ITDR is, why it needs to exist and how it works in practice.
What is ITDR?
ITDR recognizes identity as one of the primary vectors through which attacks on organizations occur and provides a definition to the process and tooling required to defend it.
Gartner coined this term in 2022 and defined it as “a security discipline that encompasses threat intelligence, best practices, a knowledge base, tools and processes to protect identity systems. It works by implementing detection mechanisms, investigating suspect posture changes and activities, and responding to attacks to restore the integrity of the identity infrastructure.” (Teixeira, Firstbrook, Allan, and Archambault, 2022, p. 3)
Why is ITDR important?
As I dug into what makes up ITDR, I learned three key things that helped me understand why it needs to exist, why it’s so important and how it works.
1) Identity is complex and needs its own security discipline
When I started in information technology nearly 25 years ago, for many organizations I worked with, security was synonymous with the network team. Networking teams have long had firewalls and network packet inspection technology to keep attackers “out,” wrapped up in a “Network Detection and Response” (NDR) discipline that proscribes how to detect and respond to network-based threats.
And as more computing began happening outside of the network perimeter, the endpoint (the workstation, laptop or mobile device) became a frequently exploited target by attackers. Again, this gave rise to a security discipline: “Endpoint Detection and Response” (EDR), which combined tools, processes, and best practices to secure endpoints.
And now, identity is the new perimeter. Organizations are enabling their users to access their applications and data from anywhere with any device, with the user’s identity being the essential control for that access. This, naturally, has led to increased attacks on both user’s identities and the infrastructure supporting those identities.
Defending identity platforms
Consider the challenges in defending modern identity platforms. Most organizations have at least two core directory systems that supply authentication and authorization: Microsoft’s Active Directory and Azure Active Directory. And there may be more! Legacy mainframe or *nix-based systems with their own identities, LDAP directories such as RedHat or Oracle, and cloud-based identities such as in Google Workplace or Okta.
These systems are all quite different from one another, both with unique structure and controls but also unique auditing and threat signals. Adding further complexity, directories are often configured to synchronize with other directories using specific toolsets, such as Microsoft’s Azure AD Connect.
Directory systems often have many security signals that they are producing. Active Directory is a great example – there is the built-in security event logs, software that independently audits and analyzes Active Directory separately from event logs (such as Quest Change Auditor or Microsoft Defender for Identity), and software that analyzes these signals to produce “higher level” signals (such as Quest On Demand Audit). Or Azure Active Directory, where security signals can vary by the license level – basic Azure AD has basic audit and security signals, while Azure AD Premium P2 adds integrated risk calculations.
To manage these directory platforms, many organizations add in more three-letter acronyms: IAM (Identity and Access Management), its superset IGA (Identity Governance Administration), and the privileged focused PAM (Privilege Access Management). These systems can be used to manage some or all of the directories, and even within a directory are usually only responsible for some of the identities. For example, IGA systems often don’t manage service identities (users used in an automated fashion by software, managed service accounts, or Azure AD “Enterprise Applications”). Similarly, PAM systems typically only manage administrative accounts and user accounts used by software. And each of these systems have their own auditing and security intelligence signals, as well as their own response and mitigation capabilities.
This summary is hardly exhaustive, as there are many more potential systems in play: specific systems to supply multi-factor authentication (MFA), cloud infrastructure entitlement management (CIEM), and security orchestration, automation, and response (SOAR) systems to name just a few.
All these platforms play a key role in managing and securing a user’s identity, but they can also become targets themselves – paradoxically increasing an organization’s risk footprint.
2) Identity complexity is a strength
Given the challenges of so many platforms being involved in identity, it may be tempting to try to merge to a single vendor and technical stack. After all, with so many various platforms, auditing signals, and potential responses to sift through, wouldn’t it make sense to simplify as much as possible?
But the reality is different for two key reasons:
Putting all your eggs in a single basket means that if a compromise in one system is found, there aren’t any other identities to rely on. One of the first steps in any identity compromise is isolating different directories from one another. If Active Directory is compromised, then you’ll want to shut down Azure AD Connect so that your email continues to work.
This strength in diversity extends to the support systems for identity tools as well. While it isn’t a lot of fun to manage multiple toolsets, identifying infrastructures are specific and complex enough that it often makes sense to take advantage of best of breed solutions. For instance, recovering Active Directory is a process best left to a specific solution.
It is best to not think of ITDR as a specific solution, or even categories of solutions – but rather a discipline that supplies the connective tissue between many different platforms and toolsets.
3) The NIST cybersecurity framework is helpful to understand ITDR
At Quest, we often refer to the NIST Cybersecurity Framework to help explain the problems that we work to solve for our customers, and I found it useful in understanding what gaps in identity security ITDR is designed to fill. The NIST Framework consists of 5 aspects:
- Identify – Assess existing policies to find vulnerabilities and understand their risk.
- Protect – Institute preventative controls to limit risk.
- Detect – Look at security and audit signals for problems.
- Respond – Act on the audit signals.
- Recover – Restore any impacted services or capabilities.
As you might guess by the name, Identity Threat Detection and Response isn’t too concerned with the first two aspects of NIST – Identify and Protect. This isn’t to say they aren’t important, and every organization should expect to take feedback from an effective ITDR program and use it to better analyze and control their identity solutions.
An ITDR program would supply a framework for defining what to detect.
To give a concrete example for Active Directory, a platform I know well, an ITDR program could use a platform specific ITDR tool to supply the ability to detect and alert on the misuse of the Active Directory Group Policy infrastructure. Group Policy is a powerful and complex systems management capability tightly wrapped into the Active Directory identity platform, and a common focus point for attackers. An ITDR tool would supply the technical capability to detect changes to Group Policy Objects as well as to which identities it can affect.
An ITDR program would supply a framework for deciding how to respond.
When a potentially problematic signal is found, who investigates it? This can often be a complex question, as due to the complexity of the identity systems, it is usually not possible for a single team to be subject matter experts in all the relevant technologies. An Active Directory expert might not be an Azure Active Directory expert, and there may be sub-disciplines in each of the expertise areas — such as resources who focus in on two-factor authentication. In our Group Policy example, a response flow might be to involve platform owners for Active Directory and Group Policy, who then would have their own frameworks defined in the ITDR with what the next steps are. This would certainly include information on who would next be notified, but it may also include specific guidance on mitigation, such as disabling identity synchronization between Active Directory and Azure Active Directory.
An ITDR program would define the process for recovering or restoring an IT system or process.
This would include both the technical aspects of recovery as well as who needs to make the decision to recover. In our example, recovery might be to restore the GPO to an earlier version using GPO governance software or to recover it from backup using an Active Directory recovery solution. An ITDR program should have procedures in place to cover everything from a simple recovery of an individual identity to a recovery of the entire identity platform.
ITDR vs. EDR
ITDR and EDR serve as vital tools in detecting and preventing cyberattacks, but they differ in focus.
ITDR monitors user activity and access logs across various IAM sources, while EDR monitors endpoint devices like workstations and laptops, analyzing system logs and network traffic.
Together, they provide comprehensive incident analysis. For instance, EDR detects suspicious activity on endpoint devices, while ITDR identifies potential identity-related threats by examining credentials.
This combined approach strengthens an organization’s ability to detect and respond to complex breaches effectively.
Reduce your AD attack surface.
Conclusion
I hope these three references helped you better understand how ITDR isn’t a new category of technology, but instead a powerful means to harness technology, institutional best practice, and process to detect and respond to modern threats to identity.
References:
Teixeira, H., Firstbrook, P., Allan, A., Archambault, R. Enhance Your Cyberattack Preparedness With
Identity Threat Detection and Response, 3.
