WEBVTT 00:00:15.100 --> 00:00:17.600 Welcome to the KuppingerCole Analyst Chat. 00:00:17.700 --> 00:00:18.300 I'm your host. 00:00:18.500 --> 00:00:19.800 My name is Matthias Reinwarth. 00:00:19.900 --> 00:00:22.900 I'm an analyst and advisor at KuppingerCole Analysts. 00:00:23.000 --> 00:00:25.000 My guest today is Martin Kuppinger. 00:00:25.200 --> 00:00:28.900 He is the principal analyst and one of the founders of KuppingerCole. 00:00:28.900 --> 00:00:30.200 Hi, Martin. 00:00:30.900 --> 00:00:31.500 Hi, Matthias. 00:00:31.900 --> 00:00:33.200 Pleasure being here. 00:00:33.400 --> 00:00:34.100 Great to have you. 00:00:34.200 --> 00:00:42.300 We are still on our road to EIC, and we want to talk about a topic I know you for more 00:00:42.300 --> 00:00:45.600 than 11 years now or 12, I don't know. 00:00:45.900 --> 00:00:54.900 This has accompanied us over the time because it's more or less a challenge, a problem, 00:00:55.900 --> 00:00:57.700 a nuisance for many organizations. 00:00:58.300 --> 00:01:03.900 You've just written a blog post about that, and I really like the angle that you chose, 00:01:04.500 --> 00:01:10.600 especially that we maybe have the tools to solve parts of the problem. 00:01:11.000 --> 00:01:14.200 We want to talk about the problem, and please don't go away. 00:01:14.300 --> 00:01:16.400 This is an important topic, and maybe it helps you. 00:01:16.900 --> 00:01:19.000 We want to talk about recertification. 00:01:19.300 --> 00:01:25.700 The blog post you've written is called Recertification from 100 to Zero in a Day. 00:01:25.700 --> 00:01:31.500 This is a bold statement, but first of all, to lay the groundwork, why is recertification 00:01:31.800 --> 00:01:32.800 still a problem? 00:01:33.700 --> 00:01:35.721 So recertification or access review or 00:01:35.721 --> 00:01:38.700 whichever term you want to use, there are quite a number 00:01:38.700 --> 00:01:39.700 of access certifications. 00:01:39.900 --> 00:01:40.800 There are quite a number of terms. 00:01:41.800 --> 00:01:46.100 It's a challenge, and yes, it's a bit of a provocative title, but I think there's also 00:01:46.100 --> 00:01:48.100 a lot behind that. 00:01:48.100 --> 00:01:52.116 So my starting point is when I look at things 00:01:52.116 --> 00:01:56.400 and I feel there are things that remain unsolved 00:01:56.400 --> 00:02:04.300 or not very well solved over a very long time, then it's time to step back and think about 00:02:04.300 --> 00:02:09.700 do we take the right approach, or are there better other ways to address a challenge? 00:02:09.800 --> 00:02:15.000 And for recertification, I think that my starting point is no one likes it. 00:02:15.000 --> 00:02:17.671 So I haven't seen a single organization 00:02:17.671 --> 00:02:21.300 globally where anyone would say, hey, my departmental 00:02:21.300 --> 00:02:26.100 managers, they are really so happy next week, the next recertification campaign starts for 00:02:26.100 --> 00:02:28.300 all the excellent entitlements of their workers. 00:02:28.800 --> 00:02:30.000 It never happens. 00:02:30.100 --> 00:02:34.018 And then something is wrong, plus the results of 00:02:34.018 --> 00:02:38.100 how we still most commonly do access certification 00:02:38.100 --> 00:02:39.900 are not good. 00:02:40.800 --> 00:02:48.400 So this entire thing popped up with the idea of we need to regularly review, or basically 00:02:48.400 --> 00:02:53.900 the idea is we need to ensure that we enforce the least privilege principle. 00:02:54.100 --> 00:02:55.900 This is basically the mandate. 00:02:56.100 --> 00:02:59.600 And then someone ended up with, okay, then let's review the entitlements. 00:02:59.900 --> 00:03:06.900 The problem is when you have a long list or a huge matrix, I also have seen stacks of 00:03:06.900 --> 00:03:11.700 paper of 70 pages of paper where someone should then check all the entitlements. 00:03:12.600 --> 00:03:17.400 But regardless of which approach you take, there's a tendency to rubber stamping. 00:03:17.700 --> 00:03:20.311 Vendors have invested a lot in saying, okay, 00:03:20.311 --> 00:03:23.100 we help you, we split this into smaller trunks, 00:03:23.200 --> 00:03:27.700 we do it on occasion when there's a certain event, when there's a certain change there, 00:03:27.700 --> 00:03:32.100 we focus on the most critical ones, we provide you with context, et cetera. 00:03:32.100 --> 00:03:36.900 But it still means it's a complex thing and the quality of what is done is not overly 00:03:36.900 --> 00:03:37.500 good. 00:03:38.000 --> 00:03:40.900 So at the end, we are not where we should be. 00:03:41.300 --> 00:03:49.500 And I believe we can really simplify the life of everyone that sort of has to deal with 00:03:49.900 --> 00:03:57.300 that by just taking some obvious, easy to, in many cases, really easy to implement very 00:03:57.300 --> 00:03:58.100 logical measures. 00:03:58.100 --> 00:04:04.100 And you've mentioned 70 pages of documents to look at, to do an access recertification. 00:04:04.400 --> 00:04:07.400 But I think there is a general problem behind that. 00:04:07.700 --> 00:04:13.200 Could it be that access models are too complex, are over-engineered, are too large? 00:04:13.300 --> 00:04:19.100 And maybe that could be a starting point at first to say, okay, maybe I don't need 15 00:04:19.100 --> 00:04:20.600 dimensions and three approvers. 00:04:21.700 --> 00:04:22.000 Okay. 00:04:21.900 --> 00:04:26.800 So if you have that, then you anyway did something wrong and yes, blame on me. 00:04:26.800 --> 00:04:33.000 I've been talking in very early Copenhagen Call webinars also about multi-tier role 00:04:33.000 --> 00:04:33.300 models. 00:04:34.700 --> 00:04:40.900 No, don't go for too sophisticated entitlement models, be pragmatic. 00:04:41.900 --> 00:04:47.700 I've been in projects where already men months, probably men years or person years to 00:04:47.700 --> 00:04:51.300 be precise and politically correct, have been spent. 00:04:51.300 --> 00:04:56.500 But I think when these projects were running, the common term was the older one. 00:04:57.800 --> 00:05:03.100 So there has been a lot of time spent on just discussing about terminology. 00:05:03.500 --> 00:05:09.800 And yes, then you have your business role in your IAM project and that business role 00:05:09.800 --> 00:05:12.300 is not the same as the business role in SAP. 00:05:13.600 --> 00:05:16.100 And that leads to endless discussions. 00:05:16.100 --> 00:05:21.100 And then the question is about, can I, in this multi-tier model, map a system role 00:05:21.100 --> 00:05:25.900 directly to a business role or do I need the IT functional role in between? 00:05:26.500 --> 00:05:28.600 Oh, by the way, what's an IT functional role? 00:05:29.200 --> 00:05:34.100 And so we create complexity and that doesn't help. 00:05:34.200 --> 00:05:40.300 And then there's also frequently a tendency to over-sophistication, that every 00:05:40.300 --> 00:05:46.100 exception is ideally treated by another role, which can lead to this role explosion 00:05:46.100 --> 00:05:48.200 thing. You have more roles than you have employees. 00:05:48.800 --> 00:05:52.000 Latest time you should know, OK, something went wrong. 00:05:52.900 --> 00:05:59.600 So the number of roles, which is an abstraction grouping, must be very, very, very 00:05:59.600 --> 00:06:04.000 significantly lower than the number of identities, full stop. 00:06:04.600 --> 00:06:12.700 Right. And I think technologies, processes and concepts are available right now to 00:06:12.700 --> 00:06:13.900 actually do things better. 00:06:14.100 --> 00:06:19.200 And in your text, in your blog post, you suggest that 80 to 90 percent of entitlements 00:06:19.200 --> 00:06:24.300 that are currently recertified could be policy based, so automated. 00:06:25.100 --> 00:06:30.100 And based on that, policy could be taken off the list of recertification. 00:06:30.100 --> 00:06:32.600 Is it necessary to allow for this? 00:06:33.000 --> 00:06:36.900 Because we've promised or I've promised in the beginning that there might be help for 00:06:36.900 --> 00:06:39.000 those who struggle with recertification. 00:06:39.600 --> 00:06:41.200 So there needs to be groundwork to be done. 00:06:41.400 --> 00:06:45.500 I think that there are two important things you need. 00:06:46.300 --> 00:06:54.300 The first one is you need a technical solution that knows which entitlements have been 00:06:54.300 --> 00:06:59.600 granted via policy and which have been granted via manual requests and approval. 00:07:00.100 --> 00:07:09.400 This distinction is important because if the entitlement came via policy, it has a 00:07:09.400 --> 00:07:15.600 very different status from a recertification perspective because then it's just a 00:07:15.600 --> 00:07:17.900 question, does your system work correctly? 00:07:18.100 --> 00:07:19.100 Is the policy correct? 00:07:19.700 --> 00:07:21.700 And is the data used by the policy correct? 00:07:21.700 --> 00:07:26.400 So you end up with a policy and data governance requirement, but it's not that you 00:07:26.400 --> 00:07:28.600 need a manual access review. 00:07:29.100 --> 00:07:34.300 And my thesis, and that is something that comes from a very long experience in 00:07:34.300 --> 00:07:40.900 identity management, is that probably 90% of all entitlements can be assigned 00:07:41.400 --> 00:07:44.000 automatically and managed, not only assigned. 00:07:44.200 --> 00:07:45.200 It's not just birthright. 00:07:45.600 --> 00:07:47.600 Birthright is oversimplifying. 00:07:48.000 --> 00:07:53.100 You need it for the mover, the relocation, the leaver process as well. 00:07:53.100 --> 00:07:59.200 But 90%, that is my statement, can be automated. 00:07:59.700 --> 00:08:01.300 Let's be 80%. 00:08:01.300 --> 00:08:05.500 But if you have 80% that come in because someone is in a certain organization, in a 00:08:05.500 --> 00:08:10.200 certain location, has a certain job title, a certain organizational roles, which 00:08:10.200 --> 00:08:15.400 require that you have this information, but that exists in, ideally you have some 00:08:15.400 --> 00:08:19.800 business process, business activity information, which exists in many, many 00:08:19.700 --> 00:08:22.700 organizations, then you can use that. 00:08:23.100 --> 00:08:28.800 You can assign and change automatically based on policies. 00:08:29.600 --> 00:08:34.000 Something you, Matthias, and me have built into our process models that you can get 00:08:34.000 --> 00:08:35.000 from Kubernetes Code Analysts. 00:08:35.000 --> 00:08:40.400 So we've built the process models that reflect this difference between manual 00:08:40.400 --> 00:08:41.600 and automated assignments. 00:08:42.000 --> 00:08:47.300 It must be in every proper identity management implementation, there must be 00:08:47.300 --> 00:08:54.000 a defined, visible, described process model, and that must reflect this 00:08:54.000 --> 00:08:54.400 difference. 00:08:54.900 --> 00:08:59.300 If you don't have this, you anyway have an issue in your IAM, a major issue, 00:08:59.700 --> 00:09:04.100 because then you fail in the processes and then you anyway fail in identity 00:09:04.100 --> 00:09:04.600 management. 00:09:07.400 --> 00:09:12.800 So, but having said this, if you have these, whatever, 80% automatically 00:09:12.800 --> 00:09:19.100 assigned, that means there are 80% of the entitlements that don't need to go into 00:09:19.600 --> 00:09:25.400 your manual access review process and your recertification, and you're already 00:09:25.400 --> 00:09:36.600 down 80% with one logical measure and one you already should have these, honestly. 00:09:36.600 --> 00:09:47.100 If not, step back and ask our advisors to help you in sort of optimizing your IAM 00:09:47.400 --> 00:09:47.900 implementation. 00:09:48.600 --> 00:09:50.600 That's the latest time to do that. 00:09:51.000 --> 00:09:55.900 It's a process perspective, as you said, so it needs to be baked into the overall 00:09:56.500 --> 00:09:58.400 lifecycle plus provisioning part. 00:09:58.500 --> 00:10:02.000 On the other hand, of course, and that's the prerequisite that we need to think of, 00:10:02.100 --> 00:10:05.200 but we should have thought about that 20 years ago as well. 00:10:05.200 --> 00:10:07.700 So it's not nothing new, it's data quality. 00:10:08.300 --> 00:10:13.400 So having the right information available to achieve this automation, to have these 00:10:13.400 --> 00:10:18.800 automated policy-based assignment of access rights to people. 00:10:19.900 --> 00:10:26.800 Otherwise, you get to garbage in, garbage out, and using not properly maintained data 00:10:26.800 --> 00:10:30.000 for automation is a recipe for disaster, of course. 00:10:30.000 --> 00:10:35.300 So cleaning up the data, having current data and automation in the processes, I 00:10:35.300 --> 00:10:36.400 think that's a starting point. 00:10:36.900 --> 00:10:43.100 So you don't always need AI and nice nifty new features, just doing the groundwork 00:10:43.100 --> 00:10:45.200 right might help already. 00:10:45.300 --> 00:10:48.500 So this is not a selling a tool, it's improving processes. 00:10:48.800 --> 00:10:55.400 And another idea that we both discussed very early at Köppinger Coal is time 00:10:55.400 --> 00:10:56.100 limited access. 00:10:56.500 --> 00:11:02.600 So really making sure that even if access is assigned manually, it should be only 00:11:02.600 --> 00:11:04.700 assigned for a limited time. 00:11:05.500 --> 00:11:11.400 Ideally, a time that is shorter than the typical recertification period, so that 00:11:11.500 --> 00:11:14.700 it ends before you need to recertify it. 00:11:14.700 --> 00:11:17.800 And if you really need it, then you just order it again. 00:11:18.200 --> 00:11:20.600 Is this the simple idea behind that? 00:11:20.900 --> 00:11:23.400 It is a simple idea and it's a practical one. 00:11:23.400 --> 00:11:27.500 I just saw this happening in a project that a customer of ours in the financial 00:11:27.500 --> 00:11:33.700 services industry, where it's about physical access and it's not super easy to 00:11:33.700 --> 00:11:36.900 automate physical access because the integration into the systems that handle 00:11:36.900 --> 00:11:41.500 physical access from an IGA tool is tricky, not because of the IGA tools, but 00:11:41.500 --> 00:11:45.800 because of the state of immaturity of the physical access control systems. 00:11:46.600 --> 00:11:52.500 And that means if you just say, okay, six months is for the critical access, the 00:11:52.500 --> 00:11:57.600 review period or recertification period, and I go up to six months, then you never 00:11:57.600 --> 00:11:59.300 have to do a recertification. 00:11:59.500 --> 00:12:01.300 You need to reissue or re-approve. 00:12:02.200 --> 00:12:11.400 Yes, but that is something which can be done much easier than the access review. 00:12:11.600 --> 00:12:14.500 And my analogy comes from email. 00:12:15.000 --> 00:12:18.400 So when you have an email system, a lot of your mails are handled by rules. 00:12:18.500 --> 00:12:21.600 So they are handled by the trunk mail or spam filters. 00:12:21.600 --> 00:12:26.200 They are handled by maybe who's you've set up or you just move their mails into 00:12:26.200 --> 00:12:29.100 certain folders because you anyway, don't look at these. 00:12:29.100 --> 00:12:33.500 And then you have two other remaining groups of mails. 00:12:33.600 --> 00:12:39.200 So once you can very quickly handle where you say yes, no, short sentence, direct 00:12:40.400 --> 00:12:42.400 response, and that is the one. 00:12:42.400 --> 00:12:44.700 And the other is the ones that you look at and say, oh God. 00:12:45.900 --> 00:12:49.100 And then you move them somewhere or you leave them in your folder. 00:12:49.100 --> 00:12:54.300 And when you have time or when you need to find time after the third escalation, 00:12:54.600 --> 00:13:00.500 the third reminder, you start working on that and approving an access request, 00:13:00.700 --> 00:13:03.900 extending an approval and say, okay, it's still valid for the next three months. 00:13:04.200 --> 00:13:06.800 That is the first type of mails. 00:13:07.600 --> 00:13:11.500 One where a decision maker looks at and say, okay, yes, Matthias is 00:13:11.500 --> 00:13:13.700 still in my project team, click done. 00:13:14.100 --> 00:13:17.600 Recertification, so where you have to look at multiple things. 00:13:17.600 --> 00:13:21.700 And even if it's sort of reduced to a limited number of things, where you need 00:13:21.700 --> 00:13:26.600 to look at these people, this access across these projects, across these 00:13:26.600 --> 00:13:29.600 business processes, it's a complex thing. 00:13:30.100 --> 00:13:31.900 And you don't do it too frequent. 00:13:32.000 --> 00:13:34.100 So you need to think about how to do it again. 00:13:34.500 --> 00:13:35.800 You don't like to do it. 00:13:35.900 --> 00:13:38.600 So it is the other type, so to speak. 00:13:39.000 --> 00:13:44.700 So when we work with time limited, we reduce complexity and we simplify the handling. 00:13:44.700 --> 00:13:50.000 We need to be a bit smart so that not on the 1st of January, a departmental 00:13:50.000 --> 00:13:54.900 manager receives 300 individual mails for extending a certain type of access, 00:13:55.100 --> 00:14:00.300 that there can be then again, smart grouping for the similar things or just 00:14:00.900 --> 00:14:03.600 sort of distributing a bit the mails over time. 00:14:04.000 --> 00:14:07.700 So I think there are some smart ways to handle it, but we can do it. 00:14:07.800 --> 00:14:09.700 It's an element, but it's clearly not the first one. 00:14:09.700 --> 00:14:10.800 The first one is automation. 00:14:11.400 --> 00:14:14.000 Maybe it's not even the second one, maybe it's the third one. 00:14:14.700 --> 00:14:16.500 Because you already touched AI. 00:14:17.200 --> 00:14:17.600 Exactly. 00:14:18.300 --> 00:14:22.200 But up until now, everything that we explained and talked about is something 00:14:22.200 --> 00:14:27.500 that you can do without upgrading your infrastructure, extending your identity 00:14:27.500 --> 00:14:31.200 fabric with additional capabilities, because they are already there. 00:14:31.500 --> 00:14:34.500 And this is also part of the beauty of the EIC. 00:14:34.800 --> 00:14:40.300 We will have lots of best practices sessions where people talk about how to 00:14:40.300 --> 00:14:45.400 do properly and lessons learned and what can be derived for yourself. 00:14:45.800 --> 00:14:48.900 And this is what we wanted to do with this episode as well to say, okay, yeah, 00:14:48.900 --> 00:14:52.700 you can just do this with everything you have on board right now. 00:14:53.100 --> 00:14:58.500 Having said that, of course, there are new capabilities that can support in 00:14:58.500 --> 00:15:01.300 getting from 100 to zero in a day. 00:15:01.300 --> 00:15:03.800 And that of course is the elephant in the room. 00:15:04.100 --> 00:15:09.600 It's AI, it's usage driven, it's pattern matching, it's understanding how 00:15:09.600 --> 00:15:13.000 people actually work, and this is an additional factor that you've 00:15:13.000 --> 00:15:14.100 mentioned in the blog post, right? 00:15:14.400 --> 00:15:14.700 Yeah. 00:15:14.700 --> 00:15:20.400 And I think, you know, when we saw AI coming into IGA solutions, so identity 00:15:20.400 --> 00:15:24.500 governance and administration, the first thing was around, we analyzed the 00:15:25.000 --> 00:15:29.400 existing entitlements, we proposed role candidates, stuff like that. 00:15:29.400 --> 00:15:33.700 And from the very first day I said, hey, why don't you look at how 00:15:33.700 --> 00:15:35.300 entitlements are actually used? 00:15:36.200 --> 00:15:39.000 And I think this is where the potential of AI comes in. 00:15:39.600 --> 00:15:45.200 Not just saying, okay, these are the existing entitlements, but how are these 00:15:45.200 --> 00:15:45.600 used? 00:15:47.100 --> 00:15:54.500 And then there are very obviously scenarios where entitlements are not used at all. 00:15:55.400 --> 00:16:00.200 I talked recently with an expert in the SAP space and he said, we have numbers. 00:16:00.800 --> 00:16:04.200 And so my estimate was that 40 to 50% aren't used. 00:16:04.200 --> 00:16:06.500 And if you look at the higher level of entitlements, yes. 00:16:06.500 --> 00:16:12.600 He said, when we go deeper into the SAP transactions, it's 80 to 90% that are not 00:16:12.600 --> 00:16:14.000 used at all. 00:16:14.800 --> 00:16:21.400 Plus you have certain entitlements that are only used in very defined situations, 00:16:23.400 --> 00:16:30.200 like certain types of things you do in financial systems at certain periods, 00:16:30.500 --> 00:16:32.700 like years end booking, stuff like that. 00:16:32.700 --> 00:16:39.900 So certain things don't happen frequently or they just happen in certain defined 00:16:39.900 --> 00:16:40.300 periods. 00:16:40.600 --> 00:16:46.700 So when you have a factory, when you have manufacturing during a summer break, there 00:16:46.700 --> 00:16:50.900 will be a lot of very different access because all the suppliers come in, update 00:16:50.900 --> 00:16:53.800 firmware of the machines and stuff like that. 00:16:53.900 --> 00:16:58.100 But that's something which is predictable where you can move to a trust in time 00:16:58.500 --> 00:17:00.700 access and AI can help in that. 00:17:01.200 --> 00:17:09.100 And, but just going back to removing what never is used, if we take the 50%, so we 00:17:09.100 --> 00:17:17.500 have 80% of wire automation, we have 20% remaining, half of them we remove because 00:17:17.500 --> 00:17:18.300 it's never needed. 00:17:18.900 --> 00:17:21.200 Okay, a bit oversimplifying the mathematics here. 00:17:21.700 --> 00:17:24.400 We are at 10% maybe. 00:17:24.400 --> 00:17:31.500 And then we do a bit of time restricted for the remaining few entitlements. 00:17:32.300 --> 00:17:35.000 And then we've moved to the strategic solutions. 00:17:36.300 --> 00:17:40.500 And that is a topic that, that, that, that we've discussed also very often. 00:17:40.700 --> 00:17:42.400 It's, it's, I don't want to take it away. 00:17:42.600 --> 00:17:46.600 So what is the root of all evil when it comes to having the necessity to do 00:17:46.600 --> 00:17:47.700 access recertification? 00:17:48.500 --> 00:17:50.100 Static entitlements, standing privileges. 00:17:51.200 --> 00:17:52.100 Very clearly. 00:17:52.100 --> 00:17:59.500 You know, we have role models introduced to manage all these entitlements and to 00:17:59.500 --> 00:18:00.600 assign them to all the people. 00:18:01.000 --> 00:18:02.800 So that's already where the problem starts. 00:18:03.500 --> 00:18:06.100 Role project and to be complex, they take a long time. 00:18:07.200 --> 00:18:12.300 They have a tendency to over sophistication and we have recertification because of that. 00:18:12.600 --> 00:18:18.600 So we have a couple of obvious challenges stemming from standing privileges. 00:18:19.100 --> 00:18:20.900 And, oh, interesting. 00:18:21.000 --> 00:18:23.100 We are in 2026 now. 00:18:23.300 --> 00:18:27.700 It's the 50 year anniversary of where we should know how to do it better. 00:18:28.500 --> 00:18:29.700 You know why? 00:18:30.500 --> 00:18:31.400 IBM. 00:18:31.400 --> 00:18:32.200 IBM RACF. 00:18:32.800 --> 00:18:37.300 1976, IBM released RACF, the Resource Access Control Facility. 00:18:38.300 --> 00:18:44.800 A solution where different applications can basically author some external 00:18:44.800 --> 00:18:46.000 authorization system. 00:18:46.000 --> 00:18:51.000 You know, in this case, a very defined environment, but at the end of the day. 00:18:52.200 --> 00:18:55.300 It's out there for five decades. 00:18:55.700 --> 00:19:00.800 So there's absolutely no excuse for not doing it now. 00:19:02.200 --> 00:19:07.600 So every good software should support externalization of authorizations. 00:19:08.200 --> 00:19:12.600 There must not be anything baked into the software, not today anymore. 00:19:12.600 --> 00:19:18.200 As I've said, no excuse for that because we know how to do it better for five 00:19:18.200 --> 00:19:19.900 decades now, at least. 00:19:20.300 --> 00:19:26.800 And that means basically over time, we need to shift to better approaches in the 00:19:26.800 --> 00:19:29.200 software and in the way we handle authorizations. 00:19:30.700 --> 00:19:34.800 And so we have also better standards nowadays to handle that. 00:19:35.300 --> 00:19:40.700 We see quite some stuff happening, be it OSX and be it OPA, policy agent, other 00:19:40.700 --> 00:19:43.600 stuff, so we see some tendency towards that. 00:19:44.100 --> 00:19:48.500 But yes, we also need to, I would say, become more mature in software 00:19:48.600 --> 00:19:54.200 development, but you know, honestly, as long as most new services in the net 00:19:54.200 --> 00:19:59.700 still come with username, password, as long as most software does not support 00:19:59.700 --> 00:20:03.300 modern authorization schemes, we probably still have some way to go. 00:20:03.700 --> 00:20:07.400 But clearly, yes, we need to overcome static entitlements because this is 00:20:07.400 --> 00:20:09.700 really the root cause of where things become problematic. 00:20:10.000 --> 00:20:13.500 And they are a risk because they are standing. 00:20:14.700 --> 00:20:17.900 And yes, there's a logic in saying we move to zero standing privileges. 00:20:18.200 --> 00:20:22.600 We move to approaches where there are no permanent assignments because all 00:20:22.600 --> 00:20:25.300 of that is part of the attack surface. 00:20:26.200 --> 00:20:30.100 And if you're interested in learning more about these mechanisms that you, 00:20:30.500 --> 00:20:33.700 Martin, just described, so I'm talking to the audience, of course, just a few 00:20:33.700 --> 00:20:37.500 weeks ago, we had a conversation with Philip, our colleague, and David 00:20:37.500 --> 00:20:39.800 Brossard from the OfficeN working group. 00:20:39.900 --> 00:20:43.700 And they just finalized the interoperability standards around 00:20:43.700 --> 00:20:48.300 OfficeN and the implementations that allow the interoperability can be there. 00:20:48.600 --> 00:20:49.600 The standards are available. 00:20:49.800 --> 00:20:56.400 So it's now really, really evangelizing and doing things differently to achieve 00:20:56.400 --> 00:20:59.000 all these principles that you've just mentioned. 00:20:59.100 --> 00:21:03.000 Of course, also this modern authorization will be part of the 00:21:03.000 --> 00:21:06.500 topics to cover at EIC in Berlin in May. 00:21:06.600 --> 00:21:10.700 But this is something where you can educate yourselves immediately also with 00:21:10.700 --> 00:21:14.100 research from our side and talk to us as advisors. 00:21:14.500 --> 00:21:20.900 So again, that was, I think, a really useful session because most of what we 00:21:20.900 --> 00:21:24.400 discussed can be done with what you have on board already. 00:21:24.800 --> 00:21:29.700 You can extend, you can get better when it comes to user behavior analytics 00:21:29.700 --> 00:21:32.100 and to drilling down the access rights assigned. 00:21:32.100 --> 00:21:36.900 And you can actually change the way you do authorization in 00:21:36.900 --> 00:21:39.700 general as the next big step. 00:21:40.000 --> 00:21:43.800 Any final words from your side before we close down or anything you're looking 00:21:43.800 --> 00:21:46.800 forward to at EIC when it comes to modern authorization? 00:21:47.500 --> 00:21:53.300 So I am really eager to discuss with the OfficeN people about where 00:21:53.300 --> 00:21:54.700 they are and where they are heading. 00:21:55.800 --> 00:21:57.700 I think that is one of the things. 00:21:58.700 --> 00:22:04.100 Also to exchange maybe with vendors about how to bake some of these 00:22:04.100 --> 00:22:07.200 things into their solutions, because there's a lot which can be done. 00:22:09.800 --> 00:22:15.900 And just educating about this because at the end of the day, I think, as I've 00:22:15.900 --> 00:22:19.500 said at the beginning, if we have a challenge we are facing for years and 00:22:20.100 --> 00:22:24.400 we haven't solved it well, we are always coming up with sort of patches and 00:22:24.400 --> 00:22:27.500 small improvements and doing it as a bit better here and a bit better there. 00:22:27.700 --> 00:22:30.000 And we really should step back and think about how can we 00:22:30.000 --> 00:22:32.600 do it fundamentally different? 00:22:34.000 --> 00:22:38.700 What is the sort of the root cause and how can we cure or address the 00:22:38.700 --> 00:22:40.600 cause instead of curing symptoms? 00:22:41.500 --> 00:22:41.800 Absolutely. 00:22:42.100 --> 00:22:44.900 Thank you very much, Martin, for your explanations. 00:22:45.100 --> 00:22:49.900 For the blog post, if you as the audience have not yet read it, please do. 00:22:50.300 --> 00:22:51.600 It's available on our website. 00:22:52.000 --> 00:22:54.600 Recertification from 100 to zero in a day. 00:22:54.600 --> 00:22:58.700 Bit over-exaggerated, but hey, but it's the right way to move forward. 00:22:59.200 --> 00:23:00.600 So thank you very much, Martin. 00:23:00.800 --> 00:23:03.800 See you at EIC and thank you for your time. 00:23:04.300 --> 00:23:04.600 You're welcome.