Granting users with authorization to access sensitive business information means that you rely on them to adopt cybersecurity best practices. This trust is violated when a disgruntled employee acts maliciously and leaks sensitive information.
What’s more concerning — the same violation is also possible when users unwittingly fall prey to social engineering attacks, zero-day exploits or vulnerabilities that remain unpatched in your IT networks. (In fact, 40% of all cyberattacks involve social engineering, such as entering real login credentials on a fake authentication form.)
The solution to this problem is to limit security access for every user. And that’s what the Principle of Least Privilege helps to do.
How least privilege access works
In the NIST definition of Least Privilege access, every entity in a security architecture is granted access to the bare minimum of system resources and authorization required to perform its function. By limiting the access privilege, you can mitigate the risk posed by a user relating to intentionally malicious attacks or accidental security breach incidents.
Limiting human access to only essential actions and information is critical for organizations seeking to limit cyber risk. The human element is responsible for 82% of all cybercrime incidents. Perhaps that’s because every employee is authorized to access, on average, 11 million files! That makes employees a potentially valuable target for bad actors.
Here’s a few more stats that bare this out:
- Over 66% of organizations allow all users to view sensitive files.
- 33% of employees risk running malware on their machines.
- Data breach incidents caused due to the human element cost on average, $3.24 million.
So, this concept makes sense in theory: with fewer people accessing files, you reduce risk. But how do you apply it?
Applying security controls with the Principle of Least Privilege
The first step to apply least privilege security controls is to understand the roles and responsibilities for every user.
Start by creating a scope of job functions that excludes all unnecessary and privileged sensitive information. The corresponding permissions will likely overlap: users from different business functions may need access to a variety of information and system resources depending on the job task.
Permissions leakage aka privilege creep
An unintended consequence here is that users who share similar responsibilities may end up with access permissions beyond what they should, or need to, have. For example, your job responsibilities might grant you a certain level of authority that allows you to override the access restrictions that were meant to limit your access in the first place.
This situation — known as permissions leakage, privilege creep or privilege escalation — creates a security vulnerability by granting users more access than necessary. This vulnerability potentially compromises sensitive information or systems.
Permissions leakage is common in such as Role Based Access Control (RBAC). This scheme assigns security authorizations based on user roles, which in turn, are governed by the associated job functions and responsibilities. This approach simplifies I&AC, since new user entities belonging to a certain role group can simply adopt all security controls assigned to that role.
(Learn how to detect AWS privilege escalation with Splunk.)
Challenges with identity & access control
In practice, however, the corresponding responsibilities can change rapidly. This is especially the case for dynamic organizations and startup firms that:
- Adopt Agile and DevOps frameworks.
- Rely heavily on automation systems.
Of course, rapid provisioning of new tools and access to data is the foundation of rapid and continuous development, continuous integration and rapid release cycles.
Other power users at digitally transformed organizations rely on analytics tools that process large volumes of business information – including sensitive data to guide mission-critical business decisions. Similarly, policy regimes within the organization can change abruptly and arbitrarily.
Compounding this issue are limitations to circ*mstances that define the specifics to access control permissions. The circ*mstances can depart from full generality and create situations where the permissions cannot hold.
In contrast, defining too many outlying circ*mstances makes for a highly inefficient and unscalable I&AC scheme, forcing frequent manual interventions — slowing down the process and potentially contributing to permissions leakage. (Taking too long for approval for an app? Your co-worker might just share their login details with you instead.)
And finally, there may be multiple ways to enforce the same principle of least privilege access. The challenge here is to establish an I&AC scheme…
- That minimizes loss with a more general approach. That is, your scheme does not require manual overrides and exceptions.
- That is sufficiently specific. That is, the generality does not lead to permissions leakage in situations where multiple group clusters from different roles may share some overlapping responsibilities but cannot be allowed to share the same set of permissions.
Best practices for least privilege access
So how do you control access to sensitive information in the complex hierarchy of your organization?
Instead of defining security controls based on roles, an alternative approach is to adopt Policy Based Access Control (PBAC) schemes that use policies to outline access permissions. One example of the PBAC is Attributes Based Access Control (ABAC), which allows organizations to define a granular and fine-grained control scheme by considering the environment and subject attributes corresponding to the access requests.
To get context for a given permissions request, ABAC system evaluate:
- The requesting subjects or entity
- Their request actions
- The resources requested
- Environment variables
The security control scheme then evaluates the request against predefined organizational policies — these policies can change dynamically as users are assigned new responsibilities.
Depending on the changing policies as well as evolving attributes pertaining to different access requests, ABAC can maintain the principle of least privilege access with minimal permissions leakage.
