The 2017 Thales Data Threat Report found that 59% of U.S. federal government respondents cited privileged users as the most dangerous insider threat. Privilege misuse was the number three breach pattern, according to the Verizon Data Breach Investigations Report. Security breaches are not the only problem that organizations face related to privileged accounts. Regulatory requirements have increasingly focused on addressing the risks associated with the shared privileged accounts, and specify a number of mandatory requirements organizations must comply with:
What are privileged accounts on public clouds?
Most of us are familiar with what privileged accounts are in private data centers and how to identify them. Everyone is aware of the infamous ‘root’ accounts, which give full administrative privileges to users in Unix/Linux operating systems. Another well-known type of privileged accounts are the domain accounts, which give administrative access to all servers within a Windows domain. Public clouds further extend this list. In the context of public clouds, privileged accounts can have broad access to the management and configuration information of cloud services and resources — from network and network security rules, to database services and IaM roles. AWS Root accounts and accounts assigned the Microsoft Azure ‘Owner’ role are examples of privileged accounts in public cloud environments.
The most dangerous of the privileged accounts are the so called ‘application’ accounts. These are used by cloud tools and products to gain access to cloud resources. ‘Application’ accounts often have almighty access to critical cloud resources, management functions and configuration information. The threat of privilege misuse starts to creep in when cloud products and tools allow users to leverage these ‘application’ accounts without maintaining individual accountability. Escalation of privileges allows unauthorized users legitimate access to resources, making such access indistinguishable from authorized activities. If these accounts are used to perform actions that lead to a security breach, it is simply not possible to establish which user is responsible.
Privilege Misuse in Microsoft Azure Environments
In Microsoft Azure, the Azure Active Directory (Azure AD) provides directory, identity and application access services. Every Azure subscription delegates authentication to the ‘trusted’ Azure AD tenant. In Azure AD tenant, you can create an ‘end user’ account, thus generating a user principal object; alternatively, you can register an ‘application’ with a corresponding service principal object. Either way, you will have a security principal object that can be assigned a role with specific privileges to access Azure resources at various scopes: subscription, resource group or individual resource. The accounts that are assigned roles with unrestricted access to Azure resources within the subscription scope have the ability to manage IAM users and groups, and fall into the privileged accounts category. The misuse of privileges typically happens when cloud products and tools do not use end user identities, as in a delegated permission model, and rely on the shared application identity that was granted privileges which far exceed those required by any specific organizational role.
Here are a couple of real-life examples that can lead to privilege misuse in Azure environments:
Cloud virtual machines images building tool — The documentation for this tool advises registering an application to create a service principal in the organizational Azure AD tenant, and assign the service principal to the Azure built-in ‘Owner’ role. The ‘Owner’ role is the top administrative role in Azure subscription that “has full access to all resources, including the right to delegate access to others.” Hence, anyone who gets access to this machine images building tool, will also get full access to Azure resources and all management privileges under the shared application account identity. The real identity of that individual will be hidden from Azure monitoring and logging tools, since it will be under the disguise of the shared application account used by the tool. In other words, if you follow the recommendations, you will create an account with privileges that go significantly beyond what is required to execute necessary functions, and that can be used in a manner that does not provide individual accountability.
Cloud infrastructure provisioning tool — Similarly, the documentation for the cloud infrastructure provisioning tool recommends registering an application to create a service principal in Azure AD tenant, and to assign the service principal to the Azure built-in, subscription-scope ‘Contributor’ role. In real life, we have seen environments where the ‘service principal’ for this application was granted even more privileges. The infrastructure provisioning tool would be given a permanently over-privileged account, which privileges and utilization do not align with the minimum that is consistent with the operational and business needs of any specific organizational role. For example, IT specialists would request the ‘Owner’ role be assigned to this product service principal, justifying the request by the need to provision new, custom Azure RBAC roles.
How CTP Can Help
You cannot mitigate the risks associated with shared privileged accounts in your cloud environments, if you do not know which accounts pose a risk. Manual checking and cross-referencing various logs is a time consuming and error prone exercise. CTP offers a Continuous Compliance solution that aims to automatically validate compliance and security technical controls in cloud environments. Our Continuous Compliance Program for Azure, available in the second half of 2018, will initially offer two frameworks: the CTP CIS Azure Foundations Benchmark and CTP Best Practices. The CTP Best Practices rules will perform automated examination of the accounts to identify accounts used by cloud products and tools which have been assigned a broad range of Azure privileges. As the CTP Continuous Compliance Program matures, we will be using these automated validation rules to introduce support for the major industry compliance regulations, such as PCI DSS, that define the corresponding privileged accounts control requirements.
Mitigating the security risks related to privileges misuse, and establishing individual accountability in IT systems have been priorities for enterprises for quite some time. As public cloud utilization comes of age, new additions to the arsenal of enterprise compliance and security tools can accelerate establishing comprehensive compliance and security policies across public cloud environments.