Protect against identity-based attacks by sharing Cloudflare user risk scores with Okta

Cloudflare One, our secure access service edge (SASE) platform, is introducing a new integration with Okta, the identity and access management (IAM) vendor, to share risk indicators in real-time and simplify how organizations can dynamically manage their security posture in response to changes across their environments.

For many organizations, it is becoming increasingly challenging and inefficient to adapt to risks across their growing attack surface. In particular, security teams struggle with multiple siloed tools that fail to share risk data effectively with each other, leading to excessive manual effort to extract signals from the noise. To address this complexity, Cloudflare launched risk posture management capabilities earlier this year to make it easier for organizations to accomplish three key jobs on one platform:

1. Evaluating risk posed by people by using first-party user entity and behavior analytics (UEBA) models

2. Exchanging risk telemetry with best-in-class security tools, and

3. Enforcing risk controls based on those dynamic first- and third-party risk scores.

Today’s announcement builds on these capabilities (particularly job #2) and our partnership with Okta by enabling organizations to share Cloudflare’s real-time user risk scores with Okta, which can then automatically enforce policies based on that user’s risk. In this way, organizations can adapt to evolving risks in less time with less manual effort.

Introduced earlier this year, Cloudflare’s user risk scoring analyzes real-time telemetry of user activities and behaviors and assigns a risk score of high, medium, or low. For example, if Cloudflare detects risky or suspicious activity from a user — such as impossible travel, where a user logs in from multiple geographically dispersed locations within a short time frame, data loss prevention (DLP) detections, or endpoint detections suggesting that the device is infected — the user’s risk score will increase. The activity leading to that scoring is logged for analysis.

Cloudflare includes predefined risk behaviors to help you get started. Administrators can create policies based on specific risk behaviors and adjust the risk level for each behavior based on their company’s tolerance.

Customers that opt in to this new integration will be able to share continually updated Cloudflare user risk scores with Identity Threat Protection with Okta AI. If a user is deemed too risky, Okta will automatically take action to mitigate the risk, such as enforcing multi-factor authentication (MFA) verification or universally logging the user out from all applications. 

For example, a user has a low risk score from Cloudflare that was shared with Okta, but after exhibiting “impossible travel” behavior, the user’s risk level is raised to high. Cloudflare sends the updated score to Okta, which triggers a Universal Logout and an MFA challenge if the user attempts to log in again. Access to sensitive systems may be revoked completely until the user is verified. 

^{Figure 1. Diagram showing risky behavior by a user, resulting in sign-out.}

We begin by detecting risky behavior from a user (such as an “impossible travel” event between two geographic locations). Instances of risky behavior are called Risk Events. We perform two actions when we observe a Risk Event: logging the event and evaluating whether further action is required. For customers that have enabled Risk Score Sharing with Okta, any change in Risk Score is transmitted to Okta’s Identity Threat Protection (ITP).

Upon receiving a new event, Okta evaluates the change in user risk against the organization's policies. These policies may include actions such as re-authenticating the user if they become high risk.

When we design new features, we aim for them to be extensible across the industry. For this reason, we chose the OpenID Shared Signals Framework Specification (SSF) to be the foundation of our transmission format. By doing this, we are able to leverage current and future providers that support the standard. The core functionality of SSF revolves around sharing Security Event Tokens (SETs), a specialized version of a JSON Web Token (JWT). Providers can produce and consume Security Event Tokens, forming a “network” of shared user risk information between providers.

^{Figure 2. Diagram showing a Security Event Token being transmitted from Cloudflare to Okta.}

The diagram above (Figure 2) details the process of sharing risk. When sharing Risk Score changes with Okta, we bundle metadata about the risk event and user into the body of a Security Event Token. Following this, the JWT/SET is signed using our private key. This is an important step, as the signature is used to verify the sender's identity (cryptographic authenticity) and that the payload body has not been tampered with (cryptographic integrity). In plain terms, this signature is used by Okta to verify that the event is unaltered and was sent by Cloudflare.

Once Okta has verified the authenticity and integrity of the SET token, they may use the risk metadata within the body to execute Identity Threat Protection policies defined by the customer. These policies could include actions such as “if a high risk score is received from Cloudflare, sign out the offending user”.

Learn more about the Shared Signals Framework and CAEP in Okta’s announcement blog post.

Cloudflare customers can easily enable risk score sharing from the Cloudflare One SSO setup page. This is available to customers whether you’ve already integrated with Okta or are setting up the integration for the first time. You will also be able to confirm that the feature was enabled in your audit logs.

If you’ve already integrated Okta within your Cloudflare One dashboard:

1. As an admin, navigate to Settings > Authentication and select the Okta login method.

2. Select “send risk score to Okta.”

If you haven’t yet integrated Okta within your Cloudflare One dashboard:

1. As an admin, navigate to Settings > Authentication and select a new login method.

2. Follow the instructions to add Okta as an SSO.

3. Select “send risk score to Okta.”

Now, whenever a user’s risk score changes within the organization, information is sent to Okta automatically and an audit log is documented.

In conclusion, the ability to incorporate rich context is essential for making accurate and informed access decisions. With vast amounts of data — including user logins, logouts, websites visited, and emails sent — human analysts would struggle to keep pace with modern security challenges. Cloudflare provides context in the form of a risk score, enabling Okta’s risk engine to make more informed policy decisions about users. This sharing of information powers the continuous evaluation required to enforce Zero Trust policies within your organization, ultimately strengthening your organization’s security posture.

Not yet a Cloudflare One customer? Reach out for a consultation or contact your account manager.