Darran Rolls: Standing on the Beach, Looking at the Sea: Identity Governance & Administration, Today, Tomorrow and Sometime Later

Excellent. Thank you very much. And I'm gonna trust everyone can see my slides.

Well, great to be with everybody here this morning, live from Austin, Texas, and maybe I'll start my presentation by explaining its title, standing on the beach, looking at the sea. Well, I'm a surfer, a wind surfer and a foil kite. And over the years, I've spent a lot of time standing on the beach, looking at the sea. And the key question always is what board to take out, what sail or, or what kite is, is gonna work best.

The wind, the tide, the current, they're all big factors. And you really want to try and get this right? Because if you take the wrong gear out, it hurts when you get it wrong. It's quite simple, right? That poor guy there that isn't me. I'm glad to say. Of course a weather forecast is very useful, but it's just that it's a forecast, right? It's a prediction.

It, it it's math, I guess it, it's not a real event. And so I've always found that the very best insight comes from your buddy, as he struggles back up the beach, like a, like a drown rat, I guess, because you just can't beat real world experience and knowing what worked and what didn't comes from true recommendations from the field. And I guess I'm lucky that I've experienced this in my professional career too. I actually spent 20 years in the vendor space as a strategist and architect. And as I said, a CTO at SalePoint for GE over 12 years.

And for the last four of those years, I also took on the role of CS. O you might say, I, I got off the beach and, and went out onto the water myself. And like every C I S O encountered breaking waves and strong currents. And of course I wanted a world class security program. So we bought and deployed all of the tools from EDM and stock to end user training and IM, and of course, as you might expect, IM we drank our own champagne, as we say, not dog food. And so my security architecture was identity centric and employed the best that IGA had to offer.

Now, at the beginning of this year, I actually retired from sale point. And now you might say I'm up on the cliff, looking down at the sea and you know what? I I've come to the conclusion. I really like that perspective, not speaking from the vendor pool pit is very refreshing and it's insightful. And so I'd like to relay some of the things I now observe about this space.

And in the short time we've got today, I'm gonna present some of the issues and the opportunities there always are under the headings of scope, complexity, and impact, and less than 15 minutes, I'm gonna explain where I think IGA stands today relative to each of these now, before I do. So let's begin with a common definition of what IGA as IGA is today. I know everyone's heard plenty about that.

You know, it, it can be a complex and esoteric topic, but it's one that's so easily simplified by this picture. You've no doubt seen many of these before this particular structure comes from the identity attack vectors book that I authored with ma Haber's last year. And in simple terms, IGA means understanding and managing who currently has access today. So that's an audit assessment of the actual configuration state for access. IGA also means providing policy models, constructs that allow for the definition of who should have access. So that's a statement of the desired state to be academic.

And lastly it involves assessing who did have access. So gathering, hopefully a clear picture of what's being used by who and importantly when. So if we have a common understanding of what IJ IGA is, let's answer the question, where do we stand today on this technology? And let's do so through, as I said, that lens of scope, complexity, and impact, and let's start by perhaps qualifying what I mean by scope that is deployment scope. It is capability scope, and it's what actually gets achieved in an IGA project.

I hate to say this, but my observation is far too many IGA products that I see today. They're just way too limited in that scope, or too often, they have very limited net visibility, however, who has access to what large scale projects.

They, they just always seem to struggle with app and identity source onboarding and achieving a comprehensive view of the actual state system-wide is actually quite elusive. And as they say, in system systems management circles, you can't manage what you can't see, right? So visibility really is king expect.

We, we we've just got to, to fix this. And sadly poor connectivity is so often full after 20 plus years of a maturing provisioning industry. Connectivity is still way too complex and way too costly. And so if I, if I put my Casos hat back on, I blame the vendors and not so much that IGA vendors as the application vendors, because I mean, if I see another new enterprise SAS application with a custom IAM interface, I'm just gonna screen standard API. And what I mean by standard API is stop taking a known domain and writing new dumb APIs.

I mean, we have skim, and I know it's not perfect yet, but this isn't rocket science. And if it is SpaceX is a reusable rocket now, right? So why can't we have reusable connectivity, but this isn't just a vendor problem. It's a customer motivation issue too. When buying a new SAS app or renewing a subscription, I think we should all say no skim, no accounts payable, right?

