WEBVTT 00:00:14.200 --> 00:00:18.900 Welcome to the KuppingerCole Analyst Chat. I'm your host. My name is Matthias Reinwarth. 00:00:19.400 --> 00:00:25.300 I'm analyst and advisor with KuppingerCole Analysts. My guest today is Alexei Balaganski 00:00:25.300 --> 00:00:28.861 and he has come with some kind of a new topic, 00:00:28.861 --> 00:00:32.500 which is not that new at its core. But first of 00:00:32.500 --> 00:00:36.800 all, hi Alexei, good to have you. Great to have 00:00:36.800 --> 00:00:41.100 you and especially when it's really an upcoming 00:00:41.400 --> 00:00:43.973 important topic that we want to talk about. And 00:00:43.973 --> 00:00:46.600 for those who typically switch away very quickly 00:00:46.600 --> 00:00:50.995 when they consider terms as boring or a long time 00:00:50.995 --> 00:00:55.300 ago, don't go away. This is important. This is a 00:00:55.300 --> 00:00:58.614 We want to talk about Zero Trust Platforms. So 00:00:58.614 --> 00:01:02.000 there is the term Zero Trust in there, which is 00:01:02.000 --> 00:01:08.100 some kind of a no-no word in some companies already. But no, this time we are aiming at 00:01:08.100 --> 00:01:14.900 doing things right. But before we go to the platform part of the term, maybe a brief recap 00:01:15.000 --> 00:01:21.300 of Zero Trust as its history and what it actually is and why we still need it. 00:01:22.100 --> 00:01:27.000 Well, I guess the term Zero Trust has been with us for well over a decade, 00:01:27.500 --> 00:01:30.250 probably closer to two now. And it was extremely 00:01:30.250 --> 00:01:33.000 popular and it was eagerly picked up by a lot of 00:01:33.000 --> 00:01:36.186 people, especially non-technical people back then, 00:01:36.186 --> 00:01:39.500 exactly because it was very non-technical in nature. 00:01:39.700 --> 00:01:43.135 I've always said Zero Trust is basically feng 00:01:43.135 --> 00:01:46.800 shui for IT. It's a set of philosophical tenets, 00:01:46.800 --> 00:01:52.300 how to organize your life, how to rearrange the furniture in your home and so on, 00:01:52.300 --> 00:01:55.151 to make sure that your work, your energies, 00:01:55.151 --> 00:01:58.400 your productivity and whatnot, and of course your 00:01:59.500 --> 00:02:02.618 security increases accordingly. That was kind of 00:02:02.618 --> 00:02:05.800 the core idea. Never trust, always verify. Sounds 00:02:05.800 --> 00:02:12.100 very easy. The next question is, okay, you had me at hello, now where do I buy Zero Trust? 00:02:12.800 --> 00:02:15.101 And again, we always had to go through the same 00:02:15.101 --> 00:02:17.500 pitch saying, you know, Zero Trust is not a tool, 00:02:17.900 --> 00:02:20.297 it's a journey, it's a strategy. Perfect Zero 00:02:20.297 --> 00:02:22.800 Trust will never be achievable, but you have to 00:02:22.800 --> 00:02:25.846 strive to make it your strategy. You have to 00:02:25.846 --> 00:02:29.100 go step by step. And at that very stage, we are 00:02:29.100 --> 00:02:31.919 starting to lose a lot of people's interest 00:02:31.919 --> 00:02:35.000 exactly because they needed practical guidance. 00:02:35.300 --> 00:02:38.120 Where do we start? How do we continue? Where do 00:02:38.120 --> 00:02:41.000 we invest? And how do we calculate the return of 00:02:41.000 --> 00:02:43.426 that investment? Well, and then of course, the 00:02:43.426 --> 00:02:45.800 COVID came, everybody was locked at home, but 00:02:45.800 --> 00:02:49.150 still had to work from home. And this was a major 00:02:49.150 --> 00:02:52.500 boost for one very special and narrow application 00:02:52.500 --> 00:02:57.900 of Zero Trust, namely Zero Trust network access. So again, everyone had to work from home, 00:02:58.200 --> 00:03:00.835 but of course we did not want to export the 00:03:00.835 --> 00:03:03.900 entire networks for remote sessions. Everybody was 00:03:04.100 --> 00:03:08.158 scrambling for some tool to replace VPN and ZTNA 00:03:08.158 --> 00:03:12.300 was the tool. That was a major spike in returning 00:03:12.500 --> 00:03:16.550 interest for Zero Trust. And for a few years, it 00:03:16.550 --> 00:03:20.600 was of course a buzzword, a very quickly selling 00:03:20.600 --> 00:03:25.500 market segment. And basically now everyone who actually needed one of those tools probably 00:03:25.500 --> 00:03:32.000 already has one, at least all the smart and forward thinking companies, those which are 00:03:32.000 --> 00:03:34.523 less smart, probably still struggling with the 00:03:34.523 --> 00:03:37.100 old VPNs. But again, after all the restrictions 00:03:37.200 --> 00:03:39.750 were lifted, some people were starting to return 00:03:39.750 --> 00:03:42.300 back home. The others just kind of forgot how it 00:03:42.300 --> 00:03:45.069 all felt. So again, we are starting to forget 00:03:45.069 --> 00:03:47.900 about Zero Trust. And yes, you are right. Some 00:03:47.900 --> 00:03:50.656 people just hate the word because of all the 00:03:50.656 --> 00:03:53.600 overexposure, because before AI, Zero Trust was 00:03:53.600 --> 00:03:56.377 the buzzword. But again, this absolutely does 00:03:56.377 --> 00:03:59.400 not mean that this is somehow no longer relevant, 00:03:59.400 --> 00:04:05.700 or this is bad, or this is useless. To the contrary, it is absolutely very relevant again. 00:04:06.100 --> 00:04:09.100 And exactly because of all the developments we 00:04:09.100 --> 00:04:12.100 wanted to discuss today, starting from the AI. 00:04:13.200 --> 00:04:19.000 Right. And if I remember back to ZTNA, for me, as I'm a very simplistic person, for me, 00:04:19.000 --> 00:04:21.863 it's really providing a Zero Trust 00:04:21.863 --> 00:04:27.000 infrastructure as a service. So most probably all from out of 00:04:27.000 --> 00:04:33.300 hand as a package. And that could help, as you said, especially during the COVID era, 00:04:33.600 --> 00:04:38.300 to have a platform which on the one hand replaces these VPNs, which did not scale. 00:04:39.000 --> 00:04:42.082 On the other hand, to have something very easily 00:04:42.082 --> 00:04:45.100 available, which was not possible to build from 00:04:45.100 --> 00:04:48.250 scratch in an own platform. But since COVID, you 00:04:48.250 --> 00:04:51.400 have mentioned that things have changed. We have 00:04:51.400 --> 00:04:55.140 AI, we have new technologies, but we still have 00:04:55.140 --> 00:04:58.800 the requirement to protect network access. And 00:04:58.800 --> 00:05:01.800 when we look at Zero Trust with this triangle 00:05:01.800 --> 00:05:04.800 between account network and devices, and then 00:05:04.800 --> 00:05:07.582 trying to access services, that's still around. 00:05:07.582 --> 00:05:10.600 We still need to deal with it. So CTNA is no longer 00:05:10.700 --> 00:05:14.709 the go-to solution, right? Well, let's again 00:05:14.709 --> 00:05:18.900 kind of recap what ZT and the concept actually 00:05:18.900 --> 00:05:23.061 supposed to mean. Zero Trust means, again, no 00:05:23.061 --> 00:05:27.500 implicit trust to anything or anyone. Basically, 00:05:27.500 --> 00:05:30.900 it boils down to one simple requirement. You or 00:05:30.900 --> 00:05:34.300 any other entity and actor that needs to access 00:05:34.300 --> 00:05:37.635 something, data, resources, applications, APIs, 00:05:37.635 --> 00:05:40.900 anything within your corporate infrastructure, 00:05:41.200 --> 00:05:44.477 they should only be able to access it if they 00:05:44.477 --> 00:05:47.900 have, if they were given explicit and hopefully 00:05:47.900 --> 00:05:50.818 like very limited and time limited and kind of 00:05:50.818 --> 00:05:53.800 scope limited access to that specific resource. 00:05:54.000 --> 00:06:00.000 There should never be a situation where you get too much access. And this problem, 00:06:00.100 --> 00:06:05.300 when you think of it, is actually way older than the notion of Zero Trust. I mean, 00:06:06.700 --> 00:06:09.637 as any IAM professional will tell you, this was 00:06:09.637 --> 00:06:12.700 the original problem, which existed as long as we 00:06:12.700 --> 00:06:19.400 had identity systems. This whole role management and ABAC and RBAC and all the other bags, 00:06:19.600 --> 00:06:22.222 it's something, something based access control. 00:06:22.222 --> 00:06:24.900 Zero Trust is basically just another requirement 00:06:24.900 --> 00:06:27.384 to trim down that access as much as possible. 00:06:27.384 --> 00:06:30.200 And the question is, how do you do that universally 00:06:30.800 --> 00:06:34.700 across any environment, any system and any type 00:06:34.700 --> 00:06:38.600 of identity? ZTNA was a quick and easy solution 00:06:38.600 --> 00:06:41.718 for a very specific use case. How do you allow a 00:06:41.718 --> 00:06:44.900 human, which is currently located outside of your 00:06:44.900 --> 00:06:47.967 existing local IT infrastructure, to access not 00:06:47.967 --> 00:06:51.100 just the entirety of the infrastructure that can 00:06:51.100 --> 00:06:54.098 be done with an old VPN, but a very specific 00:06:54.098 --> 00:06:57.300 resource, like an application. And only if they 00:06:57.600 --> 00:07:01.550 need and explicitly were granted access to that 00:07:01.550 --> 00:07:05.500 application. Simply because if somebody has too 00:07:05.500 --> 00:07:08.854 much access, their credentials, their identity 00:07:08.854 --> 00:07:12.500 can be stolen and abused for stuff like ransomware 00:07:12.500 --> 00:07:15.470 attacks or lateral movements across your networks, 00:07:15.470 --> 00:07:18.500 stealing stuff as they come by and stuff like that. 00:07:19.000 --> 00:07:22.000 So yes, ZTNA was a very quick and fairly 00:07:22.000 --> 00:07:26.200 reliable answer to that challenge. But now we have other 00:07:26.200 --> 00:07:32.200 things happening. And again, just everything is now bigger and faster and scales and very 00:07:32.200 --> 00:07:35.316 drastically. And things are now more ephemeral 00:07:35.316 --> 00:07:38.500 in nature as before. So you have containers and 00:07:38.800 --> 00:07:41.850 microservices and things are just kind of pop up 00:07:41.850 --> 00:07:44.900 and disappear. But more importantly, we now have 00:07:45.500 --> 00:07:52.000 again AI systems. So we now have tons of non-human agents and other types of identities. 00:07:52.300 --> 00:07:55.169 And those were completely neglected in the most 00:07:55.169 --> 00:07:58.100 traditional Zero Trust network access solutions. 00:07:58.900 --> 00:08:05.000 So if we want to make sure that access restrictions apply to anyone and anything, 00:08:05.400 --> 00:08:08.368 especially on those dreadful AI agents who can 00:08:08.368 --> 00:08:11.400 wreak havoc across all your stuff very quickly, 00:08:11.700 --> 00:08:16.500 we have to think bigger. We have to think strategically. And this is exactly when this 00:08:16.500 --> 00:08:19.482 notion of a Zero Trust platform emerges. Right. 00:08:19.482 --> 00:08:22.400 And you've mentioned that with half a sentence 00:08:22.400 --> 00:08:28.700 really to enforce it everywhere. ZTNA was, as you said, a helpful platform approach to 00:08:29.100 --> 00:08:31.830 or architecture approach to solve parts of the 00:08:31.830 --> 00:08:34.500 problem. But we are getting much more hybrid. 00:08:34.800 --> 00:08:38.900 We have much more solutions that are around. Plus all the threats that you just mentioned 00:08:38.900 --> 00:08:44.200 when it comes to new types of identities, ephemeral, quickly changing, quickly scaling up 00:08:44.200 --> 00:08:48.515 and down identities, that requires a different 00:08:48.515 --> 00:08:53.300 way of thinking of Zero Trust, I assume. So we need 00:08:53.800 --> 00:08:57.477 to combine existing platforms or systems into 00:08:57.477 --> 00:09:01.400 an overall approach to achieve this constant and 00:09:01.400 --> 00:09:07.000 global enforcement. Is this the way to move forward in that approach? Well, again, let's 00:09:07.000 --> 00:09:11.250 start by explicitly putting down the things we 00:09:11.250 --> 00:09:15.500 have to implement. First, we have to implement 00:09:15.500 --> 00:09:21.200 universal access enforcement across any kind of identity and any kind of resource. 00:09:21.900 --> 00:09:25.595 Doesn't matter whether it's me accessing your 00:09:25.595 --> 00:09:29.700 Excel spreadsheets or 10,000s of AI agents lurking 00:09:29.700 --> 00:09:33.000 through your entire cloud footprint. The rules 00:09:33.000 --> 00:09:36.300 should be the same. They should work the same, 00:09:36.300 --> 00:09:39.651 regardless of scale, location, type of 00:09:39.651 --> 00:09:44.500 identity, you name it. Second, we have still to enforce 00:09:44.500 --> 00:09:47.026 continuous trust evaluation. This is the 00:09:47.026 --> 00:09:50.500 fundamental of Zero Trust, basically. You do not assume 00:09:50.500 --> 00:09:53.531 anything. You constantly have to evaluate whether 00:09:53.531 --> 00:09:56.500 it's still Matthias. Is it still the same agent? 00:09:56.600 --> 00:10:02.300 Is it still given the same goals and rules as five minutes ago? Is it still okay to trust 00:10:02.300 --> 00:10:05.044 the device? We have to be able to answer all 00:10:05.044 --> 00:10:08.100 those questions in real time, at any time. Third, 00:10:08.500 --> 00:10:11.863 we have to understand that those decisions can 00:10:11.863 --> 00:10:15.300 no longer be binary, whether you get it or not, 00:10:15.400 --> 00:10:20.900 because there will be too many decisions. You have to start segmenting your resources. 00:10:21.500 --> 00:10:24.855 And ideally, you have a broad range of 00:10:24.855 --> 00:10:29.800 approaches towards segmentation. You can do it on a very 00:10:29.800 --> 00:10:32.500 resource scale, just saying, this is my outside 00:10:32.500 --> 00:10:35.200 network and this is my inside. This can be like 00:10:35.200 --> 00:10:38.800 an easy start. But of course, it's not enough because it doesn't stop you from 00:10:39.600 --> 00:10:41.825 ransomware attacks and retro movement. Again, 00:10:41.825 --> 00:10:44.100 ideally, you should be able to do it on a very 00:10:44.100 --> 00:10:50.100 fine-grained basis, not just every resource, but let's say every method in an API endpoint 00:10:50.900 --> 00:10:53.674 becomes that grain of access. And you should 00:10:53.674 --> 00:10:56.700 be able to do it on an intelligent and automated 00:10:56.700 --> 00:10:58.700 basis because you would never be able to do it 00:10:58.700 --> 00:11:00.700 manually. And finally, you have to know what's 00:11:00.700 --> 00:11:04.700 going on. So you have to maintain unified visibility and analytics across all those 00:11:05.300 --> 00:11:08.660 developments. These are four requirements, 00:11:08.660 --> 00:11:12.500 universal enforcement, intelligent segmentation, 00:11:13.300 --> 00:11:19.500 continuous trust evaluation, and unified analytics. Those are the prerequisites for 00:11:19.500 --> 00:11:27.200 a true platform-based solution, which could claim implementing zero trust. And from that, 00:11:27.300 --> 00:11:30.139 we can start discussing the details. For 00:11:30.139 --> 00:11:33.900 example, ZTNA doesn't go away. It's still a very much 00:11:33.900 --> 00:11:36.395 important part of that platform. But you have 00:11:36.395 --> 00:11:39.000 to think about other things. You would probably 00:11:39.000 --> 00:11:41.681 already have some kind of a policy-based 00:11:41.681 --> 00:11:45.100 access solution in place, at least for some of your 00:11:45.100 --> 00:11:48.475 resources. PBAC, we call it. So there is some 00:11:48.475 --> 00:11:52.000 kind of a dynamic engine, which gets in context 00:11:52.000 --> 00:11:55.246 information from all those actors and resources 00:11:55.246 --> 00:11:58.700 and decides, yeah, this guy can access their thing 00:11:59.000 --> 00:12:02.019 now, based on these conditions. Again, this is 00:12:02.019 --> 00:12:05.300 also a key building part of this solution. It just 00:12:05.300 --> 00:12:13.600 has to be more aware of the entirety of your environment and work ideally across that 00:12:13.600 --> 00:12:16.850 environment. So it should be integrated on both 00:12:16.850 --> 00:12:20.100 ends. It should get in more context information 00:12:20.100 --> 00:12:22.479 for all decisions and of course, be able to 00:12:22.479 --> 00:12:25.300 enforce the same policies across different types of 00:12:25.300 --> 00:12:28.181 resources. Strong authentication and continuous 00:12:28.181 --> 00:12:31.000 risk-based authentication. Again, it's another 00:12:30.800 --> 00:12:33.604 prerequisite. And we do have a lot of those 00:12:33.604 --> 00:12:36.800 systems in place. We just do not think about them 00:12:36.800 --> 00:12:39.027 as a strategic building part of the zero trust 00:12:39.027 --> 00:12:41.400 platform. We don't have to reinvent anything. You 00:12:41.400 --> 00:12:44.503 don't have to define it as a completely new type 00:12:44.503 --> 00:12:47.800 of solution, which will just pop up out of nowhere. 00:12:48.500 --> 00:12:51.400 The building blocks are already there. We just 00:12:51.400 --> 00:12:54.300 expect vendors to be able to combine them in a 00:12:54.300 --> 00:13:00.800 simple, useful package, which can be deployed quickly, extended to cover as much of your 00:13:00.800 --> 00:13:07.100 footprint as possible. And again, provide a combination of visibility and operational 00:13:07.700 --> 00:13:10.622 flexibility, but also convenience and the 00:13:10.622 --> 00:13:14.400 ability to respond to all those issues automatically. 00:13:14.800 --> 00:13:16.834 So if I understand you correctly, the same way 00:13:16.834 --> 00:13:19.000 that we learned that zero trust is not a product, 00:13:19.300 --> 00:13:24.900 we have to learn that zero trust platforms is not something provided by a single vendor, 00:13:25.000 --> 00:13:27.302 by a single product, but really an architectural 00:13:27.302 --> 00:13:29.700 approach, a way of thinking, of implementing that. 00:13:29.700 --> 00:13:33.300 And then we need the products that play nicely in that architecture. 00:13:34.000 --> 00:13:37.053 Well, yes and no. Again, kind of the problem is 00:13:37.053 --> 00:13:40.300 we have always said, yes, you cannot expect to get 00:13:40.300 --> 00:13:42.846 such a platform from one vendor. It's too 00:13:42.846 --> 00:13:46.200 complex. It's too, well, it's more like a fabric. Like 00:13:46.200 --> 00:13:48.410 Kuping et al. loves the term fabric. We 00:13:48.410 --> 00:13:51.300 already have like a fabric defined for identity and 00:13:51.300 --> 00:13:53.826 cybersecurity. Well, this is just another kind of 00:13:53.826 --> 00:13:56.300 fabric specifically to live in this intersection 00:13:56.300 --> 00:13:59.400 of identity and security to provide this universal 00:13:59.400 --> 00:14:02.500 zero trust. But unfortunately, not a lot of people 00:14:02.500 --> 00:14:06.952 buy that idea and say, yes, but like, I am not 00:14:06.952 --> 00:14:11.500 an expert. It was way over my head or resources 00:14:11.500 --> 00:14:15.557 or just kind of time to build this fabric on my 00:14:15.557 --> 00:14:19.700 own. Where can I reach out to that would be able 00:14:19.700 --> 00:14:22.980 to help me? And vendors are already responding. 00:14:22.980 --> 00:14:26.400 So yes, we definitely see our emerging offerings. 00:14:26.400 --> 00:14:32.800 I would probably not call them like full featured platforms in a traditional sense, 00:14:33.100 --> 00:14:35.475 but again, kind of anything can now be called a 00:14:35.475 --> 00:14:37.900 platform. Like everybody loves the term platform 00:14:37.900 --> 00:14:41.427 without actually specifically explaining where a 00:14:41.427 --> 00:14:45.100 platform starts as opposed to a fabric or a suite. 00:14:45.400 --> 00:14:47.823 But I believe that the term itself is gaining 00:14:47.823 --> 00:14:50.300 traction and this is why we want to be able to 00:14:51.300 --> 00:14:54.417 market as it develops. And as our own customers 00:14:54.417 --> 00:14:57.600 are coming to us with these questions, we should 00:14:57.600 --> 00:15:00.479 be able to point them in the right direction. And 00:15:00.479 --> 00:15:03.300 yes, this is a development market, but there are 00:15:03.300 --> 00:15:06.400 some already interesting existing offerings available. Right. And as you've mentioned, 00:15:06.500 --> 00:15:09.050 we want to cover that market. And I know that 00:15:09.050 --> 00:15:11.600 you have already provided a leadership brief, 00:15:11.700 --> 00:15:16.700 a brief document that summarizes what we discussed, but much more as well. 00:15:16.700 --> 00:15:23.900 So it's really a starting point to lay the foundation as you described. And on the other 00:15:23.900 --> 00:15:27.164 hand, we really want to cover those products, 00:15:27.164 --> 00:15:30.500 those vendors that provide key infrastructures 00:15:30.500 --> 00:15:33.735 for such a platform. So that is something that 00:15:33.735 --> 00:15:36.900 you're currently working on. Well, I can tell 00:15:36.900 --> 00:15:41.006 you exactly what we did. We did cover ZTNA as a 00:15:41.006 --> 00:15:45.200 standalone market a few years ago. We released a 00:15:45.200 --> 00:15:51.900 compass on those and it was well-received and we had a lot of participants. And of course, 00:15:52.000 --> 00:15:54.750 we had a lot of leaders. So yes, this is a very 00:15:54.750 --> 00:15:57.500 mature and developed market segment. But again, 00:15:58.000 --> 00:16:00.615 with time, kind of the interest, the immediate 00:16:00.615 --> 00:16:03.400 urgency of that subject disappeared. And instead, 00:16:03.600 --> 00:16:06.100 people started asking different questions. How do 00:16:06.100 --> 00:16:08.600 we expand that approach towards everything? Like, 00:16:08.600 --> 00:16:11.281 how do we go from tools-based zero trust to a 00:16:11.281 --> 00:16:14.200 platform-based approach, if you will, a strategic 00:16:14.200 --> 00:16:22.300 approach? How do we address this notion of disappearing trusted perimeter, not just for 00:16:22.300 --> 00:16:25.540 external access, but for any kind of access, 00:16:25.540 --> 00:16:29.000 for your cloud deployments, for your industrial 00:16:29.000 --> 00:16:32.152 networks, for your application level networking, 00:16:32.152 --> 00:16:35.500 this whole kind of microservice-based architectures 00:16:35.500 --> 00:16:39.238 with tons of traffic, which always lives inside a 00:16:39.238 --> 00:16:42.900 presumed trusted VPC, for example, in the cloud, 00:16:42.900 --> 00:16:45.784 but still, I mean, rogue microservices are a 00:16:45.784 --> 00:16:48.800 thing. So we have to be able to apply the same 00:16:48.800 --> 00:16:50.952 approach to every scale and to every kind of 00:16:50.952 --> 00:16:53.300 environment. And this is what people are looking 00:16:53.400 --> 00:16:56.330 for. And we said, yes, let's expand our coverage. 00:16:56.330 --> 00:16:59.200 Let's observe what else the market has to offer. 00:16:59.400 --> 00:17:02.631 And let's formulate a set of criteria. And this 00:17:02.631 --> 00:17:06.000 is why we are now planning to create a leadership 00:17:06.000 --> 00:17:08.323 compass, a market coverage report for zero 00:17:08.323 --> 00:17:11.200 trust platforms, which would combine everything from 00:17:11.200 --> 00:17:16.000 the TNA and intelligent segmentation and strong authentication. And of course, 00:17:16.200 --> 00:17:19.009 is a strong focus on non-human identities as 00:17:19.009 --> 00:17:22.200 well to address all those burden challenges, which 00:17:22.200 --> 00:17:25.909 our customers are asking us to help them find 00:17:25.909 --> 00:17:29.700 the solution. So this will not be a new topic, 00:17:30.000 --> 00:17:32.722 but this will be a substantially different topic 00:17:32.722 --> 00:17:35.500 with a much broader coverage. So we decided we'll 00:17:35.500 --> 00:17:41.500 actually reach out to vendors and ask their opinions as well. And we actually got quite a 00:17:41.500 --> 00:17:44.319 lot of very interesting thoughts. So we did, I 00:17:44.319 --> 00:17:47.200 had to do kind of a second round of re-planning 00:17:47.300 --> 00:17:50.153 and finalizing the scope for our report. And 00:17:50.153 --> 00:17:53.200 we finally have this. I hope it will be in good 00:17:53.300 --> 00:17:56.700 agreement between customer expectations and what 00:17:56.700 --> 00:18:00.100 vendors are already offering. And this is how we 00:18:00.100 --> 00:18:02.523 define zero trust platforms in this sense. So 00:18:02.523 --> 00:18:05.000 there will be a very specific set of criteria. 00:18:05.800 --> 00:18:08.477 They're actually already available on our website. 00:18:08.477 --> 00:18:11.100 Anybody interested should go and have a look. And 00:18:11.100 --> 00:18:16.600 of course, if you are a vendor offering such a solution, you are very welcome to reach out 00:18:16.600 --> 00:18:18.893 directly to us and hopefully participate in 00:18:18.893 --> 00:18:21.400 this report. Right. And for the audience that's 00:18:21.400 --> 00:18:24.044 listening, yes, this is something that is a new 00:18:24.044 --> 00:18:26.800 approach also to make transparent where we are in 00:18:26.800 --> 00:18:29.431 that research process, that we are, as you 00:18:29.431 --> 00:18:32.500 said, in the refinement of the market definition, 00:18:32.900 --> 00:18:38.300 but also really saying, okay, we expect this to be useful to both end user organizations 00:18:38.300 --> 00:18:45.100 and to vendors to participate here and to really extend, expand, and improve that 00:18:45.100 --> 00:18:48.492 overall zero trust market, it being so big. 00:18:48.492 --> 00:18:52.200 So we really want to make clear and transparent 00:18:52.200 --> 00:18:54.829 that this is a way to move forward. And as you 00:18:54.829 --> 00:18:57.400 said, if you are a vendor providing solutions 00:18:57.400 --> 00:18:59.787 that you think fit into that overall 00:18:59.787 --> 00:19:03.700 architecture approach and to that platform approach and can 00:19:03.700 --> 00:19:06.382 significantly contribute, yes, please reach 00:19:06.382 --> 00:19:09.500 out. And for those who like me want to have a good 00:19:09.700 --> 00:19:13.140 approach for implementing such a zero trust 00:19:13.140 --> 00:19:16.900 platform that is stable, but flexible to extend 00:19:16.900 --> 00:19:19.172 for all types of identities, as you've 00:19:19.172 --> 00:19:22.400 described. And it's also stable for the next 10 years, 00:19:22.500 --> 00:19:24.550 and we don't know what happens. We talked 00:19:24.550 --> 00:19:27.100 about predictions. So this would be a good starting 00:19:27.100 --> 00:19:32.000 point. So our request is really reach out to us, reach out to Alexei when you're a vendor, 00:19:32.200 --> 00:19:37.000 and to watch the space on the Coupling & Co website when it comes to learning more about 00:19:37.000 --> 00:19:42.800 zero trust platforms. Anything that I've forgotten? Well, I would like to emphasize 00:19:42.800 --> 00:19:50.100 our approach has always been before starting something big, we should kind of pave the way 00:19:50.100 --> 00:19:53.600 for it with smaller, shorter, more digestible 00:19:53.600 --> 00:19:57.100 content for everybody to understand what it's 00:19:57.100 --> 00:19:59.400 actually all about. And I guess a good starting 00:19:59.400 --> 00:20:01.700 point would be a leadership brief on zero trust 00:20:01.700 --> 00:20:05.026 platforms, which was published on our website 00:20:05.026 --> 00:20:08.500 back in December, very close to Christmas time, 00:20:08.500 --> 00:20:15.100 I'm afraid for the state of your radar, but you can definitely revisit. It's a very short 00:20:15.100 --> 00:20:17.106 document where I try to summarize all the 00:20:17.106 --> 00:20:19.700 things we've discussed in this podcast, but also give 00:20:19.700 --> 00:20:22.867 you a list of very kind of concrete suggestions, 00:20:22.867 --> 00:20:26.100 how to evaluate the potential importance of these 00:20:26.900 --> 00:20:30.089 solutions for your specific scenario, and 00:20:30.089 --> 00:20:33.900 what prerequisites to look for and what things to 00:20:34.200 --> 00:20:37.433 let everyone learn from others' mistakes instead 00:20:37.433 --> 00:20:40.800 of making their own. So definitely looking forward 00:20:41.500 --> 00:20:46.900 to your responses to that publication as well. Exactly. I think I highly recommend that 00:20:46.900 --> 00:20:49.527 leadership brief. And as you said, smaller, more 00:20:49.527 --> 00:20:52.100 digestible formats before we go to a leadership 00:20:52.100 --> 00:20:54.750 compass like this podcast, that's the reason why 00:20:54.750 --> 00:20:57.400 we're talking about that. We really want to gain 00:20:57.500 --> 00:21:00.220 the attention of everybody who can reasonably 00:21:00.220 --> 00:21:03.000 contribute to that topic. And that's why we're 00:21:03.100 --> 00:21:05.741 here. We've made that claim. We made that ask 00:21:05.741 --> 00:21:08.500 towards you. So please follow up with us, watch 00:21:08.500 --> 00:21:11.244 the space because we will cover this as well 00:21:11.244 --> 00:21:14.300 and talk more about zero trust platforms, because 00:21:14.400 --> 00:21:20.800 I think that is really the sum of properly created security architectures, including 00:21:20.800 --> 00:21:27.200 identity and cybersecurity. And I think that is really a good way to move forward. Alexei, 00:21:27.200 --> 00:21:29.878 thank you very much for giving that insight also 00:21:29.878 --> 00:21:32.500 into your research process. I think that's also 00:21:32.500 --> 00:21:38.900 shedding some light into things that usually happen more on your desk and where nobody has 00:21:38.900 --> 00:21:41.622 some insight into. And I think it's really great 00:21:41.622 --> 00:21:44.400 to have this transparency. And I'm really looking 00:21:44.400 --> 00:21:47.362 forward to reading this zero trust platform 00:21:47.362 --> 00:21:50.600 leadership compass in six months, seven months. 00:21:50.600 --> 00:21:53.785 That would be the timeframe, I assume. Yeah, I 00:21:53.785 --> 00:21:56.900 expect it to be available sometime in summer. 00:21:57.500 --> 00:22:00.481 But before that, we will definitely not keep 00:22:00.481 --> 00:22:03.800 entirely silent. We will be offering more content 00:22:05.300 --> 00:22:11.800 or insights more into what's happening now and what's going to be happening in the future. 00:22:12.300 --> 00:22:17.000 Again, let me reiterate, probably as a final takeaway for this episode, that zero trust 00:22:17.000 --> 00:22:20.486 platform is not a new kind of tool. It's not a 00:22:20.486 --> 00:22:24.200 new buzzword for vendor marketing. It's basically 00:22:24.200 --> 00:22:29.500 a way to package existing capabilities to make sure that they work together in a 00:22:31.200 --> 00:22:35.600 sensible and useful manner, that they offer unified coverage, unified visibility, 00:22:36.200 --> 00:22:39.775 and unified control. Because all those tools 00:22:39.775 --> 00:22:44.000 work great in very specific scenarios and use cases, 00:22:44.100 --> 00:22:46.856 but there is still no way to expand zero 00:22:46.856 --> 00:22:50.300 trust uniformly across the entire environment. And 00:22:50.300 --> 00:22:56.100 zero trust platforms are exactly the market's attempt to deliver those kinds of solutions. 00:22:56.300 --> 00:23:01.100 I'm definitely looking forward to those because they are very useful and well, 00:23:01.100 --> 00:23:03.568 there's just no reason not to adopt them 00:23:03.568 --> 00:23:06.900 because they will make your entire security posture so 00:23:06.900 --> 00:23:09.908 much better. Yes, I fully agree. And maybe a 00:23:09.908 --> 00:23:13.600 final thought from my side. One key topic that will be 00:23:13.600 --> 00:23:17.415 handled at the EIC in Berlin in May is making 00:23:17.415 --> 00:23:21.400 your identities zero trust ready. So zero trust 00:23:21.400 --> 00:23:24.017 identities. And this is something you don't 00:23:24.017 --> 00:23:27.000 have to wait for Alexei's report. You should have 00:23:27.000 --> 00:23:29.758 started with this years ago and you should be 00:23:29.758 --> 00:23:32.700 refining that just right now. And best practices 00:23:32.800 --> 00:23:39.900 and experiences will be shared at the EIC when it comes, for example, to zero trust ready 00:23:39.900 --> 00:23:42.579 identities. And I think that's a good starting 00:23:42.579 --> 00:23:45.200 point that then can be integrated into such a 00:23:45.200 --> 00:23:48.900 platform approach. Again, thank you very much, Alexei, for being my guest today, 00:23:49.900 --> 00:23:56.200 running up to EIC and really, yeah, kind of shaping a market. That's great to see. Thank 00:23:56.200 --> 00:24:01.800 you very much. Thank you. And see you in Berlin, I guess. I think so. See you. Bye bye.