Defending Against Threats in Identity Security; Part 1: Detect

While many understand the need for security practitioners to evolve with attackers, the hard truth is that current solutions already do not do enough to combat advanced security attacks (and we would be remiss not to also mention that tools alone also aren’t sufficient, you need the human element as well like trainings, processes, etc.). This isn’t hypothetical: these advanced attacks are starting to emerge, and current solutions are often insufficient in detecting them.

For instance, in the CircleCI breach this past December/January, the attacker compromised an Okta session by stealing a session cookie which allowed them to impersonate the employee without having to sign in themselves. This exposes a gap between traditional IAM tools and current attacks: what can MFA or SSO do if an attacker can bypass needing a password to sign in to the SSO provider without interacting with MFA at all?

Since its release last year, the 2022 Gartner Report has fundamentally changed how we see identity and access management (IAM). Much of this is due to Identity Threat Detection and Response (ITDR), a phrase coined in the Gartner report that offers a new approach to changing security threats.

According to the report, “ITDR is 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.”

In this two-part series, we break down the defense against emerging problems in identity security into their two major steps: Detect and Remediate. This is Part 1: Detect.

Part 1: Detect

Traditional detection models, as preventative controls, aim to avoid misconfiguration, vulnerabilities, and exposure. According to Gartner, these models avoid misconfiguration by ensuring “that the IAM configuration is continuously monitored for suspicious changes and that appropriate steps are taken to investigate and, if necessary, resolve issues.” Additionally, these measures also help to address “commonly exploited vulnerabilities in the identity infrastructure via patching or compensating controls” and “exposure by reducing the attack surface by removing unnecessary or excessive privileges.”

The standard IAM model off of this structure is that MFA prevents a bad actor from logging in (i.e., getting a session) because even if they have a username/password, they don’t have the additional factor, so sign-in fails. However, as we saw with CircleCI, you can obtain session tokens through malware (infecting a machine that has a session cookie) or by purchasing stolen sessions online, which means that attackers might be using MFA-backed sessions (the correct user used MFA to get the session, but then the attacker stole the session).

Since traditional MFA isn’t sufficient to prevent these kinds of attacks, you need to be able to detect stolen session tokens that are being used. Detecting session token abuse (i.e., detecting that they have been lifted from the original device) is largely unsolved in IAM today for various reasons. For one, IdP vendors typically sell to IT as opposed to security and IT together (a difficulty we elaborate on in our piece, “Identity Is a Co-owned Problem Between Security and IT”), making it challenging to get security stakeholders involved and causing a gap in security products focused on identity.

These “major detection gaps between IAM and infrastructure security controls,” as the Gartner report illustrates, are a key part of identity’s security threat detection problem. The report goes on to clarify that “IAM is traditionally used mainly as a preventive control, whereas infrastructure security is used broadly but has limited depth when it comes to detecting identity-specific threats.”

One new step in detection is scanning access logs to identify patterns in access. Typically there are two ways to go about this when bridging that detection gap: you can either scan access logs and compare them to actual entitlements to identify unused access (preventive, IAM/IdP) or scan access logs to identify anomalous access (threat hunting, D&R).

While problems with IAM and IdP tools have been illustrated above, there are also problems with current D&R (Detection & Response) tools needing to better ingest identity signals. The traditional D&R “hunt” model is designed to look for a very specific pattern within a single timespan (for example, >10 GB data exfiltrated over 7 days). Contradictorily, identity-related threats often emerge as some kind of user behavioral pattern that emerges through continuous observation of user behavioral baseline (for example, a user has never logged in on this day of the week for the last year). This is exacerbated by a shortage of talent who knows identity-related security issues well, resulting in bad hunts that don’t detect relevant identity-security problems or miss signals that emerge.

Despite the challenges, there are security mitigation strategies that neutralize cookie theft if it occurs, like device trust and channel-bound cookies. With device trust, your device must be enrolled in a corporate device management platform (MDM) in order to authenticate to any application. However, the issue here is that you can compromise a “low-privilege” device (e.g., a warehouse associate) and then use a “highly-privileged” user’s cookie (e.g., an SRE) on the low-value device because the device is still technically a corporate device.

With channel-bound cookies, you “bind,” or strongly associate, a cookie with a client certificate installed on the device or some other cryptographic material generated by the client. If the token is stolen from the client, as long as the original cryptographic material is not stolen, the cookie/token is safe. The idea here is that it is much harder to steal cryptographic material off of a device than a token because the certification likely lives in a separate part of your computer called a TPM (trusted platform module) that will not allow you to copy out the private cryptographic material under any circumstances.

As these examples illustrate, all is not lost! There are solutions starting to show up from across the identity space, and we’ll talk more about them soon. To get notified when we post more about these solutions (and to stay up to date with Crosswire on all things identity and infosec), sign up to receive our updates below!

This is Part 1 (Detect) of a series on changing security threats and approaches. Continue on with Part 2 which covers 'Remediate.'