Surface-level permissions are misleading. Here’s how to discover effective permissions that tell the full story.
Threat actors are increasingly exploiting excess permissions in critical systems as a leverage point for cyberattacks. As organizations migrate more of their applications, assets, and operations to public clouds, they’re gaining new efficiencies and business agility…but loosening the tight grip they once had on securing privileged access management. Charged with fast-tracking digital transformation, IT leaders have at times enabled a liberal approach to access rights, giving more access than necessary to reduce friction in the short run and facilitate business agility. The cost of taking this shortcut is a silent sprawl of unnecessary shadow privileges that isn’t well understood by organizations, and that attackers can easily exploit to expand any unauthorized access they’re able to secure. That’s why it’s mission critical for enterprises to move beyond surface permissions—the access rights they think are in place—and understand their effective permissions—the true current state of access privileges.
The Risks of Over-Permissioning
A good example of the risks of excessive permissions is onboarding third-party contractors or partners. One study by Wiz—a security company that scans organizations’ public cloud environments for vulnerabilities—found that 82% of the companies they studied give their third-party vendors highly privileged roles including read access. These vendors have the ability to leak the client company’s sensitive data, posing a significant privacy risk even if they aren’t themselves bad actors. (The research, conducted last year to assess the direct exposure from IAM roles, was based on more than 1,300 AWS accounts and over 40 popular third-party vendors, but Wiz head of research Shir Tamari says they’re seeing similar issues with Microsoft Azure and Google Cloud accounts.)
The study discovered that 76% of the surveyed companies had third-party roles that allowed for complete account takeover. In most cases, those with these effective permissions don’t need them and didn’t ask for them; in this study, over 90% of cloud security teams were not even aware that they had granted these unnecessary permissions to vendors. This represents a serious security gap, but also a visibility gap: Most organizations that have migrated to public clouds simply don’t have a good grasp on which users have access to systems or resources that they don’t need—and consequently, what their resulting threat exposure is.
So what’s going on, here?
Why Cloud Over-Permissioning Happens
Given the fact that traditional on-premises IT infrastructures were built with an emphasis on creating and managing permissions, some might wonder why that discipline seems to have faltered as organizations migrated to cloud environments. The bottom line is that on-premises administrators had physical control over on-premises server, storage, and network infrastructure, and could easily determine and enforce permissions to specific resources. As Eyal Arazi of Radware, which provides application delivery controllers,recently noted: “In worst-case scenarios, if they detected a problem, they could walk over and disconnect the server, therefore blocking off the problem.” In those simpler times, perimeter security like firewalls and secure web gateways could effectively protect on-premises datacenter resources from outside threats.
Digital transformation changed all of that. As growing organizations started migrating to public clouds, users and managers often didn’t know what permissions different users and roles would need, and how that would evolve over time. For many, overpermissioning seemed to solve efficiency problems in the short run, ensuring teams could get their work done without being hindered by access friction. And cloud services make it easy to grant permissions, using Infrastructure as Code to automate permissions in bulk based on user roles. AWS customers, for example, can define access through pre-defined AWS managed policies. The popular “ReadOnlyAccess” policy, for example, may sound safe and harmless, but actually provides broad access for vendors to see inside your databases, S3 buckets, and more.
Clearly, it’s critical to sift through your raw permissions and come to an understanding of the effective permissions that truly define the state of an enterprise’s access privileges. But teasing out your effective permissions from the raw data isn’t easy.
Critical Challenges to Cloud Permissions Visibility
Understanding enterprise cloud permissions is complicated by four specific factors: Breadth of actions, depth of evaluation logic, lack of natural language, and lack of IAM or multi-cloud standards. Let’s take a look at each of these in turn.
1. Breadth of actions refers to the daunting variety of allow/deny combinations that potentially exist between services, operations, resources, and conditions for any given policy. The resulting thousands of potential permutations is virtually impossible for humans to untangle.
2. Depth of evaluation logic refers to the multi-dimensional nature of how raw permissions interact with one another. Knowing the permissions granted in a specific situation by a specific policy isn’t enough—you have to also understand what other policies apply, and figure out what will be enforced when permissions collide. Permissions naturally begin with identity-based policies (who can do what), but other layers, such as Service Control Policies and Permission Boundaries, can impose their own rules that can override identity-based policies. And some resource-based policies, such as S3 bucket policies, reside outside of IAM altogether, meaning that cross-account access could be granted without leaving any trail in IAM.
3. Lack of common terminology. Proprietary access policies are often described in proprietary terminology as well, making it difficult and tedious for non technical types to come to an understanding of what’s permitted and what isn’t. In the cloud, API operations like “dynamodb:GetItem,” “dynamodb:PutItem,” and “dynamodb:UpdateItem.” At the app level, these might be represented in GitHub with words like “Pull,” “Fetch,” and “Push.” And at the database RBAC level, they might be expressed using the SQL syntax of “Select,” “Insert,” or “Alter.” True visibility requires first finding a way to translate these representations into a common, natural language that helps admins understand how each applicable permissions set defines what can be Created, Read, Updated, and Deleted ( the CRUD model).
4. Lack of app or multi-cloud IAM standards. Authorization is tracked against services and API operations, but APIs vary greatly between providers, meaning that the associated permissions can be surfaced in dramatically inconsistent manners across multiple apps and cloud providers. AWS, Azure, and GCP have different organizational access boundaries, resulting in an additional level of permission terminology that is not intelligible between them.
Why visibility is the critical first step
Security teams need to take immediate action to minimize the threat of third-party permissions in their cloud environments, and reduce the growing risk of a supply-chain attack or vendor-based security breach. But organizations can’t start reining in over-permissioning until they can find it—seeing is securing. That’s why it’s so important to solve these challenges and conquer the monumental task of determining your effective permissions, aggregated across multiple cloud providers, and translated into a natural-language understanding that compliance officers and other non-technical managers can view or audit. Without a fully evaluated and normalized view of authorization across intra-cloud and inter-cloud providers there is significant risk of granting excessive privilege, with toxic permissions interactions that can enable lateral movement, privilege escalation, and data exfiltration. Your effective permissions define your attack surface—and only with a true understanding of who can take what action on what resources can you apply the best-practice principle of least privilege across your organization.
How Veza arms you to discover, understand, and normalize permissions
Veza is built to help you uncover, understand, and remediate the shadowy sprawl of effective permissions. It uncovers all access privileges across your ecosystem: not just across multiple cloud providers, but down to the granular level of the apps (GitHub, Salesforce, Workday, Gitlab, etc), and data stores (Snowflake, SQL Server, Redshift, etc) that comprise your enterprise ecosystem. Veza considers the access boundaries of each app, cloud, and repository, and maps a complete path of privilege between identities, apps, and data, defining your effective permissions. Using a canonical data model, Veza then normalizes the results, presenting your teams with an easily understood, natural language create, read, update and delete (CRUD) model that’s easy for non-technical people to digest and interpret.
C-suite managers, compliance officers, security teams, and other users—including technical people who just don’t want to dig into all the API calls to visualize the effective permissions for themselves—can easily consume, search and query these effective permissions and link them to monitoring and alerting tools. The only cloud-native data security platform centered around authorization, Veza turns effective permissions from an unreachable goal to an everyday reality that can shrink your attack surface and protect your enterprise against cyberattacks, compliance breaches, and other negative outcomes.
