How Okta Protects You Against Identity Attacks
From Okta’s position at the “front door” of many organisations, we tend to see a significant number of authentication-related cyber attacks. This presents a real risk to organisations, especially when exacerbated by poor password habits. As we detailed in our 2019 Businesses at Work report, 40% of survey respondents reported using only 2-4 passwords for most accounts, while 10% reported (re)using one password.
Naturally, we also get questions from companies on how Okta can help protect them from these threats. This isn’t a simple question to answer because these attacks can take many different forms and have different objectives, and appropriate countermeasures need to take into account an organisation’s specific use cases. So there is no silver bullet (this is cybersecurity after-all).
But yes, we can help.
Below, we’ll go through some examples of attacks we tend to see and discuss the measures Okta takes to protect our platform, as well as our customers, from cyber attacks.
What We See
Many of the attacks Okta sees targeting authentication are credential stuffing and password spraying attacks. As a quick recap, to perform credential stuffing attacks, attackers take a list of stolen username/password combinations and automate logins into target accounts. To perform password spraying attacks, the attacker tries common passwords across multiple accounts in an attempt to avoid detection.
Most customers have also integrated Okta with other cloud-based business applications like Salesforce, Zoom, or Microsoft Office 365. Attackers targeting credentials for these apps will also hit Okta as the identity provider, so we also get visibility into the authentication attacks on these applications. The bulk of these attacks are targeted at Office 365.
Some password spraying and credential stuffing attacks against Okta, customer Okta tenants, and applications federated into Okta can also lead to user account lockouts as a side-effect. This not only creates a security issue but frustrates end users and IT teams as well.
In order to protect the Okta service and our customers from these cyber attacks, Okta divides protection against authentication-based attacks into two areas of focus: service-level responsibilities and product-level features.
Okta Service-Level Security
Service-level responsibilities are best-practice security measures that SaaS providers are responsible for providing to all customers as part of a shared security responsibility model. These are often services and operations running in the background, invisible to our customers. The goal is to protect the cloud service itself, as well as all tenants in a multi-tenant service. You can think of these as functions a security or infrastructure team would be responsible for if you were running your own servers and software on-premises to maintain service security. With cloud services, because a central investment in security operations and controls applies to all customers, the economics of providing cybersecurity play out to everyone’s benefit.
We take our responsibility of protecting the Okta Identity Platform very seriously since it affects all our customers as well as Okta employees. This responsibility is spread out across multiple teams within Engineering and Security at Okta; we’ll discuss a couple of key roles below.
Authentication and API Call Limits
One of the primary ways Okta combats against DDoS and brute force attacks is to enable rate limits on authentication and API calls to Okta services. We set various organisation-wide and concurrent rate limits so that legitimate calls to Okta are not affected, but spikes in traffic that are often characteristic of DDoS attacks are dropped, preventing lockouts to the Okta service. (Of course, if you have planned development or testing that will increase your traffic, we are happy to work with you to adjust rate limits to your tenant.)
Proactive Detection and Prevention
The second major service area we focus on is the proactive detection and prevention of attacks against the Okta platform. Our security operations team investigates suspicious events such as mass login failures across multiple tenants or authentication attempts from malicious sources. Once these events are confirmed as malicious, these attempted attacks are blocked at the network level so all customers are protected.
As a network-level block can also adversely affect customers, we require a high level of confidence that an IP is malicious before we block it. With such a high confidence level required, this service focuses on attacks to the Okta platform itself, as we often do not have enough insight into each customer's use case to confirm malicious intent on specific tenants. All our customers do benefit from the prevention of these attacks to the overall Okta platform and service though.
However, we also understand customers look to Okta to help protect their organisation's authentication services and applications sitting behind single sign-on or MFA. That's why Okta has also invested in product features to protect against identity attacks against individual customer tenants. We see many of these capabilities as core security features that should be available to all customers to maintain baseline security. Others solve specific use cases and are made available to our customers through specific products and SKUs. Read on for a highlight of some of our product-level security features.
Product-Level Security Features
At Okta, we believe the foundation of a Zero Trust security strategy starts with identity, so we’ve built all our solutions with security in mind. As it relates to protecting customer tenants and applications behind Okta from the aforementioned attacks, we’ll highlight just a couple of key features that will help organisations protect themselves from identity-based attacks.
Okta ThreatInsight: Leveraging Network Effects
The first feature we’ll highlight is Okta ThreatInsight. We first announced ThreatInsight at Oktane18 to help customers take advantage of the threat signals Okta and our security team surfaces from our global network of customers and partners. Here’s how it works.
Okta sees many suspicious events that we cannot guarantee as malicious and do no block to avoid impacting legitimate users. An example could be a hotel hosting a conference. In this scenario, it’s quite common to have multiple login failures across multiple organisational accounts that appear to come from the same source (i.e. the hotel’s network). In this case, blocking the hotel’s IP addresses would actually be blocking legitimate authentication attempts. But with ThreatInsight, customers can take advantage of Okta threat intel generated by our security program and take action by applying step-up authentication in these ambiguous cases. This allows customers to benefit from network effects and intel that an individual organisations do not have visibility into.
As of the writing of this blog, Okta ThreatInsight is available in EA to all Okta customers. (Customers must opt-in.)
Risk-Based Authentication: Security + Usability
To take authentication context and ThreatInsight to the next level, Okta has also introduced risk-based authentication. Now, organisations can take advantage of login context like device, location, and user biometrics to take dynamic actions based on risk level. This means step-up authentication can be automatically implemented in high-risk scenarios, reducing the burden on admins to create and manage complex policies. Through machine learning, Okta can also refine login context, continually improving security as well as user experience.
At the time of this writing, risk-based authentication is available in Beta to Okta Adaptive SSO and Adaptive MFA customers.
Pre-Authentication Policies, Factor Sequencing, and Passwordless
Account lockouts are one of the consequences IT and security teams must grapple with from authentication attacks. As many organisations implement temporary account lockouts when an account has exceeded a set number of failed login attempts, identity attacks can result in DoS-like results with end users unable to access resources. Pre-authentication sign-on policies, factor sequencing, and passwordless authentication can be an effective countermeasure to prevent these attacks and lockouts.
Okta’s pre-authentication sign-on policy evaluation helps organisations reduce the chances of user account lockouts due to brute-force identity attacks. By enabling this feature, Okta can evaluate sign-on policies prior to the evaluation of a password or factor. For example, organisations can deny access from certain geolocations except from specific IPs. Authentication attempts outside of specified IPs do not go against the lockout attempt number, thus decreasing the number of account lockouts from brute-force attacks. Attackers also will not know if a username they tried is invalid or not. This can be combined with factor sequencing for even more effective prevention against locked accounts.
With factor sequencing, passwords don’t have to be your first factor. You may choose to ask for a “something you have” or “something you are” factor first, like Okta Verify Push or a biometrics, before asking for a password. As an attacker would not be able to supply an appropriate response for these authentication prompts, account lockouts from password-based attacks would be less likely.
Finally, with Okta Modern Passwordless, since there is no password involved at all, there's even less chances for account lockouts from failed login attempts since attackers would be incapable of using credential stuffing or password spraying. You can also layer on Okta contextual access policies so that you can specify factor, sequence, and when to prompt based on risk signals like user, app, device, and location.
Okta has built these and other security features directly into our solutions to help customers combat identity-based attacks to their individual tenant. Our solutions like Adaptive Multi-factor Authentication and Lifecycle Management also help solve other security challenges like mitigating the risk of phished credentials, including phishing reverse proxies, and reducing the attack surface area.
Pre-authentication sign-on policy evaluation is available in EA to all Okta customers.
Factor sequencing and Passwordless are available in Beta to Okta Adaptive SSO and Adaptive MFA customers.
Cloud Security - A Shared Responsibility
Achieving end-to-end security can be a daunting task, and here at Okta, we're dedicated to helping our customers achieve their security goals while enabling the business. As a cloud service provider, we're committed to ensuring the security of our cloud platform for all our customers. We see this as part of the core responsibilities of a service provider.
In fact, from our perspective, cloud customers like you should expect security services to accumulate, meaning each service provider’s protections build on the others. For example, if you’re an Okta customer and an Office 365 customer, you’re entitled to the service-level protections of both.
Individual organisations have a critical role to play here. While service providers are responsible for ensuring the security and reliability of the platform plus underlying services, you're the one in charge of the security of your organisation's tenant.
With the combination of our security product features and logging capabilities, we give you the ability to effectively take control and manage the security of your Okta tenant in the face of credential attacks such as phishing and password spraying. We've also created some in-depth resources on how we secure Okta and best practice documentation to help. Ready to get started? Check out these whitepapers, as well as our Security Roadmap video embedded below.
Follow Yassir Abousselham
