8 mins to read
What Is Least Privilege And How to Implement It
What is the Principle of Least Privilege?
The Principle of Least Privilege (POLP) is widely recognized as a security concept that enforces giving an identity (a person or machine identity) only the permissions that are essential to performing its intended function. If an identity does not need the permission, they should not possess it. It is implemented to minimize the cloud attack surface and protect data by mitigate the number of opportunities for exploitation via permissions.
How Does A Least Privilege Policy Work?
A Least Privilege policy works by limiting an identity or group’s scope of access to resources, applications, data, and overall function. It helps designate identities into clear cut workflows or tasks, as opposed to giving identities the ability to do or perform anything they want.
For a Principle of Least Privilege example, read about this dating website’s data breach.
The Importance of Maintaining Least Privilege
Today, identity and entitlements are the stepping stones of the cloud, and what we consider to be ‘the perimeter.’ Privileged access control is finally getting the attention it deserves and many established organizations are highlighting the role privileged accounts play in cloud breaches. In fact, Forrester estimates that 80% of security breaches involved privileged credentials. The heavy influence privilege plays in cloud breaches is further backed by IBM’s annual Cloud Threat Landscape Report:
“In 99% of pen testing engagements, X-Force Red was able to compromise client cloud environments through excess privileges and permissions on cloud Identities. In other words, 99% of cloud identities (person and non-person meaning, service accounts, compute, roles, etc.) were overprivileged. This result is consistent with our own research at Sonrai, finding only 3% of permissions granted to actually be used. Increased privilege, especially excessive privileges, is just an increased attack surface.”
IBM Cloud Threat Landscape 2022
Benefits of Least Privilege
- Eliminates Human Error: Enforcing an identity and access policy like Least Privilege takes away the need for human manual efforts that could lead to unintentional error. Less error means less risk.
- Reduces Attack Surface: Granting identities the least amount of privilege possible to do their job means less opportunity to exploit. When an attacker enters an environment, they are searching for identities with the right permissions assigned to execute their intended outcome. Least Privilege reduces that leeway for lateral movement or the opportunity to exploit a privileged user.
- Streamlines Compliance/Audits: Some compliance frameworks entail following a Least Privilege policy outright, or have regulations around access for privileged accounts. Implementing POLP makes proving compliance a smoother process.
Four Reasons You Need Least Privilege
There are four main identity risks that Least Privilege addresses. These include the separation of duty, dormant identities, privilege escalation, and toxic combinations.
Separation of Duty
Separation of duties (SoD) is an internal control concept that involves the distribution of responsibilities and privileges among multiple users with the intention of preventing fraud and error..
Separation of Duties applies to two areas. The first is the prevention of conflict of interest (real or apparent), wrongful acts, fraud, abuse, and errors. The second is the detection of control failures that include security breaches, information theft, and circumvention of security controls. It is designed to ensure that identities (people and non-people) don’t have conflicting responsibilities or are in a position of opening the organization to risk. Privilege creep – the gradual increase of permissions over time – can lead to toxic combinations, but more on that later.
SoD entails that the individual responsible for designing and implementing security must not be the same person as the person responsible for testing security, conducting security audits, or monitoring and reporting on security.
Separation of duties can be difficult to achieve with limited staff members, but controls should be put into place as much as possible to reduce the risk of a single point of compromise. You should assess the likelihood of a privileged activity causing a major impact to the business and build controls to reduce this likelihood or minimize the impact.
Dormant Identities
Dormant identities are characterized by a lack of login activity for a set amount of time, if at all. Malicious parties may access these identities, without the knowledge of its original owners, to conduct destructive activities to the organization’s systems, data security, and reputation. As such, they’re essentially sitting ducks, an increased attack surface, and carry potential security risks to organizations.
It is necessary for cloud users to accurately identify and flag dormant identities to keep a close tab on them while subsequent activities are promptly clamped down. Ideally they can be removed altogether. Some possible solutions include ID-mapping on the cloud, where all identities are automatically sorted according to their business attributes or functions through classification, or by importing organizational charts, which recognizes identities based on the updated workflow. The big takeaway is your organization should keep a continuous inventory of all the identities in your environment.
Privilege Escalation
Privilege escalation occurs when a malicious attacker exploits a vulnerability, often an IAM misconfiguration, in the cloud. There are five types of privilege escalation defined by Sonrai Security.
Direct Self Escalation. When you allow an identity to modify its own rights, it’s called Direct Self Escalation. This means that the identity can move throughout your environment with all of the permissions needed for administrative access, such as being made into a system admin or having full control over data access.
Indirect Escalation. Indirect Escalation is where one identity can modify another identity’s credentials to impersonate it and complete their desired action. For example, an identity has the permission to modify roles. While this identity cannot read sensitive data itself, it can modify other roles so that it can read that data, and then jump into this new role and ultimately reach its goal.
Unintended Escalation. Unintended Inheritance is often the result of the complexity in your cloud, including a web of rules, policies, trust relationships, and permissions that give access at an unintended level. Unintended Inheritance occurs when there are too many interconnected components within the environment you’re managing, like web of regulations, permission structures on top of each other coupled with sensitive data being stored everywhere.
Confused Deputy. Confused Deputy refers to an identity with a low set of permission that gets access to a resource or a service with a higher level of permission and then uses that to perform actions on its behalf. For example, an EC2 instance has an instance profile with access to read sensitive data. The low-level identity uses the EC2 to read all of the sensitive data on its behalf.
Resource Permission Escalation. This is when an identity has the permission to change the configuration settings on a resource to allow the identity to perform unintended actions on that resource. For example, this identity is at least privilege, but it has the permissions to change the configurations of a datastore that normally it only has read access to, giving it the ability to delete the datastore.
Toxic Combination
Toxic combinations are the result of overlapping privileges that create abilities passed what is intended for an identity. Sometimes the abuse of privileges enabled by SoD results in toxic combinations. For example, a developer is assigned to Group A, and Group A has assigned privileges that are in line with least privilege. However, the following year, the developer’s role expands and they are now a part of Group B, which on its own is in accordance with least privilege, but the overlap of permissions between A and B give this developer unintended abilities. Simply put, toxic combinations are permissions that have been put together, but they create risk.
Notable Breaches
Here are some violations of the Principle of Least Privilege examples:
SolarWinds: This breach hit the headlines in 2020 with widespread damage. The attackers deployed malware into SolarWinds’ Orion source code. Customers were vulnerable to the supply chain attack because of one fatal mistake: the Orion application needs unrestricted access, or, shared admin access, to work. This is inherently unaligned with the principle of least privilege, and allowed attackers unrestricted privilege access through the compromised Orion application.
Uber: An attacker used social engineering to compromise an employee’s Slack account, persuading them to hand over a password that allowed them access to Uber’s internal systems. Once in Uber’s environment, the bad actor was able to move throughout the tech stack, gaining unimaginable access. The bad actor gained access to the company’s internal network *.corp.uber.com. From Uber’s internal network, the attacker found PowerShell scripts, one of which contained credentials for an admin account from Uber’s Privileged Access Management (PAM) solution.
The PAM controls access to multiple systems, and having admin access means the attacker can give themselves complete access or extract secrets to all connected systems. Critically, Uber’s platform was compromised through the exposure of its admin credentials. In this case, no privilege escalation was needed, just a compromise of a single employee or endpoint, some simple reconnaissance, and admin credentials stored in a script on an internally open share.
Best Practices: Implementing a Least Privilege Policy
Organizations can achieve and maintain least privilege in the cloud with strong identity security through four steps and best practices.
Relentless and Continuous Monitoring
This relates to the monitoring of both data and identity. This starts with having a continuous inventory of all identities in your environment and data. Where is all your data? What is it? Who and what can and is accessing it? Data discovery and data classification is a must. Establishing these knowns then allows you to monitor your environment against secure baselines and detect deviations or suspicious activity.
Know Your Effective Permissions
This is a core pain point for many organizations – a lack of visibility into their cloud. However, this ignorance will be your Achilles heel, as identity is at the core of cloud security. Effective permissions are the end-to-end or entirety of an identity’s abilities. What is the true picture of what each and every identity can do in your cloud? Evaluating the risks of identities (people and non-people) across multiple public clouds, containing hundreds of accounts is challenging. Understanding all the effective permissions of an individual identity is a problem that cannot be solved by evaluating a single policy or calling an API. Trust relationships, nested groups and other covert compounding privileges create a lot of complexity. The scale and scope of cloud leaves manual efforts insufficient – leveraging a cloud security platform is largely the only way to gain visibility into effective permissions.
Enable Your Teams to be Part of the Solution
First, educate your teams on PoLP best practices. Second, your organization should shift left by integrating your Security, Cloud, Audit, IAM, and DevOps teams. Security is no longer a security team issue – it is an organization-wide concern. Culturally, involving all aspects of your organization improves security by building security into your processes from the start, as opposed to last minute security checks.
If There is an Issue, Fix it Fast
Operationalize your security processes. First line of security is preventing the problem from happening in the first place, but if you missed it, closing the gap quickly. Put prevention rules like policies or bot checks in place across your cloud and make sure they stay there. When issues are detected, you want a threat triaging process that alerts responsible parties quickly and efficiently.
It’s Time to Enforce a Least Privilege Policy
Following these four guiding best practices will get you started on the right path to eliminating risk across your cloud. Successfully achieving and maintaining Least Privilege is core to a strong security program. Sonrai Security offers Cloud Infrastructure Entitlement Management to tackle Least Privilege and other cloud-native identity and data risks.
See what we’re talking about with a demo or by exploring our Least Privilege solution.
For more information on building a least privilege policy, read our blog. or watch this on demand webinar ‘Achieving and Maintaining Least Privilege.”
Read the latest news and insights
12.17.2021
Clouds, while revolutionizing business, have exponentially...
03.10.2021
When you think of identity management in an enterprise...
06.09.2020
Read our webinar recap to understand how your organization...
