WEBVTT 00:00:00.000 --> 00:00:16.900 Welcome to the KuppingerCole Analyst Chat. 00:00:16.900 --> 00:00:17.900 I'm your host. 00:00:17.900 --> 00:00:18.900 My name is Matthias Reinwarth. 00:00:18.900 --> 00:00:22.600 I'm analyst and advisor with KuppingerCole Analysts. 00:00:22.600 --> 00:00:26.700 My guests today, it's a plural, I have two guests. 00:00:26.700 --> 00:00:28.600 I have with me Martin Kuppinger. 00:00:28.600 --> 00:00:33.600 He is the principal analyst of KuppingerCole, and Alexei Balaganski, he's a lead analyst 00:00:33.600 --> 00:00:34.600 in cybersecurity. 00:00:34.600 --> 00:00:35.600 Hi, Alexei. 00:00:35.600 --> 00:00:36.600 Hi, Martin. 00:00:36.600 --> 00:00:37.600 Hello. 00:00:37.600 --> 00:00:38.600 Welcome. 00:00:38.600 --> 00:00:44.600 Great to have you, and when I have two guests, it's usually for a good reason, and it is 00:00:44.600 --> 00:00:48.800 again, I want to start with a small anecdote. 00:00:48.800 --> 00:00:58.100 I'm old enough to remember back to 1992 or early 1993, when in the company I was working 00:00:58.100 --> 00:01:03.000 at at that time, a friend or a colleague came in and said, I want to show you the future 00:01:03.000 --> 00:01:06.600 of the internet, and he showed us the World Wide Web. 00:01:06.600 --> 00:01:12.600 By the end of that day, we had created one of the first 10 commercial web servers in 00:01:12.600 --> 00:01:18.100 Germany that was a list at Freie Universität Berlin, where you could look up all these 00:01:18.100 --> 00:01:22.600 internet services, commercial ones, and of course, academic ones. 00:01:22.600 --> 00:01:27.600 By the end of the day, we were really blown away by the idea that there is a decentralized 00:01:27.600 --> 00:01:30.735 failover-capable, secure, democratic 00:01:30.735 --> 00:01:35.700 infrastructure around for spreading information, also for 00:01:35.700 --> 00:01:38.771 doing business, and we were really, really 00:01:38.771 --> 00:01:42.500 looking forward to a bright future of decentralized 00:01:42.500 --> 00:01:47.300 and democratized information provision. 00:01:47.300 --> 00:01:55.300 Fast forward 25 plus years, so 32 years, I think, we want to talk about the internet 00:01:55.500 --> 00:01:58.000 and its status for today. 00:01:58.000 --> 00:02:01.043 And we want to talk about something that 00:02:01.043 --> 00:02:05.000 happened on the 18th of November, that was an outage 00:02:05.000 --> 00:02:10.500 of a platform, of a security and a delivery platform called Cloudflare. 00:02:10.500 --> 00:02:12.500 Alexei, what happened? 00:02:12.500 --> 00:02:17.300 Well, it all went down unexpectedly, as usual. 00:02:17.300 --> 00:02:23.000 I think the first feeling was that half of the entire internet was suddenly unavailable. 00:02:23.000 --> 00:02:29.500 And the worst feeling for an IT specialist, I guess, is that you cannot do anything. 00:02:29.500 --> 00:02:31.800 It's somebody else's problem. 00:02:31.800 --> 00:02:33.700 It's a global scale problem. 00:02:33.700 --> 00:02:38.600 And not only you cannot fix it yourself, you cannot even find out what's going on. 00:02:38.600 --> 00:02:44.600 So basically, we had to wait for hours and refreshing the Cloudflare status page and 00:02:44.600 --> 00:02:49.300 seeing that, yes, they are working on the investigation and bringing back the services 00:02:49.300 --> 00:02:50.700 slowly. 00:02:50.700 --> 00:02:56.200 And of course, in the end, we found out it was another, quote-unquote, honest mistake 00:02:56.200 --> 00:03:01.600 of somebody pushing out an incorrect configuration or something like that. 00:03:01.600 --> 00:03:05.000 Basically, it's definitely not the first time a company does something like that. 00:03:05.000 --> 00:03:10.500 It's not even the first time for Cloudflare or an oops like that. 00:03:10.500 --> 00:03:13.600 And all that scale and impact. 00:03:13.600 --> 00:03:16.400 The issue is basically, what can we do next time? 00:03:16.400 --> 00:03:20.500 Apparently, some vendors just don't learn from their own mistakes. 00:03:20.500 --> 00:03:23.510 Can we make them or should we do something, 00:03:23.510 --> 00:03:26.800 should we prepare and be ready for such outages 00:03:26.800 --> 00:03:28.200 ourselves and can we even? 00:03:28.200 --> 00:03:30.900 I guess this is exactly what we are going to discuss today. 00:03:30.900 --> 00:03:38.400 If we look at the architecture, way back in 1993, we had three servers, PC, SEO, Unix, 00:03:38.400 --> 00:03:39.600 to be precise. 00:03:39.600 --> 00:03:43.600 And if I switched one off, then that portion of the internet would go down. 00:03:43.600 --> 00:03:49.900 Today, we have the architectural possibility that the outage of one service takes half 00:03:49.900 --> 00:03:50.900 of the internet down. 00:03:50.900 --> 00:03:53.600 That would have been impossible way back then. 00:03:53.600 --> 00:03:55.800 So what changed from an architectural perspective? 00:03:55.800 --> 00:04:00.900 And maybe that is the lever to use how we can look at that, Martin. 00:04:00.900 --> 00:04:01.900 Yeah. 00:04:01.900 --> 00:04:05.189 So I think, when we go back, even before 00:04:05.189 --> 00:04:09.300 1992, before the World Wide Web, I think the basic 00:04:09.300 --> 00:04:14.050 idea when we go back in the anti-history was to 00:04:14.050 --> 00:04:18.800 build a resilient communication infrastructure, 00:04:18.800 --> 00:04:19.800 a resilient communication network. 00:04:19.800 --> 00:04:27.700 It was the whole idea behind everything from ARPANET and others, starting, whatever, in 00:04:27.700 --> 00:04:31.205 the 1960s or so, if I'm right, which really 00:04:31.205 --> 00:04:35.200 took a long time then to become what the internet 00:04:35.200 --> 00:04:37.200 and the web, et cetera, were. 00:04:37.200 --> 00:04:40.000 And this is the foundation. 00:04:40.000 --> 00:04:45.800 There are definitely elements when you go to the, so to speak, core of the internet, 00:04:45.800 --> 00:04:48.200 which are still built for that resilience. 00:04:49.200 --> 00:04:57.900 You can have multiple DNS servers, et cetera, and the traffic finds its path, in a sense. 00:04:57.900 --> 00:05:03.800 So at the end, the underlying infrastructure still follows this principle. 00:05:03.800 --> 00:05:09.900 What has changed is that we have more and more overlays, one thing, like content delivery 00:05:09.900 --> 00:05:16.600 networks, and we have more and more very widely used services that can potentially fail. 00:05:16.600 --> 00:05:20.400 We have seen these failures virtually everywhere. 00:05:20.400 --> 00:05:24.400 We have seen CDNs like Fastly having their issues. 00:05:24.400 --> 00:05:28.500 We have seen email security solutions like Proofpoint. 00:05:28.500 --> 00:05:31.100 We have seen Cloudflare. 00:05:31.100 --> 00:05:38.200 We have seen AWS, certain microservices, soft services, et cetera, being off for a while. 00:05:38.200 --> 00:05:42.700 And a while, basically, when we look at our usage and consumption at a global level, a 00:05:42.700 --> 00:05:45.800 while is everything above a few seconds. 00:05:45.800 --> 00:05:52.400 But we have had these outages in the hours up to days range, sometimes even mostly several 00:05:52.400 --> 00:05:54.200 hours, happening every now and then. 00:05:54.200 --> 00:05:56.200 And this is impacting business. 00:05:56.200 --> 00:05:57.200 Right. 00:05:57.200 --> 00:06:03.800 And if we look at these platforms that are obviously built on top of the regular internet 00:06:03.800 --> 00:06:08.700 infrastructure, they are providing redundancy, failover, segmentation, as long as they're 00:06:08.700 --> 00:06:09.700 working. 00:06:09.700 --> 00:06:14.700 And as you said, Alexei, once we use these services and they're working all the time, 00:06:14.700 --> 00:06:20.500 most of the time pretty well, but if they go away, we're potentially lost and not able 00:06:20.500 --> 00:06:21.500 to do anything. 00:06:21.500 --> 00:06:27.700 So this consolidation or concentration or lock-in, is this really something that we 00:06:27.700 --> 00:06:29.800 should reconsider, Alexei? 00:06:29.800 --> 00:06:37.300 Well, you just used the very E word for this whole discussion, platform. 00:06:37.300 --> 00:06:39.561 Everybody nowadays, especially in the 00:06:39.561 --> 00:06:42.800 security business, everybody wants to have a platform 00:06:42.800 --> 00:06:44.800 for one simple reason. 00:06:44.800 --> 00:06:51.600 If you have just one universal tool, which combines and unifies multiple functionalities 00:06:51.600 --> 00:06:57.600 and reporting capabilities and whatnot, it's obviously much easier and cheaper both to 00:06:57.600 --> 00:07:01.600 run and to use as a consumer, the customer. 00:07:01.600 --> 00:07:07.800 So of course, companies like CloudFlare and Palo Alto Networks, and even though all the 00:07:07.800 --> 00:07:10.489 big cloud hyperscalers, of course, they push 00:07:10.489 --> 00:07:13.300 this notion that the platform is always better 00:07:13.300 --> 00:07:16.100 than an independent set of tools. 00:07:16.100 --> 00:07:21.400 Even if each of those tools is best of breed on its own, it's then your responsibility 00:07:21.400 --> 00:07:23.427 and a lot of work to basically juggle all 00:07:23.427 --> 00:07:25.900 those tools and make sure that they work together. 00:07:25.900 --> 00:07:30.900 So they will happily take this burden off you for a price. 00:07:30.900 --> 00:07:36.600 And they promise, of course, to have an easy, universal experience where you only need a 00:07:36.600 --> 00:07:40.600 credit card to unlock the entire digital business, if you will. 00:07:40.600 --> 00:07:45.000 But then again, the same applies to them as service providers, too. 00:07:45.000 --> 00:07:47.469 If it's really a platform designed by the 00:07:47.469 --> 00:07:50.600 lowest bidder, if you will, if it's an architecture, 00:07:50.600 --> 00:07:55.400 well, the only reason to make it integrated is to reduce cost. 00:07:55.400 --> 00:07:58.862 Of course, if some tiny part of this platform 00:07:58.862 --> 00:08:02.400 fails, you just have this whole domino effect. 00:08:02.600 --> 00:08:09.000 If basically the entirety of your international cloud architecture depends on a single DNS 00:08:09.000 --> 00:08:16.400 service in one of the regions, obviously it will never survive a nuclear blast as it was 00:08:16.400 --> 00:08:18.100 originally intended by DARPA. 00:08:18.100 --> 00:08:23.400 It won't even survive an intern unplugging their own cable from a network, right? 00:08:23.400 --> 00:08:27.000 It goes down because of a simple mistake. 00:08:27.000 --> 00:08:30.300 And then again, half of the Internet goes down with it. 00:08:30.300 --> 00:08:36.800 This is exactly the direct consequence of platformization of the entire Internet, if 00:08:36.800 --> 00:08:37.800 you will. 00:08:37.800 --> 00:08:38.800 Yeah. 00:08:38.800 --> 00:08:42.000 And I think there are two aspects maybe to bring in. 00:08:42.000 --> 00:08:46.259 The one is vendors, platform providers 00:08:46.259 --> 00:08:52.200 potentially could do a better job in increasing their 00:08:52.200 --> 00:08:56.200 own availability and resilience against failure. 00:08:56.200 --> 00:08:58.100 And failure happens. 00:08:58.100 --> 00:09:03.300 The other is, I think, the equation a lot of customers use for making decisions might 00:09:03.300 --> 00:09:10.600 be somewhat incomplete because it looks at, I think what customers frequently don't factor 00:09:10.600 --> 00:09:21.800 in sufficiently is the risk and cost of outages, of failure, and also the lock-in risk. 00:09:21.800 --> 00:09:23.800 I think these are different aspects. 00:09:24.400 --> 00:09:27.706 When I look at the first one, let's take 00:09:27.706 --> 00:09:32.500 something where something leads to updates being installed 00:09:32.500 --> 00:09:39.600 on a large number of endpoints and bring these endpoints down. 00:09:39.600 --> 00:09:44.800 Something by the way, me as a Windows user from basically more or less day one, I remember 00:09:44.800 --> 00:09:52.400 these Microsoft patches in the past, which brought down a lot of Windows systems. 00:09:52.400 --> 00:09:57.000 We haven't seen these major things, I've seen whatever, 15 or 20 years ago, we haven't 00:09:57.000 --> 00:10:01.500 seen them for a very, very long time. 00:10:01.500 --> 00:10:06.500 Hopefully this remains as it is, but I think you can improve. 00:10:06.500 --> 00:10:08.600 And I think it's very important to learn from 00:10:08.600 --> 00:10:10.700 failure, but I think it's also important that 00:10:10.700 --> 00:10:14.576 vendors put in, I would say, controls to 00:10:14.576 --> 00:10:20.100 understand whether changes have an impact to stop changes 00:10:20.100 --> 00:10:22.400 to roll back quickly if needed. 00:10:22.400 --> 00:10:28.200 So if I take rolling out an update and then you observe first in Australia, oh, there 00:10:28.200 --> 00:10:34.000 are issues, but it runs all over the globe, through all the time zones, hour by hour, 00:10:34.000 --> 00:10:39.400 and you can't stop it, why not having something in which is basically a kill switch? 00:10:39.400 --> 00:10:45.500 Something where the update component, the update service asks central components first, 00:10:45.500 --> 00:10:47.800 can I run this update now or not? 00:10:47.800 --> 00:10:51.281 If you collect telemetry data, you then have 00:10:51.281 --> 00:10:55.000 an option for a kill switch, easy to implement, 00:10:55.000 --> 00:10:57.600 really not rocket science at all, things like that. 00:10:57.600 --> 00:10:59.600 I think we need to also think a bit beyond. 00:10:59.600 --> 00:11:01.165 So I think that would be one call to the 00:11:01.165 --> 00:11:03.200 vendors, looks like you want to say something before 00:11:03.200 --> 00:11:07.900 I move to the other side, the end user side, Alexei? 00:11:07.900 --> 00:11:10.140 I just wanted to say, what you are talking 00:11:10.140 --> 00:11:12.700 about is an easy question you could ask yourself 00:11:12.700 --> 00:11:16.800 because you already know the answer, if you will, but unfortunately not everybody in the 00:11:16.800 --> 00:11:19.800 world is as responsible and forward thinking. 00:11:19.800 --> 00:11:22.600 A lot of people just, well, why not? 00:11:22.600 --> 00:11:25.500 Because nobody ever thought about it until it's too late. 00:11:25.500 --> 00:11:30.400 But the problem is not that, I mean, we are all human, the world is human after all. 00:11:30.400 --> 00:11:34.700 The problem is that a lot of people continue not thinking about this even after the first 00:11:34.700 --> 00:11:35.700 issue. 00:11:35.700 --> 00:11:43.500 You know, we are analysts and we analyze software services for decades. 00:11:43.500 --> 00:11:47.800 Maybe even before doing as an IT freelance journalist, I think since 35 years, I look 00:11:47.800 --> 00:11:54.100 at software and it was always interesting to see that there were mistakes that were 00:11:54.100 --> 00:11:58.300 made by many recurring and could have been easy to fix. 00:11:58.300 --> 00:12:05.000 So I remember back in the days, I had a lot of Windows NT software and Windows NT services 00:12:05.000 --> 00:12:06.000 installed. 00:12:06.000 --> 00:12:13.500 And in the early days, a lot of them failed coming from US or UK software vendors. 00:12:13.500 --> 00:12:19.400 I installed them on a German version of NT and it didn't work because they were looking 00:12:19.400 --> 00:12:23.800 for the group domain admins. 00:12:23.800 --> 00:12:26.900 But in German, it says domain administrator. 00:12:26.900 --> 00:12:33.200 So the text string is different, but the GID below it was the same. 00:12:33.200 --> 00:12:36.900 So they just would have done it right following the APIs and it would have worked. 00:12:36.900 --> 00:12:41.800 And I saw plenty of solutions until they learned in some sense. 00:12:41.800 --> 00:12:48.700 And yes, I think it's an important thing that vendors, and for many areas, step back and 00:12:48.700 --> 00:12:50.200 think about what can we do differently. 00:12:50.200 --> 00:12:53.563 So really also a bit of a shift left thinking, 00:12:53.563 --> 00:12:57.000 maybe thinking about what is really a different 00:12:57.000 --> 00:12:59.000 way to tackle it. 00:12:59.600 --> 00:13:03.300 By the way, this is also something analysts are there for. 00:13:03.300 --> 00:13:07.000 I think we won't fix everything, we won't have a great idea for everything, but I think 00:13:07.000 --> 00:13:13.000 we are extremely good sparring or discussion partners to think about maybe from a broader 00:13:13.000 --> 00:13:14.600 perspective of how you could fix this. 00:13:14.600 --> 00:13:19.300 So just reach out to us because this is where the experts are there for. 00:13:19.300 --> 00:13:22.800 The other thing I think is clearly on the end user side. 00:13:22.800 --> 00:13:31.100 And I think we massively, or the customer side, we massively tend to underestimate price. 00:13:31.100 --> 00:13:33.681 We have to pay for some of the things like 00:13:33.681 --> 00:13:37.000 platformization, like the super powerful hyperscalers. 00:13:37.000 --> 00:13:40.400 There are always consequences. 00:13:40.400 --> 00:13:42.800 There's no such thing as a free lunch. 00:13:42.800 --> 00:13:45.800 So platformization comes at a cost. 00:13:45.800 --> 00:13:48.200 It comes at a promise and a cost. 00:13:49.200 --> 00:13:55.400 I think one of the things we probably will discuss more in the future, but I think when 00:13:55.400 --> 00:14:01.400 you, for instance, count the number of services of hyperscalers and other cloud providers, 00:14:01.400 --> 00:14:05.400 you can come to the conclusion that some of the well-known hyperscalers are by far the 00:14:05.400 --> 00:14:08.600 best because they have the most services. 00:14:08.600 --> 00:14:11.000 But what happens if you use all of these services? 00:14:11.000 --> 00:14:14.600 You hardly can then run a multi-cloud strategy anymore. 00:14:14.600 --> 00:14:20.200 You hardly can move to a sovereign cloud if you want or need to do that because you 00:14:20.200 --> 00:14:21.200 have a lock-in. 00:14:21.200 --> 00:14:27.000 And I think what everyone, what you don't do well overall when we do product decisions 00:14:27.000 --> 00:14:31.400 is thinking about how do I get out of it again? 00:14:31.400 --> 00:14:35.500 This is one of the most fundamental questions. 00:14:35.500 --> 00:14:38.000 So what can go wrong? 00:14:38.000 --> 00:14:41.600 What happens if this fails and how do we get out? 00:14:41.600 --> 00:14:44.000 Ask these questions. 00:14:44.000 --> 00:14:50.000 You know, this reminds me of a really old joke about a guy who just found a new job 00:14:50.000 --> 00:14:55.200 at a firefighter station and basically his friends asked him, how is it going? 00:14:55.200 --> 00:14:56.900 How are you enjoying your job so far? 00:14:56.900 --> 00:14:59.100 He said, you know, it's awesome. 00:14:59.100 --> 00:15:04.800 I get to just sit on my couch all day long, eating sandwiches, watching TV, would love 00:15:04.800 --> 00:15:05.900 to do it the whole life. 00:15:05.900 --> 00:15:11.800 But you know, every time there is a fire, I'm seriously considering quitting. 00:15:11.800 --> 00:15:15.148 And I think this kind of perfectly describes 00:15:15.148 --> 00:15:18.800 the whole situation in the IT industry nowadays. 00:15:18.800 --> 00:15:23.100 I guess it's all in this whole, it's a cultural thing, if you will. 00:15:23.100 --> 00:15:28.000 Like we have this tinkerer culture in the whole IT industry and some people just have 00:15:28.000 --> 00:15:30.700 never grown up from that stage. 00:15:30.700 --> 00:15:36.200 They love to play with things, nowadays are very expensive and kind of cloud scale things 00:15:36.200 --> 00:15:37.200 as well. 00:15:37.200 --> 00:15:38.913 But they never think about the real 00:15:38.913 --> 00:15:41.800 responsibilities of an adult, consequences of their actions 00:15:42.200 --> 00:15:45.300 If something goes down, somebody has to pay for it. 00:15:45.300 --> 00:15:48.000 And if it's not you, who then? 00:15:48.000 --> 00:15:53.200 Until our industry grows up, well, we will be facing this challenges over and over again. 00:15:53.200 --> 00:15:57.400 And I think it's also, basically, this is also one of the reasons why most organizations 00:15:57.400 --> 00:16:01.200 have a sew of tools in cybersecurity. 00:16:01.200 --> 00:16:06.500 Because okay, something goes wrong, I need a tool to fix it without thinking too much 00:16:06.500 --> 00:16:09.100 about could I do this in a different way? 00:16:09.100 --> 00:16:12.300 Maybe I have tools, I just need to use them the right way. 00:16:12.300 --> 00:16:14.300 How do I handle these tools, et cetera? 00:16:14.300 --> 00:16:17.400 I think overall, and I think this holds true for everything. 00:16:17.400 --> 00:16:22.600 If you go for a content delivery network, it's very clear that helps you in delivering 00:16:22.600 --> 00:16:23.600 your content. 00:16:23.600 --> 00:16:27.500 If it goes down, you're in trouble. 00:16:27.500 --> 00:16:30.900 So what is your exit strategy or what is your failover strategy? 00:16:30.900 --> 00:16:34.900 This is the question which isn't asked frequently enough. 00:16:34.900 --> 00:16:36.300 And there might be consequences. 00:16:36.300 --> 00:16:41.400 If you say, I don't want to rely on a single hyperscaler, I go for a multi-cloud strategy 00:16:41.400 --> 00:16:48.200 and I want to leave the door open for having serenity, at least in certain critical areas, 00:16:48.200 --> 00:16:50.800 then it means you can't utilize all the services. 00:16:50.800 --> 00:16:54.800 And then it means, okay, then I need to pay a price for it. 00:16:54.800 --> 00:17:00.500 And I think we must become more honest to ourselves as decision makers to ask these 00:17:00.600 --> 00:17:06.500 questions and to think about the fallback strategies, the failover strategies, all the 00:17:06.500 --> 00:17:10.700 stuff we need to have in place, depending on the criticality and the risk of a service. 00:17:10.700 --> 00:17:15.500 Some of the services we may say, we don't care much if they're out for a couple of hours. 00:17:15.500 --> 00:17:19.700 For other services, it's just business critical that they run. 00:17:19.700 --> 00:17:25.700 So if your business depends on selling stuff over the internet and your servers are not 00:17:25.700 --> 00:17:32.000 available for a couple of hours, then it costs you effectively revenue. 00:17:32.000 --> 00:17:34.980 One of the consequences of this platformization is 00:17:34.980 --> 00:17:37.900 if you, for example, go in, let's say CloudFlare, 00:17:37.900 --> 00:17:41.234 kind of emit to all of their services 00:17:41.234 --> 00:17:46.100 completely, it's not easy to switch off it in terms of 00:17:46.100 --> 00:17:47.100 a crisis. 00:17:47.100 --> 00:17:49.200 Like if it goes down, everything goes down. 00:17:49.200 --> 00:17:53.600 If for example, your DNS is hosted on CloudFlare as well, you will never be able to switch 00:17:53.600 --> 00:17:56.700 to a different CDN, even if you have one. 00:17:56.700 --> 00:17:59.480 So do you have to kind of build another 00:17:59.480 --> 00:18:03.400 independent overlay on top of all those overlays on top 00:18:03.400 --> 00:18:09.500 of the internet, or do we have to come up with some completely new 40-year-old networking 00:18:09.500 --> 00:18:12.700 patterns which we forgot how to use in the cloud times? 00:18:12.700 --> 00:18:19.200 Yeah, I think that the first question is making up your mind, can I stand these scenarios? 00:18:19.200 --> 00:18:24.000 And I think we have sufficient examples of what has happened already. 00:18:24.000 --> 00:18:30.500 And we can extrapolate that other situations will occur. 00:18:30.500 --> 00:18:32.891 There's a likeliness that something will 00:18:32.891 --> 00:18:36.000 happen also in the not too distant future that takes 00:18:36.000 --> 00:18:37.500 longer than a couple of hours. 00:18:37.500 --> 00:18:42.900 And then the question is, which are the services you need to have up and running and where 00:18:42.900 --> 00:18:47.300 you say, okay, if the risk is too high because I can't easily build a failover, then you 00:18:47.300 --> 00:18:51.300 need to take a different route, probably. 00:18:51.300 --> 00:18:53.675 You have to think even deeper than that, because 00:18:53.675 --> 00:18:56.000 you have to consider your entire digital supply 00:18:56.000 --> 00:18:57.300 chain too. 00:18:57.300 --> 00:19:02.300 If you are, as you just mentioned, an online store, and if you are worried about your CDN 00:19:02.300 --> 00:19:06.200 going down, fine, you can build a second one or a third one. 00:19:06.200 --> 00:19:11.500 But what if your credit card processor goes down as well, because it was also dependent 00:19:11.500 --> 00:19:13.200 on CloudFlare? 00:19:13.200 --> 00:19:17.600 What if your identity provider is down as well? 00:19:17.600 --> 00:19:24.200 What if your whole security stack is unavailable because it was exclusively supposed to be 00:19:24.200 --> 00:19:28.300 managed through the cloud, and the cloud is down? 00:19:28.300 --> 00:19:31.550 Where do you draw the line before reinventing 00:19:31.550 --> 00:19:34.800 the entirety of your existing infrastructure? 00:19:34.800 --> 00:19:37.600 Yeah, I think it's a tricky question. 00:19:37.600 --> 00:19:42.100 I think the first thing is to be aware of what can go wrong. 00:19:43.100 --> 00:19:45.749 If it's a manual process for certain things, 00:19:45.749 --> 00:19:48.700 and yes, if you say, I don't build on a platform, 00:19:48.700 --> 00:19:52.700 then you have to pay the price somewhere else. 00:19:52.700 --> 00:20:00.700 It's not that saying, I just don't use them doesn't solve the challenge. 00:20:00.700 --> 00:20:03.700 It is about understanding what it means if you do something. 00:20:03.700 --> 00:20:06.800 I think this is the main point, and then making a really informed decision. 00:20:07.000 --> 00:20:12.100 I think we can transform this to a much simpler scenario. 00:20:12.100 --> 00:20:21.700 I know a lot of organizations that ended up with EntraID as their primary system for user 00:20:21.700 --> 00:20:26.302 authentication on the endpoints, because someone 00:20:26.302 --> 00:20:31.000 made a decision to go for Office 365 or Microsoft 00:20:31.000 --> 00:20:32.500 365. 00:20:33.300 --> 00:20:36.646 The decision wasn't about EntraID, the 00:20:36.646 --> 00:20:41.400 decision was about Microsoft 365, which in consequence 00:20:41.400 --> 00:20:47.300 meant EntraID was there, which triggered our decisions, which can be good or bad. 00:20:47.300 --> 00:20:55.100 I like EntraID, to be honest, but it must not happen that this comes in through the 00:20:55.100 --> 00:20:58.964 back door, without understanding in a 00:20:58.964 --> 00:21:04.500 decision made for a workplace, having a decision that 00:21:04.500 --> 00:21:10.100 has a huge impact on your ecosystem or identity security. 00:21:10.100 --> 00:21:14.900 It's clearly something you can handle, but it has an impact, and doing decisions without 00:21:14.900 --> 00:21:19.900 thinking about the consequences, the full consequences, I think is important. 00:21:19.900 --> 00:21:25.200 One of the most overlooked things is at the end of the day, lock-in. 00:21:25.200 --> 00:21:29.600 What does it mean from a lock-in when you do that or that or that? 00:21:29.600 --> 00:21:32.900 Can you get out of it? 00:21:32.900 --> 00:21:36.900 Relatively simple to get away from your office solution. 00:21:36.900 --> 00:21:41.300 Way more tricky to get away from your ERP system. 00:21:41.300 --> 00:21:47.100 Having this in mind and understanding what you can do helps you also to develop better 00:21:47.100 --> 00:21:48.800 resilience strategies. 00:21:49.300 --> 00:21:53.900 I think this is, at the end, a bit of the starting point, not to assume that there's 00:21:53.900 --> 00:21:57.900 something that doesn't come at a cost. 00:21:57.900 --> 00:22:06.900 You always pay a price for that, and if it's convenient, then there's also a price to pay. 00:22:06.900 --> 00:22:12.100 If I play the devil's advocate, I would say that – or I could say, I never would do 00:22:12.700 --> 00:22:15.397 that, of course – that these platforms 00:22:15.397 --> 00:22:19.300 introduce systemic risk for organizations, and systemic 00:22:19.300 --> 00:22:23.500 risk should be something that should be prevented. 00:22:23.500 --> 00:22:26.122 In all these episodes that I did in this 00:22:26.122 --> 00:22:29.400 podcast, almost every third ended up with the idea 00:22:29.400 --> 00:22:35.100 of proper risk management, understanding and evaluating and mitigating risk, understanding 00:22:35.100 --> 00:22:36.300 what that actually means. 00:22:36.300 --> 00:22:40.800 Of course, these vendors are able and capable of understanding what went wrong. 00:22:40.800 --> 00:22:45.200 Of course, it's documented, everybody knows, and how to fix this issue. 00:22:45.200 --> 00:22:49.600 But the question is – and this is the much more tricky question, as you said, Martin 00:22:49.600 --> 00:22:56.200 – it's really to understand what the user organization, the end user of these systems, 00:22:56.200 --> 00:22:59.788 platforms, or only one platform can actually do 00:22:59.788 --> 00:23:03.300 to mitigate the risks of being out of business 00:23:03.300 --> 00:23:06.000 for six hours, for 12 hours, for 18 hours. 00:23:06.000 --> 00:23:09.351 And these customers could be hospitals, could 00:23:09.351 --> 00:23:13.000 be governmental organizations, could be military, 00:23:13.000 --> 00:23:14.000 could be anything. 00:23:14.000 --> 00:23:17.900 So the question is really, how do I deal with risks? 00:23:17.900 --> 00:23:22.400 So this is way back then, and so we've come full circle. 00:23:22.400 --> 00:23:26.100 It's us understanding what we need to do better. 00:23:26.600 --> 00:23:35.600 There's an established methodology, which is called business impact analysis, BIA. 00:23:35.600 --> 00:23:39.100 Our advisory team does this. 00:23:39.100 --> 00:23:50.500 And it's interesting to see the results of it, because every customer learns about it, 00:23:50.500 --> 00:23:55.500 learns a lot of things when doing this, and understanding which are the things that are 00:23:55.500 --> 00:23:56.500 at risk. 00:23:56.500 --> 00:23:59.844 And I think that is something every 00:23:59.844 --> 00:24:05.100 organization must do to understand which are the really 00:24:05.100 --> 00:24:07.000 business-critical things. 00:24:07.000 --> 00:24:09.476 And if you don't map it to your IT 00:24:09.476 --> 00:24:13.700 infrastructure and understand what happens, there could be 00:24:13.700 --> 00:24:17.300 a situation where you say, okay, with the one approach, I might have a higher risk of 00:24:17.300 --> 00:24:22.500 smaller outages, latency, et cetera. 00:24:22.500 --> 00:24:25.500 With the other, this fixes a lot of this. 00:24:25.500 --> 00:24:28.300 I'm always available, high performance. 00:24:28.300 --> 00:24:37.000 But if it's out for a longer time, this can go beyond the time I can stand a failure. 00:24:37.000 --> 00:24:44.200 So sometimes the one long incident is more problematic than sort of a continuous weakness 00:24:44.200 --> 00:24:46.100 or the other way around. 00:24:46.100 --> 00:24:47.800 And understanding this is important. 00:24:47.800 --> 00:24:52.900 I think at the end, it's about doing this more properly, more thoughtful, and as I've 00:24:52.900 --> 00:24:59.400 said, also really understanding the lock-in risk. 00:24:59.400 --> 00:25:03.700 And as I've said, the most important question when you purchase a software is, how can I 00:25:03.700 --> 00:25:07.100 get rid of it again? 00:25:07.100 --> 00:25:12.100 You need to factor in the access strategy when you actually consider purchasing something. 00:25:12.100 --> 00:25:13.700 Alexei, final thoughts. 00:25:13.700 --> 00:25:16.343 This is not a light ending for an easy 00:25:16.343 --> 00:25:20.100 episode, but what are your thoughts at the end of this 00:25:20.100 --> 00:25:21.100 discussion? 00:25:21.100 --> 00:25:26.400 Well, to put it somewhat bluntly, if I may, I think that we have just collective as the 00:25:26.400 --> 00:25:30.500 entire Western society, not just IT industry or whatever. 00:25:30.500 --> 00:25:33.400 We forgot how to do risk management somehow. 00:25:33.400 --> 00:25:34.400 I don't know. 00:25:34.400 --> 00:25:37.900 Maybe it's because people just kind of got used to, you know, that electricity is always 00:25:37.900 --> 00:25:39.800 coming out of the wall. 00:25:39.800 --> 00:25:42.767 There's always food in the local supermarkets 00:25:42.767 --> 00:25:45.800 and stuff like that, and the ramps are driving 00:25:45.800 --> 00:25:48.300 around and cars don't brake suddenly. 00:25:48.300 --> 00:25:54.200 We are not exposed to risk on a daily basis, as opposed to a lot of countries out there 00:25:54.200 --> 00:25:55.200 in the world. 00:25:55.200 --> 00:25:59.700 So we just forgot that risk management is a thing, and it's a critical survival skill, 00:25:59.700 --> 00:26:03.300 if you will, both for physical and digital businesses. 00:26:03.300 --> 00:26:07.400 And there are rules, as Martin mentioned, there are rules, methodologies of doing it 00:26:07.400 --> 00:26:08.400 properly. 00:26:08.400 --> 00:26:13.100 I mean, at the very basic level, I would say, risk management boils down to, first 00:26:13.100 --> 00:26:17.900 of all, understanding your own business domain, because nobody can tell you how to do your 00:26:17.900 --> 00:26:18.900 business properly. 00:26:18.900 --> 00:26:24.100 But on the other hand, you have to do some mathematics on top of that. 00:26:24.100 --> 00:26:30.500 And of course, there are some basic rules, you know, like there are rules for handling 00:26:30.500 --> 00:26:32.717 guns, for example, which were created by 00:26:32.717 --> 00:26:35.600 people who experience those issues on a daily basis. 00:26:35.600 --> 00:26:40.400 And now you don't have to shoot yourself in the foot to learn how to use guns. 00:26:40.400 --> 00:26:45.700 The same should be applied to clouds, if you will, and everything on the internet. 00:26:45.700 --> 00:26:48.174 You have to be able to learn from other 00:26:48.174 --> 00:26:51.600 people's mistakes, you have to repeat all those stupid 00:26:51.600 --> 00:26:52.600 things. 00:26:52.600 --> 00:26:57.800 I think it's interesting, you know, I think we tend to be somewhat naive sometimes. 00:26:57.800 --> 00:27:03.900 One of my favorite examples, and I wasn't a fan of trust in time, delivery logistics 00:27:03.900 --> 00:27:13.000 way ahead of the pandemic and all the supply chain disruptions that occurred then. 00:27:13.000 --> 00:27:19.600 Because at the end, this was a classical mathematical or a failure in the equation. 00:27:19.600 --> 00:27:27.000 So there was the advantage of lower capital binding, so lower sort of bone capital and 00:27:27.000 --> 00:27:32.300 having only smaller storage units, et cetera. 00:27:32.300 --> 00:27:38.700 All true, but I think every strike already showed, okay, that may disrupt the supply 00:27:38.700 --> 00:27:39.700 chains. 00:27:39.700 --> 00:27:43.800 And it was very clear that there could be larger disruptions of that. 00:27:43.800 --> 00:27:50.300 And I think we have a bit of a tendency to ignore the risk side of things and look more 00:27:50.300 --> 00:27:51.900 at the positive side of things. 00:27:51.900 --> 00:27:54.818 Ideally, economic professors should have done 00:27:54.818 --> 00:27:57.800 it properly when bringing up the idea of trust 00:27:57.800 --> 00:27:58.800 in time. 00:27:58.800 --> 00:28:01.800 Obviously, they didn't do it that well. 00:28:01.800 --> 00:28:03.100 It's true in other areas as well. 00:28:03.100 --> 00:28:08.500 I think, you know, automotive industry right now suffers from availability of chips. 00:28:08.500 --> 00:28:14.600 And at the end of the day, it has been clear for whatever, 15, 20 years at least, that 00:28:14.600 --> 00:28:20.100 the main differentiator in an automobile is not the fuel-powered engine anymore, but what 00:28:20.100 --> 00:28:21.100 is in the chip. 00:28:21.100 --> 00:28:26.300 So that should have been a center of attention of every C-level leader in the automotive 00:28:26.300 --> 00:28:33.600 industry to build resilience and autonomy and sovereignty, in that sense, for this part 00:28:33.600 --> 00:28:34.900 of the vehicle. 00:28:34.900 --> 00:28:39.100 And so I think it's something we can transfer to a lot of other areas in the economy, and 00:28:39.100 --> 00:28:40.700 we need to get better here. 00:28:40.700 --> 00:28:41.700 Yes. 00:28:41.700 --> 00:28:46.700 So the summary for today is that we send all back with some homework, rethinking their 00:28:46.700 --> 00:28:50.000 risk posture and understanding what the actual risks are. 00:28:50.000 --> 00:28:56.200 And that is based on their own business context, and then try to find better solutions to 00:28:56.200 --> 00:28:58.400 processes that are in place. 00:28:58.400 --> 00:29:00.100 Would that be a good summary? 00:29:00.100 --> 00:29:02.000 And that would involve this event as well? 00:29:02.000 --> 00:29:04.900 I would say we cannot do the first step for you. 00:29:04.900 --> 00:29:10.100 We as like IT analysts, like coping your call, because again, only you, your peers in your 00:29:10.100 --> 00:29:14.400 industry know the exact risks, the impacts and probabilities. 00:29:14.400 --> 00:29:18.800 But as soon as you have figured out those numbers and you identified your top priorities, 00:29:18.800 --> 00:29:22.700 this is where experts like ourselves, if you will, come into play. 00:29:22.700 --> 00:29:28.900 This is why you should start talking around, finding the right people and understanding. 00:29:28.900 --> 00:29:31.200 You should learn from other people's mistakes. 00:29:31.200 --> 00:29:32.800 You don't have to do the same. 00:29:32.800 --> 00:29:36.200 You don't have to step on the same rake over and over again. 00:29:36.200 --> 00:29:38.455 And well, the events like our EIC, for 00:29:38.455 --> 00:29:41.600 example, are the right place to talk to those people, 00:29:41.600 --> 00:29:46.500 both successful and formerly unsuccessful in their businesses. 00:29:46.500 --> 00:29:48.600 But at least they've learned their lessons and 00:29:48.600 --> 00:29:50.700 they will be happy to share their experiences. 00:29:50.700 --> 00:29:51.700 Final words, Martin? 00:29:51.700 --> 00:29:55.100 Well, I think we've said enough. 00:29:55.100 --> 00:29:56.500 Just take risk earnest. 00:29:56.500 --> 00:29:57.500 True. 00:29:57.500 --> 00:29:58.500 Okay. 00:29:58.500 --> 00:29:59.500 Thank you very much, Martin. 00:29:59.500 --> 00:30:02.600 Thank you very much, Alexei, for being my guests today. 00:30:02.600 --> 00:30:07.800 And that was, yeah, a tough discussion, but sometimes there are no easy solutions and 00:30:07.800 --> 00:30:11.600 we can even support you in finding not so easy solutions. 00:30:11.600 --> 00:30:16.400 So thank you again, Alexei and Martin, and see you in the next episode sometimes. 00:30:16.400 --> 00:30:18.700 And we are getting close to Christmas. 00:30:18.700 --> 00:30:20.200 Have a happy new year. 00:30:20.200 --> 00:30:23.900 This is the final episode that you're listening to for 2025. 00:30:23.900 --> 00:30:24.900 But don't be too happy. 00:30:24.900 --> 00:30:26.900 I'll be back early next year. 00:30:26.900 --> 00:30:30.900 So there will be more analyst chats in January. 00:30:30.900 --> 00:30:33.900 So thank you again and looking forward to meeting you again. 00:30:33.900 --> 00:30:34.900 Bye-bye. 00:30:34.900 --> 00:30:35.400 Bye.