From Buzzword to Reality: Identity Security Requires an IAM Services Thinking

Good evening. So this is the final talk for today. And since it's late, we decided to split it up between the two of us. As you can see, we have myself. I'll start with Darran. We have Darran Rolls, fellow analyst with KuppingerCole Analysts. He will do the second part. I will start out with the first part. And we want to talk about From Buzzword to Reality.

Okay, this is the tagline, but Identity Security Requires IAM Service Thinking. And I think this is true. I did this a few months ago at a smaller event, at an impact day, and I talked about that we also need to have identity at the speed of business, and now we have identity at the speed of security. And I think that is important to get there. And why we want to do this, and why it even says IAM Service as the control plane for identity security, my part is to explain why we need that, why we should do that, and then Darran will explain how to do that.

So that will be the more challenging part, I think. So if you think of your IAM department like something like this, basement, engine room, damp, wet, feels like 1999 or 2005, then you are exactly where we think we shouldn't be. Because identity has changed, and this is something that has been said a lot of times around that, the question is what do we make out of it? What does that mean for the way we deliver identity to an organisation? Identity is no longer supporting security. It is no longer doing that.

It is the enforcement layer, and that means everything that we've been talking about for two days already. We're talking about humans, workloads, APIs, AI agents, and identity also as the central attack surface, and we need to understand that we cannot wait for this damp machine room reacting to some security incident. We need to be much faster. Security response must happen at runtime. And our conventional IAM systems were not originally designed to address identity security needs.

They think of let's do an access request, let's approve it, or second approval, let's do an assignment, provisioning, deprovisioning. This is not the speed we need for cyber security. But many IAM projects and many IAM programs today still simply fail to serve this purpose. Why? That's the reason. We plan identity projects still to last, and I'm nice here, quarters of years, half a year, we'll deliver the next version in a year, next summer, so this is what we are thinking of right now. So how long do IAM projects run?

Planning, approval, procurement, rollout, that's the project cadence, and that does not work for identity security when you need to add new capabilities. Minutes, or even seconds, is the amount of time you have to react to a security incident, from detect, to exploit, to breach, to escalate. We are talking about fractions of a minute that actually is required by an attacker when it comes to exploiting your systems. So you need to react at that speed. So we have the speed of creating and adding new capabilities, and we have the speed of reacting to an incident.

And what do dev teams, application teams, do when IAM is slow? They bypass it. They create their own solution. We are in large organizations where if you don't deliver, they do it themselves. They do it in other platforms. They do it in other systems of records. They don't care. So we have shadow authentication, we have hard-coded tokens because you don't have the right mechanism to do it properly, and this ends up in the security debt. And who is happy about that? The developers aren't. The hackers are. What comes to the rescue? I think you are afraid that I will say that, and I will say that.

The identity fabric. And if you were wondering how it does look like, you can see it in the background. There is a big, huge identity fabric, at least in my chat GPT, so you can see it in the background. And the idea is to use this concept as the foundation for delivering identity security services at the speed of security. And that means real-time performance when it matters. That was the middle column of the slide before. Rapidly delivering the right services. That was the left part where you have no longer the time for quarters of years, half a year.

For the right identities exactly when needed. That is what we are aiming for. How do we get to that? That's what I want to talk about. You've seen that picture a lot of times, starting with Martin's opening keynote yesterday. The idea is I won't explain that. I don't have the time. I promised Tim to only waste seven minutes for this. But the idea is we have a common language, and we get from the left to the right, from capabilities to services to tools. So we design capabilities, we combine them in services, and then we implement them with tools.

But we are not allowed to wait a quarter of a year, or a month, or half a year, or next summer. This is not what we are allowed to do. So we need to go to the middle of the picture that we have before I go back. The middle is capabilities. This is what we want to implement. So we put the capabilities at the center of what we want to achieve, and then we create services from that. So the fabric we are using that for defining what we need, for evolving what we have to what we want, and we take the identity reference architecture to say, okay, what do I need next ITDR?

Let's add a basic functionality for ITDR, and let's do this within the next three weeks. So getting the time segment that you have smaller, deliver faster, and provide services that you really want to provide. So you get to identity services, what we deliver that evolved with business needs slash security needs. How does that look like? And that is already my final slide before I hand over.

No, the second final slide. Sorry for that. You end up with an implementation that is as modular as the identity fabric as a concept. If you make it smaller and even more smaller, you get to a service delivery that ends up feeling like continuous, feeling like it's an internal SaaS service that you provide for your own organization because you're getting faster. That's the idea behind that. You have services that are owned by somebody who's responsible, who defines service-level objectives and accountability.

You have modular services, maybe the same service in different versions at the same time to fulfill new needs, be faster, really deliver what you need, and putting the identity fabric services layer, middle layer, at the center of the delivery. So you end up with authentication service as an example that is SLO-backed, API-first. It's an owned service that is an owner who defines it, who has to justify what he or she needs to do. And then you have the service description that you require. You can go through all these services much, much more that you can provide the services that you need.

