Minimizing the blast radius when authentication is compromised

Nearly 80% of high-profile system outages stem from identity breaches attributable to excessive standing privilege — and the rate of successful attacks keeps climbing up.

All it takes is one targeted identity compromise to inflict a devastating attack. Even as security teams and IT make substantial investments to stop threat actors from infiltrating systems, 79% of CISOs reported SaaS security incidents in their company.

To prevent excessive damage during and after an identity breach, enterprises must focus on reducing their potential “blast radius.”

What is a blast radius? And how does it expand?

A blast radius refers to the impact an organization could suffer from a security breach, such as an identity compromise. It represents the scope of damage an attacker can inflict on your company once they’ve gained unauthorized access to your systems.

The term originates from the blast radius of a bomb, describing the physical area affected by the explosion. Similarly, in a cybersecurity context, the blast radius includes the systems that a malicious actor can gain unauthorized access to if they’ve successfully compromised the identity of an employee, contractor, partner, or vendor.

The attacker inherits all the roles and entitlements associated with the compromised identity, meaning a single compromised account can lead to widespread damage if it’s connected to multiple systems and some amount of privileged access.

Unfortunately, the blast radius naturally expands as companies evolve. This is due to:

1. Continuously adding more roles and entitlements: Growing companies must provision identities to the extended workforce of employees, partners, contractors, and any person or machine that “works” for the organization. As companies add these users, identity teams create additional user roles to accommodate new and changing job functions. While roles define permissions for users based on their jobs to be done, entitlements are the actual permissions that allow users to perform specific actions (e.g., “edit this Google doc” or “modify this user’s Office 365 permissions”). Throughout the course of normal business, employees grant other users more entitlements regularly. This pattern leads to a larger attack surface and bigger potential blast radius.
2. Allowing standing access to critical systems: Giving users standing privileges significantly increases the blast radius. If a malicious actor compromises an identity with standing access, no further authentication is needed when they attempt to access connected systems and resources. Even well-intentioned users can cause harm with standing access by making accidental changes in production environments.
3. “Rubber-stamp” access reviews: Organizations rely on overworked managers to perform periodic access reviews across various systems. These access review requests are typically too time-consuming and technical for most managers. For example, a manager may be asked, Does Bob need to have the entitlement:”sales-fileowners”? Without any context for what sales-fileowners is and how it relates to daily operations, the manager will err on the side of caution and rubber-stamp the approval rather than perform due diligence. The more managers who rubber-stamp access reviews, the more standing access remains intact.

Figure 01. As roles and entitlements are added to cloud and on-prem systems, the potential blast radius increases substantially for all users in the company.

Example: How generous access rights create a large blast radius

Consider an enterprise company where an employee has access to several critical systems, such as GitHub and AWS. This employee’s identity includes multiple roles (and their subsequent entitlements) that have been granted standing access to these systems.

Because of these privileges, a threat actor can run the following play:

1. Compromise the user’s identity in a less secure system, such as a third-party app integration to GitHub. Even enterprises using SSO can be susceptible to identity compromises.
2. Because the third-party app has been granted a standing token to GitHub, the attacker inherits those credentials.
3. The attacker injects malicious code into GitHub and, because of the standing access settings, pushes the code to a production AWS environment.
4. The production AWS environment experiences a significant customer-facing incident as a result.

Figure 02. Standing access and excessive privilege allows a threat actor to move laterally across a compromised user identity’s roles and entitlements.

The danger corresponds to the complexity of a user’s entitlements. If the employee can modify user permissions or access administrative functions, the attacker can escalate their privileges, gaining even more control over the network.

Can legacy access tools address my company’s blast radius?

Traditional authorization frameworks like identity governance & administration (IGA) and privileged access management (PAM) can make modest blast radius reductions, but these technologies face severe limitations.

IGA is typically employed for birthright access, which are the access rights and permissions automatically granted to employees when they’re hired or change roles. This does help to establish a baseline of limited privileges. But access and entitlements, as illustrated above, change constantly. IGA cannot accommodate the business context for these change requests. As such, the blast radius continually expands.

PAM platforms, as the name implies, secure and manage highly privileged accounts. Most PAM platforms rely on creating and maintaining shared secrets, which are then used to access the critical systems they protect. This added layer of security, in practice, negates the strong authentication features (e.g., MFA or passkeys) those systems, especially cloud-based systems, have in place. PAMs are typically cumbersome and slow to deploy, requiring extensive administrative overhead to maintain access rules. Inefficiencies and delays are common. These high costs stop most PAM customers from making a notable difference in their potential blast radius.

What solutions can meaningfully reduce my blast radius?

A new authorization framework we refer to as modern privileged identity management (PIM) can drastically cut your blast radius. This access management approach severely limits the impact of an identity breach in two key ways:

• Eliminating standing access by introducing contextual access: Instead of granting continuous access, access is granted only when necessary and for a limited duration. This contextual approach provides users with the necessary permissions only when needed, and only for as long as needed. It ensures that if credentials are compromised, the attacker’s window of opportunity is slashed.
• Eliminating shared secrets: Modern PIM solutions provide accounts for named users who need access to critical systems only if the specific access is justified in the present context — and only to the required resources within the systems. Unlike PAM platforms, no generic accounts or shared secrets are ever created, completely removing the risk of a shared secret being compromised. To further strengthen authentication, PIM customers can add MFA or passkeys that most critical system platforms natively support.

SGNL’s modern solution for privileged identity management allows and revokes access in real-time based on changes in context. This dynamic authorization completely eliminates the need for standing access to critical systems. As a result, companies can achieve Zero Standing Privilege (ZSP) and significantly reduce their blast radius.

With SGNL in place, the large blast radius example we shared earlier plays out quite differently:

1. The attacker compromises a user’s identity. In this case, it’s an SRE (Site Reliability Engineer) who can normally log in to GitHub.
2. With Zero Standing Privilege in force, the SRE does not have access to any GitHub repositories without a specific reason.
3. When the attacker wants to roll out a service to production using GitHub actions, their access request to GitHub is denied because SGNL determines that the request is not coming from a recognized device, the user is not on duty, and there is no IT ticket justifying the access privileges. If the attacker tries to log into other systems, they will soon discover they do not have any rights in those systems.
4. Since the attacker does not have rights to GitHub, they are unable to mine any secrets from GitHub in order to leverage those to access other systems.

Figure 03. SGNL’s privileged identity management (PIM) solution dynamically grants access for limited timeframes based on established policies and contextual data from multiple systems.

Moreover, SGNL’s solution integrates with the most commonly used IT infrastructure and systems along with custom-built applications, enabling dynamic access management across diverse, often unconnected, environments. This further diminishes the potential blast radius by applying access policies consistently and monitoring them continuously.

Adopting modern privileged identity management solutions provides the agility enterprises need to drastically limit the blast radius. See how SGNL can help.