One IdP to rule (or breach) them all: How identity access management tools can secure -- or destroy -- your kingdom

When we want to secure something highly valuable, say, a bag of ancient Spanish coins worth millions, we think of locking it behind as many layers as possible. For example, you might put it in a safe deposit box in a bank vault, nestled safely inside the institution that is itself blanketed with redundant physical security controls.

As organizations have become increasingly complex, so too have their associated layers of security around application access. Enterprises have tremendous amounts of applications and data, as well as users and devices with differing levels of permissions trying to access that data. To provide a consistent, IT-vetted method of creating, managing, storing, and authenticating the complexity of application access, we have arrived at Identity Provider (IdP) tools. IdPs are (typically) cloud-hosted services that store unique information used to identify users, organizations, and devices ("digital identities"), authenticate access requests, add/remove users, and provide security around these functions. Popular examples of solutions often used for IdP functionality include Okta, Microsoft Azure AD, and Duo.

Despite IdPs’ many benefits, these solutions designed to solve the complexity of growing layers of security have arguably reverted us back to a world where there is "one key to rule them all." Like having our coins in a drawer with only a single door lock to protect them, an attacker only needs to compromise your IdP to gain access to every IdP-gated application. Since the raison d’etre of these tools is to centralize the management of all application access, this means an attacker would have access to almost everything with administrative access to the IdP or certain user credentials.

How Can IdPs Be Compromised

Considering how most IdPs are configured and protected (as noted from many assessments of these systems), attackers need only gain access to a set of user credentials to exfiltrate data and obtain initial and persistent access. This can be accomplished in several ways, such as social engineering -- without proper safeguards, an attacker could contact user support and claim to be a known user locked out of the system due to a forgotten password and obtain new IT gear, user identities, and/or IdP credentials. They can also harvest user credentials from browser password caches (or tokens from the browser cookie caches) from compromised user machines.

Many organizations enable users to connect to corporate SaaS applications via personal devices that have not been security-vetted by IT. Consequently, cached credentials could be nabbed from a wealth of locations with varying degrees of security. Once in the system, attackers can leverage their current access levels or work to elevate privileges to control the IdP system itself, giving them leverage over all passwords and authentication protocols (and thus the ability to access systems and data). Discovered vulnerabilities in IdP code has also enabled hackers to obtain signing keys, forge authentication tokens, and penetrate the system, such as was seen in a recent attack on the U.S. government by China-backed hackers.

How Can IdP’s Be Protected?

Much like our coins in a bank vault, IdPs require the right policies and layers of protection, so they aren’t themselves a single point of vulnerability.

From a policy perspective, only company-issued or company-vetted devices should be permitted access to cloud applications to minimize cached IdP credentials (among other security risks these devices present). While it’s no simple task, IT departments should screen every personal device, such as smartphones, that request access to applications for adherence to security policy standards and ensure ongoing compliance/patching -- or limit these users to corporate devices. The IdP should establish device trust before establishing user trust to conduct device and user authentication effectively.

The access strategy should then follow the three-legged stool approach we recommend, at minimum, for all defensible positions in the enterprise: having three layers of protection utilizing differing types, manufacturers, monitoring techniques, and approaches to arrive at a stronger overall posture. An in-depth defense approach for IdPs includes:

• Single Sign-on (SSO) integration with an IdP.
• The IdP should have impossible travel condition blocking enabled, malicious logon detection, and geo-blocking. These should not just detect, but also block.
• Tokens should be configured to expire within 36 hours within “supported” geographies and 12 hours within non-supported geographies.
• Authentication to these SSOs/IdPs should be blocked EXCEPT from corporately issued devices, and device trust should be established through checks (Intune membership, domain membership, and certificate presence).
• MFA should be integrated with IdP using a different MFA IdP provider.
• The MFA provider should provide geo-blocking, malicious logon detection and blocking, and impossible travel detection and blocking.
• The MFA/IdP solution should perform device trust using a three-legged defense approach and block unsupported or unpatched browsers and systems from access.

Don’t Make the Complex So Simple That You're Once Again Vulnerable

Managing the complexity of security is a time-worn challenge. IT teams must always look for ways to simplify the complexity; new tools, like IdPs, often supply that efficiency. But it’s essential that we don’t revert to a state of simplicity in those tools that provides attackers with a single key to our data kingdom. IdPs are important and helpful solutions; but they must have some layers of strategic complexity around them to properly defend enterprise applications and data.

Photo Credit: Fer Gregory/Shutterstock

Heath Renfrow is Co-Founder, Fenix24.