How and Why IGA Programs Fail - A Case Study [Intermediate]

We can just skip my presentation because you should just take the inverse of the previous one and then we'll go through everything that I have to offer. So this is how and why IGA programs fail and I'm Jon Lehtinen. And before I begin, because it's a force of habit of mine, I say the views and opinions in this talk are my own and not necessarily representative of those of any organizations with which I am currently or have ever previously been affiliated. So blame me.

All right, I present this as a case study. Now a case study is a situation where you look at ideally a real life example and then the student takes a look at it and then you attempt to extrapolate the lessons learned. So that way you can say, here's what went well, here's what went bad. So in our case study today, our subject is a SaaS company. It's been in business for 15 years. Has four years of experience operating as a publicly traded company. It has less than 10,000 employees, so it is big but not gargantuan.

It has a strong startup culture and despite its growing size, so I would refer to this as an awkward adolescence of an organization. And this organization is attempting to navigate a pivot from that go-go startup culture to something a little bit more mature. And here are the players and principles inside of this.

Note, there's a lot of them, a lot of them with very similar titles. We have the C-suites, a bevy of C-suite representatives, each interested in this project for their own reasons. We have security as in security security, the folks monitoring, doing incident response and security GRC. We have information technology where the protagonists, the IM team, operate. And for some reason the IT team also has an enterprise security team as well as an enterprise GRC team. So we're up to two GRCs now. And then also we have an internal audit and compliance team.

So I'm going to call that two and a half GRCs. So a lot of stakeholders here. Sounds great, things should be aligned. So this IM team had been working and building and growing over the last several years and deploying some very, very slick identity technologies. The emphasis was always on the shiny new cool thing, things like passwordless, phishing resistance, device authentication, and profiling. These are all very, very cool and very, very important security tool sets.

But whereas these were the neat shiny things, we had our old jalopy outback, which was our lifecycle management and IGA process. I'm saying our as if I were representing the point of view of the IM team. But I assure you this is a case study. So this organization had an organically developed LCM process, very immature entitlement management and role-based access control process. Quarterly access reviews and attestations were a flurry of Google Sheets.

And then the stable of applications in scope was a mix of SaaS applications for finance, customer relationship management, plus several homegrown processes and tools. So over the years, the IGA team was growing and developing credibility with the business. How come they did not choose to prioritize IGA? The culture of this organization, though they strive to be better, is one that rewards heroics.

If there's a big forest fire, they like the person swooping in with the tanker, dropping the water on it, instead of the people who should be working for years clearing the underbrush to make sure the forest fire doesn't happen. Additionally, competing priorities. That new shiny is very, very neat. And it gets a lot of engagement and excitement. And it still prioritizes the security emphasis, not necessarily a governance emphasis. The IM team here attempted over the course of the years to take the fledgling and, you know, they had the capabilities to support IGA.

But they attempted to build it from the bottom up. Build it as part of a service catalog that then business owners could come and request services from them for. But something as big and compliance riddled as IGA doesn't really lend itself to that skunkworks methodology. And so things operated in this wise forever without incident. Until it didn't.

Overnight, there was a change in culture and prioritization in which now governance and secret management and life cycle management and access control were the orders of the day. One day, this team was instructed to inventory and rotate every secret in the environment. Inventory and rotate every nonhuman identity in the environment. Implement an advanced and automated joint remover lever process based on attributes inside the user store, inside of that environment. And also offer fully automated role-based access control for all the applications. All within time frames.

The executives certainly love to give ultimatums. I suppose that's where that heroics culture would show up. Because if people would jump through hoops, then they get rewarded. Yeah. So the interesting thing about this new push wasn't that it came from an edict from internal audit or a compliance org, rather. This was given to security to drive. So I can see why security would be very interested in making sure we have all of our secrets managed and rotated appropriately. But security personnel often act a little forceful. And they expect results less than nuance behind that.

So despite these headwinds, this organization made significant progress. They were giving those arbitrary deadlines to inventory and rotate those secrets. And they were successful. This gave the impression that such would be the path for the rest of the process.

Namely, automated joint remover lever and role-based access control. Yeah. So starting with role-based access control, because that's a lot easier than detailed entitlement management. The team attempted to demonstrate value and demonstrate progress in an attempt to show that this was going to be an endurance race and less a sprint.

And so if they could move the needle and demonstrate how new employee onboarding was now fully automated with the appropriate applications, then perhaps they'd listen to their guidance when the identity team would start saying, all right, for entitlements, this is going to require a whole lot of more of the village than just them. So they began developing their templates in the process to interview department heads to try to figure out, okay, we've known that having people become effective when they join in this role has been a pain point for some time.

So we are now ready and prioritizing making sure that every single person in every single department for every single role gets what they need when they need it on day one. So department head, what does your staff use? They don't know. Go deeper.

