Identity is now a top priority for security decision makers. The need to overcome malicious TTPs, such as credential access, privilege escalation and lateral movement, has never been more urgent. When over 80% of breaches involve the use of compromised credentials and ransomware attacks take down even the largest organizations, the price of neglecting identity security is unaffordable.   

This state of affairs has led to the rise of a product category purpose-built for the protection of the identity attack surface: Identity Threat Detection and Response (ITDR). However, the introduction of a new category inevitably entails a period of confusion for buyers, during which identity security teams must figure out which ITDR capabilities are mandatory and which are a “nice to have”.  

This article assists organizations in this journey by providing the top five evaluation criteria to assess how well an ITDR solution can deliver on its promises.   

Evaluation criteria #1: The breadth and depth of coverage  

The identity attack surface is extremely heterogeneous and comprises multiple components. We can classify these to the following groups: 

Resources 

The on-prem environment includes workstations and servers, IT infrastructure, databases, and legacy apps. Some virtual machines are managed in data center servers, while IaaS virtual machines reside in the public cloud. These are joined by the corporate SaaS and web apps for storage, email and other purposes. 

Protocols and access methods 

Active Directory uses protocols such as NTLM, Kerberos, and LDAP to manage access to servers, workstations, and other on-prem resources. This access is carried out in various ways – command line, RDP, and dedicated remote access tools (Teamviewer and others like it). VPN remote access is usually done via a RADIUS, while federation servers and cloud IdPs employ SAML, OpenID, and OAuthor to access SaaS apps via users’ web browsers.  

User accounts  

Additionally, there are various types of users: standard, privileged, human and non-human. Some are easier to detect and monitor while others are more challenging. A prominent example is Non-Human Identities (NHI) such as service accounts in Active Directory environments, which are extremely hard to locate and map.  

An ITDR solution must be able to apply its capabilities on all users, resources, and access methods in the hybrid environment.  

Why does it matter? 

To truly protect an attack surface you must protect all of it without any blind spots. Protecting only a part of it simply leaves the path clear for adversaries to target the unprotected portion instead. That’s why, for example, lateral movement and ransomware propagation are carried out mostly via command line access (such as PsExec, PowerShell, and WMI tools) rather than with RDP. While the latter is usually protected with MFA, the former doesn’t support it. Securing a single access method to a server is not sufficient protection when there are other unsecured access points.  

Evaluation criteria #2: As near real time as possible  

ITDR solutions analyze user authentications and access attempts to disclose potential threats. Real-time analysis provides the ITDR with visibility into each authentication from the initiation and verification stages to actual completion and access. The alternative is to analyze the authentication log after the access attempt is approved or denied.  

Why does it matter? 

The purpose of ITDR is to detect suspected malicious activity. The closer this analysis is to the real-time authentication event, the higher its chances of detecting malicious access before it can mature into an actual threat. Additionally, there are various anomalies that can be detected only during the actual authentication; these would be a blind spot for ITDR solutions that rely on retroactive log analysis. 

Evaluation criteria #3: Multi-layered detection engine 

Detecting malicious activity relies on spotting anomalies that deviate from standard legitimate behavior. However, this is not a zero-sum game and while some anomalies are clearly associated with malicious activity, most can occur for other unrelated reasons. Using a risk engine that is capable of detecting different types of anomalies can increase accuracy and reduce the risk of false positives. The anomalies an ITDR should typically look for include: 

Protocol anomalies 

These anomalies result from attack techniques that exploit weaknesses in authentication protocols to gain malicious access – pass the ticket, pass the hash, etc. These are called protocol anomalies because they involve an alteration of the authentication process.  

Behavior anomalies 

These anomalies occur as a result of lateral movement activity. Lateral movement is by nature an opportunistic activity in which the adversary hops from machine to machine in search of any stored users and machines that could help them reach their target. For example, an attacker that has landed on the patient-zero machine would use it as a starting point to access others one by one, searching for stored admin credentials or the computer name of a critical server. This type of search and movement varies greatly from standard legitimate user access. 

User anomalies  

Every user has its own baseline of resource access. This is especially true for non-human identities like AD service accounts, but applies to most human users as well. Excluding helpdesk and IT admins who need access to multiple machines for troubleshooting, most users have a defined set of resources they access in their working routine. Once an adversary compromises a user account to perform lateral movement, there’s a high chance they’ll attempt to access resources that this user has never accessed before. 

Why does it matter? 

While each anomaly by itself entails a percentage of false positives, the intersection between them is significantly more reliable. Here’s an example: 

The user Bob accesses a resource he had never accessed before. Does that mean that Bob is compromised? Not necessarily. These types of naïve anomalies also occur within the legitimate activity of every user. Let’s now assume that the authentication Bob has performed to access this resource used a weaker encryption algorithm than expected. While suspicious, this is also not necessarily malicious. However, if both anomalies occur in same access attempt, the probability that it is malicious rises significantly.  

Evaluation criteria #4: Ability to trigger real-time identity security controls   

Identity security is carried out with dedicated controls to prevent malicious access, such as access block, MFA and just-in-time access. The core role of the ITDR is to detect whether an access attempt is malicious. However, it’s essential that the ITDR also has the required integrations to trigger real-time identity security controls. The most critical ones are MFA and access block. 

Why does it matter? 

Alerts require manual triage and investigations, and as a rule of thumb, resolving all of them is beyond the capacity of the SecOps team. An ITDR that’s capable of using its detection signals to trigger MFA and block access can provide automated real-time protection and block malicious activity rather than just alerting its presence.  

Evaluation criteria #5: Seamless integration with the security stack 

While ITDR owns the identity aspect of cyber attacks, this only a part – albeit a significant one – of the whole threat protection story. To offer comprehensive protection, an ITDR solution should be able to exchange data and risk signals with the other key components of the security stack. For example, the EDR/XDR should be able to provide the ITDR with data on suspicious processes and files, and the firewall or ZTNA on open ports and traffic origin/destination. Also, the ITDR should be able to share data with the SIEM solution to add identity security signals to the full context of network and file activity, as well as take place in automated SOAR workflows. 

Why does it matter? 

Increases accuracy 

Every security solution has a type of activity it can monitor and analyze and others that it’s blind to. For example, in the same way endpoint protection solutions are blind to the authentication process, the ITDR is blind to running processes and executing files. Intersecting the two perspectives increases accuracy and efficiency.  

Better operability 

SecOps teams employ a multitude of security tools. However, there’s usually a component – SIEM or XDR – that operates as the main interface from which alerts are managed. The ITDR must be able to seamlessly fit into the workflows of this interface to deliver its security value.  

ITDR is a key factor in reducing the probability and impact of identity threats   

The purpose of ITDR is to reduce the probability and impact of a successful identity-related attack. The criteria discussed in this article are singled out based on their contribution to this cause.  

Have you already shortlisted some ITDR solutions? Use these criteria to ask the hard questions. The answers will let you know if the solution you’re looking at can reduce your identity risk and provide the resilience you’re looking for.  

The post Top 5 Evaluation Criteria For Choosing The Right ITDR Tool  appeared first on Silverfort.

*** This is a Security Bloggers Network syndicated blog from Silverfort Blog - Cyber Security News authored by Yiftach Keshet. Read the original post at: https://www.silverfort.com/blog/top-5-evaluation-criteria-for-choosing-the-right-itdr-tool/