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 keep your critical apps and data. We’ll examine common bad permissions, how they happen, and how you can rid yourself of them for good.
This is the second of a series of four posts, looking at expired permissions. Expired permissions were once necessary permissions granted to allow an employee or service account to do necessary work. At some point, either a temporary project ended, or the responsibilities of an employee changed, but the related permissions were never revoked.
Why expired permissions happen
Understanding why expired permissions multiply means understanding how teams balance important work with urgent work. IAM teams are busy, and prioritize according to perceived urgency. In real-world conditions, granting access that’s holding up a project is always going to feel more urgent than removing access that is no longer needed.
The problems caused by insufficient access are often immediate and can impact deliverables. For example, if a developer isn’t able to commit to a source code repository, a key product feature might miss its ship date. On the other hand, a developer having more access than they really need might not seem like an urgent problem…at least not until they get phished.
So, while IAM teams recognize that enforcing the Principle of Least Privilege is important, it’s easy to think about expired permissions as a problem you’ll deal with later, when you’re not so busy.
How expired permissions hurt you
Expired permissions often start off as urgent ad hoc requests that circumvent your regular IT processes. It’s common for these urgent requests to include sensitive or critical resources: a source code repository, a table of customer data, etc. Resources your employees need urgent access to are likely to also be of interest to attackers.
In more general terms, as discussed in our previous post, identity is the weak link in security, so applying the principle of least privilege is vital. In this sense, expired permissions are potentially harmful in the same way that any unneeded permissions are. They increase the risk of sensitive data being compromised without accomplishing anything useful for the identity that holds them.
Why expired permissions go unnoticed
The main reason expired permissions go unnoticed is that it’s hard to recognize that a permission is no longer needed without knowing the full context. While most organizations conduct annual or even quarterly reviews of access, the reviewer generally only sees the names of group memberships and access profiles a user has. These are human-generated labels that, even if broadly accurate, do not offer a full accounting of the granular permissions group members have. For example, a reviewer might see that a developer, Gary Ward, is a member of the “UI-dev” group in Okta, but not realize that members of this group have permissions that Gary no longer needs.
A second reason is that expired permissions are often also ungoverned local permissions. Temporary or ad hoc access needs are much more likely than birthright permissions to be handled outside of your normal provisioning processes. For example, a developer urgently needing access to a snowflake table for a temporary project may reach out directly to a snowflake admin for credentials, always intending to remove them later. This type of access is invisible to legacy IGA tools and much less likely to be picked up in an access review.
How to fix expired permissions
To stop access creep and curb expired permissions, you need to create a culture of access removal. Start with the assumption that access is not needed, and make sure you understand the business justification for all access to sensitive resources.
Track all identities—human and machine—with access to critical data at all times and try to keep the total number of identities with access under a set limit. Collecting this kind of access intelligence creates opportunities to discover expired permissions. Without full context, it can often be difficult to determine if, for example, Will really needs merge access to the Production repository. But knowing that the number of identities with merge access to production has doubled in the last six months is a strong indicator that unneeded access is growing, prompting you to investigate.
When conducting access reviews, make sure you’re getting to the granular permissions of identities. Knowing the name of a user’s groups and access profiles often isn’t enough to understand what access they really have, so it’s not enough to be able to identify expired permissions.
How Veza can help
Unlike legacy IGA tools, Veza’s Authorization Graph can connect any identity—human or machine—with its actual permissions on any resource. By closing the context gap, Veza allows you to continuously monitor for bad permissions, including expired permissions.
Monitor for access creep
Veza can continuously monitor all permissions to all resources in your environment, and report on trends over time. This means that you can get automatic alerts on changes like:
- A jump in the total number of identities with sensitive access.
- Access to resources like Snowflake Tables or AWS S3 buckets that hasn’t been used recently.
- An increase in the percentage of total resources an identity can access.
Expired permissions aren’t the only possible cause of the above, but by watching for these warning signs you can investigate access creep and fix it before an attacker can take advantage of over-permissioned accounts.
By integrating with SOAR and ITSM tools, Veza also creates automated, audible workflows around potential expired permissions, so they’re not forgotten when the next deluge of access requests hits.
Full context access reviews
In Veza, access reviews show not just the names of access profiles and group memberships a user has, but the full details of what actions they can perform on what resources. With this context, a reviewer is much more likely to recognize access that is no longer needed.
For example, developer Gary Ward needed access to the INVENTORY table in BigQuery to work on a temporary project for Sigma’s retail site. An access review in a traditional IGA platform might see that Gary still belongs to a group labelled “UI_dev”, but it might not be clear that he no longer needs his access. If the reviewer can specifically see that Gary retains access to the INVENTORY table, they’re more likely to understand that Gary no longer needs this access.
Learn more
This is part two in our Field Guide to Bad Permissions series. Read our first post on ungoverned permissions, and check back on the Veza blog next week for part three, examining excessive 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.
