WEBVTT 00:00:00.000 --> 00:00:18.800 Welcome to the KuppingerCole Analyst Chat. I'm your host. My name is Matthias Reinwarth. 00:00:18.800 --> 00:00:24.700 I'm an analyst and advisor with KuppingerCole. I've mentioned that many episodes before, 00:00:24.700 --> 00:00:27.976 but this is a really special episode of this 00:00:27.976 --> 00:00:31.400 podcast. This time, we have two guests. One of 00:00:31.400 --> 00:00:34.142 the guests is easy to introduce. This is Martin 00:00:34.142 --> 00:00:37.000 Kuppinger. He's one of the founders and the lead, 00:00:37.000 --> 00:00:41.400 the principal analyst at KuppingerCole. Hi, Martin. Good to see you. Then, much more 00:00:41.400 --> 00:00:44.286 importantly for today, we have an additional 00:00:44.286 --> 00:00:47.500 guest, an external guest, and somebody who should 00:00:47.500 --> 00:00:54.200 be known within the identity space for several years. I want to welcome Felix Gietkens. 00:00:55.100 --> 00:00:58.700 For the introduction, I hand over to you. Hi, Felix. Good to have you. 00:00:58.700 --> 00:01:01.200 FG Gietkens Hey, folks. Great to be back, 00:01:01.200 --> 00:01:02.500 at least for an hour or so. 00:01:02.500 --> 00:01:07.300 MW Right. A brief introduction for those who 00:01:07.300 --> 00:01:10.100 managed to avoid you in the last 20, 25 years. 00:01:10.100 --> 00:01:12.900 What's your role currently? Where you've been? 00:01:13.100 --> 00:01:16.245 FG Okay. Some of the really old ones may still 00:01:16.245 --> 00:01:19.800 remember me because I used to work for KuppingerCole 00:01:19.800 --> 00:01:23.632 as well for, I think, about two years. I was 00:01:23.632 --> 00:01:27.900 much younger and much handsomer in probably 2010, 00:01:27.900 --> 00:01:33.027 2009, 2010. I have a fairly long background as 00:01:33.027 --> 00:01:38.600 an IAM specialist. I got into it in probably 1999, 00:01:38.600 --> 00:01:45.900 2000, when I was doing LDAP provisioning and LDAP virtual directories. Afterwards, 00:01:47.100 --> 00:01:50.010 the term identity management was formed. I did 00:01:50.010 --> 00:01:53.300 quite a bit of a lot of things, some single sign-on, 00:01:53.300 --> 00:01:56.665 some access management, identity governance 00:01:56.665 --> 00:02:00.500 and administration. I was actually responsible at 00:02:00.500 --> 00:02:02.395 Gartner for creating the first magic quadrant 00:02:02.395 --> 00:02:04.500 for identity governance and administration at that 00:02:04.500 --> 00:02:07.728 time in 2012. I worked for Gartner until June 00:02:07.728 --> 00:02:11.100 this year, and I'm currently on a career break. 00:02:11.100 --> 00:02:15.000 MW Okay, great. But this break gives you time 00:02:15.000 --> 00:02:20.900 to join us today. For me, as a moderator, this is perfect because now I have two of the 00:02:20.900 --> 00:02:24.200 monsters of rock of IAM in the room, so to have 00:02:24.200 --> 00:02:27.500 them together and discuss topics. This is where 00:02:27.500 --> 00:02:34.200 we just really want to jump in to just really leverage the opportunity. When we discussed 00:02:34.200 --> 00:02:37.485 what could we talk about, what is important, we 00:02:37.485 --> 00:02:40.700 came up with two of those interesting acronyms 00:02:40.700 --> 00:02:47.800 that are around. The first we have is Identity Threat Detection and Response, ITDR, so one 00:02:47.800 --> 00:02:51.090 four-letter acronym. Maybe starting with you, 00:02:51.090 --> 00:02:54.600 Felix, is this a meaningful evolution in the IAM 00:02:54.600 --> 00:02:57.500 landscape, or is it just the next marketing-driven 00:02:57.500 --> 00:03:00.400 term, analyst-driven term? We are analysts, we are 00:03:00.400 --> 00:03:03.800 all analysts. FG Boy, ITDR, now that's a term that 00:03:03.800 --> 00:03:07.200 makes me want to reach for my buzzword bingo card, 00:03:07.200 --> 00:03:10.800 right? But before I get too cynical, let me give 00:03:10.800 --> 00:03:14.700 credit where it's due. The core idea behind Identity 00:03:14.700 --> 00:03:17.198 Threat Detection and Response is actually solid. 00:03:17.198 --> 00:03:19.800 We've been so focused on detecting malicious files 00:03:19.800 --> 00:03:22.781 and machine anomalies that we kind of forgot 00:03:22.781 --> 00:03:26.100 identities themselves, whether human or machines, 00:03:26.100 --> 00:03:32.000 because they can be the attack vendor. When someone compromises a user account or when a 00:03:32.000 --> 00:03:34.384 service account starts behaving weirdly, 00:03:34.384 --> 00:03:37.900 traditional SIEM tools often just see legitimate identities 00:03:37.900 --> 00:03:40.861 doing legitimate things. ITDR says, well, 00:03:40.861 --> 00:03:44.400 let's actually look at identity behavior patterns 00:03:44.400 --> 00:03:47.583 across the board. But here's exactly where 00:03:47.583 --> 00:03:51.600 vendor overreach and overhype kicks in hard. I swear, 00:03:51.600 --> 00:03:56.900 half of the vendors in the market just took their existing user behavior analytics, 00:03:56.900 --> 00:03:59.125 maybe added some machine identity monitoring, 00:03:59.125 --> 00:04:01.400 slapped ITDR on that box, and called it a day, 00:04:01.400 --> 00:04:03.738 right? Suddenly everyone's got an ITDR 00:04:03.738 --> 00:04:07.000 solution, even if it's just alerting you that a human 00:04:07.000 --> 00:04:13.600 logged in from a new location or an API key has made more calls than usual. But we need 00:04:13.600 --> 00:04:16.935 to admit that it is smart, because if you go to 00:04:16.935 --> 00:04:20.200 a German workers' council and say we introduce 00:04:20.200 --> 00:04:27.800 user behavior analytics, they will shout at you. If you say we introduce identity threat 00:04:27.800 --> 00:04:30.510 detection and response, they will say, oh, 00:04:30.510 --> 00:04:33.800 great, they help us improving our security posture. 00:04:33.800 --> 00:04:39.600 It's a positive thing. So from that perspective, even if it's just UBA, 00:04:39.600 --> 00:04:46.200 it's definitely a smarter term than UBA. I actually have not thought about this. I 00:04:46.200 --> 00:04:51.400 live in Germany for outside of Germany for 25 years. I'm not even allowed to vote anymore. 00:04:51.400 --> 00:04:57.500 And I completely forgot about that. You're right. The generally transformative piece, 00:04:57.500 --> 00:05:02.500 though, is when ITDR starts looking at relationships and patterns across your 00:05:02.500 --> 00:05:07.600 identities. This employee who normally acts financial systems is suddenly pulling HR data, 00:05:07.600 --> 00:05:11.800 or this service account that usually talks to, say, three databases now 00:05:12.600 --> 00:05:15.322 accessing the executive file shares on the drive, 00:05:15.322 --> 00:05:18.100 or even this human's credentials are being used to 00:05:18.100 --> 00:05:20.885 spawn machine workloads that they've never 00:05:20.885 --> 00:05:24.400 created before. So that cross identity correlation is 00:05:24.400 --> 00:05:28.700 where the real value lies, understanding how human or machine identities interact and 00:05:28.700 --> 00:05:31.593 spotting where those patterns go sideways. 00:05:31.593 --> 00:05:34.900 You still need to do a reality check. ITDR isn't 00:05:34.900 --> 00:05:39.800 some magical standalone discipline. I don't even think it's a market. It's really just 00:05:40.600 --> 00:05:44.600 identity where detection that should be integrated into your broader 00:05:44.600 --> 00:05:49.100 SOC operation. You're covering the whole spectrum of identities in your environment. 00:05:49.800 --> 00:05:52.741 This implementation, I've kind of seen as 00:05:52.741 --> 00:05:56.400 where it treats it as a lens through which you view 00:05:56.400 --> 00:06:01.400 all of your other telemetry, not necessarily as a separate ITDR silo. 00:06:01.800 --> 00:06:10.000 I think that it might be, or maybe a bit oversimplifying to just say we should 00:06:10.900 --> 00:06:14.362 integrate ITDR into the SOC operation, 00:06:14.362 --> 00:06:19.100 because there are two aspects in that go well beyond 00:06:20.100 --> 00:06:24.900 the typical SOC operation, which is very log, very event focused. 00:06:25.800 --> 00:06:30.300 The one thing is, or maybe three, the one is identity relationships. 00:06:31.100 --> 00:06:35.800 So we're looking at complex relationships you brought up in machine identities or 00:06:35.800 --> 00:06:39.700 non-human identities or workload identities, whatever we call it. Maybe we touch this a 00:06:39.700 --> 00:06:46.300 little later in the conversation. But anyway, I think this relationship thing is adding a 00:06:46.300 --> 00:06:50.200 certain level of complexity, and it's also something we haven't solved really well. 00:06:50.200 --> 00:06:56.000 The second element is that machine identities 00:06:56.000 --> 00:07:01.800 have, I would say, a complex ecosystem behind 00:07:01.800 --> 00:07:04.363 when you look at applications, the workloads 00:07:04.363 --> 00:07:07.100 and the applications and where these identities 00:07:07.100 --> 00:07:09.498 occur, et cetera. So then again, we have a bit 00:07:09.498 --> 00:07:12.000 more complexity. We also need to understand what 00:07:12.000 --> 00:07:14.777 is happening more from the development DevOps 00:07:14.777 --> 00:07:17.800 side. And the third thing is that identity threat 00:07:17.800 --> 00:07:24.100 detection response also has to do with the entitlements. So what is someone allowed to do? 00:07:24.100 --> 00:07:32.300 What are people actually doing, et cetera? I think to understand the threat, you need to 00:07:32.300 --> 00:07:35.050 understand entitlements. They can be, as we know, 00:07:35.050 --> 00:07:37.800 when you go to a whatever traditional SAP system, 00:07:37.800 --> 00:07:40.750 they can be fairly complex. And also we have a 00:07:40.750 --> 00:07:43.700 user group, which are more the identity people 00:07:43.700 --> 00:07:49.800 who need to understand what is going on with the use of identities and what does it mean 00:07:50.500 --> 00:07:57.400 for my static or the entitlements for my policies, whatever else. So I would say it's more 00:07:57.400 --> 00:08:00.178 than just a piece of software. And so I would dare 00:08:00.178 --> 00:08:02.900 to say, if you, for instance, and we saw a lot of 00:08:02.900 --> 00:08:07.300 vendors from the XDR space, which said we also can look at identity events. 00:08:07.300 --> 00:08:17.400 But that's not, I think it needs more than just saying XDR can consume these events. 00:08:19.000 --> 00:08:22.400 You're right about that. And you raise a really, 00:08:22.400 --> 00:08:25.800 really good point. I think we need to understand 00:08:25.800 --> 00:08:29.262 though, the difference between visibility 00:08:29.262 --> 00:08:33.400 versus observability. And that's where we need to 00:08:33.800 --> 00:08:39.800 look at ITDR as what it actually means, because it does mean detection and response. 00:08:41.400 --> 00:08:44.200 Talk a little bit about visibility versus observability, because I think this will make 00:08:44.200 --> 00:08:50.200 a lot of things clear. Real distinction that most people completely miss in IAM, but it's 00:08:50.200 --> 00:08:53.042 absolutely critical to understand the difference. 00:08:53.042 --> 00:08:56.000 Because visibility in IAM is like doing an autopsy, 00:08:56.000 --> 00:08:58.836 right? You're examining the static snapshot. 00:08:58.836 --> 00:09:01.800 You look at reports on who has access to what, 00:09:02.700 --> 00:09:06.800 you do these quarterly access reviews, you look at old assignments, frozen in time. 00:09:06.800 --> 00:09:10.412 It's asking what does our access look like right 00:09:10.412 --> 00:09:14.100 now? Or even what is the path to potentially more 00:09:14.100 --> 00:09:16.008 privilege? What is the potential attack 00:09:16.008 --> 00:09:18.600 surface? You're basically taking a photograph of your 00:09:18.600 --> 00:09:21.229 identity landscape while everything's standing 00:09:21.229 --> 00:09:23.800 still. But observability, that's watching the 00:09:23.800 --> 00:09:28.200 movie, not just looking at the poster. Observability is like seeing identities in motion. 00:09:28.200 --> 00:09:32.700 Who's actually authenticating? What are they accessing in real time? How are permissions 00:09:32.700 --> 00:09:37.800 used moment by moment? That's the difference between Sarah has database admin rights, 00:09:37.800 --> 00:09:40.343 and Sarah just executed 17 unusual database 00:09:40.343 --> 00:09:43.300 queries at 3 a.m. on Sunday from totally different 00:09:43.300 --> 00:09:45.429 locations. And of course, when we talk about 00:09:45.429 --> 00:09:47.800 machine, here's where it gets really interesting. 00:09:47.800 --> 00:09:50.526 Like with humans, visibility might be enough 00:09:50.526 --> 00:09:53.500 sometimes. You can ask Sarah why she was working 00:09:53.500 --> 00:09:56.885 late. But with machines, forget about it. It 00:09:56.885 --> 00:10:00.500 would be too late. Especially when you're three 00:10:00.500 --> 00:10:02.774 months or six months in the world for reviewing 00:10:02.774 --> 00:10:05.000 things. And anyway, only do rubber stamping in 00:10:05.000 --> 00:10:07.728 IGA because the certification process is far too 00:10:07.728 --> 00:10:10.400 complex to really understand what is asked for. 00:10:11.300 --> 00:10:14.417 So I think we need to go into an observability. 00:10:14.417 --> 00:10:17.600 That's where I fully agree with you. If we don't 00:10:17.600 --> 00:10:21.221 have that, we have a gap. And I think then the 00:10:21.221 --> 00:10:25.000 next challenge is how can we derive action? So a 00:10:25.000 --> 00:10:28.100 real response out of that. It reminds me a bit 00:10:28.100 --> 00:10:31.200 when we go back to the early days of what back 00:10:31.200 --> 00:10:34.038 in the days was called access governance, 00:10:34.038 --> 00:10:37.500 before you coined the term IGA. The early vendors, 00:10:37.500 --> 00:10:41.700 they allowed you to do reviews. And then you had a long list of things that are 00:10:42.400 --> 00:10:50.600 wrong or problematic, critical, whatever. But you didn't have an option to remediate that. 00:10:51.400 --> 00:10:54.224 And at some point, I think in the early days, 00:10:54.224 --> 00:10:57.300 it was a point of Alexa. They then came and said, 00:10:57.300 --> 00:11:01.800 Hey, we invented something great. And they basically finally came and asked you for a 00:11:01.800 --> 00:11:04.054 briefing more or less at the same point in time 00:11:04.054 --> 00:11:06.500 and said, we right now can sort of trigger actions. 00:11:07.300 --> 00:11:12.900 We can help you in really automatically or semi-automatically sort of fix the problem. 00:11:12.900 --> 00:11:22.200 And I think we need the same for ITDR. So I would say that the ITD part overall is 00:11:23.000 --> 00:11:29.000 so much better than the R. Yeah, there isn't much R. The R part is, let's send a log, 00:11:29.000 --> 00:11:32.400 let's open a ticket somewhere. Yes, but that's not a response. 00:11:32.900 --> 00:11:37.800 No, it isn't. I'm not going to disagree with you, Martin. I just think we need 00:11:37.800 --> 00:11:41.600 both parts. We need the visibility part and we need the observability part. And 00:11:41.600 --> 00:11:48.000 they're really different. Now, ITDR is such a big piece of hive that vendors sometimes, 00:11:48.000 --> 00:11:50.181 well, they call anything ITDR these days, 00:11:50.181 --> 00:11:53.000 whether it's doing some kind of observability or some 00:11:53.000 --> 00:11:58.600 kind of visibility or maybe a mixture. But I think it helps end-user organizations best if 00:11:58.600 --> 00:12:04.000 they think about both of them as discrete capabilities that you need to imagine. And 00:12:04.000 --> 00:12:06.696 part of them go a little bit outside the 00:12:06.696 --> 00:12:10.200 purview of what most IAM teams actually are. They're 00:12:10.200 --> 00:12:12.853 probably tools that are going to be more 00:12:12.853 --> 00:12:16.500 relevant for the SOC and others, not at all. Others are 00:12:16.500 --> 00:12:22.600 going to be very much in the purview of IAM teams. You need these two capabilities, these 00:12:22.600 --> 00:12:24.807 two distinct things, visibility and 00:12:24.807 --> 00:12:28.400 observability. But even in the IAM team, you need to have 00:12:28.400 --> 00:12:31.822 visibility and observability. And in the SOC 00:12:31.822 --> 00:12:35.400 team, you also need to have both. And I think, 00:12:35.400 --> 00:12:37.775 Uri comes in and you touched this already. When 00:12:37.775 --> 00:12:40.200 we look at, let's call it machine identities for 00:12:40.200 --> 00:12:44.350 now. When you look at that, then we also, anyway, 00:12:44.350 --> 00:12:48.500 in the space where the traditional human approach 00:12:48.500 --> 00:12:51.450 of visibility, like we have a recertification 00:12:51.450 --> 00:12:54.400 level, will work. Because these things change 00:12:54.400 --> 00:13:01.700 far too quickly. They may not exist three months after anymore. Way too many of these, 00:13:01.700 --> 00:13:06.600 et cetera. So it means we anyway need to go into automation. And then we move from this 00:13:06.600 --> 00:13:13.800 more static visibility into an observability, also with the need for a rapid response. 00:13:14.600 --> 00:13:21.400 Because when we have these relatively short-lived identities and what they can cause, 00:13:21.400 --> 00:13:29.700 then we need something which helps us to act way faster than we are obliged to do 00:13:29.700 --> 00:13:36.700 with traditional recertification processes in our IGA realm. 00:13:38.600 --> 00:13:42.254 Okay. I think most of that makes sense. I 00:13:42.254 --> 00:13:46.800 don't agree with one small point, though. And maybe 00:13:46.800 --> 00:13:49.150 we'll agree after I say this. Because you say 00:13:49.150 --> 00:13:51.500 that IAM teams, they need both visibility and 00:13:51.500 --> 00:13:53.846 observability. SOC teams also need visibility 00:13:53.846 --> 00:13:56.400 and observability. Let's start with the SOC team. 00:13:56.400 --> 00:13:59.224 They certainly need both and they can use 00:13:59.224 --> 00:14:02.600 both. Because if they just have the observability 00:14:02.600 --> 00:14:06.300 and then they actually need to investigate, they need the whole visibility of what is 00:14:06.300 --> 00:14:08.378 behind those things. And they also need to 00:14:08.378 --> 00:14:11.000 actually understand that. So that is absolutely true. 00:14:11.000 --> 00:14:19.100 Now with the IAM team, I'm not so sure whether observability is really the thing that they 00:14:19.100 --> 00:14:22.161 should prioritize. For one simple reason, if 00:14:22.161 --> 00:14:25.500 you're in the IAM team, are you working 24 by 7? 00:14:25.500 --> 00:14:27.750 Because if that's true, then for sure you can 00:14:27.750 --> 00:14:30.000 have observability. But if you find something 00:14:30.000 --> 00:14:36.200 at Sunday morning at 3 a.m. and the IAM team isn't there, then it's kind of pointless. 00:14:36.800 --> 00:14:46.900 Which would mean that you either need 24 by 7 in the IAM team, which is challenging. 00:14:48.500 --> 00:14:58.200 Or you need an IAM empowered SOC team that understands IAM specifics and machine 00:14:58.200 --> 00:15:01.732 identity specifics and many other things well 00:15:01.732 --> 00:15:05.500 beyond the common focus of what they are looking 00:15:05.500 --> 00:15:09.513 at. If you let me jump in there, ITDR for me 00:15:09.513 --> 00:15:13.800 also is the source for signals that can be used 00:15:13.800 --> 00:15:16.897 downstream in authentication authorization. I 00:15:16.897 --> 00:15:20.200 think that when you derive the R in that manner, 00:15:20.200 --> 00:15:22.881 when you understand, okay, there is something 00:15:22.881 --> 00:15:25.800 fishy, unexpected in authentication authorization 00:15:25.800 --> 00:15:32.600 processes, but this is fed by well-done intelligence resulting from an ITDR tool. 00:15:32.600 --> 00:15:39.500 Maybe the IAM teams can sleep at night and don't have to work at 24 by 7. So, 00:15:39.500 --> 00:15:42.020 this is really something that can be 00:15:42.020 --> 00:15:45.800 automated and really directly injected into viable and 00:15:45.800 --> 00:15:48.024 important processes downstream when the user 00:15:48.024 --> 00:15:50.400 interacts with the system. Isn't that a role of 00:15:50.400 --> 00:15:54.644 ITDR as well? Eventually. I think in the future, 00:15:54.644 --> 00:15:58.800 we might see more of that. I think the state of 00:15:58.800 --> 00:16:01.819 the art is that you don't really see this very 00:16:01.819 --> 00:16:05.100 much. I think the state of the current IAM affairs 00:16:05.100 --> 00:16:08.547 and ITDR is that they're selling to the wrong 00:16:08.547 --> 00:16:12.300 stakeholder. You can't really easily sell ITDR to 00:16:12.300 --> 00:16:14.876 the IAM team. You can impress them with some great 00:16:14.876 --> 00:16:17.400 demos and all of that, but at the end of the day, 00:16:17.400 --> 00:16:21.109 what Markin said is actually, I 100% agree to 00:16:21.109 --> 00:16:24.900 that. You have somebody from the IAM team that 00:16:24.900 --> 00:16:27.543 works with the SOC team, that acts as a 00:16:27.543 --> 00:16:31.000 bridge between those two, that educates them what's 00:16:31.000 --> 00:16:36.200 going on within the IAM space, that helps them understand how all of these things are tied 00:16:36.200 --> 00:16:39.662 together. But ITDR is actually selling to 00:16:39.662 --> 00:16:43.800 more of a SOC function than an IAM function. Now, 00:16:43.800 --> 00:16:49.500 visibility is a different thing. Visibility tools, they're definitely for the IAM team, 00:16:49.500 --> 00:16:51.463 but we don't really, I don't know what it's 00:16:51.463 --> 00:16:53.700 going to be called. I think my former colleagues, 00:16:54.400 --> 00:17:00.500 they've coined a new term now. Is it IVIP? Identity, visibility, something that could be. 00:17:01.100 --> 00:17:04.500 We've got other things like ISPM and all of that. 00:17:04.500 --> 00:17:07.900 I just prefer to call them visibility and hygiene 00:17:07.900 --> 00:17:11.083 tools. Actually, you may not even really need to 00:17:11.083 --> 00:17:14.200 buy a lot of tools because you probably already 00:17:14.200 --> 00:17:20.100 have a lot of things that you're not using correctly as an end user. Then perhaps you 00:17:20.100 --> 00:17:25.500 might make some point purchases to buy some additional things, but I think visibility is 00:17:25.500 --> 00:17:29.300 more like a capability. It's not so much like something that you can buy. 00:17:29.900 --> 00:17:33.300 Yeah, but to a certain extent, there's again a blurring line. 00:17:36.600 --> 00:17:44.900 One of the things I thought about when the first AI-backed identity analytics solutions 00:17:44.900 --> 00:17:48.400 came to the markets, then vendors said, okay, 00:17:48.400 --> 00:17:51.900 this helps you in identifying role candidates 00:17:51.900 --> 00:17:55.800 and other stuff. Some of that we did 20 years 00:17:55.800 --> 00:17:59.700 ago with Excel already, but what really would 00:17:59.700 --> 00:18:01.656 have been beneficial from the very beginning 00:18:01.656 --> 00:18:03.700 would have to say, okay, I look at everything, 00:18:03.700 --> 00:18:08.200 how data, so how entitlements are used, which entitlements are used by whom. 00:18:09.200 --> 00:18:14.600 That is basically something which is, I would dare to say, usually more gathered, 00:18:14.600 --> 00:18:18.500 information gathered at the observability side of things, but it flows back into, 00:18:19.200 --> 00:18:23.000 in that sense, the visibility because that is information that also helps us to understand 00:18:23.600 --> 00:18:28.500 which of the entitlements are not needed, which of the entitlements are only needed 00:18:28.500 --> 00:18:32.186 in certain scenarios, maybe at certain points 00:18:32.186 --> 00:18:36.200 in time, like whatever certain things that happen 00:18:36.200 --> 00:18:42.200 once a fiscal year, certain things that happen only during the summer break from 00:18:42.200 --> 00:18:49.500 maintenance in the OT environment or other things. Then we could use that to have less 00:18:49.500 --> 00:18:54.400 static entitlements, but also a partially dynamic assignment of entitlements. 00:18:56.200 --> 00:18:58.120 I think there's a strong intersection. The other 00:18:58.120 --> 00:19:00.000 thing that you brought up, I liked that really, 00:19:00.000 --> 00:19:05.500 was to whom to sell because the thing I had in mind just when you talked about that was, 00:19:05.500 --> 00:19:08.336 at the end of the day, what we are currently 00:19:08.336 --> 00:19:11.300 discussing, I would say, reconfirms one of the 00:19:11.300 --> 00:19:15.317 things I tell for quite a while, and that is 00:19:15.317 --> 00:19:19.700 IAM belongs in the realm of modern first line of 00:19:19.700 --> 00:19:24.620 defense CISO. So IAM belongs there. We could 00:19:24.620 --> 00:19:30.100 talk about the term identity security, which is a 00:19:30.600 --> 00:19:41.400 very fuzzy term. I know that you have strong opinions on that term, but I think there's a 00:19:41.400 --> 00:19:45.900 certain intersection there and it makes a ton of sense to have identity management, 00:19:46.800 --> 00:19:50.050 in the broader definition of identity management, 00:19:50.050 --> 00:19:53.300 as part of the domain of the CISO. Then you have, 00:19:53.300 --> 00:19:57.200 at the end of the day, that one buyer's persona where everything comes together. 00:19:58.100 --> 00:20:01.016 If I can just summarize what you said and 00:20:01.016 --> 00:20:04.500 what we kind of discussed, I think ITTR is really 00:20:04.500 --> 00:20:10.600 misleading for many organizations, and people are really confused. IAM teams are thinking, 00:20:10.600 --> 00:20:13.050 do I need ITTR because everyone's talking about 00:20:13.050 --> 00:20:15.500 it? But then again, they're not prepared for 24 00:20:15.500 --> 00:20:18.450 by 7. If you're not prepared for 24 by 7, you 00:20:18.450 --> 00:20:21.400 cannot do detection and response. This is the 00:20:21.400 --> 00:20:23.750 fact, right? It's like if something happens and 00:20:23.750 --> 00:20:26.100 they call you up, no, sorry, Mr. Cooper is at a 00:20:26.100 --> 00:20:28.013 meeting, right? You can't respond to it, 00:20:28.013 --> 00:20:30.500 right? You don't even have an incident response plan 00:20:30.500 --> 00:20:34.392 for those people to do it. So the capabilities 00:20:34.392 --> 00:20:38.200 for the IAM team are mostly around visibility 00:20:38.200 --> 00:20:40.850 and perhaps additional data that tells you how 00:20:40.850 --> 00:20:43.500 entitlements are being used. And when will you 00:20:43.500 --> 00:20:49.800 use that? You're obviously not going to use this for some detection of immediate response, 00:20:49.800 --> 00:20:52.367 at least not now, but you'll probably use it 00:20:52.367 --> 00:20:55.400 when you have your next attestation run, or when you 00:20:55.400 --> 00:20:59.600 have some kind of procedure that looks at these things, or when you have some 00:20:59.600 --> 00:21:02.537 prioritized finding that bubbles up and says, 00:21:02.537 --> 00:21:05.800 hey, while you were happily enjoying your weekend, 00:21:05.800 --> 00:21:10.500 something weird happened here with Matias' account. Are you sure Matias still requires 00:21:10.500 --> 00:21:12.450 these things? Let's do like a micro attestation 00:21:12.450 --> 00:21:14.400 right now and not wait till the next quarter or 00:21:14.400 --> 00:21:17.255 something like that. For sure. I think that's 00:21:17.255 --> 00:21:20.300 probably in the scope for IAM teams. And I think 00:21:21.800 --> 00:21:24.553 the whole segmentation is not very helpful 00:21:24.553 --> 00:21:27.700 for end users at this point in time. It will get 00:21:27.700 --> 00:21:35.800 hopefully better. Yeah. When I think a little bit further, a lot of SOC services are not 00:21:36.600 --> 00:21:45.700 provided internally. When I think about that, you have a managed service provider, 00:21:45.700 --> 00:21:51.100 there's a rather standardized type of offering, and you have this very bespoke 00:21:52.600 --> 00:22:00.300 world of excellent entitlements, identity relationships related to applications. 00:22:00.300 --> 00:22:06.700 You can also take the SAP sort of threat intelligence, threat detection tools 00:22:06.700 --> 00:22:14.400 into that, where you also have a lot of specifics. Then this becomes a pretty interesting 00:22:14.400 --> 00:22:20.200 challenge, how to enable your SOC teams to come up with well-lit analyzers, well-lit 00:22:20.900 --> 00:22:26.100 potential incidents, well-lit detections at the end of the day, and how to handle that 00:22:26.900 --> 00:22:30.400 in a meaningful manner. So how to act fast when 00:22:30.400 --> 00:22:33.900 it's needed, with the IAM specialists not being 00:22:33.900 --> 00:22:38.054 on 24-7, and maybe, so to speak, two steps 00:22:38.054 --> 00:22:43.000 away. So the MSP, to the security, to the identity 00:22:43.000 --> 00:22:47.700 people. So I think we will need to think a lot about organizational setup for that. 00:22:48.300 --> 00:22:54.700 100 percent. We are not prepared for it yet. 100 percent. A lot of teams are doing IAM, 00:22:54.700 --> 00:23:01.300 not just the IAM team. And the question is, how do you make all of this happen in this 00:23:01.300 --> 00:23:05.800 energetic and not in a counterproductive way? Same thing is happening with machine IDs. 00:23:05.800 --> 00:23:10.100 Yeah. Look at where Microsoft EnterID is located in many organizations. 00:23:10.100 --> 00:23:16.400 Or even Active Directory, back in the day. I think EnterID is easier, because I think 00:23:16.400 --> 00:23:19.038 for EnterID as an authentication system, 00:23:19.038 --> 00:23:22.600 there's absolutely no doubt that it belongs to the IAM 00:23:22.600 --> 00:23:25.745 team. For Active Directory, you have a little 00:23:25.745 --> 00:23:29.100 bit of an infrastructure element and crew policy 00:23:29.100 --> 00:23:31.667 objects, which are sort of device-focused. 00:23:31.667 --> 00:23:34.600 You may argue a little bit, but I say for years, 00:23:35.300 --> 00:23:38.317 also Active Directory belongs to the IAM team. 00:23:38.317 --> 00:23:41.400 And for EnterID, I would dare to say everything 00:23:42.200 --> 00:23:50.100 else is just raw. So now I jump in again, because we agreed that before we change topics, 00:23:50.100 --> 00:23:56.300 that we have some kind of final thoughts or recommendations. So we realized that ITDR is 00:23:56.300 --> 00:23:59.050 often not yet well understood. It's not yet well 00:23:59.050 --> 00:24:01.800 integrated. But we have two analysts in the room 00:24:01.800 --> 00:24:06.600 who can make recommendations. So let's get to recommendations. What would you recommend to 00:24:06.600 --> 00:24:10.200 organizations who really maybe even bought an ITDR 00:24:10.200 --> 00:24:13.800 product, whatever that means? And what should they 00:24:13.800 --> 00:24:17.589 do to leverage these tools better? What would be 00:24:17.589 --> 00:24:21.300 a first step? So the real first recommendation, 00:24:21.800 --> 00:24:23.200 Felix, maybe you want to start? 00:24:24.700 --> 00:24:27.700 Well, if you already bought an ITDR tool, that's 00:24:27.700 --> 00:24:30.700 not a really good situation to buy something and 00:24:30.700 --> 00:24:32.754 then figure out what are you going to do with 00:24:32.754 --> 00:24:34.900 it, right? I'd rather answer it from the point, 00:24:34.900 --> 00:24:36.911 well, what if you don't have these 00:24:36.911 --> 00:24:40.400 capabilities? And I would say, start with visibility first, 00:24:40.400 --> 00:24:43.600 because visibility helps you to establish proper 00:24:43.600 --> 00:24:46.800 hygiene within your IAM stack. If you don't have 00:24:46.800 --> 00:24:50.500 the proper hygiene, then you're going to likely 00:24:50.500 --> 00:24:54.200 face potential breaches or potential attacks or 00:24:54.200 --> 00:24:57.012 just some events that you could have totally 00:24:57.012 --> 00:25:00.400 prevented in the first place. So I think preventative 00:25:00.400 --> 00:25:02.875 is always a good thing. And I would perhaps start 00:25:02.875 --> 00:25:05.400 by shoring those things up over there. Once you do 00:25:05.400 --> 00:25:11.400 that and then you get to detection, I would look at the use case that Marjan already 00:25:11.400 --> 00:25:15.139 suggested, which is analysis of events over time 00:25:15.139 --> 00:25:18.800 that may cause you to look at your posture, for 00:25:18.800 --> 00:25:23.800 example, by tweaking entitlements for a particular account. I wouldn't necessarily go into 00:25:23.800 --> 00:25:27.032 detection and response until you're ready to really 00:25:27.032 --> 00:25:30.200 have that fundamental discussion with your SOC and 00:25:30.200 --> 00:25:33.550 see how you can inject IAM in there. Or perhaps 00:25:33.550 --> 00:25:36.900 they're going to approach you because they need 00:25:36.900 --> 00:25:40.144 your help as an IAM leader to do that. I 00:25:40.144 --> 00:25:44.200 think that's a part of everything Felix said here. 00:25:45.700 --> 00:25:49.517 Maybe to add or maybe emphasize a bit, the one 00:25:49.517 --> 00:25:53.500 thing is start with thinking about capabilities. 00:25:53.500 --> 00:25:55.572 Don't start with thinking about tool categories 00:25:55.572 --> 00:25:57.600 or anything else. I think when you look at our 00:25:57.600 --> 00:26:04.200 Identity Fabric, there's a reason why the Identity Fabric goes from capabilities to 00:26:05.100 --> 00:26:08.450 services, which are sets of capabilities, to tools 00:26:08.450 --> 00:26:11.800 which actually deliver that. You should start with 00:26:11.800 --> 00:26:15.100 the capabilities and then you should think about what do you need, what do you have, 00:26:16.100 --> 00:26:22.700 what is missing, do you need what is missing, and when can you realistically implement it, 00:26:22.800 --> 00:26:30.100 what are the prerequisites for doing so. I think today we discussed some interesting 00:26:31.100 --> 00:26:41.800 prerequisites here when it comes down to organizational readiness for certain 00:26:41.800 --> 00:26:44.296 capabilities. That means I think there's a lot 00:26:44.296 --> 00:26:46.900 of thinking about what is the right organization 00:26:47.600 --> 00:26:55.700 for that entire stack. How do you build interfaces between IAM and clearly also 00:26:55.700 --> 00:26:58.329 the security development teams, but especially 00:26:58.329 --> 00:27:00.900 the security teams, even more when you have a 00:27:00.900 --> 00:27:05.700 managed service provider in there or an MSSP, managed security services provider in there 00:27:06.600 --> 00:27:13.100 running the SOC. Then you need to have very well-thought-out approaches for that. 00:27:13.700 --> 00:27:16.291 Then I think also part of that is clearly to 00:27:16.291 --> 00:27:19.000 understand who, so to speak, has the knowledge 00:27:19.000 --> 00:27:21.661 about what, where is a knowledge transfer 00:27:21.661 --> 00:27:25.100 needed, and who's the recipient of which information. 00:27:25.800 --> 00:27:29.500 Last but least, I think we should think about 00:27:29.500 --> 00:27:33.200 how can we make this entire thing actionable, 00:27:33.200 --> 00:27:36.253 so not just ending up with a long list of 00:27:36.253 --> 00:27:40.200 things that are suspicious, but understanding what is 00:27:40.200 --> 00:27:47.100 a real challenge and being able to address this on time. That will be at the end. 00:27:47.800 --> 00:27:54.900 That's where we need to move towards. Minimizing the number of things we need to look at, 00:27:54.900 --> 00:27:57.500 but having the right ones in front of us where 00:27:57.500 --> 00:28:00.100 we say, okay, and this is where we really need 00:28:00.100 --> 00:28:02.396 to take an action. We need to sometimes take 00:28:02.396 --> 00:28:04.900 it very fast, especially when we could go beyond 00:28:04.900 --> 00:28:10.200 the world of humans into the world of all the other types of identities or their related 00:28:10.200 --> 00:28:17.400 identities, because then it's about automation. This is where I jump in with my chance to 00:28:17.400 --> 00:28:24.600 actually start my second questions after 30 minutes. That's nice, and it's an important 00:28:24.600 --> 00:28:27.500 question. We want to look at a topic that even 00:28:27.500 --> 00:28:30.400 is difficult to give a name because even names 00:28:30.700 --> 00:28:36.600 are disputed right now, but I think it's not necessarily necessary because we want to talk 00:28:36.600 --> 00:28:42.300 about machine identity, non-human identity, workload identity, everything that goes into 00:28:43.000 --> 00:28:45.967 that bucket. There are a lot of bright people 00:28:45.967 --> 00:28:49.000 writing clever stuff, and Felix is among them. 00:28:49.000 --> 00:28:54.400 If you follow him on LinkedIn, there's a lot of interesting stuff to follow up on there. 00:28:54.400 --> 00:28:56.876 Of course, I have to mention that Köppinger told 00:28:56.876 --> 00:28:59.300 us this as well, but there's really interesting 00:28:59.300 --> 00:29:04.400 reason around that. When we turn to machine identities, let's look at their operational 00:29:04.400 --> 00:29:08.013 reality. First, the term or non-human identities, 00:29:08.013 --> 00:29:11.700 and then the operation reality. This is the second 00:29:11.700 --> 00:29:16.800 buzzword that we're looking into, of course, but this buzzword has an actual core to it. 00:29:18.900 --> 00:29:21.804 I think I started with Felix earlier, so I 00:29:21.804 --> 00:29:25.400 start with Martin. First thoughts on how to actually 00:29:25.400 --> 00:29:32.200 deal with all these non-human related identities in terms of non-human control at runtime? 00:29:32.700 --> 00:29:41.700 Yeah. I think we should be very, very careful with terminology here. The one thing is that 00:29:41.700 --> 00:29:49.400 there's always this risk of endless disputes, which at the end will not result in a full 00:29:49.400 --> 00:29:56.900 agreement. The second thing is in this NHI read-down, there's such a huge or wide range 00:29:56.900 --> 00:29:59.917 of identities that we can't treat them all the 00:29:59.917 --> 00:30:03.000 same, unless we go very generic and say there's 00:30:03.000 --> 00:30:10.700 an identity, and we treat every identity the same way. Clearly, there are identities like 00:30:12.300 --> 00:30:17.800 functional accounts, so technical accounts, traditional ones we have for decades that are 00:30:17.800 --> 00:30:22.904 very close to any of their characteristics to a 00:30:22.904 --> 00:30:27.900 human identity. Then we have AI bots with very 00:30:27.900 --> 00:30:31.570 different types of identities. If you go to an 00:30:31.570 --> 00:30:35.400 IIoT thing, the thing is already in the acronym, 00:30:35.400 --> 00:30:39.400 so Internet of Things, so it's a really very technical thing. They are also, again, 00:30:39.400 --> 00:30:45.400 fairly different, for instance, from what we have in the software development space. 00:30:46.000 --> 00:30:50.900 It is not that we can easily differentiate here. I think the best thing probably is to 00:30:52.900 --> 00:30:55.350 not spend too much time on terminology. I think 00:30:55.350 --> 00:30:57.800 we need a little bit of clarification, clearly, 00:30:58.400 --> 00:30:59.907 at least when we go into concrete 00:30:59.907 --> 00:31:02.600 conversation. I think it's always good advice to say, okay, 00:31:02.600 --> 00:31:05.400 what exactly are we talking about? Now, is it 00:31:05.400 --> 00:31:08.200 this or this or this? But until then, I think 00:31:08.200 --> 00:31:13.000 the terminology war, it's not a war at the end of the day. Fortunately, it doesn't help us 00:31:13.900 --> 00:31:17.800 much. I think it's an understanding that there are new challenges arising 00:31:18.700 --> 00:31:20.661 that we need to deal with. I think there are 00:31:20.661 --> 00:31:22.800 some obvious challenges. One challenge is scale. 00:31:23.700 --> 00:31:26.681 The other is, I would say, the volatility. These 00:31:26.681 --> 00:31:29.600 identities change much faster than many others, 00:31:29.600 --> 00:31:32.521 but if you go to the consumer space, you also have 00:31:32.521 --> 00:31:35.500 a lot of short-lived identities. On the human side, 00:31:35.500 --> 00:31:38.516 it also may happen, but I think it's a bit of 00:31:38.516 --> 00:31:41.600 a characteristic here. I think we, again, have 00:31:41.600 --> 00:31:45.300 other players in. By the way, the same would happen when we started with consumer identity 00:31:45.300 --> 00:31:52.800 management. We had more identities, they had different life cycles, and there were other 00:31:52.800 --> 00:31:56.250 owners of them. In that sense, it's, again, not 00:31:56.250 --> 00:31:59.700 so different, but I think we need to understand 00:32:00.200 --> 00:32:06.500 how to deal with that, how to mitigate the risks associated with them. 00:32:07.200 --> 00:32:08.200 Stay Forever 00:32:08.200 --> 00:32:13.400 Handing over to Felix, your thoughts. Both of you are very outspoken on what you consider 00:32:13.400 --> 00:32:17.900 important. Just one thought from my side. I think one issue with NHI is that we put 00:32:17.900 --> 00:32:19.871 things in there that should have been taken care 00:32:19.871 --> 00:32:21.800 of for decades, as Martin mentioned – technical 00:32:21.800 --> 00:32:25.900 accounts, service accounts, system accounts. Just because you have not managed them yet 00:32:25.900 --> 00:32:29.800 properly, don't put them in the NHI bucket. Stay Forever 00:32:30.700 --> 00:32:37.700 Personally, I think that NHI is a really sloppy term. I still don't like the term. 00:32:42.500 --> 00:32:47.200 This term is being thrown around to describe accounts, credentials, 00:32:47.200 --> 00:32:52.500 identifiers, but they're not the same thing. Identity is not an account and it's not a 00:32:52.500 --> 00:32:57.281 credential. We're mixing up fundamental 00:32:57.281 --> 00:33:03.900 concepts. I've started using the term recently because 00:33:05.800 --> 00:33:09.887 it's used predominantly to denote static 00:33:09.887 --> 00:33:15.200 identity constructs for machines. That's really what 00:33:16.000 --> 00:33:21.300 someone means when they say NHI. I need to manage my NHIs. They're not talking about 00:33:21.300 --> 00:33:23.804 microchipping your dogs and cats and giving 00:33:23.804 --> 00:33:26.600 them an RFID identity, which is also a non-human 00:33:26.600 --> 00:33:32.500 identity database, or managing a legal entity identifier for your organization. That's not 00:33:32.500 --> 00:33:35.237 really what they refer to. They very 00:33:35.237 --> 00:33:39.800 specifically talk about API keys, service accounts, and some 00:33:39.800 --> 00:33:44.200 other static identity constructs for that. What Martin said before, I think he said, 00:33:44.200 --> 00:33:46.540 was the difference between how we manage 00:33:46.540 --> 00:33:49.700 identity for humans and for machines. I think the main 00:33:49.700 --> 00:33:54.800 difference, I would actually put them into a few things. First one, and this is a really, 00:33:54.800 --> 00:34:01.400 really important one, machines don't necessarily need accounts. This is a super important 00:34:01.400 --> 00:34:03.471 clarification. Think about it. You have a 00:34:03.471 --> 00:34:06.400 container that spins up. An identity is created for it. On 00:34:06.400 --> 00:34:08.694 the fly, the container terminates, poof, the 00:34:08.694 --> 00:34:11.300 identity vanishes. No orphaned accounts cluttering 00:34:11.300 --> 00:34:13.826 your directory. This is actually a very good way 00:34:13.826 --> 00:34:16.300 to do it in a femoral way. The second thing is, 00:34:16.300 --> 00:34:18.696 forget multi-factor authentication for 00:34:18.696 --> 00:34:22.100 machines, because they can't use MFA. You can't really 00:34:22.100 --> 00:34:26.600 secure them by storing credentials for them at all, where they have access to it. Instead, 00:34:26.600 --> 00:34:29.123 you need to generate these one-time credentials 00:34:29.123 --> 00:34:31.700 on the fly when the machine gets up. That's also 00:34:31.700 --> 00:34:36.600 where it gets really messy, because most organizations are doing this completely wrong. 00:34:36.600 --> 00:34:40.300 They're treating machines like humans, and then they create accounts, and assign owners, 00:34:40.300 --> 00:34:42.699 store credentials in a vault, to have a status, 00:34:42.699 --> 00:34:45.200 whether we still need an individual decommission. 00:34:45.300 --> 00:34:48.028 It's totally backwards. It's also, unfortunately, 00:34:48.028 --> 00:34:50.700 driven by vendors that call themselves non-human 00:34:50.700 --> 00:34:52.519 identity vendors, or workload identity 00:34:52.519 --> 00:34:55.200 management vendors, how we used to call them at Gartner. 00:34:55.800 --> 00:34:58.929 That's what they sell. They prefer you do it 00:34:58.929 --> 00:35:02.200 in the old way, because the more legacy static 00:35:02.200 --> 00:35:04.476 identity constructs you use, the more money you 00:35:04.476 --> 00:35:06.800 have to pay for them, the more you get dependent 00:35:06.800 --> 00:35:09.436 on them. The better way is actually, if we're 00:35:09.436 --> 00:35:12.600 going to use that NHI term the way it was intended, to 00:35:12.600 --> 00:35:15.377 try to get rid of your NHIs. Get rid of them. 00:35:15.377 --> 00:35:18.400 Eliminate NHIs. Exchange them for something else. 00:35:18.400 --> 00:35:20.668 You probably can't get rid of 100 percent of 00:35:20.668 --> 00:35:23.400 them, but you could probably get rid of 80 percent of 00:35:23.400 --> 00:35:26.491 your NHIs, or 75 percent. This, by the way, 00:35:26.491 --> 00:35:30.300 hints already on a challenge, that most of NHI is not 00:35:31.100 --> 00:35:38.100 NHI. It's because, I think in that sense… Exactly. It's a very sloppy term. 00:35:38.100 --> 00:35:46.400 It's more the secret that is handled than an identity. We could go back to this discussion 00:35:46.400 --> 00:35:50.900 about identity versus users, etc. Sure. We're going to bore people to death. 00:35:51.400 --> 00:35:57.000 We could do that. Yeah, but I think terminology in that sense is important 00:35:57.600 --> 00:35:59.759 to make clear what we are talking about. There 00:35:59.759 --> 00:36:02.200 are then constructs which we must not underestimate. 00:36:02.200 --> 00:36:07.400 We have an application which consists of a range of modules with a ton of APIs. There are 00:36:07.400 --> 00:36:09.406 relationships and there are developers who are 00:36:09.406 --> 00:36:11.500 responsible for certain elements that are owners 00:36:11.500 --> 00:36:16.004 of the entire application. We have a relationship 00:36:16.004 --> 00:36:20.600 challenge. We may end up with services that access 00:36:20.600 --> 00:36:23.354 resources in the cloud. We have these 00:36:23.354 --> 00:36:27.300 relationships, but I think we are not really precise. 00:36:28.300 --> 00:36:31.100 I think Matthias has been writing about it as 00:36:31.100 --> 00:36:33.900 well, already in our blog. I think we had one 00:36:34.500 --> 00:36:40.100 or two podcast episodes already on that. I think we need more preciseness. Yes, 00:36:40.100 --> 00:36:43.800 I think it's obviously a good idea and something where we are very much on the same page. 00:36:47.000 --> 00:36:54.500 It's very worse to think about how can we handle challenges by not trying to map them to a 00:36:55.300 --> 00:36:58.381 concept that hasn't been built for this use case. 00:36:58.381 --> 00:37:01.400 The traditional workforce identity use case is a 00:37:02.000 --> 00:37:05.838 very different one than we are talking about here. 00:37:05.838 --> 00:37:09.600 Trying to map this to an identity to user account 00:37:10.300 --> 00:37:14.232 to entitlement schemes approach just might be 00:37:14.232 --> 00:37:18.600 wrong. It is. It is actually a very legacy pattern 00:37:18.600 --> 00:37:22.200 and we really strike out with it. It is creating 00:37:22.200 --> 00:37:25.800 so many problems. The question, of course, is if 00:37:25.800 --> 00:37:27.879 we're talking to IAM teams, you can probably 00:37:27.879 --> 00:37:30.100 convince them, but that's not where the problem 00:37:30.200 --> 00:37:32.800 is caused. The problem is if you go out on the 00:37:32.800 --> 00:37:35.400 street, the people that throw their garbage on 00:37:35.400 --> 00:37:37.395 the street, that's actually where it happens. 00:37:37.395 --> 00:37:39.700 It's done at software development, at infrastructure 00:37:39.700 --> 00:37:41.721 and operations. That's where these things may be 00:37:41.721 --> 00:37:43.700 created. Probably not so much at infrastructure 00:37:43.700 --> 00:37:45.509 and operations because they probably tend to 00:37:45.509 --> 00:37:47.400 do the right things nowadays with cloud-native 00:37:47.400 --> 00:37:52.200 approaches, but application and development, application and installation, the classics, 00:37:52.200 --> 00:37:57.400 for sure. You raise a really good point. I always like to make this analogy. 00:37:57.400 --> 00:37:59.366 We talk about non-humans. Let's talk about 00:37:59.366 --> 00:38:01.800 cats. You've got two cats born at the same time from 00:38:01.800 --> 00:38:04.295 the same litter. They look the same, kind of, 00:38:04.295 --> 00:38:06.900 almost. They almost look identical, but you can 00:38:06.900 --> 00:38:09.563 still tell them apart because each of them has 00:38:09.563 --> 00:38:12.400 their own unique identity. This one has a bushier 00:38:12.400 --> 00:38:14.508 tail. This one here is a little more playful 00:38:14.508 --> 00:38:17.000 than the other. The other one is maybe a little more 00:38:17.000 --> 00:38:19.658 reserved. That's because each of them has 00:38:19.658 --> 00:38:22.900 their unique identity. You can use identifiers and 00:38:22.900 --> 00:38:24.765 attributes to describe really what makes the 00:38:24.765 --> 00:38:26.800 difference. This is the same thing for machines. 00:38:27.800 --> 00:38:31.200 You have two containers, but they're launched from the identical image. 00:38:32.500 --> 00:38:35.177 So, you get exact copies of the same service, but 00:38:35.177 --> 00:38:37.800 still, they're different. They have different IP 00:38:37.800 --> 00:38:42.300 addresses. They have different container IDs. If you can describe what makes them unique, 00:38:42.300 --> 00:38:44.529 you've defined their identities. That's 00:38:44.529 --> 00:38:47.500 actually where people get really confused because an 00:38:47.500 --> 00:38:50.444 account is not the same as an identity. An 00:38:50.444 --> 00:38:54.300 account is just a registry entry on some kind of system 00:38:54.300 --> 00:38:56.423 for a particular identity. The ugly way is 00:38:56.423 --> 00:38:59.000 taking those two containers and creating one static 00:38:59.000 --> 00:39:00.895 account for both, stick the credential in the 00:39:00.895 --> 00:39:03.000 secrets manager, and boom, you've just implemented 00:39:03.000 --> 00:39:09.500 a terrible legacy pattern. A more elegant way could be to use something such as Spiffy to 00:39:09.500 --> 00:39:12.035 assign each container a unique service ID on 00:39:12.035 --> 00:39:14.800 the fly and let them use that for system access. 00:39:14.900 --> 00:39:16.950 Suddenly, your observability is crystal clear 00:39:16.950 --> 00:39:19.000 because you know exactly which container does 00:39:19.000 --> 00:39:23.900 what and where and when. That's actually the difference between managing accounts 00:39:23.900 --> 00:39:27.255 and managing identity. That's the move from 00:39:27.255 --> 00:39:31.000 legacy credential juggling and NHI management to 00:39:31.700 --> 00:39:34.950 modern machine IAM. I always like to say, your 00:39:34.950 --> 00:39:38.200 cats, they don't share the same label on their 00:39:38.200 --> 00:39:40.647 food bowl, so why should your containers share 00:39:40.647 --> 00:39:43.200 static credentials? It really doesn't make sense 00:39:43.200 --> 00:39:46.382 there either. I remember Matthias and me having 00:39:46.382 --> 00:39:49.700 been in an interesting project a longer time ago, 00:39:49.700 --> 00:39:55.700 and we touched a wide range of identities, including identities for real things, real 00:39:55.700 --> 00:40:01.000 machines, and other stuff. Sometimes really big things which consist of a lot of things. 00:40:01.800 --> 00:40:06.900 What really was interesting then to see how, I would say, the legacy approaches 00:40:07.800 --> 00:40:11.065 of assigning identities, managing secrets, etc. 00:40:11.065 --> 00:40:14.400 basically failed. Because at the end of the day, 00:40:14.400 --> 00:40:17.938 for some of these environments, the only thing 00:40:17.938 --> 00:40:21.400 they could manage a bit was, so to speak, the 00:40:21.400 --> 00:40:24.976 joiner process in that sense. But anything which 00:40:24.976 --> 00:40:28.700 went beyond that renewal of whatever keys or stuff 00:40:28.800 --> 00:40:33.404 like that, it really got ugly. I think we really 00:40:33.404 --> 00:40:38.200 must be careful of applying traditional approaches 00:40:38.200 --> 00:40:41.900 to everything. I think there's this tendency, we started this workforce IAM, 00:40:42.600 --> 00:40:48.900 so a lot of things are applying this concept. I think there's another analogy which 00:40:49.400 --> 00:40:53.119 really made me think. That was when we look at 00:40:53.119 --> 00:40:57.000 SSL TLS certificates and their reduced lifetime. 00:40:58.000 --> 00:41:06.400 Then it basically is, we still stick to an established approach, and we try to fix 00:41:07.100 --> 00:41:14.300 a challenge by saying, okay, we go down to whatever, 30 days then, to reduce the risk. 00:41:14.300 --> 00:41:17.595 But it doesn't at all solve the root challenge, 00:41:17.595 --> 00:41:21.100 the root problem we have, which would be how could 00:41:21.100 --> 00:41:26.500 we come to an ephemeral approach instead of a static approach. 00:41:28.400 --> 00:41:32.500 Exactly. But the thing is, these ephemeral approaches, they exist, they work, they're 00:41:32.500 --> 00:41:35.382 actually being pervasively used. Who are we 00:41:35.382 --> 00:41:38.600 actually talking to? Who's going to be listening 00:41:38.600 --> 00:41:42.150 to these episodes over here? Because if it's the 00:41:42.150 --> 00:41:45.700 IAM team, then they may actually not be the ones 00:41:45.700 --> 00:41:48.350 in the position to solve this. This is actually 00:41:48.350 --> 00:41:51.000 the most frustrating thing I see in this market 00:41:51.000 --> 00:41:53.700 right now. Who is responsible for machine IAM? 00:41:53.700 --> 00:41:56.400 IAM teams are basically missing an action when 00:41:56.400 --> 00:42:01.300 it comes to machine. This is creating this massive leadership back here. Here's what's 00:42:01.300 --> 00:42:04.200 actually happening on the ground. You've got the infrastructure engineers who are 00:42:04.200 --> 00:42:08.600 spinning up containers. They need those workloads to authenticate to databases. 00:42:08.600 --> 00:42:10.557 As you mentioned, they should be doing this in 00:42:10.557 --> 00:42:12.600 an ephemeral way. So what do they do? They might 00:42:12.600 --> 00:42:14.802 call up the IAM team and say, hey, how do I do 00:42:14.802 --> 00:42:17.100 this security? You know what they get back? They 00:42:17.100 --> 00:42:19.474 get back radio silence. If they're lucky. 00:42:19.474 --> 00:42:22.600 Because maybe if they're unlucky, someone from the IAM 00:42:22.600 --> 00:42:24.682 team says, ah, just create a service account 00:42:24.682 --> 00:42:27.000 and stick the password involved somewhere. That's 00:42:27.000 --> 00:42:29.704 not leadership. That's application. At least 00:42:29.704 --> 00:42:32.900 it's a proven mistake. We're doing that for decades. 00:42:32.900 --> 00:42:36.500 I know. But this is application. It's not leadership. 00:42:36.500 --> 00:42:39.289 Yeah. I always say, if you use a functional or 00:42:39.289 --> 00:42:42.200 technical account that way, then you already did 00:42:42.200 --> 00:42:47.000 something wrong. You can do it. And we could do it, could have done it better for decades. 00:42:48.600 --> 00:42:51.450 That's the bad thing. On the other hand, I think 00:42:51.450 --> 00:42:54.300 there's a role for the IAM team in that. Because 00:42:55.100 --> 00:43:01.700 I think when we look at infrastructure development identity, then all are domains 00:43:01.700 --> 00:43:09.100 that require quite some expertise, specific expertise. And most identity people are not 00:43:10.100 --> 00:43:12.397 very good developers. And they are also 00:43:12.397 --> 00:43:15.400 usually not very good infrastructure people. Always 00:43:15.400 --> 00:43:18.257 exceptions there. Same for infrastructure. Not 00:43:18.257 --> 00:43:21.300 necessarily good developers, not necessarily good 00:43:22.000 --> 00:43:27.300 identity people. Developers, they do not even want to care about security. 00:43:28.100 --> 00:43:34.600 Or so they just want to solve a certain challenge, to build a certain software. And 00:43:35.300 --> 00:43:44.600 so I think the art is to figure out how can identity deliver for the IAM world, deliver 00:43:44.600 --> 00:43:48.200 services for the others to work like the others 00:43:48.200 --> 00:43:51.800 want it and need it. I think this is the point. 00:43:51.800 --> 00:43:54.513 So if you take the everything or infrastructure 00:43:54.513 --> 00:43:57.400 as code things, they also caused a lot of security 00:43:57.400 --> 00:44:01.343 challenges because things were coded in there. 00:44:01.343 --> 00:44:05.200 We see still ways where whatever API keys are 00:44:05.800 --> 00:44:09.262 shared and securely, because I think there are 00:44:09.262 --> 00:44:12.800 different domains and we should do it that way. 00:44:12.800 --> 00:44:18.200 But that requires, I would say, a thorough understanding and collaboration of the IAM's 00:44:18.200 --> 00:44:24.900 three different parties. And only that way it will work. And then it must be a very much 00:44:24.900 --> 00:44:26.927 service-driven approach, which doesn't limit, 00:44:26.927 --> 00:44:29.000 which doesn't lead to situations where someone 00:44:29.000 --> 00:44:32.864 says, no, you can't deploy an Azure Key Vault 00:44:32.864 --> 00:44:36.900 because we already have HashiCorp and AWS here. 00:44:36.900 --> 00:44:42.000 That's not the right answer then. It's about enabling it, delivering it in a well-hardened 00:44:42.000 --> 00:44:44.328 and a secure manner so that it can be used 00:44:44.328 --> 00:44:47.100 very quickly, that you don't stand in the way, but 00:44:47.100 --> 00:44:53.400 that you take all the identity and security related burden over from the other teams. 00:44:53.400 --> 00:44:56.172 I think what I, for instance, as an analogy, what 00:44:56.172 --> 00:44:59.000 I like is, for instance, that OPA, the Open Policy 00:44:59.000 --> 00:45:02.820 Agent, gained quite some traction because it 00:45:02.820 --> 00:45:06.900 simplified the life of developers. Because they 00:45:06.900 --> 00:45:10.623 just had to basically do a simple call. They 00:45:10.623 --> 00:45:14.600 didn't need to care about the details behind it 00:45:15.400 --> 00:45:17.839 anymore. That is what is the way. So it must 00:45:17.839 --> 00:45:20.500 be thought from how does the developer work? How 00:45:20.500 --> 00:45:22.925 does an infrastructure engineer work? And 00:45:22.925 --> 00:45:26.000 security needs to deliver the right type of service. 00:45:27.300 --> 00:45:33.800 Yeah, but if you look at security, we've discussed security being an old IGA guy, I'm 00:45:33.800 --> 00:45:39.500 looking at the G part, the governance part. So most of these NHI accounts, let's keep with 00:45:39.500 --> 00:45:42.271 that term, they are privileged. They are highly 00:45:42.271 --> 00:45:45.100 privileged. They can do things that we would not 00:45:45.100 --> 00:45:50.300 love our neighbor or colleague to have. But they are ephemeral, but they do things. 00:45:50.900 --> 00:45:53.800 How do you apply, apart from security, governance? 00:45:53.800 --> 00:45:56.700 How do you hold somebody responsible, accountable, 00:45:56.700 --> 00:46:02.500 maybe liable for what this thing did in this short lifespan of its existence? Where would 00:46:02.500 --> 00:46:05.908 you approach that, Felix? Well, okay, before you 00:46:05.908 --> 00:46:09.600 do this, there are a few fundamental things that you 00:46:09.600 --> 00:46:11.588 have to put in place, right? Because you're 00:46:11.588 --> 00:46:13.900 saying, how do you hold someone accountable? Well, 00:46:13.900 --> 00:46:16.438 accountable for what exactly? Because most 00:46:16.438 --> 00:46:19.400 organizations, they don't have a policy for this. 00:46:19.400 --> 00:46:21.821 And even if they had a policy, they don't have 00:46:21.821 --> 00:46:24.400 any kind of guidance for the developers for this. 00:46:25.900 --> 00:46:29.500 Now, IAM teams, many of the IAM teams, when you talk to them about your developer, 00:46:29.500 --> 00:46:36.100 they kind of look at you like, I'm business focused, right? Tell you what, every critical 00:46:36.100 --> 00:46:39.435 business process of your organization is enabled 00:46:39.435 --> 00:46:42.700 by machine to machine interactions, right? Now, 00:46:42.700 --> 00:46:46.350 if that's not a business problem, then what is, 00:46:46.350 --> 00:46:50.000 right? So, you would think that somebody should 00:46:50.000 --> 00:46:52.527 be leading this conversation. Is it going to be 00:46:52.527 --> 00:46:55.000 IAM teams? I thought they could step in there, 00:46:55.000 --> 00:46:58.900 because they have all the coordination skills, they understand all the identity concepts, 00:46:58.900 --> 00:47:01.126 they know how to do all the cat herding and get 00:47:01.126 --> 00:47:03.400 multiple groups aligned. But the problem is that 00:47:03.400 --> 00:47:06.550 they're kind of stuck thinking about machine ID 00:47:06.550 --> 00:47:09.700 as if they were weird humans. So, what needs to 00:47:09.700 --> 00:47:12.460 happen is that somebody needs to step up. I've 00:47:12.460 --> 00:47:15.400 seen this happen more under the CISO, rather from 00:47:15.400 --> 00:47:18.734 the IAM teams, but that's okay, too. But somebody 00:47:18.734 --> 00:47:22.000 needs to step up and form these cross-functional 00:47:22.000 --> 00:47:24.193 machine IAM working groups. I think that's 00:47:24.193 --> 00:47:26.700 the best way to get this to work. Bring everyone 00:47:26.700 --> 00:47:32.700 to the table, from DevOps, security, from application teams, infrastructure and operations 00:47:32.700 --> 00:47:34.722 folks. Because right now, we've got this 00:47:34.722 --> 00:47:37.400 business, this critical business infrastructure being 00:47:37.400 --> 00:47:39.914 secured by whatever happens to be closest to 00:47:39.914 --> 00:47:42.600 the keyboard, right? And then once you do that, 00:47:43.800 --> 00:47:48.600 that's where you can actually start giving strategic direction and giving proper guidance. 00:47:48.600 --> 00:47:50.487 And once you have that guidance, then you can 00:47:50.487 --> 00:47:52.500 actually enforce it. That's where the governance 00:47:52.500 --> 00:47:55.800 comes in. Because if I tell you how to do it properly, you don't do it properly, 00:47:56.700 --> 00:47:59.733 then I'm going to have a problem with what 00:47:59.733 --> 00:48:03.200 you do. But before, there is no guidance. If you 00:48:03.200 --> 00:48:04.993 don't give them guidance, they're going to look 00:48:04.993 --> 00:48:06.900 at the internet on how to do this and they'll say, 00:48:06.900 --> 00:48:08.935 well, use a vault, right? Or just use a 00:48:08.935 --> 00:48:11.700 service account and stick the password, I don't know, 00:48:11.700 --> 00:48:15.186 somewhere. This is not the right way to do it. 00:48:15.186 --> 00:48:18.900 So you have to do this on a programmatic way as a 00:48:18.900 --> 00:48:22.100 multidisciplinary working group. It's not going 00:48:22.100 --> 00:48:25.300 to work otherwise. I don't even think IAM teams 00:48:25.300 --> 00:48:28.013 should be responsible for that unless they 00:48:28.013 --> 00:48:31.500 really rethink what their role in this is going to be. 00:48:32.000 --> 00:48:36.800 Yeah, I think it depends a bit on how you define IAM team. Also, again, back into this, 00:48:37.800 --> 00:48:40.950 where does IAM belong? What's the role of the 00:48:40.950 --> 00:48:44.100 CISO in there? As you said, I think there are 00:48:44.100 --> 00:48:47.000 other elements, there are other teams which also 00:48:47.000 --> 00:48:49.900 play. And I think we need to get away also a bit 00:48:52.200 --> 00:48:56.500 from... I think if your IAM team is basically a traditional workforce IAM team, 00:48:57.000 --> 00:49:00.200 then they're still quite a long way until we are 00:49:00.200 --> 00:49:03.400 there. If you see it as a much broader team that 00:49:03.400 --> 00:49:06.100 does way more different things and already deals 00:49:06.100 --> 00:49:08.800 with way more different types of identities in a 00:49:08.800 --> 00:49:11.932 proper manner, it might be simpler. But yes, I 00:49:11.932 --> 00:49:15.200 would agree it also requires to think about what 00:49:15.200 --> 00:49:18.650 approaches are best suited to solve certain use 00:49:18.650 --> 00:49:22.100 cases. I think the sheer fact that we first had 00:49:22.200 --> 00:49:27.900 team which is Cloud Infrastructure Entitlement Management appearing, which in a sense was 00:49:27.900 --> 00:49:34.600 non-human access, so services to resources, et cetera, where we looked a bit more on the 00:49:34.600 --> 00:49:36.938 entitlement side. And then we have right now 00:49:36.938 --> 00:49:39.700 quite a huge number of non-human identity management 00:49:39.700 --> 00:49:44.000 vendors with us appearing that clearly indicates 00:49:44.000 --> 00:49:48.300 we have a challenge that is not yet well solved. 00:49:49.300 --> 00:49:51.776 Indeed. I mean, that's kind of obvious. Yes, we 00:49:51.776 --> 00:49:54.200 do have that challenge. You're 100% right. But 00:49:54.200 --> 00:49:58.300 does the IAM team do that? It is kind of like asking if your bicycle can handle the 00:49:58.300 --> 00:50:00.032 autobahn. I mean, technically, yes, it has 00:50:00.032 --> 00:50:02.300 wheels. Are you going to get run over or pulled over or 00:50:02.300 --> 00:50:06.500 something like that? I think there are two aspects. So one could be, we say we have a 00:50:06.500 --> 00:50:12.000 different team that sits somewhere in between. Or a working group, a working group. 00:50:12.000 --> 00:50:15.900 Yes, but still then you need to come up with someone who runs the service, who provides 00:50:15.900 --> 00:50:20.000 the service, et cetera. So from the operational side, it's not just the working group. 00:50:20.000 --> 00:50:24.604 And the other thing is that it also leads to the 00:50:24.604 --> 00:50:29.400 question, how must your future IAM team look like? 00:50:30.600 --> 00:50:33.632 I think that is maybe the question we should ask 00:50:33.632 --> 00:50:36.600 ourselves. Because from sort of the traditional 00:50:36.600 --> 00:50:40.684 workforce IAM to what an identified break as a 00:50:40.684 --> 00:50:45.300 concept comprises, which is all types of identities, 00:50:45.300 --> 00:50:51.200 all types of services, way bigger, that's a tough journey at the end of the day. 00:50:51.200 --> 00:50:54.845 And I think the question which comes to my mind 00:50:54.845 --> 00:50:58.800 is, how must the future IAM organization look like? 00:50:58.800 --> 00:51:01.374 I'm looking a bit at Matthias here because I 00:51:01.374 --> 00:51:04.300 think that might be a very good scene for his team 00:51:05.800 --> 00:51:11.000 to think about how much that organization, let's call it IAM organization for now, 00:51:11.800 --> 00:51:18.000 it might be a very different IAM than today's IAM organization. But how must it look like? 00:51:18.000 --> 00:51:21.000 Because at the end of the day, with most aspects we discussed today, 00:51:21.700 --> 00:51:25.000 we touched that a traditional IAM organization is hardly capable 00:51:25.900 --> 00:51:27.600 of dealing with today's challenges. 00:51:28.200 --> 00:51:30.700 They are often over-challenged with Pam, but Felix. 00:51:31.400 --> 00:51:35.900 Yeah, I may have misunderstood you, Martin, because you said something like, well, 00:51:36.000 --> 00:51:39.790 are they even equipped to run this whole thing? 00:51:39.790 --> 00:51:43.500 I don't think it really is one particular team 00:51:43.500 --> 00:51:45.367 that runs everything. And actually, that's 00:51:45.367 --> 00:51:47.500 not how it really works with most organizations. 00:51:47.500 --> 00:51:51.800 Because you'll see that IAM, even today, it's distributed among many different 00:51:51.800 --> 00:51:54.022 sections of the organization. You've got 00:51:54.022 --> 00:51:56.800 folks that do PKI, they're not necessarily the IAM 00:51:56.800 --> 00:52:00.700 guys. You've got folks that do AD, they're not necessarily the IAM folks either. 00:52:00.700 --> 00:52:05.800 Kim tools are also not really used so much by IAM tools. You have others that are running 00:52:06.500 --> 00:52:10.700 SecretsVault, you have ones that are running Kubernetes and maybe using Kubernetes secrets 00:52:10.700 --> 00:52:14.204 over in there. And they might use things such as 00:52:14.204 --> 00:52:18.000 Spiffy, they might use their own PKI tools in there. 00:52:18.000 --> 00:52:22.700 You have folks that do customer IAM, they may also be in a different team. 00:52:23.400 --> 00:52:27.000 You may have different IDPs in there, not all of them are big. 00:52:27.000 --> 00:52:35.800 So I think this model of decentralized control, but centralized governance is what 00:52:36.500 --> 00:52:40.200 most accurately describes what's happening right now. And I don't think there's 00:52:40.200 --> 00:52:42.978 anything wrong with that, that you have different 00:52:42.978 --> 00:52:45.700 teams that are responsible, different aspects of 00:52:45.700 --> 00:52:49.600 it, but you have to have, of course, a common governance structure. And that's why I think 00:52:50.200 --> 00:52:54.900 these machine IAM working groups can really achieve that. It's perfectly, 00:52:54.900 --> 00:52:59.800 maybe fairly acceptable to say that. You don't need just the working group, 00:52:59.800 --> 00:53:04.800 that's what my point was. The working group is the one thing where you bring together. 00:53:05.400 --> 00:53:10.100 And the standards. And you can implement the governance from that side. 00:53:10.100 --> 00:53:12.396 The governance is something which is a, so a 00:53:12.396 --> 00:53:14.900 working group is something which is, at the end, 00:53:15.800 --> 00:53:21.900 temporary. It may move into something which is a sort of a regular sort of 00:53:23.500 --> 00:53:29.000 contact, which is embedded in the organization. You say, okay, we come together here. 00:53:29.500 --> 00:53:34.500 That would be the more steering committee thing, probably rather than a working group. 00:53:34.500 --> 00:53:39.600 But then you need sort of a, in your organization, someone who cares for governance across 00:53:39.600 --> 00:53:47.100 everything. And you have many, many elements which need to be implemented, 00:53:47.800 --> 00:53:54.800 managed, run, et cetera, within that. And then the question is, what do you consider 00:53:54.800 --> 00:54:02.600 of all that being part of your IAM? And that's something like an IAM department that still 00:54:02.600 --> 00:54:04.753 exists in the future. Is it something which is 00:54:04.753 --> 00:54:07.000 more descriptive of everything which is related, 00:54:07.000 --> 00:54:10.198 but which sits in various areas? How do we then 00:54:10.198 --> 00:54:13.600 avoid sprawl? So again, I think there are a lot of 00:54:13.600 --> 00:54:17.600 interesting questions around how must the organization look like? How do we call things 00:54:17.600 --> 00:54:20.768 in the future? And yes, it can't be that you have 00:54:20.768 --> 00:54:24.000 one single group or whatever, three or four people 00:54:24.000 --> 00:54:28.600 in a small organization who have all the systems under their control, because it's... 00:54:29.400 --> 00:54:34.200 No, that's something to have. I think in the reality of it... 00:54:34.200 --> 00:54:36.674 On the other hand, you can't just say, it's here 00:54:36.674 --> 00:54:39.200 and there and there and there. You need a certain 00:54:39.200 --> 00:54:44.200 degree of control also to avoid sprawl. You need governance. Because even today, 00:54:44.200 --> 00:54:50.200 you have different teams that are doing IAM in their particular way. And I don't think we 00:54:50.200 --> 00:54:52.352 disagree. It is something that is obviously, 00:54:52.352 --> 00:54:54.700 that's perpetual. It's not a project. You're not 00:54:54.700 --> 00:54:57.480 doing something, then you're done, have a party 00:54:57.480 --> 00:55:00.200 and walk away. Obviously not, right? So you do 00:55:00.200 --> 00:55:02.308 need to have all of these different 00:55:02.308 --> 00:55:05.800 stakeholders participating within that forum. If you don't 00:55:05.800 --> 00:55:08.000 want to call it group, but you want to call it 00:55:08.000 --> 00:55:10.200 forum or something like that, that may work as 00:55:10.200 --> 00:55:12.401 well. The whole idea is you have to get those 00:55:12.401 --> 00:55:14.700 people together, those individual stakeholders. 00:55:14.700 --> 00:55:20.300 Now, what is IAM's role? I think if things continue the way they're continuing right now, 00:55:20.300 --> 00:55:23.516 then I think IAM is going to be maybe consulted, 00:55:23.516 --> 00:55:26.800 possibly informed, but not really responsible for 00:55:26.800 --> 00:55:30.534 anything, not really accountable for anything 00:55:30.534 --> 00:55:34.600 either. It's kind of cut out of the loop on this, 00:55:34.600 --> 00:55:37.400 but they do actually have some great things to 00:55:37.400 --> 00:55:40.200 contribute. So I think IAM teams can actually, 00:55:40.200 --> 00:55:42.354 if they really wanted, they could probably take 00:55:42.354 --> 00:55:44.600 charge of that. It doesn't take that much because 00:55:44.600 --> 00:55:47.004 they have a good understanding of identity. 00:55:47.004 --> 00:55:49.800 They need to obviously care about those particular 00:55:49.800 --> 00:55:52.720 business cases that are very critical for machine 00:55:52.720 --> 00:55:55.700 learning, specifically application infrastructure, 00:55:55.700 --> 00:55:58.550 development, operations, all of these kinds of 00:55:58.550 --> 00:56:01.400 things. Then they might even be able to take a 00:56:01.400 --> 00:56:03.329 lead on this. But I think if that does not 00:56:03.329 --> 00:56:05.900 happen, then someone else will take the lead on this and 00:56:05.900 --> 00:56:12.600 IAM will be one of the many parties in them. I think the challenge we have today is that 00:56:13.200 --> 00:56:20.500 not only someone, but many take the lead on something in an uncoordinated manner without 00:56:20.500 --> 00:56:23.816 proper governance. And whether it's later on, 00:56:23.816 --> 00:56:27.500 maybe we have a traditional IAM team and we have a 00:56:27.500 --> 00:56:34.100 machine IAM team, which are again working in certain areas closely together with a 00:56:34.600 --> 00:56:41.300 proper governance across everything, or whether the IAM team evolves and has different 00:56:41.800 --> 00:56:46.400 sort of groups in which care for different things. I don't care much about it. But I think 00:56:46.400 --> 00:56:49.914 what becomes very, very clear is we need to 00:56:49.914 --> 00:56:54.000 think about the organization, about the governance 00:56:54.000 --> 00:56:57.293 structures, as well as who best runs what, and 00:56:57.293 --> 00:57:00.800 to avoid that things are done in an inappropriate 00:57:00.800 --> 00:57:07.400 manner. Whoever is close to the keyboard kind of decides which kind of static identity 00:57:07.400 --> 00:57:12.400 construct they use. That's the total anti-pattern. That's what organizations have to go 00:57:12.400 --> 00:57:14.600 get away from. Yes, you look like you want to say something. 00:57:16.500 --> 00:57:18.926 Yeah, I'm looking at this. I think, A, this is 00:57:18.926 --> 00:57:21.300 the longest episode ever. Second, this is the 00:57:21.300 --> 00:57:23.526 episode where I ask the least questions at all, 00:57:23.526 --> 00:57:25.800 which is great because that means the discussion 00:57:25.800 --> 00:57:32.700 went without me, which is nice. Having three people in the room who are doing identity for 00:57:32.700 --> 00:57:39.000 really a long time right now. I was afraid when I joined Identity in the late 1990s or 00:57:39.000 --> 00:57:42.174 mid of the 1990s that this is a temporary 00:57:42.174 --> 00:57:46.200 stuff, temporary things. Somebody will come up with, 00:57:46.200 --> 00:57:48.693 way back then, Data Backer Book for Identity 00:57:48.693 --> 00:57:51.300 Nexus Management. Everything is in there today 00:57:51.300 --> 00:57:54.553 now. It's IAM for Dummies, and then we're 00:57:54.553 --> 00:57:58.600 done. I could not have been more wrong. We are in a 00:57:58.600 --> 00:58:02.235 situation where identity is actually just 00:58:02.235 --> 00:58:07.200 evolving and growing and expanding and metastasizing and 00:58:07.200 --> 00:58:09.878 really getting bigger. We need to look at that. 00:58:09.878 --> 00:58:12.500 Maybe that is a positive thing for us identity 00:58:12.500 --> 00:58:15.617 professionals as well. There are still a lot of 00:58:15.617 --> 00:58:18.800 things to consider, to think of and to do and to 00:58:18.800 --> 00:58:23.256 improve. I think that's really the good thing. 00:58:23.256 --> 00:58:28.100 Identity is not yet a solved problem. Many aspects 00:58:28.100 --> 00:58:33.200 are solved, but not all of this. We're just discussing that. We did not even look at 00:58:33.200 --> 00:58:39.400 agent-based computing, agentic AI, which is part of NHI and which might or might not raise 00:58:39.400 --> 00:58:41.924 different issues. We didn't make it there. We're 00:58:41.924 --> 00:58:44.500 at the end of this episode. As I said, there will 00:58:44.500 --> 00:58:47.350 be these final thoughts questions for each of 00:58:47.350 --> 00:58:50.200 these both topics. Again, it will be the same 00:58:50.200 --> 00:58:52.711 question. If there is an organization that 00:58:52.711 --> 00:58:55.700 really wants to embark on a proper journey towards 00:58:55.700 --> 00:59:01.000 managing all types of identities, including NHI, I don't know even whom to start with. 00:59:01.000 --> 00:59:07.000 What would be your recommendation? What actually to do first to get a grip on 00:59:08.200 --> 00:59:12.600 this huge area of identities to cover at all? Starting with Felix. He's the guest. 00:59:14.300 --> 00:59:22.600 Okay. You have to build a strategic roadmap for comprehensive machine IAM strategy 00:59:23.200 --> 00:59:26.600 really on five components, like five pillars. 00:59:26.600 --> 00:59:30.000 Don't go into the trap of using some tactical 00:59:30.000 --> 00:59:32.275 NHI management approach because that strategy 00:59:32.275 --> 00:59:34.600 really transforms the fundamental architecture 00:59:34.600 --> 00:59:39.300 of how machines authenticate and interact. The first one is to establish the governance 00:59:39.300 --> 00:59:44.200 and discovery, bring everyone together, cross-functional coordination and comprehensive 00:59:44.200 --> 00:59:46.660 understanding of all of your use case in the 00:59:46.660 --> 00:59:49.400 current state. Then build modern machine identity 00:59:49.400 --> 00:59:51.973 infrastructure, assemble stuff that you already 00:59:51.973 --> 00:59:54.600 have. You probably already have a lot of things. 00:59:54.600 --> 00:59:57.050 You have API gateways, you have PKI, you probably 00:59:57.050 --> 00:59:59.500 have OAuth somewhere in your IDPs. You might want 00:59:59.500 --> 01:00:02.937 to add Spiffy to that to enable dynamic machine 01:00:02.937 --> 01:00:06.300 identity pattern for the future, if you're not 01:00:06.300 --> 01:00:08.600 already using it. If you are already using it, 01:00:08.600 --> 01:00:11.100 then roll it out even further. Then this is really 01:00:11.100 --> 01:00:13.509 important. You need to create standards, 01:00:13.509 --> 01:00:16.700 training, and guidance. Make dynamic machine identity 01:00:16.700 --> 01:00:19.553 patterns the easy path, the default path for 01:00:19.553 --> 01:00:22.600 documentation, education, policies, procedures, 01:00:23.200 --> 01:00:25.475 and of course, then compliance with this. You 01:00:25.475 --> 01:00:27.800 can't just say, don't put things in clear text 01:00:27.800 --> 01:00:30.075 or don't put things in a box. You have to give 01:00:30.075 --> 01:00:32.400 real guidance, like cookbooks for people how to 01:00:32.400 --> 01:00:34.971 do it, and then they will. After that, you're 01:00:34.971 --> 01:00:37.600 ready to embed security by design. You want to 01:00:37.600 --> 01:00:43.500 prevent new static credential creation that implement modern machine IAM best practices. 01:00:43.600 --> 01:00:49.500 Then, as the last thing, you migrate and improve. You transform your legacy using 01:00:49.500 --> 01:00:54.600 risk-based approaches and continuous improvement to migrate off of NHIs and more to 01:00:55.200 --> 01:00:59.400 modern machine IAM patterns. That's kind of how you do it. You have to do this together 01:01:00.600 --> 01:01:06.500 in a group or a forum, if you so wish. I fully agree. I think it starts with 01:01:07.000 --> 01:01:12.600 the working group. It starts with bringing people together to learn. I think that the 01:01:12.600 --> 01:01:16.139 first thing is really that everyone 01:01:16.139 --> 01:01:21.700 understands the need, the demand, the requirements, the 01:01:21.700 --> 01:01:24.054 challenges the others are facing, and also 01:01:24.054 --> 01:01:26.800 what they know, how they do it, how you can do it 01:01:26.800 --> 01:01:29.731 technically from that end, et cetera, in a very 01:01:29.731 --> 01:01:32.600 open-minded manner. I think that I fully agree 01:01:32.600 --> 01:01:38.100 with the points Felix brought up. I think the one thing to add is I think we need to 01:01:38.100 --> 01:01:45.000 be very precise with what is the sort of a more temporary working group scheme, 01:01:45.000 --> 01:01:49.800 et cetera, versus what is the resulting organizational structure out of that. 01:01:49.800 --> 01:01:52.929 That is something we need to work on because 01:01:52.929 --> 01:01:56.200 that organization will compare to what we have 01:01:56.200 --> 01:02:00.061 in a traditional IAM organization that stems from 01:02:00.061 --> 01:02:04.000 a workforce IAM history. I'd say maybe it's a good 01:02:04.000 --> 01:02:07.437 idea to do this talk in three years again from 01:02:07.437 --> 01:02:10.800 now because with about 90 years of experience 01:02:10.800 --> 01:02:15.100 we have in that room with the three of us, the next time, if we do it in three years, 01:02:15.100 --> 01:02:21.000 we probably would have 100 years of experience altogether. So quite a lot of that. 01:02:21.800 --> 01:02:23.000 This alone is a reason. 01:02:25.100 --> 01:02:28.428 Right. So quick end to this. You have provided 01:02:28.428 --> 01:02:31.900 your insights into these two topics and I really 01:02:31.900 --> 01:02:38.800 enjoyed this session because although coming now from different sources, origins, we came 01:02:38.800 --> 01:02:41.630 together through synthesis and that is the 01:02:41.630 --> 01:02:45.000 great part of it. So both for ITDR and before NHI, 01:02:45.000 --> 01:02:47.836 however we call it, we came up to the point 01:02:47.836 --> 01:02:51.200 that there is a problem that needs to be solved and 01:02:51.200 --> 01:02:54.185 the proper way that needs to be applied to get 01:02:54.185 --> 01:02:57.300 there. And maybe this point where we want to get 01:02:57.300 --> 01:03:03.300 might look different from organization to organization. And getting there, that's the 01:03:03.300 --> 01:03:06.500 journey where people can support you in and where 01:03:06.500 --> 01:03:09.700 best practices and standards and interoperability 01:03:10.600 --> 01:03:14.493 is dramatically needed and will evolve over 01:03:14.493 --> 01:03:19.200 time. And having both you, Felix and Martin, in this 01:03:19.200 --> 01:03:22.181 virtual room together in this session really was 01:03:22.181 --> 01:03:25.100 a pleasure for me and to have your insight into 01:03:25.100 --> 01:03:28.184 that. I have more of these four-letter acronyms 01:03:28.184 --> 01:03:31.400 that I can throw at you so there is room for more 01:03:31.400 --> 01:03:34.400 one-hour episodes around IAM, I'm quite sure. 01:03:34.400 --> 01:03:37.400 Would love to do that. But for today, really, 01:03:37.400 --> 01:03:39.527 thank you very much, Felix, for being our guest 01:03:39.527 --> 01:03:41.700 today. Thank you very much, Martin, for being my 01:03:41.700 --> 01:03:45.439 guest here as well. And for both of you who know 01:03:45.439 --> 01:03:49.100 each other for years, for having this vivid and 01:03:49.100 --> 01:03:55.500 sometimes controversial, but in the end also a joint discussion with a common output. 01:03:55.500 --> 01:04:02.800 Final question, final sentence, 20 words, 40 words. What would you want to give the 01:04:02.800 --> 01:04:08.000 audience from your perspective? What to look at next in IAM, Felix? 01:04:09.900 --> 01:04:12.819 Well, I think for sure machine IAM. That's kind 01:04:12.819 --> 01:04:15.800 of at the nexus of where the really big business 01:04:15.800 --> 01:04:18.371 problem is that needs to be solved. And for 01:04:18.371 --> 01:04:21.300 your IAM, if you want to start small, think about 01:04:21.300 --> 01:04:24.150 visibility and think about preventive hygiene. 01:04:24.150 --> 01:04:27.000 I think that's going to, it's too difficult to 01:04:27.000 --> 01:04:29.044 achieve, that's going to get you really, 01:04:29.044 --> 01:04:31.600 really, really far before you chase the buzzwords. 01:04:32.600 --> 01:04:33.300 Right. Martin? 01:04:33.800 --> 01:04:40.600 So beyond NHI, so let's say before NHI or related to NHI, think in more integrated 01:04:40.600 --> 01:04:43.537 approaches like Identity Fabric. Beyond that, I 01:04:43.537 --> 01:04:46.600 think one thing I think about a lot is the impact 01:04:47.400 --> 01:04:50.562 signals and AI will have on what we are doing. 01:04:50.562 --> 01:04:54.000 And I think that there are some really interesting 01:04:54.000 --> 01:05:01.400 things that will pop up over time and some interesting evolutions stemming from that. 01:05:01.400 --> 01:05:07.800 When you think about how authentication could look like in the future based on many 01:05:08.600 --> 01:05:13.500 weak signals, maybe being really passive. And when you think beyond policy-based 01:05:14.500 --> 01:05:21.300 access towards something where AI helps us making more creative, nuanced decisions. 01:05:22.500 --> 01:05:25.400 But that would be probably a good topic for another hour or two. 01:05:25.400 --> 01:05:29.300 For a future talk, yeah. For another hour or two, yeah. 01:05:30.100 --> 01:05:33.234 Exactly. So thank you again, Felix and Martin. 01:05:33.234 --> 01:05:36.300 I closed on very quickly. Thank you for being 01:05:36.300 --> 01:05:39.800 my guest today and for sharing your insights into these 01:05:39.800 --> 01:05:42.342 really topical topics. And maybe there is an 01:05:42.342 --> 01:05:45.000 upcoming episode together with the two of you. 01:05:45.000 --> 01:05:48.200 Thanks again. Have a great day. And thanks for joining me. 01:05:48.200 --> 01:05:49.000 Thanks for having me. 01:05:49.700 --> 01:05:50.200 Bye.