Privileged Identity Management (PIM): For Many, a False Sense of Security

Privileged Identity Management (PIM):

PIM is described as a service within Microsoft Entra ID, designed to manage, control, and monitor access to crucial organizational resources, encompassing Microsoft Entra ID, Azure, and other Microsoft Online Services like Microsoft 365 and Microsoft Intune.

In the cybersecurity landscape, Privileged Identity Management (PIM) emerges as a pivotal element, but its effectiveness in managing privileged access is subject to scrutiny. Integral to the broader identity and access management (IAM) framework, PIM's role in upholding least privilege and just-in-time access principles is increasingly questioned amidst evolving digital threats. While theoretically vital for risk mitigation and regulatory compliance, the practical application of PIM, especially in complex cloud and IT environments, often reveals limitations in its ability to adapt to sophisticated cyber threats. This dichotomy between PIM's intended role and its real-world efficacy underscores the necessity for a critical evaluation of how PIM solutions are implemented and integrated into the overall cybersecurity strategy.

In an era where digital identities are as critical as physical keys, grasping the nuances of PIM becomes essential for any organization looking to secure its cloud presence and navigate the challenges of a rapidly evolving digital landscape.

PIM - In Theory:

• Concept of Least Privilege: At its core, PIM is rooted in the principle of least privilege, which dictates that users should be granted only the access necessary to perform their duties. In theory, PIM enforces this principle more dynamically, adjusting access as needed rather than granting broad, permanent privileges.
• Just-in-Time Access: The just-in-time model is designed to minimize the window of opportunity for potential security breaches. By granting privileges only when needed, theoretically, the risk of misuse or compromise is reduced.
• Mitigating Insider Threats: PIM aims to address not just external threats but also the risks posed by insiders. By limiting the time and scope of access, it reduces the chance of insiders causing inadvertent or intentional damage. Though scope of access more so comes from other controls such as entitlement management.
• Enhanced Oversight and Control: Features like time-bound access, approval requirements, and audit history are meant to provide organizations with greater control over their resources. This level of oversight is essential for detecting and responding to abnormal activities quickly.
• Compliance and Accountability: With increasing regulatory pressures, PIM theoretically helps organizations maintain compliance by ensuring that privileged access is not only well-managed but also auditable. The requirement for justifications and the ability to review access patterns enforce a level of accountability.

PIM - In Practice:

PIM has multiple sides, the first replaces normal administrative role assignment. Before PIM, the common practice involved directly assigning a role to an identity, often coupled with manually setting a reminder to revoke the role after a predetermined period. With PIM this is replaced and expanded to allow the original permanent assignment but also to build real controls around the time-bound permanent roles (a role that is active for the identity for the duration of the time frame provided). This is a great use case, and with proper run-time monitoring of permanent assignments, a great modernization of an old practice.

For this discussion we’ll focus on everyone’s favorite use case and Microsoft’s PIM selling point, just-in-time access and least privilege (eligible roles). It is here admins often start granting IT users with multiple roles, because it’s eligible not active they feel more comfortable doing this. This could be compared to how you would treat AWS SSO, granting different role levels to an identity to control their access in each account. In contrast to AWS, or in the same way an AWS admin may grant many overlapping roles for one account to an identity, they still end up over privileged and with unused overlapping roles and permissions. Some may argue that having multiple roles within one account, whether it's AWS, Azure, or M365, ensures that users only select the permissions they need at the time, thereby preventing mis-clicks and errant configuration changes. However, we contend that if this is a primary concern, it may indicate a need for more user training, and such extensive permissions shouldn't be available to users who are prone to such errors. Once an identity has made it to the ability to select / activate a role, they’ve passed security checks, from an attacker perspective there was little to no benefit at this stage by providing the varying levels as they can simply select the highest.