We've just got to get tough here and either make the connectivity free from the IGA vendors somehow more extensive, more, more, less costly, or we've gotta pass that responsibility back to the application providers full start. It is not more we can do scope also includes misaligned priority features too. So as an X vendor, it might surprise you to hear me say, we've got way too many features in IGA today.

You know, every vendor has their top five differentiated features and as analysts and product architects, we live to dream up, the next must have feature, right? It's how we sell. And as an old colleague of mine from way back at Tivoli, once said 20 years ago, of course the customer doesn't really need it. We haven't printed the t-shirts yet mean it was kind of a, a fun thing to say, but, but quite telling. So even when we look at a well considered and balanced overall reference architecture like this, we got to set some clear priorities, especially in large scale deployments.

You know, it, it really just yesterday I was talking to an IAM team that planned in a very complex intra app sod model in the first phase of the deployment short, they had an external audit driver, but they didn't have basic visibility. And JML in scope first. And as I told them quite clearly visibility, and JML our job number one. And that JML absolutely can't mean just join ad manual move and leave the network. Only of course, you know, I think everybody understands. We've got to do a lot better than that. And my last point on scope is around.

I wanna sort of drill in specifically on the entitled entitlement catalog cause it's so important cuz at the heart of any good IGA solution is an extensive entitlement warehouse. And by that, I mean a single registry of identity and access entitlement for the purpose of management and oversight the you one place to catalog, describe and classify all the things that give access accounts and permissions and groups and roles and ACLS, you know, vaults keys, and interestingly, even attributes, you know, basically anything that is going to entitle access to something we care about.

And you know, you have to own this in IGA because practically no one else does. It's that simple and what's missing in far too many solutions is the business process controls to manage the life cycle of the entitlement data itself. And so tools to help with ongoing discovery and classification and verification. You've got to do that technology and best practices to connect the entitlement to the data that it gives access to and then automation to share these relationships with I TSM and importantly to fine grained access control.

So if that's scope in a summary, where do we stand on complexity? And in my view, IGA is still way too complex and way too customized. And as my favorite security podcast, Steve Gibson at security now.

Great, great, listen, I, I recommend you do so what he always says, complexity is the enemy of security and for us in IGA, that that's a big problem because if identity is the center of security, how complex is that control plane? And you know, a big cause of that complexity is customization. Every IGA deployment is custom.

You know, your needs are not like anybody else's right. Everyone always says, and you know, maybe that's why some people are prepared to pay 10 times the software cost to customize and deploy it.

Well, I just wanna say to everybody here, stop, you know, do you really need that? Can't you do it out of the box and save a bunch of money time and complexity, you know, ask, is it worth it?

You know, will you be more secure, more compliant, more available because of this customization and importantly ask yourself, and this is cold hard question. Are you gonna make more money in your core business because you have it. And this customization question, isn't just a problem with traditional on-prem IAM. That's often what we assume, because in fact, it's sometimes worse in the world of an API first IAM as a service offering. And to explain let's call this service customization, what it really is. It's API level orchestration.

You know, everyone's buying SA, but everyone still wants the service to do a few things more, right? The vendor has a dev, Porwal an API, you know, custom rest endpoints and web hooks and callbacks and triggers all that stuff. So the deployment team is going to use that to roll up, to create a new custom app. And the question really is where is that customization going to execute? And I recently saw just this situation, a very mature IAM team was using IAM APIs from interestingly access management, IGA and Pam, right? And they were gonna create a single custom process flow.

The finished solution turned out to be an AWS Lambda function, right with stored credentials and no VE no vaulting, no governance and, and, and no oversight. And this surely isn't, can't be the future of IAM orchestration because in my opinion, this type of runtime control plane, cuz that's just what it is a control plane. It has to be in scope for governance. And that's something I personally will be talking a lot more about. And finally, complexity is a problem between IAM products too. The IAM stack integration, right? Even for the best of breed solution still needs some work.

And for lots of very good reasons, we all still choose separate market leading solutions. And of course those solutions all work fantastically together on a data sheet. Unfortunately in deployment, we often see the IEM stack also integrated with ITSM at the top there. And that's a pretty normal because you know, everyone wants their IM integrated with ticketing and, and core it service management. But when you put these four things together, the integration pitch, it gets a little fuzzy. It's a bit of a case of, as they say in baseball, who's on first, right. Not being native American.

