Welcome to the KuppingerCole Analyst Chat. I'm your host. My name is Matthias Reinwarth. I'm an analyst and advisor with KuppingerCole. I've mentioned that many episodes before, but this is a really special episode of this podcast.
This time, we have two guests. One of the guests is easy to introduce. This is Martin Kuppinger. He's one of the founders and the lead, the principal analyst at KuppingerCole.
Hi, Martin. Good to see you.
Then, much more importantly for today, we have an additional guest, an external guest, and somebody who should be known within the identity space for several years. I want to welcome Felix Gietkens. For the introduction, I hand over to you.
Hi, Felix. Good to have you. FG Gietkens Hey, folks. Great to be back, at least for an hour or so. MW Right. A brief introduction for those who managed to avoid you in the last 20, 25 years. What's your role currently? Where you've been? FG Okay. Some of the really old ones may still remember me because I used to work for KuppingerCole as well for, I think, about two years. I was much younger and much handsomer in probably 2010, 2009, 2010. I have a fairly long background as an IAM specialist. I got into it in probably 1999, 2000, when I was doing LDAP provisioning and LDAP virtual directories.
Afterwards, the term identity management was formed. I did quite a bit of a lot of things, some single sign-on, some access management, identity governance and administration. I was actually responsible at Gartner for creating the first magic quadrant for identity governance and administration at that time in 2012. I worked for Gartner until June this year, and I'm currently on a career break.
MW Okay, great. But this break gives you time to join us today.
For me, as a moderator, this is perfect because now I have two of the monsters of rock of IAM in the room, so to have them together and discuss topics. This is where we just really want to jump in to just really leverage the opportunity. When we discussed what could we talk about, what is important, we came up with two of those interesting acronyms that are around. The first we have is Identity Threat Detection and Response, ITDR, so one four-letter acronym.
Maybe starting with you, Felix, is this a meaningful evolution in the IAM landscape, or is it just the next marketing-driven term, analyst-driven term? We are analysts, we are all analysts.
FG Boy, ITDR, now that's a term that makes me want to reach for my buzzword bingo card, right? But before I get too cynical, let me give credit where it's due. The core idea behind Identity Threat Detection and Response is actually solid. We've been so focused on detecting malicious files and machine anomalies that we kind of forgot identities themselves, whether human or machines, because they can be the attack vendor. When someone compromises a user account or when a service account starts behaving weirdly, traditional SIEM tools often just see legitimate identities doing legitimate things.
ITDR says, well, let's actually look at identity behavior patterns across the board. But here's exactly where vendor overreach and overhype kicks in hard.
I swear, half of the vendors in the market just took their existing user behavior analytics, maybe added some machine identity monitoring, slapped ITDR on that box, and called it a day, right? Suddenly everyone's got an ITDR solution, even if it's just alerting you that a human logged in from a new location or an API key has made more calls than usual. But we need to admit that it is smart, because if you go to a German workers' council and say we introduce user behavior analytics, they will shout at you.
If you say we introduce identity threat detection and response, they will say, oh, great, they help us improving our security posture. It's a positive thing. So from that perspective, even if it's just UBA, it's definitely a smarter term than UBA. I actually have not thought about this. I live in Germany for outside of Germany for 25 years. I'm not even allowed to vote anymore. And I completely forgot about that. You're right. The generally transformative piece, though, is when ITDR starts looking at relationships and patterns across your identities.
This employee who normally acts financial systems is suddenly pulling HR data, or this service account that usually talks to, say, three databases now accessing the executive file shares on the drive, or even this human's credentials are being used to spawn machine workloads that they've never created before. So that cross identity correlation is where the real value lies, understanding how human or machine identities interact and spotting where those patterns go sideways. You still need to do a reality check. ITDR isn't some magical standalone discipline. I don't even think it's a market.
It's really just identity where detection that should be integrated into your broader SOC operation. You're covering the whole spectrum of identities in your environment. This implementation, I've kind of seen as where it treats it as a lens through which you view all of your other telemetry, not necessarily as a separate ITDR silo. I think that it might be, or maybe a bit oversimplifying to just say we should integrate ITDR into the SOC operation, because there are two aspects in that go well beyond the typical SOC operation, which is very log, very event focused.
The one thing is, or maybe three, the one is identity relationships. So we're looking at complex relationships you brought up in machine identities or non-human identities or workload identities, whatever we call it. Maybe we touch this a little later in the conversation. But anyway, I think this relationship thing is adding a certain level of complexity, and it's also something we haven't solved really well.
The second element is that machine identities have, I would say, a complex ecosystem behind when you look at applications, the workloads and the applications and where these identities occur, et cetera. So then again, we have a bit more complexity. We also need to understand what is happening more from the development DevOps side. And the third thing is that identity threat detection response also has to do with the entitlements. So what is someone allowed to do? What are people actually doing, et cetera? I think to understand the threat, you need to understand entitlements.
They can be, as we know, when you go to a whatever traditional SAP system, they can be fairly complex. And also we have a user group, which are more the identity people who need to understand what is going on with the use of identities and what does it mean for my static or the entitlements for my policies, whatever else. So I would say it's more than just a piece of software. And so I would dare to say, if you, for instance, and we saw a lot of vendors from the XDR space, which said we also can look at identity events.
But that's not, I think it needs more than just saying XDR can consume these events. You're right about that. And you raise a really, really good point. I think we need to understand though, the difference between visibility versus observability. And that's where we need to look at ITDR as what it actually means, because it does mean detection and response. Talk a little bit about visibility versus observability, because I think this will make a lot of things clear. Real distinction that most people completely miss in IAM, but it's absolutely critical to understand the difference.
Because visibility in IAM is like doing an autopsy, right? You're examining the static snapshot. You look at reports on who has access to what, you do these quarterly access reviews, you look at old assignments, frozen in time. It's asking what does our access look like right now? Or even what is the path to potentially more privilege? What is the potential attack surface? You're basically taking a photograph of your identity landscape while everything's standing still. But observability, that's watching the movie, not just looking at the poster.
Observability is like seeing identities in motion. Who's actually authenticating? What are they accessing in real time? How are permissions used moment by moment? That's the difference between Sarah has database admin rights, and Sarah just executed 17 unusual database queries at 3 a.m. on Sunday from totally different locations. And of course, when we talk about machine, here's where it gets really interesting. Like with humans, visibility might be enough sometimes. You can ask Sarah why she was working late. But with machines, forget about it. It would be too late.
Especially when you're three months or six months in the world for reviewing things. And anyway, only do rubber stamping in IGA because the certification process is far too complex to really understand what is asked for. So I think we need to go into an observability. That's where I fully agree with you. If we don't have that, we have a gap. And I think then the next challenge is how can we derive action? So a real response out of that. It reminds me a bit when we go back to the early days of what back in the days was called access governance, before you coined the term IGA.
The early vendors, they allowed you to do reviews. And then you had a long list of things that are wrong or problematic, critical, whatever. But you didn't have an option to remediate that. And at some point, I think in the early days, it was a point of Alexa. They then came and said, Hey, we invented something great. And they basically finally came and asked you for a briefing more or less at the same point in time and said, we right now can sort of trigger actions. We can help you in really automatically or semi-automatically sort of fix the problem. And I think we need the same for ITDR.
So I would say that the ITD part overall is so much better than the R. Yeah, there isn't much R. The R part is, let's send a log, let's open a ticket somewhere.
Yes, but that's not a response. No, it isn't. I'm not going to disagree with you, Martin. I just think we need both parts. We need the visibility part and we need the observability part. And they're really different.
Now, ITDR is such a big piece of hive that vendors sometimes, well, they call anything ITDR these days, whether it's doing some kind of observability or some kind of visibility or maybe a mixture. But I think it helps end-user organizations best if they think about both of them as discrete capabilities that you need to imagine. And part of them go a little bit outside the purview of what most IAM teams actually are. They're probably tools that are going to be more relevant for the SOC and others, not at all. Others are going to be very much in the purview of IAM teams.
You need these two capabilities, these two distinct things, visibility and observability. But even in the IAM team, you need to have visibility and observability. And in the SOC team, you also need to have both. And I think, Uri comes in and you touched this already. When we look at, let's call it machine identities for now. When you look at that, then we also, anyway, in the space where the traditional human approach of visibility, like we have a recertification level, will work. Because these things change far too quickly. They may not exist three months after anymore.
Way too many of these, et cetera. So it means we anyway need to go into automation. And then we move from this more static visibility into an observability, also with the need for a rapid response. Because when we have these relatively short-lived identities and what they can cause, then we need something which helps us to act way faster than we are obliged to do with traditional recertification processes in our IGA realm. Okay. I think most of that makes sense. I don't agree with one small point, though. And maybe we'll agree after I say this.
Because you say that IAM teams, they need both visibility and observability. SOC teams also need visibility and observability. Let's start with the SOC team. They certainly need both and they can use both. Because if they just have the observability and then they actually need to investigate, they need the whole visibility of what is behind those things. And they also need to actually understand that. So that is absolutely true. Now with the IAM team, I'm not so sure whether observability is really the thing that they should prioritize.
For one simple reason, if you're in the IAM team, are you working 24 by 7? Because if that's true, then for sure you can have observability. But if you find something at Sunday morning at 3 a.m. and the IAM team isn't there, then it's kind of pointless. Which would mean that you either need 24 by 7 in the IAM team, which is challenging. Or you need an IAM empowered SOC team that understands IAM specifics and machine identity specifics and many other things well beyond the common focus of what they are looking at.
If you let me jump in there, ITDR for me also is the source for signals that can be used downstream in authentication authorization. I think that when you derive the R in that manner, when you understand, okay, there is something fishy, unexpected in authentication authorization processes, but this is fed by well-done intelligence resulting from an ITDR tool. Maybe the IAM teams can sleep at night and don't have to work at 24 by 7.
So, this is really something that can be automated and really directly injected into viable and important processes downstream when the user interacts with the system. Isn't that a role of ITDR as well? Eventually. I think in the future, we might see more of that. I think the state of the art is that you don't really see this very much. I think the state of the current IAM affairs and ITDR is that they're selling to the wrong stakeholder. You can't really easily sell ITDR to the IAM team.
You can impress them with some great demos and all of that, but at the end of the day, what Markin said is actually, I 100% agree to that. You have somebody from the IAM team that works with the SOC team, that acts as a bridge between those two, that educates them what's going on within the IAM space, that helps them understand how all of these things are tied together. But ITDR is actually selling to more of a SOC function than an IAM function.
Now, visibility is a different thing. Visibility tools, they're definitely for the IAM team, but we don't really, I don't know what it's going to be called. I think my former colleagues, they've coined a new term now. Is it IVIP?
Identity, visibility, something that could be. We've got other things like ISPM and all of that. I just prefer to call them visibility and hygiene tools.
Actually, you may not even really need to buy a lot of tools because you probably already have a lot of things that you're not using correctly as an end user. Then perhaps you might make some point purchases to buy some additional things, but I think visibility is more like a capability. It's not so much like something that you can buy.
Yeah, but to a certain extent, there's again a blurring line. One of the things I thought about when the first AI-backed identity analytics solutions came to the markets, then vendors said, okay, this helps you in identifying role candidates and other stuff. Some of that we did 20 years ago with Excel already, but what really would have been beneficial from the very beginning would have to say, okay, I look at everything, how data, so how entitlements are used, which entitlements are used by whom.
That is basically something which is, I would dare to say, usually more gathered, information gathered at the observability side of things, but it flows back into, in that sense, the visibility because that is information that also helps us to understand which of the entitlements are not needed, which of the entitlements are only needed in certain scenarios, maybe at certain points in time, like whatever certain things that happen once a fiscal year, certain things that happen only during the summer break from maintenance in the OT environment or other things.
Then we could use that to have less static entitlements, but also a partially dynamic assignment of entitlements. I think there's a strong intersection. The other thing that you brought up, I liked that really, was to whom to sell because the thing I had in mind just when you talked about that was, at the end of the day, what we are currently discussing, I would say, reconfirms one of the things I tell for quite a while, and that is IAM belongs in the realm of modern first line of defense CISO. So IAM belongs there. We could talk about the term identity security, which is a very fuzzy term.
I know that you have strong opinions on that term, but I think there's a certain intersection there and it makes a ton of sense to have identity management, in the broader definition of identity management, as part of the domain of the CISO. Then you have, at the end of the day, that one buyer's persona where everything comes together. If I can just summarize what you said and what we kind of discussed, I think ITTR is really misleading for many organizations, and people are really confused. IAM teams are thinking, do I need ITTR because everyone's talking about it?
But then again, they're not prepared for 24 by 7. If you're not prepared for 24 by 7, you cannot do detection and response. This is the fact, right? It's like if something happens and they call you up, no, sorry, Mr. Cooper is at a meeting, right? You can't respond to it, right? You don't even have an incident response plan for those people to do it. So the capabilities for the IAM team are mostly around visibility and perhaps additional data that tells you how entitlements are being used. And when will you use that?
You're obviously not going to use this for some detection of immediate response, at least not now, but you'll probably use it when you have your next attestation run, or when you have some kind of procedure that looks at these things, or when you have some prioritized finding that bubbles up and says, hey, while you were happily enjoying your weekend, something weird happened here with Matias' account. Are you sure Matias still requires these things? Let's do like a micro attestation right now and not wait till the next quarter or something like that. For sure.
I think that's probably in the scope for IAM teams. And I think the whole segmentation is not very helpful for end users at this point in time. It will get hopefully better. Yeah. When I think a little bit further, a lot of SOC services are not provided internally. When I think about that, you have a managed service provider, there's a rather standardized type of offering, and you have this very bespoke world of excellent entitlements, identity relationships related to applications.
You can also take the SAP sort of threat intelligence, threat detection tools into that, where you also have a lot of specifics. Then this becomes a pretty interesting challenge, how to enable your SOC teams to come up with well-lit analyzers, well-lit potential incidents, well-lit detections at the end of the day, and how to handle that in a meaningful manner. So how to act fast when it's needed, with the IAM specialists not being on 24-7, and maybe, so to speak, two steps away. So the MSP, to the security, to the identity people.
So I think we will need to think a lot about organizational setup for that. 100 percent. We are not prepared for it yet. 100 percent. A lot of teams are doing IAM, not just the IAM team. And the question is, how do you make all of this happen in this energetic and not in a counterproductive way? Same thing is happening with machine IDs. Yeah. Look at where Microsoft EnterID is located in many organizations. Or even Active Directory, back in the day. I think EnterID is easier, because I think for EnterID as an authentication system, there's absolutely no doubt that it belongs to the IAM team.
For Active Directory, you have a little bit of an infrastructure element and crew policy objects, which are sort of device-focused. You may argue a little bit, but I say for years, also Active Directory belongs to the IAM team. And for EnterID, I would dare to say everything else is just raw. So now I jump in again, because we agreed that before we change topics, that we have some kind of final thoughts or recommendations. So we realized that ITDR is often not yet well understood. It's not yet well integrated. But we have two analysts in the room who can make recommendations.
So let's get to recommendations. What would you recommend to organizations who really maybe even bought an ITDR product, whatever that means? And what should they do to leverage these tools better? What would be a first step? So the real first recommendation, Felix, maybe you want to start?
Well, if you already bought an ITDR tool, that's not a really good situation to buy something and then figure out what are you going to do with it, right? I'd rather answer it from the point, well, what if you don't have these capabilities? And I would say, start with visibility first, because visibility helps you to establish proper hygiene within your IAM stack. If you don't have the proper hygiene, then you're going to likely face potential breaches or potential attacks or just some events that you could have totally prevented in the first place.
So I think preventative is always a good thing. And I would perhaps start by shoring those things up over there. Once you do that and then you get to detection, I would look at the use case that Marjan already suggested, which is analysis of events over time that may cause you to look at your posture, for example, by tweaking entitlements for a particular account. I wouldn't necessarily go into detection and response until you're ready to really have that fundamental discussion with your SOC and see how you can inject IAM in there.
Or perhaps they're going to approach you because they need your help as an IAM leader to do that. I think that's a part of everything Felix said here. Maybe to add or maybe emphasize a bit, the one thing is start with thinking about capabilities. Don't start with thinking about tool categories or anything else. I think when you look at our Identity Fabric, there's a reason why the Identity Fabric goes from capabilities to services, which are sets of capabilities, to tools which actually deliver that.
You should start with the capabilities and then you should think about what do you need, what do you have, what is missing, do you need what is missing, and when can you realistically implement it, what are the prerequisites for doing so. I think today we discussed some interesting prerequisites here when it comes down to organizational readiness for certain capabilities. That means I think there's a lot of thinking about what is the right organization for that entire stack.
How do you build interfaces between IAM and clearly also the security development teams, but especially the security teams, even more when you have a managed service provider in there or an MSSP, managed security services provider in there running the SOC. Then you need to have very well-thought-out approaches for that. Then I think also part of that is clearly to understand who, so to speak, has the knowledge about what, where is a knowledge transfer needed, and who's the recipient of which information.
Last but least, I think we should think about how can we make this entire thing actionable, so not just ending up with a long list of things that are suspicious, but understanding what is a real challenge and being able to address this on time. That will be at the end. That's where we need to move towards. Minimizing the number of things we need to look at, but having the right ones in front of us where we say, okay, and this is where we really need to take an action.
We need to sometimes take it very fast, especially when we could go beyond the world of humans into the world of all the other types of identities or their related identities, because then it's about automation. This is where I jump in with my chance to actually start my second questions after 30 minutes. That's nice, and it's an important question.
We want to look at a topic that even is difficult to give a name because even names are disputed right now, but I think it's not necessarily necessary because we want to talk about machine identity, non-human identity, workload identity, everything that goes into that bucket. There are a lot of bright people writing clever stuff, and Felix is among them. If you follow him on LinkedIn, there's a lot of interesting stuff to follow up on there.
Of course, I have to mention that Köppinger told us this as well, but there's really interesting reason around that. When we turn to machine identities, let's look at their operational reality.
First, the term or non-human identities, and then the operation reality. This is the second buzzword that we're looking into, of course, but this buzzword has an actual core to it. I think I started with Felix earlier, so I start with Martin. First thoughts on how to actually deal with all these non-human related identities in terms of non-human control at runtime? Yeah. I think we should be very, very careful with terminology here. The one thing is that there's always this risk of endless disputes, which at the end will not result in a full agreement.
The second thing is in this NHI read-down, there's such a huge or wide range of identities that we can't treat them all the same, unless we go very generic and say there's an identity, and we treat every identity the same way. Clearly, there are identities like functional accounts, so technical accounts, traditional ones we have for decades that are very close to any of their characteristics to a human identity. Then we have AI bots with very different types of identities.
If you go to an IIoT thing, the thing is already in the acronym, so Internet of Things, so it's a really very technical thing. They are also, again, fairly different, for instance, from what we have in the software development space. It is not that we can easily differentiate here. I think the best thing probably is to not spend too much time on terminology. I think we need a little bit of clarification, clearly, at least when we go into concrete conversation. I think it's always good advice to say, okay, what exactly are we talking about?
Now, is it this or this or this? But until then, I think the terminology war, it's not a war at the end of the day. Fortunately, it doesn't help us much. I think it's an understanding that there are new challenges arising that we need to deal with. I think there are some obvious challenges. One challenge is scale. The other is, I would say, the volatility. These identities change much faster than many others, but if you go to the consumer space, you also have a lot of short-lived identities. On the human side, it also may happen, but I think it's a bit of a characteristic here.
I think we, again, have other players in. By the way, the same would happen when we started with consumer identity management. We had more identities, they had different life cycles, and there were other owners of them. In that sense, it's, again, not so different, but I think we need to understand how to deal with that, how to mitigate the risks associated with them. Stay Forever Handing over to Felix, your thoughts. Both of you are very outspoken on what you consider important. Just one thought from my side.
I think one issue with NHI is that we put things in there that should have been taken care of for decades, as Martin mentioned – technical accounts, service accounts, system accounts. Just because you have not managed them yet properly, don't put them in the NHI bucket. Stay Forever Personally, I think that NHI is a really sloppy term. I still don't like the term. This term is being thrown around to describe accounts, credentials, identifiers, but they're not the same thing. Identity is not an account and it's not a credential. We're mixing up fundamental concepts.
I've started using the term recently because it's used predominantly to denote static identity constructs for machines. That's really what someone means when they say NHI. I need to manage my NHIs. They're not talking about microchipping your dogs and cats and giving them an RFID identity, which is also a non-human identity database, or managing a legal entity identifier for your organization. That's not really what they refer to. They very specifically talk about API keys, service accounts, and some other static identity constructs for that.
What Martin said before, I think he said, was the difference between how we manage identity for humans and for machines. I think the main difference, I would actually put them into a few things.
First one, and this is a really, really important one, machines don't necessarily need accounts. This is a super important clarification. Think about it. You have a container that spins up. An identity is created for it. On the fly, the container terminates, poof, the identity vanishes. No orphaned accounts cluttering your directory. This is actually a very good way to do it in a femoral way. The second thing is, forget multi-factor authentication for machines, because they can't use MFA. You can't really secure them by storing credentials for them at all, where they have access to it.
Instead, you need to generate these one-time credentials on the fly when the machine gets up. That's also where it gets really messy, because most organizations are doing this completely wrong. They're treating machines like humans, and then they create accounts, and assign owners, store credentials in a vault, to have a status, whether we still need an individual decommission. It's totally backwards.
It's also, unfortunately, driven by vendors that call themselves non-human identity vendors, or workload identity management vendors, how we used to call them at Gartner. That's what they sell. They prefer you do it in the old way, because the more legacy static identity constructs you use, the more money you have to pay for them, the more you get dependent on them. The better way is actually, if we're going to use that NHI term the way it was intended, to try to get rid of your NHIs. Get rid of them. Eliminate NHIs. Exchange them for something else.
You probably can't get rid of 100 percent of them, but you could probably get rid of 80 percent of your NHIs, or 75 percent. This, by the way, hints already on a challenge, that most of NHI is not NHI. It's because, I think in that sense… Exactly. It's a very sloppy term. It's more the secret that is handled than an identity. We could go back to this discussion about identity versus users, etc. Sure. We're going to bore people to death. We could do that.
Yeah, but I think terminology in that sense is important to make clear what we are talking about. There are then constructs which we must not underestimate. We have an application which consists of a range of modules with a ton of APIs. There are relationships and there are developers who are responsible for certain elements that are owners of the entire application. We have a relationship challenge. We may end up with services that access resources in the cloud. We have these relationships, but I think we are not really precise.
I think Matthias has been writing about it as well, already in our blog. I think we had one or two podcast episodes already on that. I think we need more preciseness.
Yes, I think it's obviously a good idea and something where we are very much on the same page. It's very worse to think about how can we handle challenges by not trying to map them to a concept that hasn't been built for this use case. The traditional workforce identity use case is a very different one than we are talking about here. Trying to map this to an identity to user account to entitlement schemes approach just might be wrong. It is. It is actually a very legacy pattern and we really strike out with it. It is creating so many problems.
The question, of course, is if we're talking to IAM teams, you can probably convince them, but that's not where the problem is caused. The problem is if you go out on the street, the people that throw their garbage on the street, that's actually where it happens. It's done at software development, at infrastructure and operations. That's where these things may be created.
Probably not so much at infrastructure and operations because they probably tend to do the right things nowadays with cloud-native approaches, but application and development, application and installation, the classics, for sure. You raise a really good point. I always like to make this analogy. We talk about non-humans. Let's talk about cats. You've got two cats born at the same time from the same litter. They look the same, kind of, almost. They almost look identical, but you can still tell them apart because each of them has their own unique identity. This one has a bushier tail.
This one here is a little more playful than the other. The other one is maybe a little more reserved. That's because each of them has their unique identity. You can use identifiers and attributes to describe really what makes the difference. This is the same thing for machines. You have two containers, but they're launched from the identical image.
So, you get exact copies of the same service, but still, they're different. They have different IP addresses. They have different container IDs. If you can describe what makes them unique, you've defined their identities. That's actually where people get really confused because an account is not the same as an identity. An account is just a registry entry on some kind of system for a particular identity. The ugly way is taking those two containers and creating one static account for both, stick the credential in the secrets manager, and boom, you've just implemented a terrible legacy pattern.
A more elegant way could be to use something such as Spiffy to assign each container a unique service ID on the fly and let them use that for system access. Suddenly, your observability is crystal clear because you know exactly which container does what and where and when. That's actually the difference between managing accounts and managing identity. That's the move from legacy credential juggling and NHI management to modern machine IAM. I always like to say, your cats, they don't share the same label on their food bowl, so why should your containers share static credentials?
It really doesn't make sense there either. I remember Matthias and me having been in an interesting project a longer time ago, and we touched a wide range of identities, including identities for real things, real machines, and other stuff. Sometimes really big things which consist of a lot of things. What really was interesting then to see how, I would say, the legacy approaches of assigning identities, managing secrets, etc. basically failed. Because at the end of the day, for some of these environments, the only thing they could manage a bit was, so to speak, the joiner process in that sense.
But anything which went beyond that renewal of whatever keys or stuff like that, it really got ugly. I think we really must be careful of applying traditional approaches to everything. I think there's this tendency, we started this workforce IAM, so a lot of things are applying this concept. I think there's another analogy which really made me think. That was when we look at SSL TLS certificates and their reduced lifetime. Then it basically is, we still stick to an established approach, and we try to fix a challenge by saying, okay, we go down to whatever, 30 days then, to reduce the risk.
But it doesn't at all solve the root challenge, the root problem we have, which would be how could we come to an ephemeral approach instead of a static approach. Exactly. But the thing is, these ephemeral approaches, they exist, they work, they're actually being pervasively used. Who are we actually talking to? Who's going to be listening to these episodes over here? Because if it's the IAM team, then they may actually not be the ones in the position to solve this. This is actually the most frustrating thing I see in this market right now. Who is responsible for machine IAM?
IAM teams are basically missing an action when it comes to machine. This is creating this massive leadership back here. Here's what's actually happening on the ground. You've got the infrastructure engineers who are spinning up containers. They need those workloads to authenticate to databases. As you mentioned, they should be doing this in an ephemeral way. So what do they do? They might call up the IAM team and say, hey, how do I do this security? You know what they get back? They get back radio silence. If they're lucky.
Because maybe if they're unlucky, someone from the IAM team says, ah, just create a service account and stick the password involved somewhere. That's not leadership. That's application. At least it's a proven mistake. We're doing that for decades. I know. But this is application. It's not leadership. Yeah. I always say, if you use a functional or technical account that way, then you already did something wrong. You can do it. And we could do it, could have done it better for decades. That's the bad thing. On the other hand, I think there's a role for the IAM team in that.
Because I think when we look at infrastructure development identity, then all are domains that require quite some expertise, specific expertise. And most identity people are not very good developers. And they are also usually not very good infrastructure people. Always exceptions there. Same for infrastructure. Not necessarily good developers, not necessarily good identity people. Developers, they do not even want to care about security. Or so they just want to solve a certain challenge, to build a certain software.
And so I think the art is to figure out how can identity deliver for the IAM world, deliver services for the others to work like the others want it and need it. I think this is the point. So if you take the everything or infrastructure as code things, they also caused a lot of security challenges because things were coded in there. We see still ways where whatever API keys are shared and securely, because I think there are different domains and we should do it that way. But that requires, I would say, a thorough understanding and collaboration of the IAM's three different parties.
And only that way it will work. And then it must be a very much service-driven approach, which doesn't limit, which doesn't lead to situations where someone says, no, you can't deploy an Azure Key Vault because we already have HashiCorp and AWS here. That's not the right answer then. It's about enabling it, delivering it in a well-hardened and a secure manner so that it can be used very quickly, that you don't stand in the way, but that you take all the identity and security related burden over from the other teams.
I think what I, for instance, as an analogy, what I like is, for instance, that OPA, the Open Policy Agent, gained quite some traction because it simplified the life of developers. Because they just had to basically do a simple call. They didn't need to care about the details behind it anymore. That is what is the way. So it must be thought from how does the developer work? How does an infrastructure engineer work? And security needs to deliver the right type of service.
Yeah, but if you look at security, we've discussed security being an old IGA guy, I'm looking at the G part, the governance part. So most of these NHI accounts, let's keep with that term, they are privileged. They are highly privileged. They can do things that we would not love our neighbor or colleague to have. But they are ephemeral, but they do things. How do you apply, apart from security, governance? How do you hold somebody responsible, accountable, maybe liable for what this thing did in this short lifespan of its existence? Where would you approach that, Felix?
Well, okay, before you do this, there are a few fundamental things that you have to put in place, right? Because you're saying, how do you hold someone accountable?
Well, accountable for what exactly? Because most organizations, they don't have a policy for this. And even if they had a policy, they don't have any kind of guidance for the developers for this.
Now, IAM teams, many of the IAM teams, when you talk to them about your developer, they kind of look at you like, I'm business focused, right? Tell you what, every critical business process of your organization is enabled by machine to machine interactions, right?
Now, if that's not a business problem, then what is, right? So, you would think that somebody should be leading this conversation. Is it going to be IAM teams? I thought they could step in there, because they have all the coordination skills, they understand all the identity concepts, they know how to do all the cat herding and get multiple groups aligned. But the problem is that they're kind of stuck thinking about machine ID as if they were weird humans.
So, what needs to happen is that somebody needs to step up. I've seen this happen more under the CISO, rather from the IAM teams, but that's okay, too. But somebody needs to step up and form these cross-functional machine IAM working groups. I think that's the best way to get this to work. Bring everyone to the table, from DevOps, security, from application teams, infrastructure and operations folks. Because right now, we've got this business, this critical business infrastructure being secured by whatever happens to be closest to the keyboard, right?
And then once you do that, that's where you can actually start giving strategic direction and giving proper guidance. And once you have that guidance, then you can actually enforce it. That's where the governance comes in. Because if I tell you how to do it properly, you don't do it properly, then I'm going to have a problem with what you do. But before, there is no guidance. If you don't give them guidance, they're going to look at the internet on how to do this and they'll say, well, use a vault, right? Or just use a service account and stick the password, I don't know, somewhere.
This is not the right way to do it. So you have to do this on a programmatic way as a multidisciplinary working group. It's not going to work otherwise. I don't even think IAM teams should be responsible for that unless they really rethink what their role in this is going to be.
Yeah, I think it depends a bit on how you define IAM team. Also, again, back into this, where does IAM belong? What's the role of the CISO in there? As you said, I think there are other elements, there are other teams which also play. And I think we need to get away also a bit from... I think if your IAM team is basically a traditional workforce IAM team, then they're still quite a long way until we are there. If you see it as a much broader team that does way more different things and already deals with way more different types of identities in a proper manner, it might be simpler.
But yes, I would agree it also requires to think about what approaches are best suited to solve certain use cases. I think the sheer fact that we first had team which is Cloud Infrastructure Entitlement Management appearing, which in a sense was non-human access, so services to resources, et cetera, where we looked a bit more on the entitlement side. And then we have right now quite a huge number of non-human identity management vendors with us appearing that clearly indicates we have a challenge that is not yet well solved. Indeed.
I mean, that's kind of obvious. Yes, we do have that challenge. You're 100% right. But does the IAM team do that? It is kind of like asking if your bicycle can handle the autobahn.
I mean, technically, yes, it has wheels. Are you going to get run over or pulled over or something like that? I think there are two aspects. So one could be, we say we have a different team that sits somewhere in between. Or a working group, a working group.
Yes, but still then you need to come up with someone who runs the service, who provides the service, et cetera. So from the operational side, it's not just the working group. And the other thing is that it also leads to the question, how must your future IAM team look like? I think that is maybe the question we should ask ourselves. Because from sort of the traditional workforce IAM to what an identified break as a concept comprises, which is all types of identities, all types of services, way bigger, that's a tough journey at the end of the day.
And I think the question which comes to my mind is, how must the future IAM organization look like? I'm looking a bit at Matthias here because I think that might be a very good scene for his team to think about how much that organization, let's call it IAM organization for now, it might be a very different IAM than today's IAM organization. But how must it look like? Because at the end of the day, with most aspects we discussed today, we touched that a traditional IAM organization is hardly capable of dealing with today's challenges. They are often over-challenged with Pam, but Felix.
Yeah, I may have misunderstood you, Martin, because you said something like, well, are they even equipped to run this whole thing? I don't think it really is one particular team that runs everything. And actually, that's not how it really works with most organizations. Because you'll see that IAM, even today, it's distributed among many different sections of the organization. You've got folks that do PKI, they're not necessarily the IAM guys. You've got folks that do AD, they're not necessarily the IAM folks either. Kim tools are also not really used so much by IAM tools.
You have others that are running SecretsVault, you have ones that are running Kubernetes and maybe using Kubernetes secrets over in there. And they might use things such as Spiffy, they might use their own PKI tools in there. You have folks that do customer IAM, they may also be in a different team. You may have different IDPs in there, not all of them are big. So I think this model of decentralized control, but centralized governance is what most accurately describes what's happening right now.
And I don't think there's anything wrong with that, that you have different teams that are responsible, different aspects of it, but you have to have, of course, a common governance structure. And that's why I think these machine IAM working groups can really achieve that. It's perfectly, maybe fairly acceptable to say that. You don't need just the working group, that's what my point was. The working group is the one thing where you bring together. And the standards. And you can implement the governance from that side.
The governance is something which is a, so a working group is something which is, at the end, temporary. It may move into something which is a sort of a regular sort of contact, which is embedded in the organization.
You say, okay, we come together here. That would be the more steering committee thing, probably rather than a working group. But then you need sort of a, in your organization, someone who cares for governance across everything. And you have many, many elements which need to be implemented, managed, run, et cetera, within that. And then the question is, what do you consider of all that being part of your IAM? And that's something like an IAM department that still exists in the future. Is it something which is more descriptive of everything which is related, but which sits in various areas?
How do we then avoid sprawl? So again, I think there are a lot of interesting questions around how must the organization look like? How do we call things in the future?
And yes, it can't be that you have one single group or whatever, three or four people in a small organization who have all the systems under their control, because it's... No, that's something to have. I think in the reality of it... On the other hand, you can't just say, it's here and there and there and there. You need a certain degree of control also to avoid sprawl. You need governance. Because even today, you have different teams that are doing IAM in their particular way. And I don't think we disagree. It is something that is obviously, that's perpetual. It's not a project.
You're not doing something, then you're done, have a party and walk away. Obviously not, right? So you do need to have all of these different stakeholders participating within that forum. If you don't want to call it group, but you want to call it forum or something like that, that may work as well. The whole idea is you have to get those people together, those individual stakeholders.
Now, what is IAM's role? I think if things continue the way they're continuing right now, then I think IAM is going to be maybe consulted, possibly informed, but not really responsible for anything, not really accountable for anything either. It's kind of cut out of the loop on this, but they do actually have some great things to contribute. So I think IAM teams can actually, if they really wanted, they could probably take charge of that. It doesn't take that much because they have a good understanding of identity.
They need to obviously care about those particular business cases that are very critical for machine learning, specifically application infrastructure, development, operations, all of these kinds of things. Then they might even be able to take a lead on this. But I think if that does not happen, then someone else will take the lead on this and IAM will be one of the many parties in them. I think the challenge we have today is that not only someone, but many take the lead on something in an uncoordinated manner without proper governance.
And whether it's later on, maybe we have a traditional IAM team and we have a machine IAM team, which are again working in certain areas closely together with a proper governance across everything, or whether the IAM team evolves and has different sort of groups in which care for different things. I don't care much about it. But I think what becomes very, very clear is we need to think about the organization, about the governance structures, as well as who best runs what, and to avoid that things are done in an inappropriate manner.
Whoever is close to the keyboard kind of decides which kind of static identity construct they use. That's the total anti-pattern. That's what organizations have to go get away from.
Yes, you look like you want to say something. Yeah, I'm looking at this.
I think, A, this is the longest episode ever. Second, this is the episode where I ask the least questions at all, which is great because that means the discussion went without me, which is nice. Having three people in the room who are doing identity for really a long time right now. I was afraid when I joined Identity in the late 1990s or mid of the 1990s that this is a temporary stuff, temporary things. Somebody will come up with, way back then, Data Backer Book for Identity Nexus Management. Everything is in there today now. It's IAM for Dummies, and then we're done.
I could not have been more wrong. We are in a situation where identity is actually just evolving and growing and expanding and metastasizing and really getting bigger. We need to look at that. Maybe that is a positive thing for us identity professionals as well. There are still a lot of things to consider, to think of and to do and to improve. I think that's really the good thing. Identity is not yet a solved problem. Many aspects are solved, but not all of this. We're just discussing that.
We did not even look at agent-based computing, agentic AI, which is part of NHI and which might or might not raise different issues. We didn't make it there. We're at the end of this episode.
As I said, there will be these final thoughts questions for each of these both topics. Again, it will be the same question. If there is an organization that really wants to embark on a proper journey towards managing all types of identities, including NHI, I don't know even whom to start with. What would be your recommendation? What actually to do first to get a grip on this huge area of identities to cover at all? Starting with Felix. He's the guest. Okay. You have to build a strategic roadmap for comprehensive machine IAM strategy really on five components, like five pillars.
Don't go into the trap of using some tactical NHI management approach because that strategy really transforms the fundamental architecture of how machines authenticate and interact. The first one is to establish the governance and discovery, bring everyone together, cross-functional coordination and comprehensive understanding of all of your use case in the current state. Then build modern machine identity infrastructure, assemble stuff that you already have. You probably already have a lot of things. You have API gateways, you have PKI, you probably have OAuth somewhere in your IDPs.
You might want to add Spiffy to that to enable dynamic machine identity pattern for the future, if you're not already using it. If you are already using it, then roll it out even further. Then this is really important. You need to create standards, training, and guidance. Make dynamic machine identity patterns the easy path, the default path for documentation, education, policies, procedures, and of course, then compliance with this. You can't just say, don't put things in clear text or don't put things in a box.
You have to give real guidance, like cookbooks for people how to do it, and then they will. After that, you're ready to embed security by design. You want to prevent new static credential creation that implement modern machine IAM best practices.
Then, as the last thing, you migrate and improve. You transform your legacy using risk-based approaches and continuous improvement to migrate off of NHIs and more to modern machine IAM patterns. That's kind of how you do it. You have to do this together in a group or a forum, if you so wish. I fully agree. I think it starts with the working group. It starts with bringing people together to learn.
I think that the first thing is really that everyone understands the need, the demand, the requirements, the challenges the others are facing, and also what they know, how they do it, how you can do it technically from that end, et cetera, in a very open-minded manner. I think that I fully agree with the points Felix brought up. I think the one thing to add is I think we need to be very precise with what is the sort of a more temporary working group scheme, et cetera, versus what is the resulting organizational structure out of that.
That is something we need to work on because that organization will compare to what we have in a traditional IAM organization that stems from a workforce IAM history. I'd say maybe it's a good idea to do this talk in three years again from now because with about 90 years of experience we have in that room with the three of us, the next time, if we do it in three years, we probably would have 100 years of experience altogether. So quite a lot of that. This alone is a reason. Right. So quick end to this.
You have provided your insights into these two topics and I really enjoyed this session because although coming now from different sources, origins, we came together through synthesis and that is the great part of it. So both for ITDR and before NHI, however we call it, we came up to the point that there is a problem that needs to be solved and the proper way that needs to be applied to get there. And maybe this point where we want to get might look different from organization to organization.
And getting there, that's the journey where people can support you in and where best practices and standards and interoperability is dramatically needed and will evolve over time. And having both you, Felix and Martin, in this virtual room together in this session really was a pleasure for me and to have your insight into that. I have more of these four-letter acronyms that I can throw at you so there is room for more one-hour episodes around IAM, I'm quite sure. Would love to do that. But for today, really, thank you very much, Felix, for being our guest today.
Thank you very much, Martin, for being my guest here as well. And for both of you who know each other for years, for having this vivid and sometimes controversial, but in the end also a joint discussion with a common output. Final question, final sentence, 20 words, 40 words. What would you want to give the audience from your perspective? What to look at next in IAM, Felix?
Well, I think for sure machine IAM. That's kind of at the nexus of where the really big business problem is that needs to be solved. And for your IAM, if you want to start small, think about visibility and think about preventive hygiene. I think that's going to, it's too difficult to achieve, that's going to get you really, really, really far before you chase the buzzwords. Right. Martin? So beyond NHI, so let's say before NHI or related to NHI, think in more integrated approaches like Identity Fabric.
Beyond that, I think one thing I think about a lot is the impact signals and AI will have on what we are doing. And I think that there are some really interesting things that will pop up over time and some interesting evolutions stemming from that. When you think about how authentication could look like in the future based on many weak signals, maybe being really passive. And when you think beyond policy-based access towards something where AI helps us making more creative, nuanced decisions. But that would be probably a good topic for another hour or two. For a future talk, yeah.
For another hour or two, yeah. Exactly. So thank you again, Felix and Martin. I closed on very quickly. Thank you for being my guest today and for sharing your insights into these really topical topics. And maybe there is an upcoming episode together with the two of you. Thanks again. Have a great day. And thanks for joining me. Thanks for having me. Bye.
