Access Control: Taming Group Sprawl

IT, Security, and GRC teams have long held a love-hate relationship with directory groups. Groups are like the swiss army knife of identity. For any identity, permission, access, or authorization problem that you needed to solve, you could usually throw a group at it. This enabled companies to scale permissions for a time but the proliferation of directory groups is now causing major headaches for security. Identity teams lack context on why certain groups were created and the implications of the access inherited from that group membership.

This lack of visibility makes defining business processes around groups challenging. Imagine you are tasked with conducting access reviews on AWS Assume Role permissions, which can be granted through group membership in your SSO solution, locally via groups or policies, or locally through direct assignment – it’s messy! There needs to be a better way. But first, a brief history.

A Quick Primer on Directory Groups

Early directories created a method for lumping together user principles: the group. Directory groups organize users and resources logically into an easily addressable entity – for example, users can be grouped by department, function, team, or role. With such flexibility, groups evolved to support any use case that required targeting multiple people at once.

Below are some of the more common use cases for groups:

1. Application and infrastructure teams use groups to drive access to critical systems and resources
2. IT using group membership to drive resource access required for a certain job title or role
3. Application owners using group memberships to drive granular permissions
4. HR and IT using group membership to grant birthright access for new employees

Groups became the one solution to solve every permission and access management challenge.

The Security Implications

There have been some real benefits to using groups to drive access controls – primarily productivity. Applications speak “group” and groups are easy to create. Need to grant your marketing team access to your CRM? Submit a ticket for IT to create a group based on job function or title and grant them access. The workflow is straightforward and familiar, but eventually creates 3 severe security gaps:

1. Lack of visibility: Let’s say an employee creates a group to grant access to a given set of resources and then that employee departs the company. Some time passes and questions arise: Why was this group created? Who created it and when? What is it being used for? Without clear answers, security teams are reluctant to delete groups, which could inadvertently cut off critical access and disrupt the business.
2. Group sprawl: What’s more, without visibility or context as to why a certain directory group exists and what access and permissions it grants, teams end up duplicating groups. It is cheaper and safer to create a new group and move on than it is to try to figure out if an existing one serves the same purpose. As a result, group counts explode as a company grows. We have seen companies with as many, if not more, groups than there are identities in their directory – as a result, groups eventually become unwieldy to manage for resource-strapped IT and security teams. The burden comes to a head when companies decide to embark on the dreaded group rationalization exercise in an attempt to determine which groups to remove, keep, or modify, and which can take up hours and hours of effort over several months.
3. Neglects scope and justification: Group sprawl impacts a company’s ability to scale in a secure way. Coupling group memberships with the IT ticketing workflow addresses productivity concerns but glosses over four elements to access control decisions that have major security implications:

Achieving least privilege and implementing granular permission controls, role-based access controls, and just-in-time access requires that every permission grant addresses all of these elements – a function that groups are ill-suited for.

Thoughts on access controls moving forward

For starters, here are a few guiding principles:

Embrace iteration and incrementalism. I’m a firm believer in meeting customers and environments where they are. Requiring “clean room”-like customer environments or significant upfront work before enacting changes to the access management workflow is a recipe for poor and delayed adoption. Group rationalization exercises are time-consuming and offer nebulous value – they may reduce group sprawl, but fail to provide a solution that enables companies to scale access controls.

Context and visibility. Before we can tease apart the access control problem, we need to understand it. This requires building visibility and context. Embrace the complexity that is groups, work with groups where it makes sense, and introduce new layers of management between groups and permissions to incrementally adopt better ways of solving this problem over time.

Unbundle the concerns. We need to unbundle ticketing and groups into top-level concepts for roles, entitlements, access, policy, workflow, and justification. Granting, revoking, reviewing, and extending access and permissions are all critical lifecycle steps in terms of how we control access for identities. Once we create new tools and new primitives, we can start to counteract the group explosion.

Thanks for reading! Subscribe and keep an eye out for part two: How to Decouple Access Controls and Directory Groups.