The service model that I just described makes identity capabilities consumable at security speed, not at project speed. How to achieve that? Final slide for me. You have at the top the identity fabric and the reference architecture. These are the building blocks, around for many years right now. Next step is to define the service portfolio, make it as comprehensive as possible, and evolve it as tiny, as evolving, in smaller steps as possible, granular evolution, and continuous delivery, so that even your consumers don't even realize that something has changed.

Like you're using M365 or Salesforce or whatever, do the changes at that level so there is no update. Just do it. And of course, for this, you need a proper IAM organization. I put it in yellow to say you have to have the right people with the right mindset and kind of entrepreneur thinking to evolve the service when it's needed, to provide the security when it's required. And that really helps in turning identity into identity security and business impact. If the business asks for something, be as fast as they want you to be.

If security demands for that, do it as fast as security asks for that. And that was the theory, and he will tell us how it really works, so please welcome Darren. Thank you. So I'm between all of you and a boat and some beer and some bratwurst, so let's keep it going. We'll try and get through this as quickly as we possibly can. So the idea is here, how do we take the fabric and weave a set of services on top of the products that we already have or the products that we're about to acquire? This is actually my, I think I came to the second EIC, so this is heading on for my 19th.

So infrastructure's changed and the requirements. SAS has changed everything. So it's important to realize I'm not really an analyst. I'm not a vendor anymore. I was the CTO at SailPoint for some 12 years, and I'm not a customer. So I'm here really to represent all three of them. We've done a little bit of surveying across some of the more advanced customers to look and see how they've addressed creating service.

Now, there is no easy option here, let's just say, that service provider reality is cost reduction. Everybody is looking for a reduction in the costs and the time to value of the infrastructure. So it's no good thinking of the service as some way of increasing the cost. It's also to accelerate the onboarding. To service security, unfortunately, breadth is important. Coverage is very important. So things like application onboarding into your identity infrastructure becomes even more important. And of course, simplification. One might put them all three together.

Cheaper, faster, better. Our services have to have a flavor of each of those in order to have reason. So what is an integrated set of services? A set of value capabilities that we might deliver to security and to the business?

Well, the fabric is a complicated thing. There's going to be lots of products. And the first thing you have to do is understand how they interact with each other. Whether you have the infrastructure today or you're acquiring the infrastructure, the trick is to look across the use cases that you can provide to the business. And these are defined business services with known outcomes. Not everything that the vendor backs the truck up to deliver. So it really is about understanding the flow of your use cases across the infrastructure and choosing the services that can be of most value.

If you're talking to a security operations center, it may be more about context, relationships. If you're talking to purely the business service, it's going to be things like onboarding, application change, access request, single sign-on. So understand your fabric. Understand the pieces that you have. And understand how to weave sets of intricate use cases across them that service the business need. It's kind of the trick to it.

Now, how do you do that? Nice picture of a swimming pool. I'm an avid swimmer. That's my swimming pool in Texas. Lovely spot. But vendor swim lanes. So a couple of the companies that I spoke to very specifically about this, this is the biggest thing they said, was to define a box for the vendor. Vendors have lots of overlapping capabilities today. An IGA solution is no longer just IGA. Access management does PAM. PAM does access. And the important thing here is to strictly demark the vendor's capabilities around the services that you've provided.

Just because it does single sign-on doesn't mean you use it. Again, look at your path through the processes to create the services that you can put metrics around. It's tough to do that, of course. Rejecting the vendor, the vendor bloat strategy, is very, very hard to stand against. I've been a vendor myself for some 30 years, and we're good at convincing you to use our services, obviously. And so a very, very hard line is required in order to facilitate that. And it's a fabric-first mentality. As we look across the fabric, we've chosen the use cases.

They're the things that we're going to put our service-level potentially APIs around, and we're definitely going to make our service-level definitions. And let me go back there, sorry. This is a great quote. Somebody said that they told every vendor when they came into their updated project that they knew they thought they did everything, but they had to stay in their box and kind of do as they were told. Basic vendor management, you might say. Easier said than done.

Now, it doesn't mean our people go away. Our vendors are obviously very important. Our internal teams don't really change as much when we look at creating a service-based infrastructure for the business. The people that we've had in place are still very important. But it's critical that we create a service owner. And this is somebody that can actually define and own the service-level agreements that we'll deliver to the business. Somebody that can understand the business and help maintain the health of that service from a business perspective.

By owning the outcomes, this is a direct quote from actually a large retail bank. By owning the outcomes rather than the tickets, we're able to ensure that identity became an accelerator for the business.

So again, services, not tickets. We'll look at that in a moment in terms of metrics that we give out. The other one was an important role that came up from all five companies that have done this. One was the idea of an orchestrator. And this was somebody that would basically manage the vendor. Manage the vendor's expectations, manage what they're capable of. And then managing that vendor's was hard. The most important role that came up with just about everybody was the traditional business security officer.

