grandeduc - Fotolia
The threat of shadow admins in the cloud to enterprises
Having shadow admins in the cloud means unauthorized users can access everything a legitimate administrator can. Expert Ed Moyle explains how this works and how to stop it.
Sometimes, new technologies mask existing problems so they seem to disappear. But they're still there, and they still need to be fixed.
Engineers at CyberArk Software Ltd., an information security company based in Newton, Mass., highlighted one such potential issue in a session at RSA Conference 2018, in which they outlined the problem of shadow admins in the cloud. They pointed out situations where, even though a given user didn't appear to have administrative-level access -- something along the lines of the AdministratorAccess permission in AWS -- they still had sufficient rights to grant themselves administrator-level permissions, compromise the security of cloud resources or otherwise perform privileged functions.
What are shadow admins?
Shadow admins aren't an entirely new problem. Many organizations have struggled over the years with similar problems with on-premises technology deployments. For example, in a Microsoft Windows context, suppose a user isn't in the Domain Admins group, but has full, administrative-level control over a critical resource because their individual user account is directly assigned to the resource. Or, alternatively, consider a situation in which an organization has created a new group or user that is administrator-equivalent, but is called something different.
Shadow admins can come about in the cloud, too. The CyberArk researchers pointed out 10 different permissions that can be used to give a user full admin rights that, when viewed by a casual reviewer or by someone who does not fully understand what the permissions do, don't appear to be administrative in nature.
CreatePolicyVersion and SetDefaultPolicyVersion are both examples from the AWS parlance that fit the description from the CyberArk research. Those roles are effectively the same as having administrator-level permission because the user can create and apply a new version of the policy that does grant them administrative rights. So, even though they're not an admin now, they can become one by virtue of the permissions they already have.
Situations like that can be hard to see in on-premises deployments, but in the cloud, they can be even more difficult to find and address. This is true for two reasons.
First, the permissions are less directly visible to security teams. Unless security teams are aware of the issue, know what to look for and explicitly check the permissions, they are unlikely to find shadow admins unless or until they are used for nefarious ends.
Second, even when organizations use tightly control privileged accounts -- both on premises and in the cloud -- and periodically validate that the permissions are appropriate, introducing a cloud environment means more places where that check needs to happen and different permissions to understand and look for. The difficulty is further compounded because most organizations use more than one cloud provider.
Using cloud services can expand the surface area of the administrative permissions that the security team needs to evaluate. Likewise, it makes that evaluation harder because not every cloud provider uses the same permissions and policy structure or behaves the same way. It's a very real issue and one that can be difficult to solve.
Closing the cloud shadow admins permissions gap
One might naturally question whether the policy architecture of specific providers, granularity of policy enforcement or other aspects of individual cloud deployments facilitate shadow admins in the cloud and whether, by extension, those mechanisms are maximally conducive to robust security on the part of customers.
However, these questions are a bit of a trap. One might similarly question the specifics of Unix's root user implementation or the specific mechanics of Windows admin users or access control lists, for example. Each model works differently and, when enterprises employ these systems, the onus is on the security team to understand how they work, plan accordingly and implement strategies around them.
The question for practitioners is what they can do about shadow admins in the cloud as a practical matter. The first step is to understand that the problem exists. Fortunately, as it is similar -- at least conceptually -- to the privileged access management challenges that security practitioners have struggled with ever since the first privileged account was created, a little knowledge of the issue can go a long way. Understanding what specific permissions allow means security practitioners know what to look for when evaluating cloud policies.
This is a useful starting point, but further action is required beyond this to address the problem, particularly when more than one cloud provider -- or multiple instances of the same provider -- is in use. Specifically, the same way you might undertake a systematic review of domain accounts and resources, so too can a systematic review of cloud policy help here.
CyberArk has made available an open source tool called SkyArk to help automate this review process and glean information from log data.
Alternatively, a more manual approach to policy review can be used provided that the reviewer is armed with information about what to look for. This means learning about both cloud policy itself and about these specific permissions -- and setting up procedural and governance structures to evaluate them, remediate when appropriate, and to find and flag access levels that are not commensurate with what you desire or expect.
