Your Identity Provider is a Security Guard

Think about an identity provider as a security guard in an office building. The goal of the security guard is to ultimately monitor and regulate the access of visitors into the building. They verify that the individuals that are passing through the lobby and into the elevator bay are authorized to access the building and offices within it. To get into the building or through the lobby, employees that work in the building need to swipe a key card to provide the proper credentials to get past security and into the subsequent floors of the building.

What the security guard provides to each office tenant is the assurance that only authorized individuals can gain access into the offices within the building. If a company is leasing office space on the fifth floor of the building, that security guard gives them the peace of mind that only their employees or staff from neighboring office suites can access gain access to their floor. No pesky sales people can solicit to me, no unwanted guests. Seems like a good deal.

What the security guard doesn’t provide is any guarantee of the activity of authorized individuals once inside the building. If someone has a key fob that gives them entry into the building, they can get past the front lobby security desk and into the fifth floor office using their valid credential or identification. There is little the security guard can do to monitor or enforce the activity of the individuals that are authorized to access the building. The security within the office suites, should there be a need for it, is the responsibility of the tenant. The building’s security guard makes no guarantee about any of the activity that goes on within the office suites themselves. And the likelihood of someone gaining access to the fifth floor office after they stole Bob’s fob key that he left in the cafeteria is very high.

This is why identity providers aren’t enough to secure identities in the cloud. The increase in the amount of compromised credentials - either from exposed in public repos or readily available for sale in underground markets, quickly breaks the back of the notion that an identity provider can sufficiently secure identities across the cloud. Attackers are now targeting identity providers through compromised credentials, they’re able to bypass MFA and access all of the applications and services housed there.

The Importance of Detecting Access Anomalies When Securing Identities

Identity providers offer some conditional access capabilities to provide better enforcement in order to prevent unauthorized access to an environment. Some of these conditional access capabilities include policies around trusted devices, location based access and user attributes. So if a particular identity that logs in each day from Alexandria, VA is all of a sudden logging in from North Korea, geo-based conditional access would prevent that identity from gaining access.

While these access policies help defend against the use of compromised credentials, threat actors have shown their ability to defeat security measures put in place to keep them out. They’re able to bypass multi-factor authentication measures with SIM swapping and push fatigue, or social engineering tactics. They can bypass location based access enforcement by sourcing from similar geolocation as their victim identities.

To secure identities across cloud environments, organizations need to be empowered with a more comprehensive approach to threat detection and response that’s backed by a deep library of detection signals that address both posture, as well as runtime activity and it needs to start at the identity provider.

Imagine a scenario where Jason logs in to his IdP every day and as a creature of habit, tends to access the same handful of apps. As the technical co-founder, that might include applications like AWS, Datadog, Github and a host of other applications. Jason has access to the Hubspot instance but has only logged in a few times before, the last time being several months ago. One day, Jason changes his MFA with his identity provider. The device associated with it, previously an iphone, is now an Android. And upon sufficiently authenticating, he logs into Hubspot for the first time in nine months and exports the entire contact database.

While the identity provider isn’t responsible for what Jason does in Hubspot, there are plenty of signals about his activity leading up to this session that should be setting off alarm bells well before he exported the contacts our of the CRM — the MFA was reset, the device changed from Apple to Android, and an application that hasn’t been touched in nine months is being accessed for the first time. This is just the tip of the iceberg when it comes to thinking about conditional access from posture and activity characteristics across multiple environments. These are the things identity providers could put into place to better defend against compromised credentials and other common attacks against IdPs.

But as it stands today, there is a giant wall that stands on the authentication boundary between the Idp and applications like cloud service providers. AWS doesn’t know whats going on in the IdP, and the IdP doesn’t know whats going on in AWS. Because they don’t ‘talk’ to one another, developing conditional access with high efficacy is very difficult to do.

Timeline of Security Incidents With Identity Providers

Below is a list of incidents have either experienced or suffered from since early 2022. While different threat actor groups were at play, the identity providers have been targets as of late.

January 2022  [Okta] In early 2022, Okta confirmed a breach had occurred after a threat actor posted screenshots from the computer of a third party contractor. Customer data was exposed after the threat group Lapsus$, who was responsible for the breach, was able to gain access to Okta’s admin consoles.

August 2022  [Okta] In early August of 2022, Twillio discovered that a threat actor had gained unauthorized access to its systems. At the time, Okta was using Twillio for those customers that chose SMS as an authentication factor. The threat actor was able to steal one-time passwords (OTPs) delivered to Okta customers over SMS. Okta was able to determine that they had also accessed phone numbers of customers, in addition to the one-time passwords.

December 2022  [Okta] - Okta becomes a victim of source code theft through a GitHub breach. Github informed Okta of some suspicious activity in some of their code repositories. They found that threat actors had copied code from their Workforce Identity Cloud (WIC) application. Okta was able to confirm that the service itself, not any other okta service weren’t impacted and no customer data was accessed. https://www.theregister.com/2022/12/23/okta_code_copy_hack/

July 2023  [JumpCloud] A North Korean state sponsored threat group was able to breach JumpCloud. Their attack impacted ‘fewer than 5 JumpCloud customers’ and ‘fewer than 10 devices were impacted,” JumpCloud CISO Bob Phan said in a follow up statement of the incident on September 20th.

July 2023  [Azure AD] Breach that gave hackers working for the Chinese government access to the email accounts of 25 organizations—reportedly including the US Departments of State and Commerce and other sensitive organizations.A few months later, Okta made a statement where they disclosed the cause of the breach stemmed from corporate account of one of its engineers was compromised by a ‘highly skilled threat actor’ that acquired a signing key used to hack dozens of Azure and Exchange accounts.

October 2023  [Okta] - A few weeks ago, Okta was at the center of another breach after a threat actor was able to gain access to their support system. Days after the incident, it was revelealed that the incident stemmed from a compromised credential that was stored in an employee’s personal gmail account. With the credential, the threat actor was then able to gain access to Okta’s support system, which eventually allowed them to ‘hijack the legitimate Okta sessions of 1Password, BeyondTrust, Cloudflare, and two other unnamed companies.’

How to Better Secure Identities In Cloud Environments

These breaches, in addition to a slew of others over the past few years, have demonstrated how vulnerable credentials are to compromise and in the case of an identity providers, the impact these compromised credentials have. When threat actors are able to gain access to IdP environments and all of the applications within, the impact is nothing short of devastating to the security of any organization. When they are able to breach the service itself, and not just an isolated customer instance, the impact is even more catastrophic as hundreds of customers using the service can be compromised at a time.

Here are a few steps your organization can take to better secure your identities in the cloud

1.) Have a comprehensive view of all the identities in your environment - this includes human, machine and vendor. Understand exactly how each of those identities are currently accessing your environment.

2.) Closely monitor the privileges granted to those identities vs. the privileges they are actively using. Over-privileged identities will continue to present one of the biggest security risks to organizations and in the case of a compromised identity at the IdP level, the impact can permeate throughout the entire organization.

3.) Baseline what is ‘normal’ behavior for your users and start to profile them accordingly. By being able to establish what usual behavior for a user is in terms of resources they are touching, or ways they are accessing an environment, gives teams the ability to build detection rules that quickly identity anomalous behavior.