Stay up to date with Pomerium news and announcements.
The world’s #1 identity platform Okta has suffered a potential breach, and thousands of their corporate customers find themselves wondering if they may need to take corrective measures. Though Okta’s Chief Security Officer David Bradbury officially claims “There is no impact to Auth0 customers, and there is no impact to HIPAA and FedRAMP customers”, companies like Cloudflare have taken preventative measures to protect their internal and external accounts against hackers that may exploit Okta’s potential security breach.
More importantly, this event and subsequent scramble to secure networks, accounts, and access privileges highlights the need for context-aware access and multi-factor authentication. The event additionally acts as a strong argument for not concentrating your 2FA or MFA exclusively at your identity provider (IdP).
This blog post covers the following topics:
Identity-aware vs Context-aware
Third-party Services Expand Your Information Boundary
Deploying At Edge With A Context-aware Gateway
Identity-aware vs Context-aware
Okta’s breach is particularly newsworthy because many cybersecurity systems today are identity-driven: if the hackers truly gained the level of access they claimed, they would have had unfettered access to any network or system that account had access to. Those systems only look for signed tokens provided by the IdP — but that security model does not work when the IdP itself is compromised.
This is why context-aware access is the next level of authentication for securing your system: attackers would need to compromise more than just the identity provider to gain access. In the case of companies that used Okta’s SSO or IdP services, if they had their system set up to also confirm other contextual information (such as device ID) then the compromise of the IdP alone would not mean a compromise of their infrastructure.
Context-aware access evaluates not just the identity of the request, but also the context surrounding said request; and ideally compares it to what is expected. This includes any number of the following:
Device
Browser
Time
Region
Network
Figure 1: After authenticating with Okta, this route confirms the device identity. This example was recorded on a Chromebook, configured to ask for a PIN before providing the Device ID.
The more context a request can be validated against, the better access decisions a system can make. If dynamic access policies are written into the system, the system can even grant limited access privileges based on unexpected requests that still fulfill certain contexts.
Third-party Services Expand Your Information Boundary
This isn’t often brought up, but many third-party SaaS like Okta and Cloudflare expand your organization’s information boundary. The Okta breach shows that the customer could have done everything right, but if the 3rd party (in this case, Okta) is breached, then the customer inadvertently suffers a breach out of their control.
Taken a step further, Okta’s Chief Security Officer David Bradbury’s original statement details the following about the breached account:
The potential impact to Okta customers is limited to the access that support engineers have. These engineers are unable to create or delete users, or download customer databases. Support engineers do have access to limited data - for example, Jira tickets and lists of users - that were seen in the screenshots. Support engineers are also able to facilitate the resetting of passwords and multi-factor authentication factors for users, but are unable to obtain those passwords.
This gives a level of detailed insight into what a high-level third-party account with permissions and privileged access into information boundaries of their customers can do. Even with “limited” access, a breached third-party exposes your security to the following:
Resetting passwords and MFA factors
Seeing a list of users
Internal JIRA tickets
This isn’t to say that third-party services like Okta or Cloudflare are bad at what they do. A third-party IdP is a good tool because it’s outside your infrastructure, and can’t be compromised at the same time as internal exploits. It’s important to be aware of what sort of access and insight an organization must grant third parties when using them, and how third-party breaches can compromise your organization’s security system.
Deploying At Edge With A Context-aware Gateway
Identity providers like Okta are a fantastic tool for authenticating identity, but the ramifications of their breach is a sobering reminder that good cybersecurity hygiene cannot involve single points of failure — this includes even our own tool Pomerium. Organizations that continue using third-party tools like IdPs to authenticate their users should decouple their security posture from their IdPs to limit themselves from the blast radius of a third-party security breach.
Organizations should integrate their IdPs with a context-aware gateway to address the issues we covered above and adopt the benefits of a zero trust architecture. By deploying a context-aware gateway like Pomerium in front of your infrastructure and services, your organization can retain control of your information boundary and benefit from context-driven access.
This context-driven access would provide MFA access controls such as enrolling device identity to protect against events like an IdP becoming compromised. This additional layer of security restricts access to only known devices, limiting an attacker’s ability to access sensitive routes even if they have managed to fully compromised your IdP, removed MFA, and reset the user’s password.
