In the ever-evolving cybersecurity landscape, the principle of least privilege (POLP) stands as a bedrock principle, intricately woven into the fabric of the zero trust framework. At its core, zero trust operates on the mantra of "Never trust, always verify," challenging the conventional notions of perimeter-based security. Within this paradigm shift, the principle of least privilege emerges as a linchpin, demanding a fine-grained approach to authorization.

In a world where trust is no longer implicit, the role played by least privilege access in fortifying digital defenses is pivotal. In fact there is no zero trust without fine-grained access control. In this post, we explore how fine-grained authorization brings the principle of least privilege to life, enabling us to establish a robust security posture.

What is the principle of least privilege?

The principle of least privilege, also known as the principle of minimal privilege (PoMP), or the principle of least authorization (POLA), is the notion that every user in the system should be granted the minimum privileges required to perform their duties (i.e. just-enough access). If elevated privileges are required, they should be granted when needed and revoked after, i.e. just-in-time access control.

This is in stark contrast to traditional perimeter-based security that assumes that users within the perimeter are authorized to be there. It also demands an end to the all-too-common practice of overprovisioned roles we see in many legacy applications and RBAC systems. In these systems, local admin privileges are assigned to users that don’t really need them, because they might one day, or they need a permission that is outside of the scope of the non-admin roles. Threat actors can wreak havoc on a system by compromising one of these overprovisioned lower-level accounts. Following the principle of least privilege, superuser and administrator privileges are explicitly segmented and protected.

The principle of least privilege is a foundational component of zero trust, which demands that organizations verify anything and everything trying to connect to systems before granting access. Limiting access to the bare minimum required, along with continuously verifying those entitlements are still valid when access is requested, enable organizations to minimize the potential attack surface.

What are the benefits of the principle of least privilege?

There are multiple benefits to application security that come from adhering to the principle of least privilege, notably:

1. Minimized attack surface: by limiting access to what is strictly required we are diminishing avenues a threat actor could potentially use to access protected resources and data. There are far too many examples of breaches that resulted from not following this principle. Edward Snowden, for example, exploited admin access to leak sensitive information he shouldn’t have had access to, as his highest-level privilege was performing database backups. Since then the NSA has employed the principle of least privilege to revoke administrator privileges from a whopping 90% of those who were granted those privileges. While this is an example of an internal threat actor, almost every example of breaches from external sources could have had a significantly limited impact if organizations adhered to the principle of least privilege and users had just-enough access.
2. Limited malware propagation: by restricting access to installing unauthorized software we can stop lateral network movement, so that the malware is contained in the small section where it first entered the system.
3. Improved compliance and auditability: Many regulations call for the implementation of the principle of least privilege via fine-grained access controls. In addition, we can significantly reduce the scope of most audits when we implement the principle of least privilege.

Least privilege through fine-grained authorization

A fine-grained access control system is the mechanism used to implement the principle of least privilege. These systems help developers implement resource-level control over access to protected resources, along with real-time access checks to verify the user still has the right entitlements prior to providing access.

Fine-grained authorization systems enable us to determine exactly which resources each user should have access to, and default to denying access to anything else. They also provide authorization audit logs, which are records of every authorization decision made. These logs significantly simplify compliance and audits, as they act as legal evidence that the system is functioning in accordance with compliance requirements. They are also useful in defining the blast radius of a breach, and can even indicate that such a breach occurred, even if authentication logs don’t show multiple failed login attempts.

Fine-grained authorization models

There are two popular fine-grained access control models: attribute-based access control (ABAC) and relationship-based access control (ReBAC). Both models support the principle of least privilege by providing just-enough access to users, but they do so in different ways.

Attribute-based access control uses dynamic attributes to determine access. These can be attributes of the user, resource, or environment (location, device, time of day, network, etc.). ABAC systems use policies to define authorization rules based on those attributes.

Common examples of ABAC include denying access to internal applications from devices on public networks, or only granting CSMs access to the customer records assigned to them. Netflix’s system to authorize extra members that are accessing the system from a location that is not the defined household location, is a real-world example of ABAC at scale.

Relationship-based access control bases access on the relationships between users/groups and resources in the system. This is a graph-based model that is easy to traverse and supports hierarchical systems by default, enabling inherited permissions, parent-child, and other complex relationships.

Common examples of ReBAC include providing a user with different access levels to different resources, as well as instances of inherited permissions (i.e. a user that is granted access to a folder also gains access to all the files that are nested in that folder). Google Drive, Docs, Maps and other popular Google applications are real-world examples of ReBAC at scale. Zanzibar, the search giant’s unified authorization service that powers these apps, has popularized the model.

More about the two fine-grained authorization models and the differences between ABAC vs ReBAC.

Conclusion

Remote workforces and the cloud have rendered perimeter-based security obsolete. Zero trust has moved the burden of securing applications from the perimeter to the application itself. It demands we verify entities explicitly, use least privilege, and assume a breach.

The principle of least privilege is a core concept of zero trust. Based on this principle, users should only have access to what they need to perform their function. This limits the potential blast radius of a breach, and secures the organization from internal threat actors that might otherwise take advantage of higher-level permissions than they should have been assigned based on their function.

Fine-grained access controls, coupled with continuous access checks, are the tools for implementing the principle of least privilege. Fine-grained authorization allows us to determine exactly which resources each user should have access to, and default to denying access to anything else.

There are two popular fine-grained authorization models: ABAC and ReBAC. They both enable organizations to adhere to the principle of least privilege. ABAC uses attributes, while ReBAC uses relationships to determine access. Both models have pros and cons and are useful in different situations.

Topaz is an open-source authorization project that lets developers combine ABAC with ReBAC and other authorization models (e.g. RBAC, PBAC). It is flexible enough to support any authorization model for any application, and is easy enough that a single developer can create a prototype in minutes and be production-ready in 1-2 weeks. Give it a try and let us know what you think here, or in the Topaz community Slack.