The principle means giving an identity (a person or machine identity) only those permissions which are essential to perform its intended function. If an identity does not need the permission, they should not possess it. The principle of least privilege is widely recognized as a security concept adopted for better data protection and to minimize the cloud attack surface. Today, identity and entitlements are the stepping stones of the cloud, and what we consider to be ‘the perimeter.’
The Importance of Maintaining Least Privilege
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.”
There are four main identity risks that determine the necessity of least privilege. 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 administration, 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 Involving Privileged Access
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.
Get to Least Privilege and Stay There
Organizations can achieve and maintain least privilege in the cloud with strong identity security through four steps.
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 – 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.
When the scope of alerts is overbearing, prioritization is critical, meaning your team knows what needs to be done now, and what can be deprioritized. You need context into how threats tie back to identity, entitlements, and ultimately data, in order to do this.
Following these four guiding rules 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 a total cloud security platform addressing all identity, data, workload, and platform risks.
See what we’re talking about with a demo or by exploring our solutions page.