All right, directors of whatever sub department you are, what do you need to be effective? Okay. Perhaps GRC or security GRC or internal audit would be able to tell us what is appropriate for the various roles inside of this organization. Yes. How about enterprise security or security? Okay. So we start to see some of the problems and this ties into the previous talk where the business needs to be a stakeholder to this.

Eventually, out of a desperate need to show progress on this program, they start looking for the application owners to say, all right, well, let's see if we can find some quick wins on the entitlement front. Who can we bring in?

Well, there was a loose definition of app owner. Nobody truly felt like they were an app owner. They were the decider for their application or they supported their applications. But there was no registry, no notion of business control owner, no notion of technical control owner, and also not really a full application inventory. So this also meant that we discovered by we, I mean that team, figured out that there was a non-trivial amount of shadow IT in the organization. So now the effort was how do we determine what is actually used for the business for legitimate purposes and why?

So by this point, some months had passed, and the identity team leader was getting a little fatigued of being grilled as to why progress was not being made on the lifecycle management and role-based access control front, to the point where they finally had to address the elephants in the room, namely, they need some certain precursors. We need to be able to understand who is ultimately accountable for business processes, ownership of applications, et cetera.

And furthermore, the project, having been run so far with the success of those non-human identity and secret rotations, the executive function came out of that IM team. They're the ones with the hands on the keyboard. As a result, as the program rolled forward to do lifecycle management and role-based access control, that team still got stuck with all the R's and A's in their AC, and God help them, there was a whole lot of C's and I's who wanted to opinionate and describe and dictate what should be done.

So, further complicating this, this identity team, over a few years, had grown to a robust number of engineers. It was a 20-person team. It was not small. This team was divided between folk working on the traditional environments and a subset working inside a federal environment, which has some very significant regulations attached to it. Another point of contention between the identity team and leadership was, why are you not bringing all of your resources to bear on this priority one issue?

And the answer was, approximately half of the team needs to respond to quarterly audit requests and remediations, POAMs, plans of action, whatever POAM stands for, to make sure that the entire federal side of the business can operate. If we were to fail to do that in a quarter, the organization would lose, I don't know, approximately 8% of its revenue, and then the CEO would have a way bigger problem than an identity leader saying, help, we need to be better with our back in LCM and we need some precursors for that.

So, we weren't as big as we saw, but notwithstanding, I think, the larger struggle for this team was, there was no room for pilots. As this was being driven by security, the applications which had to be fully governed with role-based access control were to be the ones that pose the most risk, which means the ones that have client data, financial data, all sorts of fun stuff, such as the CRM system with 15 years of historical cruft and ad hoc entitlements in a go-go, let's just close the deal style culture.

So, there was not even a window for lessons learned or to start piloting or to begin the enterprise change management process through using a much more simple set of applications to introduce this notion of governance and accountability to the business. So, time went on, and eventually, the leadership team, well, the executive stakeholders, started to perceive this feedback as excuses and delays and a resistance to execute. Some of the feedback from folk who, again, were some Cs and Is were particularly cutting.

There was a sentiment that it would be embarrassing if we got more capacity or staff because then it proves that we don't know what we're doing, which is fascinating because when you know what you have to do in the time frames you have to do it and you understand what needs to be done, you can usually start extrapolating how much person power is needed to make that work. The product folk and technology officers insisted that the platform is easy to use, thus, what's your problem?

Like, it should be dead simple, turn it on. Security folk, in fact, I recall being on a call saying, no, I mean the person recalls being on a call saying, this is easy, turn it on.

So, fed up with the dithering on behalf of the identity team, the business turned to a third-party analyst where they took a look at the environment and what it would need to, what would need to be done in order to accomplish the goals of full lifecycle management and full role-based access control. And funny enough, there was an awful lot of similarities between what they turned in for an untrivial amount of money to what that identity team had been saying for some months, such as app inventory and governance processes need to be established as a prerequisite.

Otherwise, it will not be successful. Structured accountability charts across the organization. We need everybody to be a little bit more R and A and a little less C and I.

Obviously, if you want to do this fast, you're going to need more engineering capacity. And what's more, if the organization really feels strongly that department heads, GRC, internal audit, security shouldn't be the ones to figure out what roles or what applications are appropriate, well then, that capacity needs to be built up on the identity team who's doing it.

Thus, we need business analysts. And the business did not necessarily have an appreciation of the distinction between what is an identity engineer and what is a business analyst. I already addressed the enterprise change management.

And also, OK, so they corroborated the need for a comprehensive enterprise change management program to introduce people to these new concepts and ways of working. And also, they recommended piloting with simple apps for the quick wins to build confidence in the program and the capabilities before moving on to the gigantic Gordian knots of the higher risk systems. All right. Eventually, that identity team grew fatigued and started to scatter their way and move on. Thus concludes our case study.

