Photo by Ivan Samkov
Originally Posted On: https://sonraisecurity.com/education/principle-least-privilege/
What Does Principle of Least Privilege Mean?
The principle means giving an Identity (user, role and/or service) only those privileges which are essential to perform its intended function. The principle of least privilege is widely recognized as a fundamental design consideration for the protection of data and functionality from faults and malicious behavior.
Identifying the Four Major Risks
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 commonly applied which involves the sharing of a set of responsibilities and privileges among multiple users with the intention of preventing fraud and error.
Separation of Duties has 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, human and non-human, don’t have conflicting responsibilities or are in a position of opening the organization to risk.
Moreover, 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 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 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.
Privilege escalation occurs when a malicious user exploits a vulnerability, often an IAM misconfiguration, in the cloud. There are two types of privilege escalation, both having the potential to cause great disruption to user and organizational data.
Horizontal privilege escalation involves users with a limited account accessing another account with greater privileges. For example, a trial account user in a cloud environment might unlock and access the privileges of a premium user without payment.
Vertical privilege escalation presents more serious consequences, as malicious users gain the privileges of a power user, such as an account administrator. This means that malicious users can gain access to sensitive data and credentials. Malicious users may alter your environment for their benefit, steal privileged information, or erase vital data.
Toxic combinations involve the abuse of privileges enabled by SoD. For example, a user authorized to create an invoice might be mistakenly provided with the privilege of paying the bill. For example, IT users granted privileges to create identities should not be allowed to grant privileges to their created identity.
Get to Least Privilege And Stay There.
Organizations can achieve and maintain least privilege in the cloud with strong identity governance through four steps.
Relentless and Continuous Monitoring – Identity and data access should be monitored at all times with alerts being fired for events that deviate from your governance and operational models. Inactive or suspicious accounts should be swiftly detected and deactivated while identities should be constantly updated to fulfill the latest compliances through regulations such as the California Privacy Law and organizational mandates.
Know Your Effective Permissions – 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. To manage this complexity and reduce risk to your identities and data, your organization should have end-to-end visibility into the trust relationships, as they truly exist in your environment. Without this visibility you are operating more or less blindly.
Enable your teams to be part of the solution – Your organization should shift left by integrating your Security, Cloud, Audit, IAM, and DevOps teams. Dev teams across your business populate your cloud with workloads and data in development, staging, and production. Some workloads access sensitive data while others do not. Some workloads are blocked from external access while others are not. By structuring your cloud into “swimlanes” that reflect your different needs for monitoring and control, Sonrai can help provide organized analysis, context-based alerts, and actions the way you organize your cloud.
If there is an issue, fix it fast – Prevent the problem from happening in the first place and if you missed it, close the gap now. Put prevention rules in place across your cloud and make sure they stay there. As people try to move workloads to production, use prevention bots to ensure checks are in place, and promotion only happens if your risk policies are followed. When possible, your organization should apply the policies to swimlanes to prevent the creation or change of risky cloud services and thus eliminate the possibility of risks being created in the first place.
If you follow these four steps, you’ll eliminate risk across your public cloud by getting to and maintaining least privilege. To learn more about this important pillars of cloud security, watch our webinar, “Achieving and Maintaining Least Privilege“