Whatever you call that, if you have a large-scale identity program, you already have somebody whose job is to interpret the business and put it into security terms. That can then be mapped to sets of services that the fabric can deliver. So our business user roles, if you like, the teams that you still have are still extremely important. We just have to ask them to do some slightly different things. Another thing we heard very, very consistently from this group was to approach the problem slightly differently. We've had a tendency in this industry to deploy in silos, deploy in products.

We have an IGA team, we have a privilege team, we have an access team, and we deploy the products in that order. The most successful service-level identity delivery is done across the services. And so there's this notion of application-first onboarding. We don't just onboard in three separate tiers based on the products. We onboard them based on our use cases, and our use cases cross the tiers. And that's critically important. So it's something we heard from pretty much everybody, was a slightly different approach to how we onboard applications across the tiers.

What came with that also was clear service scope and definition. Where do we draw our boundary lines? It's an opportunity when taking a service-level approach to reset that with your buyer, with your customer. And incidentally, anyone here who is already delivering a SaaS identity service or has outsourced it, this is what your outsourcer does. It's absolutely no different.

Clear, demarked sets of services that align not only with the business goal, but with the architecture as it can be delivered. So something very important.

And then, I think Matthias mentioned it, continuous lifecycle. We can't do big releases, of course. It's important that we take a much more staged, small, bite-sized pieces in order to get forward. The infrastructure is much more ready for that today than it was 25 years ago when I first started doing this at Waveset. That's for sure. So how do we actually make this thing real? Last couple of slides here. And it goes beyond KPIs and metrics to operational dashboards. We're all used to giving certain new pieces of information.

But what we found everybody was doing here was, in effect, repasting the information from the ecosystem. Don't forget, it's three, four, five, potentially six products, up into one place where they could provide a single dashboard that represented the ecosystem, not the individual product. And the way AI technology is today and presentation business logic technology, this is actually quite easy to do. And these were dashboards that I was able to share from one of the... I think they're actually at the event.

Showing how to represent the health of the entire ecosystem, not just an individual product. To be able to drill into that and actually show demarked value metrics that are representative of specific services that are being delivered. And then finally, I couldn't actually share any pictures from it, so this is actually from GraphQL. But the idea of having a relationship, one of the most important things you can give the SOC, is an instant view of how accounts, privileges, and access relate to each other. You can transform a response action's time by doing that.

So, are we there yet? Are we finished yet? Have we delivered everything in Identity?

Well, unfortunately not. These are some real quotes. The vendor consolidation isn't helping me at all. They keep buying things, and they're not the tools that we've got. And then the CIO says, can't we consolidate our licenses?

No, because it breaches the fabric and the service level we've got. Our IAM programs seem to unearth all the problems we have.

Well, I'm afraid that's the nature of Identity. That's why it's the gift that keeps giving. And then this one we heard quite often, actually, was I'm being told to adopt AI faster than we have controls and governance to cover it. What do we do about that?

Well, is the situation going to be improved by a new AI fabric? We've heard lots about AI, lots about the AI fabric. Unfortunately, this is one generated by AI for us, AI generating a fabric for AI. But we are going to have new sets of capabilities that we are going to have to overlay onto our Identity infrastructure. And that can be kind of daunting. What does all this stuff mean? Where does it fit? There are other opportunities before we get there. And this was, again, another great quote. This actually came from a retail organization.

But they said that what they were doing in their Identity teams was actually partaking in the AI onboarding initiative. As Identity security people, you know lots about what the future of AI governance will be by virtue of the world that you're currently governing. And so it's a bit kind of be a part of that conversation. As that technology is being rolled out, make sure that you have a place at the table for the AI infrastructure teams. A lot of them are being isolated. They're giving it to a different group of people.

Well, if you haven't heard from this conference strong enough so far, Identity is going to be the key to making AI services real and secure. So there's a place at the table for everybody in Identity and it's going to be very important. And then how do we deal with this situation? I'm glad to say that the methodology that Matthias outlined for us remains the same.

And that is to look at the current capabilities we have, look at the capabilities we have and the capabilities we need, define sets of services that run against those capabilities, weave your fabric, weave your own Identity path through the fabric, select the tools that you need, and then rinse and repeat. So it should be more of the same. And so the finishing message here is Identity security becomes real when IAM stops being a product. Let's not talk about IGA, PAM, Identity security. Let's talk about the services that it represents.

And with that, Identity delivered at service speed and IAM measured through service outcomes. They are the take-homes for you. So with that, that's us. That's us. Get in touch. APPLAUSE Well, I think you've said it yourselves. You were standing between them and drinks. I think we'll just call it a night there. Have a wonderful evening, everybody, and I'll see you back here at 8.30 tomorrow after your morning run. Good night. APPLAUSE