Veza Has Passed a New Milestone as it Modernizes Identity Security

I’m excited to announce that Veza is now monitoring 200 million permissions for our customers. These permissions are associated with identities in systems like Okta, Ping, Azure AD, Active Directory, Google IAM, AWS IAM as well as local accounts that exist only in apps or cloud systems. The number underscores our rapid customer adoption, and it validates the scalability of our Veza Authorization Graph. But we’re just getting started. Every day, our customers add new integrations and connect to more systems, ingesting data about their permissions. As the number grows, it corroborates our central conviction: identity security requires a data mindset and lots of automation.

We love it when our customers say, “identity is the new perimeter.” In a zero trust model, there’s no presumption of access for anyone. Instead, every request from every identity must be authorized for a specific resource (database, app, service, compute, etc). Authorization defines the permissions of who can take what action on what data. And since permissions are the keys to everything, somebody had better watch those keys. Security and identity professionals acknowledge this, and they aspire to follow the principle of least privilege. Yet nobody claims success. In every company, access permissions are rife with mistakes, violations, and over-privilege. In short, companies are at war with their bad permissions.

Bad Permissions

Permissions, also known as entitlements, are rights to perform certain actions—create, read, update, or delete—on objects like database tables, files, or documents. Permissions are specific to each system, and each system has its own language. There’s no lingua franca in authorization. Companies grant permissions (to humans or machine identities) to access resources in applications and systems, whether cloud or on-premise. Permissions might be broad (“view all data” in Salesforce) or specific (read one column in a database table.)

Every permission creates some risk if the identity to which it’s assigned is ever compromised. A company will accept the risk if the permission adheres to least privilege and complies with all policies. But many permissions fail this test. Permissions are bad when they give a user dangerous capabilities or unnecessarily broad access, creating risk from insider threats and external actors who steal or phish credentials. For example, in the 2019 Capital One breach, an instance of EC2 had unnecessary access to S3 buckets containing customer data. Bad permissions also jeopardize company compliance (with SOX, SOC 2, GDPR, etc) and lead to tedious investigations and possible fines.

When we examine bad permissions, we categorize them in 4 types:

1. Over-privileged: where an identity is granted more access than necessary to do a job.
2. Residual: where access should’ve been revoked after a termination, job change, or completion of a temporary task.
3. Ungoverned: where local users are created outside the purview of identity tools like SSO and IGA.
4. Policy-violating: where security rules are not being followed due to lack of visibility (e.g. separation of duties, requirement for multi-factor)

Bad permissions are pervasive. How many do you have? It depends on your policies and level of regulatory oversight, but it’s not uncommon to see thousands of troubling permissions. Turning on Veza is a bit like opening the hood on a car that’s never had its oil changed. Prepare to grimace.

Companies are full of bad permissions because new ones are created throughout the organization every day. Over-privileged permissions are created every time an IT staffer grants access on the basis of a mislabeled group name, making their best guess about access. Residual permissions are created every time an employee leaves or changes jobs. Ungoverned permissions are created when access is provisioned locally to a cloud-based system or SaaS app. Because identity and security teams cannot see these bad permissions, they cannot fix them. Thus the permissions accumulate as “access debt”. With more debt comes increased risk of insider threats, breaches, and compliance headaches.

Blind Spots

Companies invest a lot in their effort to manage permissions. Identity teams buy tools to provision new employees and staff teams to process access requests. Managers spend time evaluating and certifying access for their employees. SecOps and security engineers spend time hunting for privilege violations across a vast menagerie of systems. Governance teams invest in policy refinement, and auditors work to collect evidence that controls are adequate. With all these FTEs at work, how do so many bad permissions escape notice?

