Zero Trust, Least Privilege, and Just-in-Time Access
Security professionals have long taught that organizations should limit the access individuals have in computer systems to just those privileges necessary to perform their job. This is known as the principle of least privilege. The problem is that knowing this is a best practice and putting it into practice are two different things. Traditionally, organizations have used access control lists (ACLs) and role-based access control (RBAC) based on groups to authorize activities. These methods are static, requiring that lists or groups be updated manually as people move between roles or leave employment. When this is extended to partners, suppliers, and other services, the problem is that much worse. And excess standing privileges are a real security risk.
Standing privileges are characterized by persistent access regardless of whether the person is using the resource or not, predefined scope where role is used to define broad access, and minimal oversight with little monitoring and accountability. Standing privileges increase the attack surface, letting attackers exploit broad permissions without further escalation. In addition, over time people accumulate permissions beyond what they need to perform their current job, a situation known as privilege creep.
In an ideal world, least privilege is like a shrink wrap, constantly adjusting the access perimeter as the needs of the employee change. Sometimes they expand and the shrink wrap expands to seamlessly grant any access to needed perform a job. Sometimes the needs shrink and the access perimeter of the employee contracts as well. By limiting access to just that necessary to perform tasks, least privilege ensures that the attack surface that an attacker can exploit is as small as possible.
Zero Trust
Sometimes it's easy to get least privilege and zero trust confused. Zero trust is an overall security framework that requires continuous trust verification. Zero trust is a strategic, overarching trust model for an entire organization. Least privilege, in contrast, is more tactical, determining who can access what and when they can do it.
To see how least privilege fits into a zero trust strategy, consider a database administrator (DBA). Least privilege might set access controls such that the DBA can manage databases, but cannot view customer data stored within them. If their credentials are compromised, the attacker cannot steal sensitive information because the DBA’s privileges are tightly scoped. Zero trust relies on the DBA's access being valid, but might also check for unusual activity such that if the DBA appears to be accessing the database from a new location or at an unusual time, access is curtailed until the DBA is re-authenticated.
As the example shows, least privilege is an important part of zero trust, but only part. Other tactics that play in a zero trust strategy include device management, multi-factor authentication, and segmenting applications and processes (i.e., microsegmentation) to make fine-grained access control possible. Still, least privilege is a core part of a zero trust strategy. And least privilege depends on eliminating standing privileges.
Eliminating Standing Privileges
Recent developments in dynamic authorization have made it easier than ever to eliminate standing privileges. Standing privileges are the result when automatically updating an employee's access in response to changing circumstances is difficult. Modern policy-based authorization systems like Cedar allow organizations to control access though policies that state who can access what and under what conditions. These policies are managed like code, making them easier to manage. More importantly, they can automatically respond to changing circumstances.
For example, the first of the following two Cedar policies forbids anyone to access any resource that's considered "critical" unless they're on a managed device with an acceptable security posture. The second permits employees in the Finance group to access any finance application. These policies work together, so that if the finance application is also a critical resource, then finance employees would also have to be on a managed device with an acceptable security posture. As employees change roles that group is automatically updated from the HR system, growing or shrinking access as needed.
forbid(
principal,
action,
resource in Category::"CriticalResources"
) unless {
context.device.security.risk == "Secure" &&
context.device.security.assessment.overall >= 80
};
permit(
principal in UserGroup::"Finance"
action,
resource in Category::"FinanceApplications"
);
While policy-based access control (PBAC) can be used to mimic a role-based access control system, proper system segmentation (i.e. being able to identify finance applications) and device management allows finer-grained access control where employee's actions can be restricted to specific systems and only when their using a company-owned device that is properly secured. Access control can be limited to certain times or from specific locations. All of these reduce the surface area of an employee's access perimeter for better security.
Just-in-Time Access Control
We can shrink the access perimeter even further using just-in-time access control. Just-in-time (JIT) access control is a mechanism that grants users, applications, or processes access to resources only for a limited time and only when it is explicitly needed. This minimizes the risks associated with long-term or persistent access privileges. While the principle of least privilege focuses on ensuring users or systems have the minimum permissions required to perform their roles or tasks, JIT access control refines this further with several other important features:
- Time-Bound Privileges:—JIT ensures permissions are time-limited, reducing the window of opportunity attackers have to exploit rarely-used accounts. For example, a developer needing access to a production server might receive elevated privileges only for a specific task and only for a set duration.
- Dynamic Privilege Assignment:—Even when policies are evaluated for each access, the permissions they allow are available indefinitely. JIT adds another dimension to the dynamic nature of PBAC where privileges are granted on demand and revoked automatically when no longer needed.
- Granular Control:—Dynamic privilege assignment complements PBAC by making access more granular—not just who can access what, but also when and for how long.
JIT access control might, for example, be used to limit access to payroll functions except during the window when payroll is being processed. Another example is in so-called "break-glass" situations where access is granted to production resources in an emergency or in the case of unexpected failure. Other examples use dynamic roles (e.g., on call) to grant access or require a third party (like a manager) to approve access.
These scenarios can fit within a policy-based authorization architecture using mechanisms such as dynamically altering roles or adding information to the authorization request context based on querying other systems or utilizing permission tokens that carry time-based permissions with them. For example, the following policy makes use of an assignment to process payroll in the oncall tracking system to ensure only people with an oncall assignment of "payroll" can process the payroll.
forbid(
principal
action == "Payroll::Process",
resource
) unless {
context.oncall.assignment == "payroll"
}
For this to work, the authorization agent that creates the request for the policy authorizer has to ensure that the context for the request includes the correct oncall assignment and oncall assignments need to be automated.
Putting it All Together
Zero trust, the principle of least privilege, and just-in-time access work together to create a comprehensive security framework.
- Zero trust enables an overarching strategy that mandates systems, resources, and actions be designed such that it is possible to continuously verify every action.
- Principle of Least Privilege forms the heart of the zero trust strategy, mandating authentication and authorization systems that can dynamically grant fine-grained access through policy.
- Just-in-time authorization augments the authorization system so that permissions can be granted not just based on who and where, but also only when they are needed to perform critical actions.
The well known adage that you can't buy security, applies to zero trust and JIT. There are products and technologies that make just-in-time, dynamic fine-grained access control possible, but besides putting them in place, you must also integrate them, make any necessary changes to other systems, and implement governance, monitoring, and auditing to ensure they work. These are organizational changes that take time, money, and perseverance. Done right, the payoff is not just a reduced attack surface and better security, but more productive employees as well. This may seem counter-intuitive, but poorly implemented, piecemeal security measures put much of the burden for keeping systems safe on employees who deal with tactics like frequent, yet ineffective password changes or requesting, and then waiting for, permissions to do their job.
When dynamic access control with JIT access is thoughtfully implemented, you shift the burden of security from employees to systems that automate protection, making it proactive and intelligent. Reducing friction so that employees can do their job while also enhancing security requires balance and a holistic approach that aligns technology, process, and culture. This transformation requires real effort but offers substantial rewards: resilient, secure systems; empowered employees; and peace of mind.
Photo Credit: Shrink Wrapped Computers from DALL-E (public domain) Prompt: draw a wide format picture of several colorful, shrink wrapped computers and smartphones.
