Role Reversal, From Years to Months

In the previous post, we covered the start of my RBAC journey and shared that I had a problem, specifically, I had a timeline that was far shorter than industry standards, but that was only half of the challenge: I also had no access to the IAM tool itself. No plan, no guidance, no access, and very limited time. What does a person do in those circumstances? They fall back on their strengths: listening to a customer, developing requirements, and software development. The client had the two problems that RBAC is classically used to solve, too many access requests and too many access certification items, and, as I found out, the unstated problem that all organizations have: no idea of what to put into roles to resolve this. I took those problems and a copy of their IAM data exported from their IAM solution and turned it into a minimum viable solution, a tool that effectively recreated the functionality of their IAM solution's role mining software. It wasn't pretty (CSVs in, CSVs out) and it wasn't easy to use (command line arguments), but it was much faster than the role mining software built into the client's IAM tool, and it was exhaustive; it didn't just create a candidate role for a department, it created a candidate role for EVERY department. I later found out that manual creation of these role candidates for review took up the bulk of an RBAC consultant's time, usually via a lot of fiddling in Excel.

The greatest strength of the solution wasn't the speed or the totality of the output; it was the control. We owned the source code, and that meant when the client asked if we could incorporate additional identity or access data that wasn't present in the IAM solution, but was critical to decision-making about role creation, we could do that; it was just a question of incorporating another input and annotating the outputs with it. Questions like "Who owns this?", "When was the last time this was reviewed?", "Does this access have special obligations regarding its authorization?" could now be answered in a meeting if the information was available to the client. Once the relevant information was added, meetings stopped generating more questions than answers, and an hour-long review session could produce a role. The speed of role creation accelerated, and the cost of creating a role came down. The same effect applied to re-certifying the access for the role. The creation and maintenance of roles became cheaper and easier, and the number of manual access requests across the client started to drop dramatically. Being able to customize the software performing the Role Analysis ultimately turned out to be far more valuable to both the client and me than mastering the Role Mining capability of the IAM tool. Moving the analysis and review out of the tool itself also meant it was easier to bring in those responsible for approving the contents of the role, most of whom are not members of the IAM team.



As I finished my time at the client they hired a new cybersecurity analyst and sent me an email telling me that he had sufficient access to start working on his first day. It wasn't everything, there were edge cases in the access that will always, and should always be managed individually, but the bulk of his access was waiting for him when he walked in the door.

"I've been doing this for over a decade and this is the first time a client has ever thanked me for doing an RBAC program. Usually they just kicked us out after a couple of years" - My Boss at the time, the partner in charge of the client relationship.

That felt great to hear, but one data point is not a trend. I knew that if I had created something valuable, it would have to be reproducible, and as I found out later on, I had gotten very lucky with this client.