There’s little doubt that Zero Trust has hit mainstream awareness for both security professionals and security companies. The key elements remain from when the concept was introduced: stop relying on security at the perimeter, and move applications to the public Internet. In essence, this gets rid of firewalls and VPNs, but invests more at the “front door” of access to applications and systems. We all want to get there, and it seems like every security company claims to be an essential part of a Zero Trust solution–even firewall companies! But, the persistent challenges and failures of the perimeter-based security model have cemented the legitimacy of the Zero Trust model.
If you think more about Zero Trust, it centers around the idea that this “front door” of access – authentication and authorization – are the pillars of your security. From an industry-practice perspective, “access” and “identity” are tied at the hip for good reason (hence “Identity and Access Management,” or IAM). Authentication has made great strides in the last decade with SSO (federation through SAML and OpenID Connect), and MFA has seen much deeper adoption with more secure implementations than the days of the 6-digit rotating code on a key fob. Companies like Okta and Microsoft have been very successful in driving forward authentication, but authorization has been left behind. Nevertheless, access and authorization are identity problems: they start with the “who.” In other words, identity is the lifeblood of Zero Trust.
When we look across common identity tools, like those for Identity Governance and Administration (IGA; like Sailpoint and Saviynt) or Identity and Access Management (IAM; like Okta and Microsoft), we can quickly see that they’re never going to solve the problems of authorization and get us to Zero Trust. There are a number of key missing pieces:
- These tools force you to manage permissions with naming conventions. How do you know what a role or a group REALLY gives access to in all the downstream applications and systems? What happens when your “read-only” group accidentally gets delete permissions added?
- Permissions are unique to each integrated system that you’re trying to manage (like Snowflake or Salesforce) – each is like a different language, with different terms, different hierarchies, and different resources. You often have to be an expert in THAT system to really understand what it means. These solutions don’t remedy this.
- These solutions usually cover only narrow targets: Cloud Platforms, SaaS apps, or unstructured data, but never all three. You’d have to own a patchwork of multiple solutions to try and cover it all, and each would be in a silo. How do you cover every system where your sensitive data is stored and used?
- Some security solutions assume that your HR system is the source of truth- and when it finds contractors or partners with access, you get the dreaded “unresolved identity” error. The reality of most environments is that many people, often with high levels of access don’t appear in your HR system.
- Integrations, particularly with common IGA systems, are slow and expensive. They require teams of developers or pricey SI contracts. We often hear stories of customers getting perhaps 5 integrations done in the first year, and giving up to revert back to manual processes and spreadsheets, even though they already own an IGA tool.
- Finally, most of these systems only look at human identities. Service accounts are typically much harder to manage, and left to be handled by Privileged Access Management (PAM) solutions. To get a handle on Zero Trust, you need to track down access paths through service accounts to really get the full story on who is on the other end.
Here’s an interesting experiment you can run to test your own organization. Sit back, and think about how many groups there ought to be, based on the number of people you have. The whole idea of a group is to make things easier to manage, right? You couldn’t possibly manage each person individually! Maybe you should have ⅒ or ⅕ the number groups as people? The reality is much starker for most organizations. We’ve seen extreme cases where organizations had 5 times the number of groups as people! How and why would things be set up this way? Usually, it’s because groups grow organically. When someone needs a new group, they look through the groups that exist. The group requestor might find a few existing group names that sound close to what they need, but they realize they don’t know what those groups actually do and they might be giving access to people that increases security risk. In the end, they simply create a new group and use that. This lack of basic visibility of the end-to-end permissions is exactly what creates the problem of group sprawl.
So, what would the world look like if we could solve all these problems and get to Zero Trust? It would start with having a tool that gives you a basic understanding of what you have today. It’s tempting to head down the road of “a clean slate”, but we all know trying to do a massive migration to an entirely new system with different behavior is a multi-year quagmire and usually has a man-in-the-middle architecture. A practical solution would be something that meets you where you are and is able to deliver wins every step of the way. It should help you meet the compliance demands of your organization quickly and easily, adding new apps and systems without massive effort. Those compliance efforts should ALSO improve security, not just be “checkbox security theater.” When you get a simple question from your auditors, like “who can edit this table of customer data?”, it shouldn’t take a week of custom scripting to figure it out. You should be able to know you’re in compliance at any point in time, not just when the quarterly process rolls around. You should be able to automate the work of “least privilege”- and not rely on manual processes to get all this done.
How does that vision actually come to pass? It’s not something that IGA and IAM solutions were ever intended to do, so it’s not surprising that they fall short. It would require a graph database- something to not just store the metadata about permissions, but keep track of all the relationships and paths that connect identities, actions, and resources. If someone has permissions they shouldn’t have, the path (e.g., through a particular group membership vs. local permissions) matters; that path tells you how to fix the issue. You need to pull all the different languages of permission into a common object model to enable universal management and policy consistency across different systems. This common model (done properly) becomes the basis for a “universal translator” of all the different RBAC models and makes it possible for business users who aren’t experts in the systems to make informed decisions about what’s right and wrong. Doing it all at scale in near real-time is computationally challenging. Access Control Lists (ACLs) can be all the way down at the file or folder level, and the number of nodes in the graph can be daunting.
This is exactly what Veza has built. It starts with our Authorization Graph, which shows you the reality of permissions today. It connects to over 60 (and counting) different systems, both cloud and on-prem, and pulls the authorization metadata into a common object model at scale and in near real-time. We enable you to not just see your permissions, but find and fix over-permissioning in your environment, starting with the most severe violations. We give you an operational path to Zero Trust.
Getting to Zero Trust requires a “Second Act” in Identity beyond solving the authentication and password problem. The first act IGA and IAM solutions aren’t up to the task. Learn more about how Veza is unlocking the power of Authorization to make this Second Act of Identity a reality.
