Access requests are a bandaid, not a fix

For many IT and security teams, identity feels like a constant treadmill of access changes: add the new hire, remove that contractor, update access to the sales tool, and worst of all, make sure nothing breaks during next Monday’s reorg. To handle the increasing volume of these access changes, the identity industry has gotten very good at handling them quickly, by letting you request elevated privileges in a CLI, or approve access changes in Slack. But you’re still on a treadmill — we’re just making it go faster and faster. What if you want off the treadmill?

The only real security improvements are solving classes of problems

In many areas of security, we’ve learned that fixing classes of problems is the only way we can address them for good. Instead of finding (and fixing) an increasing number of insecure code findings, what if we could reduce the total volume of issues by moving to memory safe languages? Solving a broader class of problems is necessary to reduce the volume of issues.

In vulnerability management, we already had automated patching, with tools like Dependabot or automated OS updates. But there is still an order of magnitude more impact by moving to a minimal base image. It’s not about applying patches faster, it’s about never getting them to begin with. Automated patching helped, but it wasn’t the real fix. Removing unnecessary dependencies was.

We haven’t had that mindset shift — and so that kind of impact — in access management. Access management is still the same: constantly updating and changing access as people’s roles and responsibilities change. It’s still human-intensive work.

Access management is full of bandaids

We’ve kept implementing bandaids to address the fact that our access management in practice doesn’t match it in reality. It makes sense to regularly review access to verify that it’s still correct — because why would you have checked since you first provisioned it? This sanity check was so desperately necessary that quarterly access reviews have become entrenched as compliance requirements across multiple industries, even if many security teams treat them as a checkbox exercise.

The next bandaid was expiring access. If we have access automatically expire, then there’s less to clean up. That makes sense. But expiring access isn’t widely available — most identity providers and applications don’t natively support it — which means it’s not frequently used outside of the highest risk situations, like prod access. Removing access automatically also means you need to think about how to reprovision it when users need it again.

Which brings us to the bandaid of Slack-based access. Rather than making a user file a ticket in Jira or ServiceNow, what if they ask for access where they already are, in Slack? This is a huge improvement in terms of user experience — but it leads to neverending access request tickets, for both the IT team to respond to, and for the user to file. The number of tickets has grown untenable. But faster approvals don’t fix the underlying issue. They just make living with it more tolerable.

Access requests are a bandaid, not a fix

With IT Ops, IT teams are moving from living in a ticket queue to building and automating operational systems. And as more and more IT teams report into the CISO, they’re adopting the security engineering mindset that’s emerged in the past few years. IT teams are using more automation and code than ever before — and they’re looking at their daily piles of access request tickets and asking why there’s not a better solution.

You can only make approvals go so fast if your request flow itself is a bandaid, because you can’t express the policies you actually want. You can’t automate a human — you’ll always be limited in how much you can automate if you explicitly decided to include a human in the loop.

The issue is both technology and process. Rarely do you actually want a line people manager determining who gets access to prod, just like you don’t want them deciding what new project management tool you procure. But when IT and security teams require manager approval as part of an access request, it’s often as a proxy control, to ensure that an intern doesn’t access production, or a contractor doesn’t have visibility to customer data. If you can’t define the controls you actually want, you need to find alternative controls to meet the same requirements. We need better building blocks.

We need expiring access, so that a one-off production debug session doesn't turn into permanent prod access that no one remembers to revoke. We need auto-approvals for known, expected access changes — like access to the customer database related to debugging a specific issue, or as part of an incident — so that routine requests don't clog up the queue, while still keeping a record. (Access requests are still necessary, just not at the scale they're being used today.) And we really, really need deny policies: hard guardrails that prevent access that should never happen, without relying on someone to catch it in review. It's a lot easier to maintain a short list of what’s approved than to audit an ever-growing list of places you might have made a mistake.

Getting off the identity treadmill means getting to fewer tickets over time, not faster tickets. The only way to get there is to have your access controls and policies express what your organization actually wants, and the reality of where it is now, updated automatically over time as things change. That’s what we’re working on here at Oblique.