What is the Principle of Least Privilege (POLP)?
The Principle of Least Privilege, one of the core elements of zero trust security, is defined as giving people access when they need it to complete a job, and for no longer than they need it. By enforcing least privilege access, you reduce the chances of account compromise by eliminating unused or unnecessary accounts, and reduce the potential impact of a compromised account or insider threat.
It’s a simple principle, but in practice, understanding and achieving least privilege access across today’s sprawling, complex identity environments can be enormously difficult. Despite the challenge, working toward least privilege is crucial for security teams who want to protect their infrastructure and users. In a 2022 IDSA report, 80% of firms surveyed reported suffering from an identity-related breach in the previous year, and many blamed “inadequately managed privileges,” “compromised privileged identity,” or “excessive privileges leading to an insider attack” for those breaches. Least privilege is also important to compliance—most security-centric compliance regulations require some level of access management controls and policies and recommend least privilege access as a top level guiding principle.
Though systems and sensitivities vary, every company can benefit from incorporating least privilege access best practices into their identity security and access control processes. Here’s how to get started.
Least Privilege Strategies & Tactics
1. Move sensitive access to time-based access
The first step to achieving least privilege is to identify which of your systems are mission critical. Once you have cataloged these systems, identify who has access and what permissions, roles, and group members provide privileged access. As a final step, shift these entitlements to a time-bound or contextually provisioned model, assuming by default that users don’t need this type of access on a regular basis. You can think of granting access in these situations as a “privileged action” escalation. Users who need elevated privileges to perform privileged actions can request just-in-time access that fits their needs.
Not all access situations need to be time-based, but transferring sensitive permissions, applications, and roles to just-in-time access ensures users will always have the access they need, when they need it, without being over provisioned.
2. Control sensitive access with appropriate policies and approvals
Establishing clearly defined, appropriate access policies and approval protocols for sensitive roles and permissions will ensure provisioning is handled consistently and with the correct checks and balances. Create standards for how employees in different roles will be onboarded, making least privilege the default for all new accounts, and decide how role changes and offboarding will be communicated and managed to make deprovisioning quick and comprehensive.
Educate all stakeholders on your new standardized access request and approval procedures, especially those that pertain to sensitive, just-in-time access, to make sure policies are clear and easy for everyone to follow.
3. Automate gaining visibility over who has sensitive access
The basis of securing any environment is to understand the environment. With the proliferation of SaaS and IaaS applications and the centralization of management of these environments, it can be a massive challenge to simply understand what roles and access exists, what identities and accounts have been created, and who has access to what. Security teams need to be able to answer these questions quickly and easily to achieve least privilege and this depends on automating the collection of data and the centralization of the information.
With this in mind, do all that you can to get full visibility of access, permissions, and group memberships across your system and keep this information centralized, up to date, and easy to reference. Once you have your system inventory in place, develop a schema for tagging roles, groups, and permissions within applications that are most sensitive so they’re instantly identifiable.
4. Keep a comprehensive catalog & audit trail
When users are granted sensitive access, log the decision, approvals, and the context under which the access is granted so that it can be easily audited. This is useful information when reviewing whether access is still necessary and may be essential proof for external compliance requirements. The catalog of current sensitive access should be easily accessible by IT, Security, and GRC teams.
Actively maintain this catalog as part of your access review process—a user’s or identity’s status should be automatically updated in the catalog as part of the provisioning and deprovisioning processes.
5. Periodically review sensitive access
Defining least privilege access policies and keeping an up to date catalog of active sensitive access will go a long way toward achieving least privilege, but it’s still crucial to regularly review sensitive access to ensure that currently provisioned access is still necessary. These reviews should not just depend on your catalog of access from any manually maintained audit trail, but ideally should poll the applications and accounts directly to ensure that the latest and most up to date information is used for review. This ensures that access was not provisioned outside of your business processes, but more importantly, if it was, that it is reviewed and re-certified.
Following a few best practices for user access reviews can make the process more seamless and accurate. Collaborate with your company’s managers and/or system administrators on periodic access reviews to certify that users have the correct levels of access.
6. Make access reviews timely and contextual
Access reviews are necessary for meeting compliance requirements, but they should also be seen as a critical tool for maintaining security by regularly identifying and removing unnecessary access. To maintain least privilege, access reviews should occur on a frequent and timely basis (at least once a quarter for privileged access) and be contextual (e.g., upon a significant role change). This level of on-going effort necessitates automation or the manual processes may become prohibitively expensive.
Create a regular schedule for user access reviews, defining the scope of each review scheduled, and share it with your supporting teams so they can prepare for and resource reviews appropriately.
7. Include context on access decisions
It’s important to understand the security implications of any granted access, permission, or group membership. Downstream authorization implications of access may not always be clear to approvers or reviewers. Group memberships, for example, may have significant knock on effects of granted permissions on resources and/or roles which can be challenging to understand. This effective access is important context when making access decisions.
Regular access reviews should include context around risk, the account with the access, and downstream implications of the grant. Help those who grant and certify access to understand the security implications of their decisions so they can make the best decision.