In all fairness, these views are not surprising, Permiso’s Nathan Eades can be cynical of many security marketing terms, “zero-trust” chief among them. He subscribes to a notion of “selective-trust”, this is often true in most organizations that have different levels of security for different identities or networks. In these environments the strict “zero” is removed in place of usability, for example: not enforcing MFA for a trusted network or only enforcing for high risk applications or heuristically high risk access patterns.

We discuss this because a similar stance can be taken with just-in-time access. To frame the idea, lets look at Microsoft’s “Reasons to Use” section of PIM:

Consider the default role policy for most roles while using PIM, which many organizations do not change other then to lower the default activation time frame of eligible roles (8 hrs) specifically for the Global Administrator role. Within the default configuration, a role is made eligible to the user and will require a justification, the justification can be anything. For privileged roles MFA is also required but will already be satisfied if required during authentication.

Default PIM Policy of a Privileged Role - Includes Azure MFA on Activation.

Default PIM Policy of non-Privileged Role - No Activation Requirement.

Lets assume we provide Global Administrator as an eligible role to 10 users. On it’s surface this now sounds like a great feature, we’ve provided “just-in-time” access (though we’ve ignored least-privilege because we figure it’s fine, it’s not like it’s permanent), the user does not have the activated role, it must first be activated with justification (and MFA, but this is most likely already satisfied on session start). The justifications are often meaningless, outside of the activation log event, the ability to “oversee what those users are doing” would be better managed through run time analysis and entitlement management.

Reviewing further, Microsoft’s marketing has been extremely successful in pushing PIM, pushing best practices to add measurable security however, has seemingly not been the priority. Any sophisticated attacker targeting Entra ID (formerly Azure AD) today is likely aware that PIM is commonly used, which means they know where to look to activate a role. With minimal effort, they may even review logs to understand how the identity normally justifies access.

Under these circumstances, what was truly gained? Merely a button. In all seriousness, the process has been reduced to a procedural formality, where “just-in-time” access becomes scarcely distinguishable from “all-the-time” access. The activation involves a simple click and often only a basic justification, thereby raising significant questions about the actual security efficacy of this system. While this may sound harsh, consider an on-prem environment 10 years ago. If we told you not to worry because a few users have domain admin access, but they need to click a button and drop a random comment in a textbox to activate it, you'd likely question the strength of such a control or if its a control at all. This scenario is akin to setting up a digital stop sign, more of a nominal checkpoint than a robust barrier, treated as a rolling yield rather than a definitive security measure.

Unfortunately, the just-in-time aspect also appears to negatively affect least-privilege. Admins feel more comfortable assigning identities roles when they are eligible, not active. They likely feel like they are not on the hook anymore for having given that access. The identities are then free to choose what they need (or think they need) at the time. Alternatively, the admins assign more permissive roles since they still need “activated”.

While these issues highlight inherent weaknesses in the default or most common implementations of PIM, they also open the door to potential enhancements. Strengthening PIM requires not only a re-evaluation of its configuration but also the integration of complementary security measures.

Advanced Strategies for PIM: Ensuring Genuine Security

• Employ Strict Justification Requirements:
  • Instead of vague and meaningless justifications like '.', 'activate', 'work', or 'tasks' – all too common among admins activating roles today – organizations must enforce policies and provide training to ensure admins adhere to meaningful justifications.
    • Meaningful justification ensures an understanding during audits of what the purpose of role activation truly was. Along with entitlement management, this can better help to understand proper permissions necessary for the identity.
    • The organization can also enforce required wording, something static, if an attacker is unwilling to put in the effort to understand these requirements, then alerts searching for them when they are missing will easily identify an attacker (or admins ignoring protocol). E.g. Justifications must begin with “Role activation required for:”. A pseudo random key may be agreed upon, such as “f3409j3#” at the end of each justification. Combined these act as a fingerprint. Example:
      
