What is the Principle of Least Privilege?

Least privilege is a foundational tenet of zero trust security, with the core philosophy to grant only as much access as necessary. While initially discussed as part of a network security strategy, applying zero trust security to the application layer for consumable resources (applications, services, data, etc.) is far more effective. This approach allows you to tie specific resource access policies to the people and programs accessing them.

What types of threats are best addressed through least-privilege security?

Least-privilege access is a security strategy focused on ensuring that identities, people, and processes are granted the minimum level of permissions needed to be productive—or in the case of programmatic access, functional. In their 800-12R1 introduction into information security, NIST (National Institute of Standards and Technology) points to common concerns addressed by least privilege: 

• Malevolent insider: This threat type is often difficult to detect, with harmful activities easily going months or years unnoticed. Inside bad actors can be contractors, employees, and even administrators and all levels of management. Least privilege is a primary security approach to limit the range of damage or abuse can inflict on an organization.
• Malevolent collusion: This can occur when two or more bad actors coordinate malevolent activities. This exploitation type often results in far more damage than typically possible from a single individual. It’s why regulators and organizations use separation of duties (SoD) to protect against this kind of abuse. SoD requires more than one person to complete a task. Although it's often thought of in the context of financial services, those same principles protect against different forms of fraud, sabotage, theft, or the misuse of sensitive information.
• Negligent insider: These are actors who, while they don’t have bad intentions, make errors that expose their organizations to risk. Negligent behaviors include configuration errors that inadvertently shuts down important digital services or exposes sensitive information to the web. These types of incidents are routinely published in the media. 
• Compromised insider: This is when an insider’s credentials have somehow been compromised, commonly through phishing. The broader and more far reaching an account’s access, the greater the potential damage is to the organization. This is why executives are increasingly being targeted (whaling).

---

What are the main causes of privilege creep?

Privilege creep is when a user accumulates entitlements beyond the justification of their role within the organization. It usually happens gradually over time, and often affects organizations that need to secure their regulated or sensitive information. When individuals change roles, permissions are often granted quickly to get people productive, but because responsibilities may linger previous entitlements are often kept in place. The types of resource where least privilege needs to be assessed include: 

• Core applications and services
• Unstructured data 
• Systems and platforms

At some point the leadership team realizes that they need to get a handle on privileged access to their core services and sensitive information. They prioritize and sponsor security teams to join forces with information owners to form privileged access tiger teams. Projects are kicked off and objectives defined. With their newly designed identity governance environment that automates access requests and approvals, the maintenance of it is handed off to operations. Too often, this type of focus isn’t ongoing—but even with automated requests and approvals, privilege creep is still a potential risk.

Often privilege creep builds as business dynamics diverge from defined governance policies. Permission workflows have a tendency to expand as organizations morph and responsibilities drift. Some of the most common sources of privilege creep include: 

• Approvals: Approvers, who are preferably information owners, are not accurately assessing permissions requests. Busy approvers may not take the time needed to precisely understand who the requesting user is and what their needs are.
• Inadequate review process: This encompasses a lack of regular reviews or ones conducted by those who aren’t equipped to properly vet or assess the appropriateness of access requests. 
• High risk users: There are some users where it’s quite possible for them to accumulate a level of entitlements over time that pose an unacceptable risk to the organization. This happens as the user temporarily takes on various projects and roles that require entitlements to perform and those entitlements are subsequently retained. 

Privilege creep is nearly inevitable as organizations adapt or respond to various dynamics imposed on them. But it violates a key zero trust tenant designed to protect organizations from outsiders, and is a contributing factor to the large breach costs that continue to grow across virtually every industry.

---

How to control privilege creep

One of the most difficult aspects of protecting against privilege creep is that it often happens over time while reviewers, who are responsible for many things, are focused on other things. It’s not observable at any one point of time, but rather must be viewed across a relatively long span of time. Acknowledging the subtle way that an account can morph into an unacceptable risk level without detection, the extent to which it poses a security concern depends on the volume of users, the number of changes users go through, and the sensitivity of the information being protected. It’s a security challenge that can’t be solved with a spreadsheet.

Preserving separation of duty

Separation of duty and other corporate policies designed to comply with regulations translate well into governance rules, but risk criteria are more subjective. Here are the most common ones:

• Too many organizations don’t have a de-permissioning processes in place. Instead, these organizations rely on basic platform account management tools. Typically, their permissions control is nothing more than disabling accounts that the leave the organization. Risk management isn’t a top priority for these organizations.  
• It’s not uncommon for select individuals across the organization who take on different roles over time are top candidates for privilege creep. Common use cases include dotted-line reporting, contributing on different tiger teams, and participating in a variety of projects across different departments. While there are overt productivity forces in play when assigning entitlements to these personnel, security considerations are often muted. The occasions for removing permissions are usually scattered, but the fear of disrupting a permissioned user is a frequent reason for not doing so.
• Over-generalized roles can be another agent of privilege creep. Here it’s less about granting permission to appropriate requests, but rather more about the over expansion or the generalization of roles used to assign them. Effective roles are those that are properly demarcated, each one being distinct to the appropriate level of permissions. It’s frequently a temptation to under define and generalize roles used to apply permissions. 

Protecting against risk creep

It’s quite difficult for reviewers to identity permissions that drift over time. These types of evaluations can be aided with automated analysis of change over time. Reviewers can then access that information in a dashboard or report. While it’s not feasible to appraise all users across an organization, it is possible to effectively review and vet the top dozen who pose the highest risk.

Other types of auto-generated risk alerts and reports are derived from analysis of the governed resources. Resources containing sensitive information that are not periodically reviewed are assigned a higher risk score. For all of these alerts, today’s dominant governance innovation is the identification and highlighting of risk areas across the entire environment.

---

How does least privilege fit into zero trust?

Least privilege access is one of the core components of a Zero Trust Architecture. This means granting only as much access as needed, with only the minimum permissions for the shortest duration necessary.

Other zero trust components include:

• Micro-segmentation: Break the environment down into smaller security zones to limit the scope of access. Maintain separate security controls for each compartment of the environment (requires distributed management of these controls).
• Multi-factor authentication (MFA): Require two or more verification factors to gain access to a resource; require greater identity assurance based on current risk state.
• API control and monitoring: Ensure appropriate control at the programmatic level as well as at the user interaction level. Control how many different devices and/or API’s are trying to access resources.
• Adaptive: Context-aware, continuous evaluation of risk – enables early detection of threats and rapid response. Dynamically respond to the current state in the context of the current environment and past activity.

 

---