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 third of a series of four posts, looking at excessive permissions. As opposed to expired permissions, which were at least needed at one time, excessive permissions are the result of inaccurate or overly broad permission grants, and allow identities to perform actions which were never necessary.
Why excessive permissions happen
As we’ve discussed elsewhere in this series, IT and IAM teams constantly struggle with the need to balance their security and governance responsibilities with the need to enable employees to do their work. This tension creates a natural bias towards excessive permissions at every stage. Employees who need new access for a project are likely to ask for more than they really need, to save having to make a second request later. Similarly, IAM teams can favor broader access grants to make sure an employee gets all the access they require, even if that means they also get plenty of access they don’t need.
Even an IAM team determined to implement the principle of least privilege struggles with a lack of visibility into the outcomes of their provisioning processes. For example, let’s say an employee asks for access to a particular Snowflake table. The IAM team is aware of at least 6 different groups in their identity provider (IdP) that would grant access to the table. Ideally, they would choose the group that fulfills the employees request, while granting the smallest total number of permissions. But since the IdP doesn’t provide this information, the team is more likely to either take a guess, or just create a new group—making the problem even more difficult next time around.
How excessive permissions hurt you
As we’ve discussed in previous entries in this series, identity is the weak link in security, so applying the principle of least privilege is vital. Excessive permissions increase the risk of sensitive data being compromised without accomplishing anything useful for the identity that holds them.
Around three quarters of breaches can be traced back to compromised or mismanaged identities. With the number and severity of breaches rising each year, it’s vital to adopt an “assume breach” mentality. That is, operate from the assumption that any given identity will be compromised. When that happens, the permissions that identity has will determine the severity of the breach. If a phished employee has access to sensitive customer information in Snowflake that they don’t actually need, the results are likely to be much more damaging than if the employee had only necessary permissions.
Why excessive permissions go unnoticed
Excessive permissions go unnoticed and unremediated because organizations lack visibility into the effective permissions of identities at every point in the access lifecycle. While employees will quickly follow up if they don’t get the access they need, they’re unlikely to notice if they’ve been given access to additional resources they don’t need, or the wrong type of access, like the ability to write and delete data when only read access was needed.
Most organizations conduct annual or quarterly access reviews. But again, legacy Identity Governance and Administration (IGA) tools only see the groups and access profiles an identity has, plus, if they’re lucky, a brief description of the permissions included. Even if this description is accurate, the reviewer rarely has enough context to make an informed decision. Does the employee really need all the access granted by a given group? Is there another group that would give the employee the access they actually need while granting fewer total permissions? Without this kind of context, access reviews are not effective at finding and removing excessive permissions.
Finally, identity governance tools rarely have insight into the world of machine identities, even though machine identities outnumber humans in the cloud by more than ten to one. When a developer initially sets up, for example, a Lambda function in AWS, they will create IAM policies that reflect the access they expect the function to need. But if they make an error, or use built-in template policies that grant wildcard access to a wide range of resources, it’s likely that their initial decisions will never be revisited.
How to fix excessive permissions
To crack down on excessive permissions you first need to tackle the visibility problem. IAM teams need to be able to see, when they first make an access decision, what permissions they’re actually granting, so that they can determine the appropriate way to fulfill an access request in accordance with least privilege.
Secondly, you need to develop business intelligence and metrics to help you spot excessive privilege. For example, if an employee has access to a high percentage of your total number of resources: Snowflake tables, storage buckets, shared drives, etc, they are likely to have excessive permissions. Think of it as an employee having a high “blast radius”, since an attacker who can compromise their credentials will be able to do a lot of damage.
Lastly, you need to automate continuous monitoring of permissions across your stack. This means monitoring both for risk factors, like high blast radius, and for changes in access to your “crown jewels”—specific high-value resources like personally-identifying information, financial information and payment data. Automated monitoring allows you to fix excess privilege without having to wait for a review cycle, or worse for a successful attack, to find out that you have a problem.
How Veza can help
Unlike legacy IGA tools, Veza’s Authorization Graph can connect any identity—human or machine—with its actual permissions to any resource. IT and IAM teams can use this visibility to validate the outcomes of provisioning and make sure that employees get the access they need and no more.
Veza’s powerful query builder also makes it simple to triage your risks and identify employees or machine identities with a high blast radius, so that you can focus your efforts on your most critical risk areas.
Finally, Veza can continuously monitor your “state of authorization”, or the permissions held by all identities across your environment. For example, you can set up an automation to monitor for any new access to a table in Snowflake containing customer data, or an S3 bucket in AWS containing payment card information (PCI). By integrating with SIEM tools like ServiceNow, Veza can initiate workflows to fix excessive permissions as soon as they arise.
Learn more
This is part three in our Field Guide to Bad Permissions series. Read our posts on ungoverned and expired permissions, and check back on the Veza blog next week for part four, examining policy-violating 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.
