Another category? Why we need ITDR

While the phrase “hackers don’t hack in, they log in” has become cliché now, it’s worth looking at what it really means.

Hacking involves accessing resources without authenticating. By contrast, identity-based attacks involve legitimate account takeover and successful authentication. While definitions of hacking are broad and varied, let’s consider it for now to be “authentication bypass.”

Traditional SecOps processes and tools analyze activity according to tangible wire-like artifacts of network flows and endpoint telemetry, as well as application and system logs. These kinds of risks often don’t look that bad!

This is because, without the context that identity and access management (IAM) expertise brings, these “authentication bypass” risks can easily be marked as normal.

ITDR technology is designed to ingest and analyze identity-specific data. It collects and correlates application logs and network flows and parses their content to uncover identity-based risks. This IAM-fluent parsing is where ITDR fundamentally differs from security information and event management (SIEM) and UBA, which are designed to see the “what” rather than the “who” or “why.”

Let’s take a look at five types of identity-based risks that ITDR is designed to detect, with a cursory look at why SIEM and UBA aren’t optimal for addressing these risks.

Weak passwords are ones with low entropy (or unpredictability). Such passwords can be cracked with minimal computing or time cost.

Strong ITDR technology will analyze how long it is likely to take to crack a password based on a variety of factors, including length and predictable sequences. ITDR can be enriched with context from password intelligence feeds like IBM X-Force Exchange. These will aid in detecting known compromised username and password combinations.

This is a risk that SIEM and UBA were never intended to detect natively.

Because ITDR can scan user accounts in identity providers (IdPs) and end systems like applications and SaaS platforms, it can detect instances of MFA being misconfigured or configured and bypassed.

SIEM and UBA, while designed to detect failed authentications and deviations from past behavior, have no way of seeing if an asset is protected by additional factors of authentication or if an authentication happened on the first factor when it should have been on a subsequent factor.

Password spray is a subtle and nuanced iteration of the brute force attack. By spreading the failed authentication attempts across many accounts, the attacker can avoid triggering account lockout controls.

ITDR is designed to provide visibility into these kinds of attacks by using filter logic to select thresholds of wrong or bad password usage, authentication attempts to a given IdP and over a given time period.

SIEM and UBA are designed to detect failed authentications for single identities in single systems. They are well set up to adopt a wider degree to correlate these more distributed, multi-account attacks without significant custom reconfiguration.

ITDR tech is designed to track connections between identities in local accounts or directories on the one hand, and end systems on the other. This allows it to detect where traffic is supposed to traverse an access-controlling intermediary but hasn’t.

By contrast, SIEM and UBA are not as able to enrich and contextualize their analyses with access policy elements. They are also more intended to detect anomalies within isolated systems than ones that straddle multiple nodes in the enterprise’s stack.

Risky authentication protocols are ones regarded as legacy or demonstrably insecure, such as network level trust manager (NTLM), in addition to ones using unencrypted connections such as hypertext transfer protocol (HTTP) or lightweight directory access protocol (LDAP) not protected by transport layer security (TLS). More and more, organizations are opting to define Kerberos as a risky protocol.

Good ITDR technology should be designed from the bottom up with the detection of these protocols in mind. SIEM platforms may be able to detect the presence of these protocols but will be more limited at mapping out the coordinates of the client browser, IdP server and application/resource server triangle in an authentication or federation flow, which may be leveraging these risky protocols.

This list of five risks is by no means comprehensive, but it is intended to broadly portray the differences between ITDR, on the one hand, and UBA-enabled SIEM, on the other.

The fact that ITDR technology can parse and correlate data from logs and network flows in a way that “speaks IAM” is what enables it to detect these identity-based risks. The engineers who write the parsers and correlation rules ensure that the technology comprehends the meanings in log and packet payloads related to identity. This might include pulling apart the contents of LDAP authentication requests/responses, security assertion markup language (SAML) assertions, or JSON web tokens (JWTs). The technology is also designed to understand and track the creation and maintenance of user sessions. Perhaps most importantly, ITDR is designed to track activity as it traverses the system of systems we all operate in today in the spirit of integration engineering.

While the established SecOps practices of interrogating data in logs, network flows and endpoint telemetry are still valid and important, it is clear that identity-specific detection techniques are another dimension of SecOps that requires a seat of equal importance at the table.

Contact Cian Walker at IBM to book a demo of IBM Verify Identity Protection, our AI-infused ITDR platform, or to be put in touch with your local client-facing technician.