• Additional MFA:
  • • • The goal would be that regardless of whether the identity used MFA during authentication to start there current session 10 minutes ago, to activate the role they are forced to do it again to reaffirm themselves. In the event the session was started by an attacker via push fatigue or similar, this second request will hopefully alert the true identity, or as we’ll see, a different version of MFA can also be enforced.
        • Microsoft doesn’t necessarily make this easy. We’ll call this a version of that “selective-trust” we discussed earlier, essentially assuming the session is legitimate (in contrast the session may have been started by the attacker or an attack similar to recent Okta breaches resulting in session token reuse).
          • Note, by default privileged roles such as Global Administrator, Privileged Role Administrator and others will enforce Azure MFA on role activation. But again, this won’t do anything in most cases for identities as they started the session using MFA and as Microsoft states, “Users might not be prompted for multifactor authentication if they authenticated with strong credentials or provided multi-factor authentication earlier in the session.”
        • To combat the above issue, there is another option. This is relatively new within Microsoft. It will require you to use Microsoft Entra Conditional Access authentication context. The key is to ensure the MFA method is different from that which is used in the identities active session. E.g. If the active session was started from Windows Hello, the next method could be an authenticator app push. Or, if the action session method was an authenticator app, a FIDO2 key could be utilized on role activation. The identity will see the following when these settings are configured correctly.
          
        • We believe it’s important to mention this final point. While just-in-time limits the time a role is assigned, it’s not completely impossible that an identity legitimately enabled a role and is compromised a few hours later. This means that role could already be active for the attacker after compromise. Microsoft offers at least one way to combat this. Assuming the organization utilizes Intune, you can use conditional access to enforce Intune-compliant devices, this policy could in theory specifically target identities with certain roles before allowing them to sign-in. In this scenario if the role is active then the device must be Intune-compliant or authentication will fail.
• Enforce Approval:
  • Arguably the most secure option, but effectively removes the true idea of just-in-time access. The identity will go through the process of role activation, a given list of approvers set in the PIM policy of the role will receive notification including justification information and will be able to approve or deny the request for approval.
    • This level of security is recommended for privileged roles such as Global Administrator, Privileged Role Administrators, Conditional Access Administrator, and any other role the organizations deem privileged or sensitive enough to require it.
• Anomaly Detection:
  • This control falls outside of PIM itself but is required in today’s security landscape.
  • A valuable run-time detection engine that can analyze historic data compared to current activity to provide insights and alerts into anomalies that don’t fit the normal access patterns or activity of an identity. Permiso provides this to customers to ensure we can identify these anomalous patterns or activity.

• Entitlement Management:
  • Precision Role Definition: Create roles with permissions tightly aligned to specific job functions, ensuring each user has access to only what is necessary for their role, thereby upholding the principle of least privilege.
  • Regular Access Audits: Conduct frequent reviews of user privileges to identify and remove excessive permissions, reinforcing least privilege adherence.
  • Context-Sensitive Access Controls: Implement dynamic access controls that adjust permissions based on real-time context, ensuring users have access only when needed and under appropriate conditions.
  • Automated Provisioning Based on Role Changes: Utilize automated processes for adapting user access in response to role changes, promptly aligning privileges with current responsibilities.
  • Anomaly Detection in Access Patterns: Monitor and analyze user access patterns for deviations, enabling quick identification and correction of privilege mis-alignments.

These strategies will allow Privileged Identity Management to be useful beyond theory. Unfortunately, all too often, this control is treated like a checkbox after its purchase, or those charged with utilizing it give too much trust to the default settings. We set out to call out these practices, highlighting their lack of security value, ensuring organizations get the most out of their PIM implementations.

By moving beyond a mere compliance-driven approach and actively re-configuring and enhancing PIM according to these strategies, organizations can transform it from a nominal security measure into a robust, dynamic tool that genuinely protects their digital assets. This proactive stance in cybersecurity management is essential in an era of ever-evolving threats. It empowers organizations not only to meet but exceed security expectations, safeguarding their operations against sophisticated cyber risks in the cloud and beyond.

We strongly encourage everyone reading this to critically evaluate their own security implementations, PIM included. Taking a thorough and questioning approach to your security suite and configurations, asking whether they genuinely enhance security is crucial in creating more secure environments.