So, what can we learn from this? I don't know whose water this is, but I'm going to drink it. All right. Remember our players from before and the accountability structure. There's an awful lot of cooks in this kitchen, each with an interest, a valid interest, I might add, in the outcome of this program. They did not seem to have an understanding of what it would take to accomplish the program, nor a realistic notion of the timing it would take to accomplish it.

In a world where you have that many sea levels demanding that much specific attention, it becomes a bit of a reporting and readout challenge. Security. Which security? There's a lot of security. Security likes to point out problems. And I'm sure they fix some things. But they did not fix the governance situation. That was entirely on the identity team.

Also, GRC. Security GRC. Internal audit. These folks would often highlight when a spaghetti type process would fail to remove an obscure account from a system, though the main identity is long since terminated, and raise a big old flag and stink, and we'd always patch it up and fix it.

However, when it came time to say, all right, how are we going to solve this problem? They didn't have much to say, other than make it good. I think asset management can not be understated. I've personally seen some asset management systems and organizations that I thought, wow, this is tedious. A quarterly process by which you'd register your app, you'd be the business owner, you'd highlight your technical control owners, and there was a quarterly workflow to keep it up to date. Young John Lennon thought that was silly.

And then this hypothetical identity leader realized, oh, my gosh, that is so valuable. I think that is truly essential to making this program work without knowing what it is we're trying to bring into the sphere of governance and IGA. Then naturally, we won't know when we're done. We won't know how to prioritize or do anything else. Additionally, this asset management type style, it has secondary benefits to the business. So I would emphasize that regardless. Next extrapolation, business analysts. A business analyst is not an engineer, and an engineer is not a business analyst.

You might have some who are pretty good at faking both, but I've seen an engineer, I've seen engineers burn out when management decides that their capabilities and skill sets are fungible. Setting aside the touchy-feely personnel management components of this, there are very few people who are actually management components of this. They are very different skill sets. Additionally, those business analysts could position themselves to be trusted advisors for the business and develop the relationships with the application owners in order to soothe their concerns and help get them onboarded.

They prime the pump so the engineers can keep operating that pump. Next lesson, iterative improvement. This organization wanted the beautiful duck statue. They needed to play with DUPLO first. And it is through fussing with DUPLO blocks that you start to realize this thing snaps here, this shape makes this good, and then as you expand and increase the granularity, you now have more complex forms you can work with, eventually getting to very fine-grained control and automation, well, entitlement management and governance.

And last but not least, I think all the parties here, including our protagonists and the identity team, have an opportunity to reflect upon that failure. It's very easy and very, very fun to suppose that the protagonists of our story are always right and, you know, the wicked business people didn't do them or did them dirty. I think a better way to frame that is if that team was I think a better way to frame that is if that team was delivering the same message to executive leadership and executive leadership wasn't responding, why do you keep delivering that same message?

Is it a stubborn sense of pride that you're trying to guide them and help them? Is it an inability to read the room to understand what it is they're actually trying to prioritize? So there's opportunities perhaps for all parties here to learn how to work a little bit better and grow from this experience. So interview. How do my programs fail? Once again, it's the last slide the previous gentleman put up here. You need enterprise buy-in, ownership and engagement at all levels.

You got to start with the precursors to make sure you can start doing the more advanced capabilities like IGA, role-based access control, and full lifecycle management. Make sure app owners are known and accountable. There's a process to refresh that information. Specialize.

Again, staff are not fungible. These are different skills. And make sure your RACI reflects reality in a way that doesn't overburden one staff while giving a whole lot of people that have to sign off on a form before you can progress.

And again, iterative improvement and incorporating the learnings from the small steps to make the big steps simpler is always going to be the superior path forward. And I believe we have two minutes. So thank you. And any questions? Do we have questions? Okay. Maybe one question from my end. When the project unfortunately failed but needs to restart because we have, let's say, compliance pressure, we need to do it. How do we build trust? What would you say? Let's see. Are there any common approaches from your experience? Any good advice?

In my experience across service delivery of all types, trust comes from consistent execution. And not necessarily the big heroic deliveries. The big heroic deliveries take a long time to manifest and there's a lot of things that can go wrong. And usually they're only about 75% good if that by the time you're done. And everyone just pretends that the 25 that didn't make it across the finish line wasn't necessary anyway, right?

So I'm a big stickler and a big proponent of process improvements, minimally viable processes, augmenting capabilities, determining who the actual internal customers are that will benefit at this point in time. So there's always a demonstrated ramp of value the business is seeing. Once they see that ramp up, then you get a little bit more grace in order to then stagger out some of the bigger, more complex components. Great. Thank you so much. I think visibility and also delivering value to the business is a great idea. Yeah. Perfect. Thank you.