Well, Okta was compromised today. (At least, we think it was compromised. Details are still being sorted out.) These things happen. When it comes to valuable targets like Okta, clients should know what their breach response will be. Hacking groups are advanced, persistent and determined. Okta isn’t Lapsus$’ first target, and it won’t be their last.
[Read more on the breach: Statement from Okta. Statement from attacker. Article in WIRED.]
But we’re not here to talk about that. We’re here to talk about how to make sure incidents like these don’t critically impact the integrity of your infrastructure.
What is Okta and why does this SSO breach matter?
Okta’s breach is a big deal, if true. Okta is a Single Sign On (SSO) provider and has become an extremely popular way for organizations to gate access to their business applications (e.g., email, docs, payroll systems, Slack, GitHub, etc).
Okta is amazing for employees because it alleviates the burden of having to maintain countless login passwords and MFA credentials for each of the company’s corporate systems. Okta is also amazing for IT administrators because it creates a central point where they can control who can log into what system, with which credential, and maintain access logs of who logs into what system. This means IT admins can see who logged into the bank account right before money was stolen or who logged into production right before a microservice failed.
In other words, Okta reduces the risk that a compromise of an employee’s credentials leads to a compromise of the company’s systems.
But what happens if Okta itself is compromised?
In the worst case, given this is an SSO breach, the gate to all the corporate systems mentioned above could be breached. Even more, the compromise of Okta means there is a risk that these systems will themselves be breached. That’s why everyone is worrying about preparing an Okta beach response today.
All is not lost
Well, everyone is worrying except the CEO of Cloudflare, who tweeted this out this morning:
In other words, Cloudflare isn’t worried because they’ve set up Okta so that it is not a single point of compromise. This is also known as defense in depth.
How can we use the concept of defense in depth to mitigate the risk of an SSO provider being compromised?
Let’s talk about MFA
Generally speaking, when we think about authentication breaches, the first mitigation anyone thinks about is Multi-Factor Authentication (MFA). In other words, rather than just having the user log in with their username and password, an additional factor to log in is required, like a hardware key or the TOTP protocol to an authenticator app on a phone.
MFA is great at preventing user compromise. MFA ensures that a compromise of a username and password does not result in a breach of a system. Because an attacker doesn’t have access to the second factor, the integrity of the system is preserved.
But would MFA prevent a compromise of the SSO provider?
The answer is, it depends.
It depends on whether your MFA provider is being used in parallel to Okta or in series with Okta.
Take a look at the figure below:
If your MFA provider is Okta, and Okta gets compromised, then the MFA won’t help prevent the SSO breach. That attacker will just ignore the MFA and continue to fraudulently authorize users to access resources.
If you are using an independent MFA provider whose information is just being ingested by Okta, then the MFA provider still won’t help prevent a breach. Again, the attacker will just ignore the ingested MFA information and continue to fraudulently authorize users to access resources.
In both of these cases, the problem is that you are using MFA in series with Okta. So the attacker can just ignore the MFA and go after Okta directly.
On the other hand, if you are using an independent MFA in parallel with Okta, your target will be protected. That’s what the bottom of the figure is showing. If the target is getting information directly from the MFA provider, independently of Okta, then a breach of Okta will not result in a breach of the target.
So where does this leave us?
- MFA in series with SSO will protect your systems from compromises of the user.
- MFA in parallel with SSO will protect your systems from compromises of your users AND from compromises of your SSO provider.
Another way to think about this is having MFA in parallel is like having a separate root of trust for user authentication that is independent of your SSO provider (Okta).
Ok but how do you actually respond to something like an Okta breach?
Building MFA in parallel to SSO can be tricky. But it can be done. Let me offer a few examples, focusing on my home area of access to backend infrastructure (and specifically Linux servers), since that’s what I know best (and where I have the most experience).
Something else that we see quite often is for users to use SSO to access their VPN, and then to use an SSH key to log into an individual target. This is indeed a “layering” of parallel defenses, because if the SSO provider is popped, the attacker still needs to have possession of the SSH keys in order to breach the targets.
However, I don’t like this VPN+SSH architecture very much, because it requires users to hold long-lived credentials (SSH keys) that are difficult to manage, rotate, and revoke; Furthermore, SSH keys have been targeted by attackers for decades (see the Akamai FluffyBunni attack from 2001). In other words, these SSH keys violate a key tenant of zero-trust, which states that users should not hold long-lived credentials.
A more appealing approach is to implement a separate hardware-token authentication (like a YubiKey) that is checked by each individual target, independently of the SSO provider. So your users first use SSO to get into the targets (e.g. because the SSO gates their access into a VPN), and then the targets themselves require you to perform a hardware key authentication each time you seek to access them. As you can see from the figure, the hardware token MFA provider is checked in parallel with the SSO provider. That way, an SSO breach does not lead to a compromise of the targets.
However, I’ve heard lots of people complain about hardware keys getting lost or broken or being painful to manage.
So if you don’t like hardware tokens, you can also use something like a Duo Unix PAM module. The architecture is the same as above, except that the users perform a Duo authentication each time they want to gain access to the targets, instead of using a hardware token.
Finally, here is what we do here at BastionZero. With BastionZero, you run an agent on your targets that validates against two independent roots of trust. One root of trust is your SSO provider. The other root of trust is the BastionZero cloud service (which users authenticate to using MFA!). Accessing a target requires authorization from both the BastionZero cloud server AND your SSO provider. That way, if one of the roots of trust is compromised but the other is not, your targets remain secure. Read more about it here.
Summary
SSO is fantastic and super convenient. But SSO breaches happen.
We can and should have a breach response plan for Okta or any other provider, mitigating risk by implementing defense-in-depth. Instead of setting up your SSO providers as a single point of compromise, consider putting your SSO in parallel with a separate authentication or MFA provider.
That way, you can use two independent roots of trust to control access to your sensitive systems. So that a breach of your SSO provider does not lead to a compromise of your targets.
See BastionZero in Action
BastionZero connects teams to resources and requires no additional infrastructure to deploy or manage. It is the first—and only—cloud-native solution for trustless access providing multi-root authentication while maintaining zero entitlements to your systems.
With BastionZero, you can reclaim your architecture from over-privileged third parties and ensure that the right people have access to the right resources at just the right time—every time.
Schedule a demo now to see how you can trust less and access more with BastionZero.
