Birthright access is an anti-pattern for secure, least privilege access control. I’ve been having a lot of conversations where teams are actively trying to move away from aggressive birthright access grants in favor of just in time access. And for good reason, most users are over provisioned: they have access they don’t need or don’t use.
When the best solution to achieving just in time and as-needed access is a ticket with lots of manual steps, it’s no surprise that we’ve gotten to where we are. The productivity-centric solve for this is to over-provision on day one. Until now, granting access, provisioning, and deprovisioning has been onerous. So, what’s the better option? It’s definitely not more tickets. But, before we explore solutions, let’s go on a journey…
First off, what do we mean by birthright access?
When people say birthright access, generally they mean apps, roles, and permissions that users get when they join a company that’s (mostly) based on their role or job function. When companies are small, this access is provisioned with click-ops: that is, lots of clicks in different applications. The specific access that users receive is largely guided from a role matrix or some similar artifact. All of this is fine for a while – until the sheer scale of user on-boarding and access requests drives a discussion about streamlining on-boarding. At this point, the company invests in birthright access and on-boarding automation. This can take on a couple of different flavors:
- Provisioning users into groups based on role definition, job function, and/or department (and the groups drive downstream access grants and user provisioning)
- Provisioning users based on the good old “Give Jane what Jim has” copy / paste access control decision (which is a blog post for another day :))
- Asking the manager what the person needs
There are several challenges with each of these approaches, but the commonality is that they all lead to sprawl of access and over permissioned users.
So, what’s the problem?
The challenge is that, from a birthright perspective, most users truly only need a core set of productivity centric apps. This set depends on the user and role, but you can safely assume that everyone needs the productivity suite (email, collaboration, file sharing, web meeting), sales teams need CRM and sales ops tools, engineers need GitHub, build env, dev env access, and so on.
So far that doesn’t sound bad – because it’s not. You’ve just saved a lot of clicks and calories. The issue comes when, to save time and the effort of subsequent one-off requests, access to things that are “usually” or “sometimes” needed get lumped into these roles.
This is a slippery slope. From a productivity standpoint, it’s great. Users get what they need day one. But it is risky from a security point of view and problematic from a license and cost standpoint. Standing sensitive access that’s not needed on an on-going basis is attack surface area that can be taken advantage of. On the usage side, licenses or roles that aren’t being used in apps can be material to SaaS spend.
It’s also worth saying that there’s rarely a “loop back” to re-evaluate this birthright access. The reason being is that it’s really, really hard to take away access without context. To remove an automatically provisioned level of access from a role or set of users means first determining if those users need that access, and next determining if the trade-offs between security vs cost vs manual effort is meaningful. Put differently, is the juice (risk and cost savings) worth the squeeze (manual provisioning + reaching out to all the users + negative impact on productivity if a mistake is made). It’s the same problem with trying to remove groups. It’s a hard calculus.
The missing link: automation
In order to solve this at scale, the manual effort + user friction side of the equation has to be addressed. With the exception of baseline collaboration access, it makes sense to move most access to just in time. The trick is to make self service access requests dead simple, access control contextual, and provisioning zero touch. Access should be:
- Self service requestable where the users are already working (e.g. slack)
- Approved based on role or need (automatically approved, if possible)
- Provisioned without any manual touches
- Removed based on time, non-usage, or changed justification
- Periodically or contextually (role or team change) reviewed for necessity
This doesn’t happen overnight: it’s a journey. The starting point and biggest win for security is usually starting with sensitive resource and infrastructure access (e.g. AWS, GCP, Twingate, etc). This type of access lends itself well to moving to just in time changes to authorization in the SaaS or IaaS, and generally affects a smaller subset of users in the org. That said, we believe that applying just in time access to a broader set of apps will ultimately not only lead to better security outcomes, but also cost savings and user satisfaction as employees are enabled to get the access they need, when they need it.
