With the vast majority of cyber breaches involving identity compromise, Identity Threat Detection and Response (ITDR) is a critical capability in any organization’s cyber defense strategy. However, while ITDR capabilities are mostly available for on-premise assets, doing ITDR in the context of the cloud is a tedious task, often involving post-facto analysis of a threat that has already passed. Not so, with SGNL, but first let’s see what ITDR is all about.
What Is ITDR?
There are two broad areas in ITDR, as indicated by the name: Detection and Response.
Like in network threat detection, the identity threat detection needs to rely on observing and identifying activities that constitute a threat to an organization’s identities. Although sessions and identities are sometimes treated differently, I’m going to group them together in this post from a threat analysis point of view.
Like in network threat detection, the identity threat detection needs to rely on observing and identifying activities that constitute a threat to an organization’s identities.
Identity threat detection activities can be categorized into three areas:
Pre-breach detection
Even before an identity is breached, there may be telltale signs:
- There is a high number of attempts to compromise a user’s password by:
- Password spray attack: Trying a large number of known passwords and their variations
- Brute force attack: Trying all possible password combinations
- A username and password belonging to one of your users has been found on the dark web
Breach-time detection
- Impossible travel - login: The same user logs in from locations that are geographically impossibly far apart
- Impossible travel - session: The same session is used from multiple user agents and locations
- Anomalous login: The sign-in event occurred outside of normal time and / or geographical patterns
Post-breach detection
- Anomalous user behavior within specific systems or applications. This can include detecting specific actions such as privilege escalation by the user
- Lateral movement across systems and applications
Response
There are multiple response strategies depending on the threat that was detected:
- Limit the user’s session access to mostly low-risk activities
- Limit the user’s account permissions to mostly low-risk activities
- Terminate the user session with specific or all applications
- Force the user to re-authenticate
- Force the user to re-authenticate with a stronger authentication factor (e.g. MFA or passkeys)
- Lock the user’s account and force them to re-establish their credentials as though they were registering for the first time
Cloud versus on-premise detection
The strategy to perform “ITD” on-premise mostly relies on observing network activity in your data center or corporate network. However, doing this in the cloud requires a completely different strategy.
The strategy to perform “ITD” on-premise mostly relies on observing network activity in your data center or corporate network. However, doing this in the cloud requires a completely different strategy, because most cloud systems do not enable real-time network observation. The “Cloud ITD” strategy therefore currently comes down to two aspects:
- Analyzing existing permissions: Some products will integrate with the cloud services’ APIs in order to help understand what the current permissions posture is. Therefore, these products are called “CSPM” products (Cloud Security Posture Management)
- Analyzing logs for past breaches: One can perform post-breach detection by analyzing log information from cloud services, and flagging certain accounts as those requiring a response
CAEP - the “R” in ITDR
Once a system has detected something that presents a threat to one or more identities or sessions, the information needs to be conveyed to other systems in order for the overall security of the organization to improve. This gets even trickier in the cloud, where each system is running in an independent network. There are a few considerations here:
- Standard, expressive format: The means should be adopted by everyone regardless of the technology they use. An open standard is required for this. The standard needs to be able to express a variety of information that need to be conveyed between systems
- Non-prescriptive communication: Since each system is relatively independent, one cannot have a standard that commands or requires another system to act in a specific manner in response to an event. The standard used to convey information should not prescribe any particular response to it.
- Asynchronous: The communication should not require any specific guarantees of uptime on target systems, but at the same time guarantee that events will be communicated
- Trust and Negotiation: Each system should be able to decide what information to receive from which other system.
All these principles are embodied in the Shared Signals Framework (SSF) and the Continuous Access Evaluation Profile (CAEP) standards. CAEP, together with SSF, is thus ideal to express the threats and responses in ITDR.
Prevention rather than detection
Employing IGA and PAM solutions can help you reduce your users’ static permissions thereby reducing the advantage attackers get from identity breaches. However, since these products rely on statically defined roles, attributes and entitlements, they can only aim for “least privilege”, but not offer zero standing privilege (ZSP). In the real-world, it has proven really hard to reduce the “blast radius” of an identity breach even when one has employed IGA and PAM solutions.
Since conventional IGA and PAM rely on statically defined roles, attributes and entitlements, they can only aim for “least privilege”, but not offer zero standing privilege (ZSP).
How SGNL leverages CAEP to provide the “R”
SGNL provides a modern privileged identity management platform, which fully supports CAEP. It can be used stand-alone or to complement existing PAM or IGA deployments to achieve:
- Prevention: With SGNL, it is possible to achieve Zero Standing Privilege (ZSP) because the SGNL platform will update permissions as needed. Because the SGNL platform obtains the context of the access from your systems of record, no additional manual steps are required to grant or remove permissions (as and when they are needed or no longer needed)
- Detection: Since SGNL is integrated into your cloud services and custom apps, it can also detect anomalous user activity such as lateral movement across cloud services. You can write policies to respond to such activity. SGNL can consume CAEP events and take action to revoke or restrict user sessions
- Response: SGNL can, in real-time, eliminate user permissions from live sessions or future sessions of a user in response to a detected identity threat, and generate CAEP events to inform other systems of its actions.