06/28/2024 | News release | Distributed by Public on 06/28/2024 15:33
Identity is foundational to modern security strategy. Identity-based attacks are on the rise, and most data breaches are caused by stolen credentials. With more than 18,000 customers and an Identity platform that performs billions of authentications every month, Okta is at the frontline of most of these Identity-based attacks.
In the past month alone, Okta blocked around 2.38 billion malicious requests (more than 20% of all login attempts to the Okta workforce Identity Cloud) with a pipeline that separates malicious traffic from legitimate traffic in real time.
In this blog, we'll describe the details of the various layers in this pipeline with particular focus on the AI-based components. We'll also describe how customers can use these features to protect their users from various types of Identity-based attacks.
We need a multi-layered defense in-depth strategy to defend against Identity-based attacks for the following reasons.
There are two main aspects to the detections at every layer in this stack.
While we try to optimize for both, we prioritize one based on the criteria described below, which differ from layer to layer.
Let's look at the details of all the layers in this pipeline. The layers are described in the order in which they are invoked in the path of a login request. Note that the order of these layers and the functionality supported in each layer may change in future.
This is the entry point of a request and the first line of defense. There are many controls in this layer to detect and protect against DDoS attacks. To help protect against large-scale credential-based attacks, we built a pipeline to identify malicious IPs that are blocked for all tenants at the edge. Okta customers can't configure any part of the functionality supported at the Okta edge.
Customers can block specific combinations of IPs, locations, IP service categories, and autonomous system numbers (ASNs) by creating blocklist zones. Requests matching these zones are blocked from accessing anyOkta Workforce Identity Cloud endpoint.
Many credential-based attacks involve requests routed through anonymizing proxy services. We recommend customers turn on the recently released self-service Early Access feature that creates a default zone to block all anonymizing proxies. If customers want to add exemptions for certain IP service categories, they can use another recently released self-service Early Access feature that introduces support for enhanced dynamic network zones.
Over the past month, Okta blocked around 318 million malicious web requests based on zone configurations. Okta relies on multiple external vendors to resolve the location, IP service categories, and ASN associated with an IP.
We continue to scale zones by focusing on the following two aspects.
Quality: To reduce false positives and negatives resulting from stale data feeds, we built data pipelines to refresh external data feeds within 24 hours of their availability.
Latency: We resolve IP metadata for every web request. To deal with this scale, we continuously make improvements to maintain a very low latency (p95 of less than 50 milliseconds) in resolving metadata from all the external providers.
ThreatInsight is Okta's native AI-driven feature to detect and protect against large credential-based attacks. It has two components - detection pipeline and enforcement pipeline.
We built streaming and batch data pipelines to detect malicious IPs involved in large-scale Identity-based attacks like password spray, credential stuffing, and brute force. We detect both cross-tenant and tenant-specific malicious IPs.
The detection pipeline also includes heuristics and ML models that flag tenants under large credential-based attacks. These models detect anomalies in login failures at the tenant level within minutes after an attack starts. Based on the output from these models, we notify customers through SystemLog and automatically flag malicious IPs more aggressively for the tenant under attack. These models help Okta to notify hundreds of tenants under attack every month.
We built a low-latency enforcement pipeline that performs these two actions (in this order):
Running ThreatInsight checks before rate limiting and flagging of suspicious requests helps reduce the chances of legitimate users running into rate limit violations because of large credential-based attacks.
Over the past month, ThreatInsight blocked around 2.08 billion requests and 3.4 million IPs associated with over 150 endpoints for more than 10k tenants. During some high-volume attacks, ThreatInsight has blocked >200k IPs every hour at a rate of >100k requests every minute. More than 31k IPs were seen in attacks involving multiple Okta tenants.
We recommend turning ThreatInsight to block mode to protect your tenant against large-scale credential-based attacks.
We continue to scale ThreatInsight by focusing on the following two aspects:
Quality: To reduce false positives and false negatives, we continuously improve our data pipelines and detections so that we identify malicious IPs within seconds of suspicious activity and make those IPs available for enforcement within a few minutes after detection.
Latency: We run ThreatInsight checks for every single web request that hits Okta Workforce Identity Cloud and we do that even before rate-limiting checks kick in. To do this at this scale, we made many enhancements to the way we cache and store the features for ML model scoring to ensure that the p95 latency of ThreatInsight evaluations is below 50 milliseconds.
Okta platform enforces rate limits at a tenant level,which is a combination of Okta managed rate limits and customer configurable rate limits. This layer doesn't directly deal with detecting and blocking Identity-based attacks. One component of this layer that is relevant for Identity-based attacks is the support for maintaining different rate limiting counters for legitimate and malicious requests.
We have the complete context (user, device, etc.) of the request at the policy evaluation layer.
Customers can configure IP, dynamic and enhanced dynamic network zones based on various combinations of IP, Geolocation, IP service categories and ASNs and use these zones in various types of policies (ex: Global session policy, Authentication policy, etc.). When zones are not blocklisted and configured in policies, they're not enforced for every single web request. They're only enforced for the requests that are scoped to that policy.
Behavior detection analyzes patterns in user behavior to detect anomalous user activities. Okta supports multiple types of anomalous behavior detections (ex: New IP, New Country, New Geo-Location, New Device, Impossible Velocity) scoped to the user. Customers can define what is risky for their tenant by combining these behaviors in global session and authentication policies. For some tenants, any login from a country the user never logged in from in the last 10 attempts may be suspicious. For other tenants, any login from a device and an IP the user never logged in to from in the last 100 attempts may be suspicious. Behavior detection provides a rules engine to enable customers to customize these anomalies so that they can optimize for false positives or false negatives.
To support behavior detection, we built a data pipeline to build user profiles based on historical activity of the users.
Risk scoring combines the signals from multiple layers of the pipeline to determine the risk level associated with a login attempt. Risk scoring removes the complexity of configuring behaviors, zones, and other conditions. Customers can simply configure the risk level in policies and set up actions such as MFA. Okta determines what is risky by combining various contexts (location, device, threat, behaviors, etc.).
Risk engine aggregates the risk across the following contexts to determine the risk level of a web request:
We use machine learning in this layer to identify the relative weights of the various features across various contexts associated with a request. The models are trained using the users' MFA access patterns (success, failure, and abandonment of MFA associated with various behavioral signals of the users).
We are launching a new version of the risk model as part of the newly launched Okta Identity Threat Protection. Customers who buy the Okta Identity Threat Protection SKU benefit from continuous risk evaluations - we run risk evaluations at login and also continuouslyto determine the risk associated with sessions. Continuous risk evaluation relies on a more sophisticated model using more features (i.e.: Device signals from OktaVerify, Anomalous ASN, Anomalous UserAgent, etc.). In addition, we introduced the concept of user risk as part of this product. User risk captures the stateful risk associated with a user identity and aggregates the risk across sessions, devices, and all the signals we get from multiple third-party security providers.
Over the past month, Okta evaluated more than 3 billion login requests for risk. We recommend configuring strong authentication in authentication policies for high-risk login attempts.
We continue to scaleRiskEngine by focusing on the following two aspects:
Quality: To reduce false positives and false negatives, we continuously improve models used to detect risk across various contexts and how we aggregate the overall risk. We also improve accuracy by scaling our data pipelines to use the latest activity associated with the users. Within a second after a user performs certain actions in the system, the user's profile is updated with this information.
Latency: We run RiskEngine checks with a p95 latency of below 50 milliseconds for every login attempt that hits Okta Workforce Identity Cloud for Adaptive MFA customers.
Have questions about this blog post? Reach out to us at [email protected].
Explore more insightful Engineering Blogsfrom Okta to expand your knowledge.
Ready to join our passionate team of exceptional engineers? Visit our career page.
Unlock the potential of modern and sophisticated identity management for your organization. Contact Salesfor more information.