Organizations have struggled to gain control on overprivileged identities; a challenge that has created issues in cloud environments across cloud security teams and through risk departments causing major data breaches.
To get a better understanding of overprivileged identities, let’s start with 3 questions:
1. Who and what has access to privileged identities in your organization?
2. Can you list all of the accounts in your environment with a high level of privilege, and all of the people, applications, and services that have access to those accounts?
3. Do your privilege controls address the unique and new challenges posed by public cloud providers like AWS, Azure, and Google Cloud?
For most of us, the answer will be “no.” It’s easy enough to name the more obvious stakeholders and roles, but it will probably be very difficult to come up with an exhaustive list – even if your organization is very small and has a relatively simple IT infrastructure.
If your operations are in the public cloud, simply putting together a ballpark estimate of the number of privileged roles is likely to be a major challenge. Compiling a complete list of those roles in detail is almost certain to be beyond the capacity of anyone in your organization.
Frankly, this is not surprising when you consider the more-than-likely possibility that your cloud operations includes thousands or tens of thousands of individual application and infrastructure elements, along with thousands of roles. Consider further that individual elements can assume roles and change roles. This means that any given element of your cloud operations may at any given time find itself with privileges which it was not designed to handle – a situation which can all too easily turn minor errors into major problems.
What is A Privileged Identity and How Does it Work in the IT World?
Why is this true, and why is it so important? Let’s take a look at the risks of overprivileged identities and inadequate control of privileges in today’s complex and highly virtualized IT environment.
Let’s start with a very basic definition of privilege:
Privilege is the ability to manage or control key functional and data elements of a system or IT infrastructure.
Quite obviously, such a definition is at least somewhat relative. A user with a low level of privilege will still be able to use some applications and manage files in some designated locations, while an identity with administrative privileges may have full or nearly full control over the entire system. In general, however, “privileged identities” refers to accounts with a high level of privilege.
Too Much Privilege
So what do we mean by “too much privilege” or an overprivileged identity?
These are identities with significantly more privileges than are required to carry out the duties assigned to those identities. A user login account which only needs access to the local file system but actually has system or network admin rights is a rather obvious example of such an overprivileged identity. On the other hand, a cloud-based resource which has been granted unnecessary “owner” status is equally overprivileged, and may be much more difficult to identify as such.
In the context of the public cloud, this kind of overprivilege has very serious implications. The scale of the cloud provides a vast number of potential points of access, and an even larger number of elements (at the data, application, and infrastructure levels) which can be affected by such access. And since many of the key parts of the cloud are virtualized, excessive privilege can include the ability to effectively modify or even delete vital elements of the infrastructure itself.
Privileged Roles
There are a variety of privileged roles in any network-based or cloud-based operation, but in general, they fall into two broad, informal categories:
1. Administrative roles. These can include single systems, a local network, a cloud-based service, or individual sites such as a WordPress blog.
2. Application/service roles. Such roles are often given a high level of privilege by default.
Admin roles are generally associated with login accounts intended for use by human beings. Application/service roles may be provisioned during the initial setup of a system or as part of software installation. Theoretically, it should be possible to keep track of both types of roles and their associated privileges; in practice, however, it can be extremely difficult to do so.
This is particularly true in extremely large public cloud environments such as AWS, Azure, and Google Cloud, since the number of roles provisioned for VMs, containers, serverless functions, and similar application and infrastructure elements can run into the thousands. At such a scale, keeping track of these roles, their behavior, and their privileges presents an extraordinary and unprecedented challenge.
Privilege Inflation
What makes the management of privileged identities so difficult? For many organizations, the difficulty arises from a combination of cumulative “privilege inflation” for individual accounts, proliferation of privileged identities, and lack of adequate tracking.
Inflated Levels of Privilege in People
What kinds of people (as distinct from roles) are likely to be assigned or accumulate inflated levels of privilege?
1. High-status individuals. This can include such people as the top managers for cloud ops and security, largely because the company or org culture requires or encourages such elevated perks.
2. Employees who are assigned multiple responsibilities requiring privileged identities. In smaller organizations where individuals may take on a variety of roles, this can lead to a gradual accumulation of privileges.
3. People who deliberately acquire privileges over time. Sometimes people do this for relatively innocent reasons (curiosity, future use, or even pseudo-status), but their motivations may just as easily be malicious, and in practice, there may be no clear boundary between the two.
Inflated Levels of Privilege in Applications and Services
Very often, applications and system resources require high levels of privilege to perform specific tasks (accessing databases, writing to restricted locations or registries, provisioning other resources). The actual levels of privilege may be set by the cloud provider, by IT, or during an application’s installation process. For the most part, there are two overall types of criteria for setting application/resource privileges:
1. What the resource might require – if it may need the right to perform an action at some point, assign it the associated privileges by default.
2. The minimum that it requires – assign only those privileges required to perform a specified set of tasks.
The minimalist approach means that the application or resource may need to request user intervention in order to perform tasks not specifically allowed, so service providers, developers, and DevOps often tend to assign the high, “might require” level of privileges by default.
In the public cloud, this process of privilege inflation is made even more complicated by the ability on the part of application and system resources to switch roles as required, producing temporary chains of privilege inflation which may be very difficult to track.
Taking Control
The best way to take control of your operation’s security and reign in overprivileged identities is by means of a comprehensive cloud-based security platform. This allows you to manage identity and data relationships at a fine-grained level while integrating with your cloud service provider’s IAM resources.
With the right kind of platform and support, you can replace privilege inflation with privilege control – and replace risk with genuine security.
To learn more on IAM security for the public cloud, download the Ultimate Guide to Least Privilege eBook or hear our experts discuss how Identities Are The New Perimeter For Securing Data In Public Cloud in our on-demand webinar.
