Introduction

Employees are signing up to cloud apps on their own every day in their organizations. When they sign up with a password, they have created a new account and a new identity on that app. 

Why both? If they had instead clicked on “Signup with Google,” they would have created a new account, but would have been using their Google identity that already exists. 

Types of identities

This informally introduces the concept of an identity provider - a place that stores primary identity information (including email address, password and other profile information).

When someone creates a new account with a password, a new local identity has been created. In contrast, they probably use a centralized identity to access business email and other core business apps. This means that the number of accounts and number of identities that an employee has are probably different.

Local identities are often unknown by security/IT teams as there are no easy observation points for them. These local identities, which employees create to sign up for new tools that help them with their job, can also open the door to potential breaches if not secured properly. 

In the shared responsibility model of cloud security, most apps only require that organizations secure user accounts and the vendor takes care of the rest. But how do security teams secure identities that they don’t even know about? 

In this blog post, we'll delve into the world of shadow identities and how security teams can find and secure them.

What is a shadow identity? 

A shadow identity is an identity a security/IT team is not aware of. Most often (but not exclusively) these exist outside IT-managed identity providers as local accounts on SaaS apps. 

These shadow identities introduce risk to the organization. However, once an organization’s security/IT function has visibility of an identity on an ongoing basis it is no-longer a "shadow identity," and becomes just a normal identity - even if it’s on a third-party app.

Where do centralized identities fit in? 

Most organizations have a central identity provider (e.g. AzureAD/Google Directory/Okta) that stores login credentials and profile information for each employee. Most organizations strive to connect their identity provider (IdP) to all the apps they use. 

It’s a noble goal because it allows efforts to be focused on securing only a single set of credentials and MFA per employee. However, the reality is that this isn’t practical and there are many reasons why each employee only having only a single identity is only a dream (it’s a good one though!). More on this later.

Understanding shadow identity security risks

Since shadow identities (or shadow cloud identities) cannot get the same level of security attention as IT-managed identities because they’re unknown, they’re usually not as tightly secured as other identities in the business. 

Common security risks in shadow identities:

• Weak password - they could be using a really basic password like the person’s name or some other dictionary word (or some combination that gets accepted by the complexity checks on the app e.g. Password1!).

• Leaked password - the password used has been leaked in a public data breach. Attackers often attempt to gain access to accounts using leaked passwords. This attack is called “credential stuffing.”

• Reused passwords - the password set is used across other identities. This means that if an attacker got access to one password (via phishing or other means), they would be able to access more than one identity or app.

• No MFA - no multifactor authentication is enabled on the account. This means that any of the above problems could lead to a direct compromise without any additional hindrances.

• No authentication logs - on centralized identities, it’s possible to see the app an identity was used on, the geographical location of the user and even the device. Contextual information like this would obviously not be available to the security/IT team for a shadow identity, so detecting compromises from unusual or suspicious activity is not possible.

Managing shadow identity and shadow cloud identity risk 

Get visibility to bring identities out of the shadows

This goes for existing identities or new ones being created. Having visibility is the first step - nothing can be secured if neither security nor IT can see them. Visibility allows organizations to start managing the risks these identities introduce.

We think the best source of discovering identities is a browser extension. Read our post on the pros and cons of this approach. 

If you’re interested in understanding more on how to gain visibility into shadow identities, see page 16 of this ebook for different data sources that could be used to do this and their strengths and weaknesses.

Centralize identities as far as possible

The ideal number of identities per employee is 1. However, there are quite a few reasons why this will not be possible. Here’s just a few:

• SSO tax - a practice where vendors put SSO support as part of their “Enterprise” tiers which are a lot more expensive (and usually bundled with unneeded features)

• Lack of support - our research shows that 69% of the top 500 apps don’t even offer SAML SSO support at any license tier.

On apps where SAML SSO support is not possible, we encourage organizations to make use of OIDC logins (“Login with Google” for Google Workspace customers). This lacks some of the manageability of SAML, but still makes use of the company’s Google identity - which is MUCH better than creating a new local identity using a password. We’ve written about this in more detail here. Centralizing identities is an essential part of a good IAM governance and compliance initiative.

If centralizing isn’t an option, secure them

If security teams can’t use a centralized identity for whatever reason, ensure the newly created one is secured to reduce risk. To do this:

• Use a strong, unique password stored in a password manager

• Enable MFA. Bonus points for a strong method like WebAuthn (if you have a Mac, look at that lovely fingerprint reader). TOTP is still totally fine.

• Engage directly with employees to help them do the above. We recommend that this process be automated to make it manageable for security and IT teams. For example:

Keep authentication logs centrally

The ability to see what app a user has logged into, from which device and location is invaluable during an incident. Identity providers allow security teams to stream logs to their favorite security analytics tools, but identities outside of it will not be possible to monitor. Unless Security have a separate data source that allows them to see authentication activity (I’m looking at you, browser extension). 

Expanding coverage to shadow identities will allow organizations to expand their monitoring use cases and better cover risks on apps that can’t be hooked into SSO. This will also go a long way in helping with compliance and IAM governance, so it’s a win-win.

Have an incident response plan 

Develop a comprehensive incident response (IR) plan that outlines steps to take if a shadow identity has been compromised. This will help Security respond swiftly and mitigate damage. Here’s some guidance on how to create one for SaaS accounts. 

Conclusion

Shadow identities and shadow cloud identities are a risk to the business simply because they’re unknown to the security/IT team. If these groups lack visibility on identities outside of their main identity provider, their impact on the company’s overall security posture is unknown. 

However, once spotted using the right data source, identities and accounts that were previously unknown can be monitored just like any other asset.

By understanding what shadow identities are and implementing proactive security measures, security teams can minimize the risks they pose to their organizations and customers.

Read more about shadow identities and how Push can help you secure them.