A couple of weeks ago, Harley Adams and I reviewed Dark Reading’s state of identity threat detection and response (ITDR) report, walking through several of the more interesting stats. OpenText commissioned Dark Reading to survey executives and hands-on security professionals, and this report is the result of that survey. It includes responses from individuals from 117 organizations in the U.S. The report intends to learn from the decision-makers and implementers how much of a footing ITDR concepts and practices have gained since Gartner designated it as a distinct category just a few years ago.
At a high level, the two most significant ITDR components are XDR (extended detection and response) and IAM (identity and access management). Combining those two technology categories makes delivering a higher level of threat recognition precision and response adaptability possible. Unlike broader security frameworks that scan for generalized anomalies, ITDR zeroes in on behaviors and signals that indicate identity compromise—unusual login patterns, access requests from unfamiliar devices or geographies, and sudden privilege escalations.
Often overlooked in conventional monitoring, these indicators can be early signs of an attacker attempting to exploit stolen credentials or manipulate legitimate access. The effective use of that approach is further magnified when it’s correlated with identity-related events that build a holistic threat profile, enabling faster, more informed responses. This integration helps security teams isolate compromised accounts before they cause damage and provides actionable insights to refine access policies and harden identity systems over time.
The IAM road to ITDR
While ITDR provides a new level of protection against identity-based attacks, it doesn’t mean that IAM isn’t without its advanced protection. In fact, even on its own, IAM has some effective heuristics that teams can leverage to help identify the need for a security response. While no one pretends that adaptive access management is the end game for organizations with serious (mandates, stringent risk controls, or cyber insurance requirements) security needs, it can be a path leading to it. Regardless of the heuristics used to indicate risk, there are some approaches that you can take to mature IAM infrastructure’s ability to recognize and respond to breach threats that actually prepare your organization to move into ITDR configuration.
Continuous recognition and response
The most common moment when access request risk levels are measured is when a user’s/program’s session is first established, and the identity claim is made. Then, the access management infrastructure determines and enforces access conditions. The most common criteria for stepping up authentication at the point of authentication are just a couple:
- Are you inside or outside the firewall?
- Is the device known (device ID or browser cookie)?
Historically, these have been the most common criteria for determining whether authentication must be “stepped up.” While this approach has been the standard for the past decade, it falls short of what is needed for an ITDR level of security. The mindset shift is that risk-based access is more than an initial control for invoking multifactor authentication. Instead, it is a continual access control process.
While access gateways are not firewalls and thus can’t drop a session at any point in time, they do have the ability to interrupt a session at the point when a user makes a new access request. Based on the bump or rise measured risk, potential action scenarios could be:
- Confirm the requestors’ identity through some type of authentication request
- Restrict the types of information and services the user can access
- End the session and block further access
It’s worth noting that while IAM technology cannot drop the session at any moment, XDR technology can trigger an automated response action to a firewall to do just that. The key point is that session security is more than just measuring user/API context at the point of authentication; it is to do so continually. Access management’s limitation is that it can only gather snapshot heuristic information at each request point. ITDR offers a valuable set of continuous access monitoring metrics, but on the way to achieving that level of security, it’s a noteworthy step to prepare IAM to recognize threats and react continually.
Get the ITDR ReportAdaptive access for security
For an adaptive security infrastructure to be effective, security needs to move beyond prescriptive risk policies and lean more on deeper user context and behavior analysis. Security groups may find that using a hybrid approach in which they enforce prescriptive access policies by default. This approach also means that these are given less weight individually as behavioral information is accumulated to high confidence levels for a specific user. To accommodate diverse scenarios, organizations may need a mix of strong and passive authentication methods to apply the best fit based on the situation and risk, i.e., how sensitive the information is and the context of access.
Adaptive access for usability
One of the key challenges of expanding access control beyond the simplest heuristics is the ability to maximize usability while limiting higher security verification for higher-risk situations. Or, in other words, focus access policies on usability and productivity while reserving disruptive intrusions like additional authentication steps or paring back authorization levels to times when risk levels (or in Access Manager’s world, risk scores) reach a defined trigger point. So, while a higher level of contextual intelligence is the lifeblood of adaptive access management, low friction access is what makes it valuable to the business.
While IAM heuristics on its own isn’t in the same league as an ITDR implementation, it does offer basic metrics that are straightforward to implement yet too many IT and security teams haven’t configured. The reality is that they can go a long way towards protecting against outsider attacks. Below are most of the available metrics taken from Access Manager’s documentation. Please check the documentation directly for additional information and scenarios. There are a few more parameters not included because they’re more complex to use:
IP Address – Use this rule to define a condition to track login attempts from an IP address, range of IP addresses, an IP subnet range, or a list of IP addresses from an external provider. For example, if you are aware that login attempts from a specific range of IP addresses are riskier, you can define a rule to watch for such login attempts. When a request originates from the specified IP address range, you can prompt for additional authentication.
Cookie – Use this rule if you want to track login attempts from a browser-based application that has a specific cookie value or name. For example: You have a financial application and a user accessing this application has cookies stored on the browser. The user is granted access without additional authentication if the cookie has a specific value or name. If the user accessing the application has no cookies stored, you can request additional authentication to validate the user.
HTTP Header – use this rule to track the HTTP header of requests based on the name or the value contained in the HTTP header. For example, if you want to track HTTP requests containing custom HTTP header information, you can define the action to be performed on the evaluation of this rule.
User Last Login—This rule creates a cookie in the browser after a successful step-up authentication. Subsequent login verifies this cookie. Use this rule to define the validity duration for the cookie. After the specified time, the user is prompted for additional authentication. For example, you can use this rule to evaluate whether a user logs in using a device that was used earlier for login. You can define the risk level and request additional authentication if necessary.
User profile—Use this rule to define a condition based on the user’s LDAP attribute. For example, you can define a rule to deny access if the employee ID of the user matches a specific string. You can use this feature to identify power users who present a greater risk to the organization if their credentials get compromised.
User time of login—Use this rule to define a condition based on the user’s attempts to log in at a specific time. For example, if an employee’s usual login pattern is between 9 a.m. and 5 p.m., you can define a rule that takes action if the login pattern differs from the observed pattern.
Device fingerprint—because the ID cannot be transferred or copied, it’s more reliable than using a browser cookie as an indicator that a device has been used before by a verified user. Depending on how you configure Access Manager, you can also use this metric to control access based on whether or not the device is a work-managed device.
Geolocation—Use this rule to track login attempts based on a user’s geographical location. You can track details ranging from a wide area, such as a country, to a smaller area, such as a region.
Geo-velocity tracker – use this rule to check a user’s current time and location compared to the time and location of the last login. Access Manager supports only the country as the location for this rule. The previous login details are picked from the history database. For example, a user logged in at 2 p.m. IST in Bangalore and tries to re-login at 5 p.m. IST from Hong Kong. Reaching Hong Kong in three hours from Bangalore is not possible. To mitigate such malicious login attempts, you can configure a policy using this rule to ask for additional authentication or deny access altogether, whichever makes more sense for the resource.
Geofencing—If you have OpenText Advanced Authentication and are using the mobile client, you can also use geofencing to control the authentication and access experience.
While the above-listed heuristics can be effective in adaptive access security based on the context of the request, there is a risk of going overboard by defining too many rules based on various criteria for different types of services. At some point, you may have so many access rules defined that you’re unable to calculate their effective results when a user accesses protected resources. This is the advantage of passive behavioral-based analytics available in ITDR environments. It lets you keep your prescribed rules to a minimum as you depend on passive ones to protect you from your security blind spots.
The payoff of going adaptive today
Even when organizations can make their transaction to ITDR, there is still a lot of value in building up the adaptive IAM capabilities available in modern solutions. Regardless of the level of passively driven responses that IT can build into its infrastructure, prescriptive IAM rules are still among the best ways to enforce risk management-driven business and organizational policies. They also let you lower access friction and are designed to optimize productivity and user satisfaction.
