On October 10, Veza announced the arrival of Next-Gen IGA. If you work in identity or security, you already know that IGA stands for identity governance and administration. And you know that these tools have been around for a long time. But the world has changed, and the identity attack surface has ballooned. Traditional IGA tools have serious blind spots because they rely on a data model built for an era with fewer systems and fewer permissions. Twenty years ago, it was sufficient to monitor user groups and roles, and it was tolerable to assume that all users would be listed in a single source of truth like ActiveDirectory. But now, with identity-based attacks a near daily occurrence, it’s clear that something is broken, and it’s time for a fresh approach to securing access in the enterprise.
It’s Hard to See Access
The world has changed. Access has decentralized to a point where security teams cannot possibly understand, let alone enforce, common-sense policies for the business. Years ago you might have been a Microsoft shop—using AD as your IDP, with Windows file shares and Sharepoint to store files, some Microsoft SQL Server, and it was all in your data center. Now you have many different vendors providing identity systems, data stores, clouds, and apps. The average enterprise has 364 SaaS apps and uses 1,295 cloud services.
With app sprawl comes access sprawl. Each of these apps has its own unique access control system, e.g RBAC or ABAC. Some are complex, with hundreds of arcane permissions and nested roles. As a result, it’s hard to determine who can access what. Making matters worse, lots of these new apps use service accounts to talk to each other, so that creates a new, fast-growing group of privileged identities. In short, it’s no longer practical to monitor enterprise permissions.
This wouldn’t be a problem if security teams could take months to evaluate access. Of course, that’s not the case. Business moves faster than ever, and if IT teams want to help their partners in the business, it’s essential to evaluate and grant access quickly while enforcing policies and regulatory compliance.
The Stakes are High
Identity is the new perimeter. Gartner has found that 80% of organizations have had some sort of incident related to identity in the last 12 months. 75% of breaches occur through the theft or mis-use of identities. CIOs and CISOs recognize that they have blind spots when it comes to who can do what with their data, and stakes are high for both the business and the team. A single incident of ransomware can cost $4.5m when factoring in the disruption and downtime. The average disruption lasts 25 days. Meanwhile, the stakes are highly personal. CISOs have been fired after breaches at CapitalOne, Equifax, Uber, Target, Facebook, and JP Morgan.
Every day, companies accumulate risky permissions in the normal course of granting access. Sometimes permissions are granted by accident, when someone misunderstands role entitlements. Sometimes permissions are not revoked when employees leave, change jobs, or finish a temporary project. All of these accumulated permissions live on as open doors for attackers. Identity and Security teams cannot see the permissions, so they cannot manage them.
Even on the good days, when these permissions don’t lead to a breach, they still jeopardize compliance (SOX, SOC 2, GDPR) and lead to onerous investigations and fines. As one CISO remarked to his Veza team, “I need you to get me out of SOX jail.”
Security and identity teams need a better way.
The Rise of Next-Gen IGA
Identity governance is difficult at scale because there are so many different ways that someone (or something) can get access. Identities are duplicated across many systems, like Active Directory, Okta, Ping, and then locally in apps. Meanwhile, the volume of apps is easily in the hundreds, from on-prem to SaaS, from commercial to home-built. Each of those apps assigns access permissions in its own unique way, so nobody can be expected to master hundreds of access systems. Moreover, some of the most modern arrivals in the cloud have access control systems that are very complex. The IAM services of the cloud providers (AWS, GCP, Azure) offer hundreds of esoteric permissions, with nesting and inheritance. Snowflake and Salesforce are also powerful but complex. As a result, it’s simply not practical anymore to answer the question of who can access what.
The IGA tools of the past risk obsolescence if they don’t adapt to the new world. At Veza, we believe that the next generation of IGA must enable organizations to govern access at scale. In short, organizations must be able to grant and revoke access permissions automatically, in accordance with policies, for all identities and systems. In order to do this, Next-Gen IGA will need to satisfy five essential tests:
1. Works for all systems
2. Works for all identities
3. Sees true permissions
4. Is democratized
5. Is automated
1) All systems
The #1 tenet for Next-Gen IGA is that it must protect all enterprise systems where access is a concern. In other words, it must connect to cloud services, on-prem, SaaS apps, and data lakes. The logic is simple: one cannot prevent policy violations if only watching a subset of systems. From provisioning to access reviews, all systems must be covered, delivering a single pane of glass for governance.
Moreover, the connection to systems must be practical. It’s well-known that in software, anything is possible given time and money. But the reality is that traditional IGA implementations often run out of budget after connecting to just a few systems. With sensitive data spread across an expanding landscape of apps and services, next-gen IGA will have to approach integrations in a fundamentally different way.
For some policies, like those related to segregation of duties, it is only possible to enforce by monitoring access across multiple systems.
2) All identities
The word “identity” is often associated with human identities (employees and contractors). But for many organizations, there are now more non-human identities like service accounts, machine identities, and IOT devices. However, for a traditional IGA tool, these non-human identities live in the shadows. Since service accounts usually have elevated privilege, it is essential that any governance program include them.
Another class of identity missed by traditional IGA is local users. When employees in an organization adopt a SaaS app, they may not always control access through an SSO platform like Okta. It’s common for employees to create user accounts directly in those SaaS apps. An IGA tool looking at the groups and roles assigned to employees will miss these local user accounts. Sometimes, the local accounts are even admin accounts, with elevated privileges. These are especially dangerous, as they may not get terminated properly when the employee leaves the company.
To govern the identity attack surface, organizations must monitor all types of identities, wherever they originate.
3) True permissions
Traditional IGA was limited to governing via groups and roles. Unfortunately, it’s often misleading to look at the defined permissions of a role as they might be mis-labeled or out of date. A group labeled “sales read-only” may very well have permissions to delete data. These labels can create a false sense of security. Even if you do realize there may be inconsistencies between your groups, roles, and permissions, traditional identity tools can’t investigate how these discrepancies occurred.
Companies will never secure their full attack surface until they can see, faithfully, who has access to what data, and how they got it. Any Next-Gen IGA solution will have to go beyond users & groups to see true permissions: granular entitlements all the way to a data object, table, or resource (like an S3 bucket). With this granularity, an IAM team can make smart decisions about which identities go into which roles. Over time, they can use this view to refine the role structure and bring more users into “least privilege” roles.
The next tenet of next-gen IGA is that it be democratized in the way it presents information. All systems require some level of system-specific expertise, but no organization should have to hire system experts just to handle access. Did you know that there are over 21,000 unique permissions available in AWS, Azure and GCP? The AWS IAM manual spans over a thousand pages. For S3 storage buckets, there are over a hundred potential permissions. Nobody is going to understand all these permissions without looking them up in the documentation, which just doesn’t scale for enterprise-wide governance.
Visualizing permissions isn’t helpful if identity professionals can’t understand them. To make smart decisions, identity teams just need to know the bottom-line: can somebody read, update, or delete this data? Next-gen IGA must translate arcane technical permissions into simple business terms.
The final tenet of next-gen IGA is that it be automated. In particular, IGA must automate the monitoring, notification, and in some cases remediation of policy violations. The goal is to reach “continuous compliance” where infractions are discovered as, or before they occur. Contrast with the traditional access review process, which relies on manual campaigns conducted infrequently. Many access review campaigns recur on an annual basis, but the obvious risk is such a process has the potential to leave risky permissions in place for the better part of a year.
One approach here would be to increase the frequency of access reviews. Even if the reviewers didn’t rebel, this onerous imposition on their day jobs would drive reviewers to be less careful, “rubber-stamping” access that they don’t fully understand (and don’t have time to dig in.)
Next-gen IGA should be a machine that is watching while you sleep, 24/7, to look for new violations of policies. For example, orphaned local accounts can be flagged for investigation. Privileged accounts not using MFA can be flagged. Dormant accounts, which have not used certain access after 60 or 90 days, can have that access paused, giving the user a chance to appeal if needed. Next-gen IGA will make it possible to change a policy, fix violations now, and monitor for new violations ever-after.
In short, automation is the only practical strategy to driving least privilege and enforcing an ever-growing list of access policies.
Closing the Doors
The primary benefit of Next-Gen IGA is that you systematically remove and prevent identity-based risks. By automating governance across all systems, Next-Gen IGA enforces your access policies in a way that scales. With continuous policy enforcement, you reduce the risk of identity threats, both those coming from external bad actors and those coming from insiders (whether malicious or accidental). Without this, it is virtually impossible to adhere to the principle of least privilege. With this, you can reduce privilege, minimize blast radius, root out risky misconfigurations (like absence of MFA), and disable dormant accounts.
Next-gen IGA will also lower operational costs. Historically it costs a lot to govern access with the manual methods and spreadsheets. Whether you’re motivated by internal policies or external regulations (SOX, SOC 2, GDPR), next-gen IGA reduces the labor required to monitor, review, and enforce policies. Moreover, this will reduce the cost and aggravation of access reviews.
Veza Access Control Platform
Veza is the Access Control Platform that powers next-gen IGA. By going beyond users and groups to understand effective permissions, Veza helps companies find and fix risky permissions and policy violations. It secures access to data in virtually any system in the modern enterprise stack, whether on-premise or cloud. And it does so for all identities, whether human or machine.
With Veza, you can visualize who has access to what, monitor privilege drift, and investigate identity threats with access search and access intelligence. You can automate access reviews to collaborate with the business on smart access decisions. And you can manage provisioning and deprovisioning throughout the identity lifecycle.
When evaluating solutions for next-gen IGA, consider Veza’s unique strengths:
Time to Value: Veza connects to systems in minutes, not months, and delivers immediate value in visibility and remediation.
Coverage: WIth over 180 integrations, Veza has the widest coverage with native integrations that cover on-prem apps, cloud services, SaaS apps, and data lakes. Veza also offers an Open Authorization API (OAA) for building custom integrations to your own apps.
Enterprise-Ready: Veza is trusted by large financial institutions & public companies. It is compliant with SOC 2 Type 2 and ISO 27001.
Proven Scale: The Veza architecture is already protecting 6 million identities and 300 million permissions. Veza designed its platform to handle the scale and complexity required by large enterprise customers, including large numbers of metadata entities, frequent temporal-based changes in data sets, and high cardinality of data sets. Handling this kind of authorization metadata efficiently at scale requires a purpose-built graph infrastructure. We built the Veza platform to seamlessly support massive AI/ML-based capabilities, from access recommendations to universal search and more.
Born in the cloud: Veza is a modern, cloud-native SaaS platform that introduces no admin overhead when deploying new updates. It also takes an API-first approach, which means that customers can build the power of our Authorization Graph into their own security apps.
Secure: Veza requires no agents, installers, ports, or firewalls for deployment. This out-of-band approach means there’s no risk of downtime. Veza embraces industry best practices including independent penetration testing, data-at-rest and inflight encryption, strict role-based access controls, complete tenant isolation and zero external access by design. Veza is SOC 2 Type I, SOC 2 Type II, and ISO 27001 certified, demonstrating our dedication to security and compliance.
5 Actionable Strategies to Improve Security Posture
We did a deep dive into cyber security, identity security, and evolving digital threats. Implement…
A field guide to bad permissions part 2: expired permissions
Why expired permissions go unnoticed The main reason expired permissions go unnoticed is that it’s…