The problem is the tools. Traditional identity tools (IAM, IGA, PAM) have blind spots because they weren’t built to understand how identities (users, groups) map to actions (policies, permissions) in resources (databases, tables, folders). The business processes around access have evolved faster than the tools. For example, IGA (identity governance and administration) tools can only manage permissions as bundles in groups and roles. They rely on the assumption that groups and roles are labeled accurately–a bad assumption. They cannot calculate the “effective permission” of a complex IAM policy. The IGA data model presumes a master list of identities, an assumption that can’t be true in a modern IT environment. In short, IGA was built for a different era.

It’s tricky to see the reality of permissions. The RBAC model (role-based access control) is the most common way of defining and managing system-specific permissions and assigning them to identities. Because each system has its own approach to access control, there’s no universal language, and security teams are left to untangle cryptic permissions on their own.

Ever try to figure out which accounts can access an AWS S3 bucket? It’s not easy. In AWS IAM, an S3 service administrator can define one policy which grants a user read access to a S3 bucket, but the overall administrator of the AWS account can define other policies (e.g. Permission Boundary Policies or Service Control Policies) which deny the same user read access to the same bucket.

Azure is no easier. An Azure Blob service administrator can grant a user read access to an Azure Blob container, but the overall administrator can define an Azure RBAC role that denies the access. To see if an issue exists, you need visibility across all policies plus intricate knowledge of how the system reconciles policy conflicts.

The Limits of Spreadsheets

Security teams might be able to sort though this complexity were it not for the huge numbers involved. The numbers multiply quickly when you consider all the ways a user (or machine) can get access. Permissions are defined at many levels (users, groups, roles, entitlements, systems, and resources). It can get complicated with nested roles, where “child” roles inherit permissions from “parent” roles. Of course, this applies to hundreds of unique systems (SaaS apps, databases, data lakes, cloud services, unstructured files, code repositories.) An enterprise with thousands of employees might have to manage millions of permissions.

No team can manage that scale by hand. Yet that’s what most companies try. Teams investigate individual systems, pulling reports and building massive spreadsheets. The spreadsheets have too many rows to evaluate, especially when compliance requires that somebody compare values across multiple spreadsheets. Teams have little choice but to “stare and compare”. The process is slow and error-prone.

Solving for Scale

Veza approached the problem of bad permissions with fresh eyes, adopting a “data-first” mindset. Instead of a relational architecture, our founders chose a graph architecture, which is the only way to solve the complex problem of mapping identity to data. We also created a normalized data model that maps any system-specific permissions to commonly understood actions like create, read, write, delete. The Veza Authorization Graph is thus able to analyze “effective permissions”, the net impact of all current policies across the organization, for billions of permissions. As a result, Veza does what traditional identity tools cannot: visualize, monitor, and control permissions at any scale. With this revolutionary approach, organizations can finally get fast answers to the question, “Who can see this data?”

The Veza platform recently passed 100 integrations (and counting) to secure access across the widest range of systems, including cloud and on-prem systems, cloud platforms, databases, data lakes, file collaboration, and SaaS apps. Veza also has a connector framework for integrating quickly with home-built custom apps.

Automation, Please

The Veza Authorization Graph enables a new level of automation. Because Veza can analyze permissions in near real-time, it is able to watch continuously for the creation of bad permissions. When an employee leaves or is terminated, Veza can find and fix residual permissions comprehensively. When an overseas contractor is accidentally granted a role with access to domestic data, Veza can shut it down immediately. When a user without MFA enabled receives privileged access, Veza can alert you or initiate a ticket for remediation. Instead of waiting for quarterly access reviews, you can catch rogue local users at the moment they’re created, so your auditors don’t put you in “SOX jail”.

In identity security, it’s easy to get blamed (even fired) for the carelessness of others. But you don’t have to be a scapegoat. Though every company accumulates bad permissions, proactive leaders get this debt under control. It’s no longer practical to wage the war with teams of people watching spreadsheets. Instead, the future of identity security has to be automation. When bad permissions open doors for attackers–Veza closes the doors. The real benefit of Veza watching 200 million permissions is that you, and your teams, no longer have to.