And that was new to me. But you know, it's about who owns the glass and who drives the user experience. And the result is everything kind of gets integrated with everything else. And I think the IGA to integration flows, although they're not perfect, they do show some good separation, right between governance and, and fault and privilege runtime. But the am to I IGA and the am to Pam flows, you know, they've gotten pretty confusing, especially due to recent mergers and acquisitions in, in those areas. And you know, none of this is good for reducing complexity.

Remember complexity is the enemy of security and go look the bad guys, know it, right? So in my view, the industry at large has to sort this out, standardize the flows and deliver much better integration, more playbooks, and more focus on our best practice. And last but not least we have impact or maybe more strategically or accurately measurable actions and impact, you know, customers today spend a fortune on IAM projects, projects that span multiple years cost multiple millions and usually end up getting owned by multiple CSOs.

And for all that cost and complexity, where is the measurable impact improving success? You know, everyone has slightly different goals for an IGA project, you know, from reduced operational costs to maybe better security and compliance, but do these projects actually deliver on their promises. And that's why I'd like to see much better flow on operational status. Something that shows the impact of the entire IGA system. Something that shows targets goals versus actuals and rolls that up into a consistently measurable metrics, cuz that's what we need. Right.

And now practically, I wanna know what requests are flowing in and what actions and changes are flowing back out and what succeeded and what failed. And I want all of that operational data rolled up onto a single ops console. And I have seen some of this in vendor offerings, but I wish we had more let's call it perhaps a true IAM metrics dashboard and as a buyer of multiple solutions, right from multiple vendors across the stack. I want that oversight for everything in I am right. Not just IGA, but for Pam and access management too. Right. It's one system to me.

So just imagine having one place to see everything, identity, operational metrics, state policies, goals, and, and real time assessment. That would be pretty cool. Wouldn't it? And with the time closing in, let's hit on one more element of impact that touches everyone these days and that's DevOps, or maybe better said identity impacting dev sec. So where DevOps meets security, cuz that's really our place. And to perhaps coin the phrase to shift left identity at DevSecOps. Now that's obviously a mouthful of tech for sure.

So let me explain what I mean the term shift left is big in dev and workload transformation circles and it summarizes the drive to move test and set up security operations to move those processes to the left in the plan code, build deploy cycle. So what about IGA?

Well, unfortunately today IGA is way, right? Hopefully I'm not mirroring in the wrong direction.

You know, everything we think and talk about from structured units of assignment, automated provisioning, approvals policy, it's all, it's all way far. Right?

In fact, you know, it's so far, right? It's kind of off the page.

You know, those IGA processes are still batch oriented. They're largely static and they're almost completely outside of the DevOps cycle.

So I, I quite passionately believe that everyone in IGA needs to think how to shift left. We all need to better understand what's happening in the composite application and microservices, architecture world and build a strategy to align with it. We need to plan how all of our IEM processes affect the emerging dev set op stack. And each vendor has to understand where their core process is, where they fit today and how to evolve them tomorrow and how to drive a market. Because if we're honest, you know, most buyers and most architects, they we're just unsure about where this goes.

And, and I wish I had more time today to really dig into this much further, cuz it's a super interesting topic. But if you do follow on my blog or, or the research that I'll be doing with Martin and the team here at coing Cole, it's something you you'll hear much more about. So with all these sessions, we're supposed to be 17 minutes. I think I'm, I'm pretty much there.

So let's wrap up everything by saying that I hope we all appreciate that IGA is just a critical part of any identity centric, security strategy and IGA alone holds that clean, clear, and concise picture of how application and infrastructure security models, how they should be configured. And it provides the processes that ensure the right people have the right access to the right data at the right time. It's been a long road getting to where we are today and IGA, but the journey's not done.

So I challenge myself and all of you to remain mindful of these notions of scope, complexity, and impact when designing, building and deploying IGA solutions and this be ruthless in how and where we trade simplicity for complexity. Because like I say, complexity is the enemy for stop. And if I get one more, I am requirements wish let it be this that we execute a rapid and decisive capability for shift left and deliver the tools and the services that bake manageable governable and compliant identity into the emerging DevSecOps runtime with that, that's all.