The migration of data and infrastructure to the cloud over the last couple of decades has exploded the scale, scope and complexity of identity security. Meanwhile, the tools we use for identity security and governance haven’t fundamentally changed from the on-prem era, leaving security and governance teams struggling to keep up. With identity-based attacks on the rise every year, organizations need new approaches to identify and control risky and dangerous permissions that can empower an attacker when (and it really is when, not if) an identity is compromised.
To that end, we’ve prepared a field guide to the major types of bad permissions you need to be aware of in order to safeguard your critical apps and data. We’ll examine common bad permissions, how they happen, and how you can rid yourself of them for good.
In this first of a series of four posts, we’ll examine ungoverned permissions. That is, permissions that aren’t captured or tracked in the tools you use for access governance, like your identity provider (IdP) and identity governance & administration (IGA) tools.
Why ungoverned permissions happen
Most SaaS apps, data warehouses and cloud infrastructure can integrate with identity providers like Okta, Azure AD and Active Directory. However, they’re also designed to stand alone, since to only allow access through third-party tools would make them harder to adopt.
For an organization that uses SaaS and cloud tools, one consequence is that every SaaS app and cloud provider you use allows for the existence of local accounts and local admins. For example, modern cloud-based organizations using an app like Salesforce, or an infrastructure-as-a-service (IaaS) provider like AWS, generally want to centralize access to these tools through a single sign-on (SSO) provider, like Okta. This allows for centralized management of accounts, especially privileged accounts.
However, no matter how much the central IT or IAM team wants to centralize user management, it’s hard to turn off the potential for local accounts to be set up by local administrators. In fact, the more rigid and time-consuming an organization’s official processes for requesting access are, the more likely time-pressed employees are to seek workarounds.
IT and IAM teams live and die on their success at enabling employees to be productive, and it’s hard to resist these types of urgent requests.
Once created, local accounts become part of a hidden system of shadow permissions. They’re not visible to IdP or legacy IGA tools—the systems we rely on to govern access and to ensure least privilege—so they’re unlikely to be identified and fixed.
How ungoverned permissions hurt you
It’s a fundamental truth of information security that most successful cyber attacks hinge on a compromised identity. No matter what protections you set up, the human element is always a weak link. While individual organizations can always do more to train employees not to fall for phishing attacks, and to identify and block bad actors, the industry as a whole has been spectacularly unsuccessful at stopping phishing attacks and other identity-based attacks, which have increased every year for the last 4 years.
Since organizations can’t guarantee against compromised identities, following the principle of least privilege is vital. When (not if) an identity is compromised, the damage depends on what permissions the compromised identity has to sensitive data and infrastructure. Seen from this perspective, the danger of ungoverned identities is clear: you can’t achieve least privilege if you don’t have visibility into all accounts and identities with access to your environments.
Furthermore, identities with ungoverned permissions are orphaned accounts waiting to happen. When an employee possessing ungoverned permissions leaves the organization, your offboarding processes are unlikely to remove them. This leaves local accounts hanging around, missing out on security updates like MFA and password rotation, waiting for an attacker to pick them up.
For organizations with SOX, HIPAA or other compliance obligations, ungoverned permissions can also lead to compliance failures if an auditor identifies accounts that your governance processes have missed.
Lastly, ungoverned permissions curtail your incident response efforts in the aftermath of an attack. If an identity is compromised, you may not be able to review or protect all the assets the identity has access to.
How ungoverned permissions go unnoticed
By definition, ungoverned permissions are invisible to your IdP and IGA tools—the systems you rely on for access governance. Local accounts won’t show up in your access reviews and your central IAM and IT teams won’t be aware of them.
Local accounts are visible from within the apps they have access to. For example, a local Salesforce administrator can see all Salesforce accounts. However, to uncover ungoverned local accounts, that local administrator would also need to be able to see the complete list of users provisioned through your identity platform. The only way to identify ungoverned local accounts is to compare all local accounts to all users in the IdP and find the gaps. In other words, you have to look for something that isn’t there.
How to fix ungoverned permissions
To surface ungoverned permissions you need to be able to compare the full permissions an identity has at the data end (in Saas, Cloud Infrastructure, Data Warehouses, and on-premise systems) and the permissions that were actually granted through your IdP. The delta represents your ungoverned permissions. Making this comparison across thousands of identities is a daunting task.
How Veza can help
Veza uses agentless read-only API access to connect to both your identity provider and all of your data systems. By automatically comparing local accounts with IdP users, Veza can quickly identify ungoverned local accounts.
As an example, let’s consider an organization that uses Okta to provision employee access to Snowflake.
Using Veza’s query builder, we can compare all Snowflake local accounts to users in Okta. By setting the “Does not relate to” flag, we can surface every local Snowflake account that does not map back to Okta.
Some of these—”LOOKER”, “TABLEAU”, etc—are service accounts for other SaaS tools. We wouldn’t expect to see those in Okta. However, others like “THOMAS.STEWART@SIGMACORPX.COM” look like human users.
These are our ungoverned local accounts. They should have been provisioned through Okta, but they weren’t. Now that we’ve found them, we can either set them up properly through Okta, or remove the access completely.
Having done our initial cleanup, we can instruct Veza to monitor the situation using Rules. A rule consists of a condition, and an action. Here we can set our condition to “if query results increase by more than 0” – in other words, any time we identify a new local account that doesn’t map back to Okta.
Our action could be as simple as dropping an alert to an email or a Slack channel. But Veza also integrates with ITSM and SOAR tools like ServiceNow. So we can create a custom workflow in ServiceNow to investigate and remove the local account.
With Veza constantly watching for new ungoverned access in Snowflake, we can be sure to identify and remediate this problem before an attacker can take advantage.
Learn more
This is part one in our field guide to bad permissions. Check back on the Veza blog next week for part two, examining expired permissions.
In the meantime, to learn more about how Veza can tighten up your identity security, take a self-guided tour of our key integrations, or schedule a personalized demo.
