Hello there. Good morning. And I hope you can see my slides as well. So I've been asked to talk about a topic, which is becoming very, very much commonly talked about now finding increasingly. So with CSOs, the idea of what they call security debt and that I hope to explain, but it really is all about how do we deal with all of the legacy overdue patches risks we haven't looked at. So that's really what security debt is all about. And I wanted to try and relate it back to some of the comments that Martin Kuppinger made in the opening keynote yesterday, when he talked, talked about that whole plan, build, deliver run cycle about identity, about hybrid environments, about policies and centralized policy management, which to me is centralized policy management is key going forward. So I'd also like to relate it back to the idea of zero trust and how we can adopt a zero trust approach in order to, to try and solve some of this issue of security and technical debt.
If we could go to the next slide, please. So what do we mean by security debt? This is a concept that was thought up about 10 years ago by a chap called Wade Cunningham. And what he was trying to express was the whole issue around all of those technology issues. We have hidden away that we haven't resolved, but will continue to impact and drag us down. So what he is talking about is the whole, some of the practical issues that we face in the, in the, in the modern world, when we are building technology stacks, it, I always say that in the CIA model, the confidentiality, integrity and availability, availability always wins. So there's always this huge pressure between doing things absolutely perfectly correctly, and getting them out into production. So the business can use them. It's the, we will come back to that later.
Let's get it out. Now, fix it in the next build. It's the balance between doing the rights thing and the speed and the priority to get a development out there. And this often leads to pro definitions, bad configurations, all of those kinds of issues that, that we, we find this is split into two areas. And this is the whole idea, which is the, the principle and the interest. And, and it always reminds me of the old credit card or running up alone. You have the principle, which is the amount that you need to pay back in order to modernize your underlying stack and how you're going to control it and how you're going to ensure that security works across it. And then there's the interest, which is the added on, on cost that we have to cover in order to make sure that we can maintain our current activities.
So it's the principle and the interest, both one of which is a capital cost. The other is the daily operational cost that we suffer in order to maintain this old stack. We could go onto the next slide. I've found some research as well, which I found quite fascinating recently by McKinsey, a strategic consultant who looked at the overall percentage of technology that was sort of out date, that sort of tech debt principle. And you could see that they've got some CIO estimates here, which are quite remarkable. This was at over 100 firms. So something like anywhere between 20 to 40% of the, the technology use was really out date and should have been got rid of, and well, over nearly 70% of people were spending more than 10% of their, their new projects to try and resolve that, that tech debt. So there's a huge, huge underlying mass of old technology that we're trying to keep going as well as having to try and fix things and bring new solutions in.
So I thought it's very interesting that, that you had these, these figures. They won't be the same for everybody, but I think in the previous presentations, one of the questions was how do you express this to management? And I think this is one of the ways of expressing it, trying to find out how much you're spending to maintain and run all solutions and how much you need to spend to replace them and how much are obsolete. And this is increasingly important in the hybrid world where we have legacy systems and cloud systems. So if we go onto the next slide, why should security leaders worry about this technical debt? Well, we all know the issue of looking after old systems. They have patching issues. I know many manufacturing companies, for example, have old windows systems that are really outdated. How do you protect them? They, it becomes really difficult because they have an old attack, surface, old operating systems.
They're a nightmare to look after also, by looking after all of the old stuff, we can't spend our money and introduce new systems. And this is one of the issues that we have to face as well. And it means that we have to do a lot of integration in both between the technologies and also into the automation side of things. And in fact, we did a study recently called the security outcome study report, and the biggest request to make a difference from CSOs was integrated tech stacks and technology refreshes. This sort of tends to back up some of these findings. And also we, we, we are all short of money. We never have enough resource. We never have enough money to spend on security. And so if we're having to look after all of the old technology and using older systems, this raises our costs and means we can't actually get more efficient security systems in place.
So really that's why we should be worrying about this technology debt and why we should be looking at how we resolve it. So if we go on to the next slide, please, how, how do we actually start to resolve this? And how do we start to, to, to manage this? Well, I I've always said we should start off with a business approach because they're going to be funding it and look at the priorities and the risk around particular applications or particular assets. And then look at them in, in who owns them. Who's going to be responsible for them. And how important are they to the business? And it then gets down to the business of how can we measure this debt? How many old systems have we got? How many of them require special security measures? How many people are involved in that and how expensive is that?
And that's part of the, the cost of technical debt and how that limits, what we can do with new security solutions and protect other areas. For example, specific patching programs can be really quite expensive. We also, I think have seen this issue kick off more, especially in the application development world. I'm gonna talk a little bit more about the infrastructure world, but there it's, it's, we've seen the change from DevOps and DevSecOps. And part of this has been changing that development cycle, making sure that you bring in the risk owners, the, the operational owners, the stakeholders, and understanding those decisions and making sure you build in test cycles around each release and making sure that you bring in people like privacy and, and compliance so that they can understand what is being developed to make sure it matches their, their requirements. So I think that has been picking up we're beginning to build those processes in, to reduce the application debt.
And certainly we, we, we now are seeing a far closer look at applications, and I would just say that one of the big drivers recently in a couple last couple of years, I've seen in organizations has been the issue of privacy where access to applications, what do applications store, how are they used, who owns them has become a driver for a lot of clearing up of loose practices in the past when too many people had access and too much data was held. So a process such as privacy and compliance can be used in order to help us overcome this kind of technical technical debt as well. So we're almost using a business driver to change what we had in the past. If you could go onto the next slide, please.
So, so how does zero trust come into this? The never trust, always verify principle. And I see there's a lot of presentations around that, and there's two elements that can really come into to, to con to play here. One is the whole idea of centralized policy, where you look at the use of the application, the device and the network. So you're always making sure they're maintained and upstate and controlled. You're limiting access, you're controlling access. You're making sure the devices are patched and up to date. So what we're doing there is we're actually using this new approach to start to clear up some of the, the, the technology debt we had in the past. For example, making sure that only the right users can get hold of an application, making sure an application only communicates with the other applications that should communicate with making sure devices are up to date patched. And we do that all through that centralized policy control. This gives us a whole huge, better view and control and visibility over our technology stack and what it does as well, which I think is quite important is that we start to have updates, especially to patching levels done a lot more quickly in part of the whole day to day user process. So we're actually reducing the growth of tech debt by reducing the number of devices. For example, that can be out of date if we can go onto the next slide, please.
So how does this work across the enterprise in terms of, of zero trust? Well, we, we split zero trust into three areas, the workforce, the users, the workload, the applications in the workplace, which is the network access. And as you can see, we have various tests or questions that we put in at the central policy management level. And these can then start to validate they do the verification, the verify, the trust aspect before access is allowed. So if you just look at it, the workforce, one of the most important things is the user validation. Okay. That, that helps us clear up the IAM aspect, giving them the right access. So we limit access. We don't have old identities wandering around with people having access everywhere else, and we make sure that their device is trusted and secure at the point of entry. So that, for example, if there's a desperate patch that needs to be put up, the user has to update the patch on that device before they can be trusted.
And this is brilliant if you're worried about, for example, ransomware attack, where you have to patch each user so that the, the malware can't spread. So the user has to patch, update, get their device under control. So we are limiting the growth and we are solving that, that growth of, of debt out of the, the endpoint. And we're bringing the user into our security team and the same with applications, make sure that applications communicate across the separate other applications that they need to work with and make sure they're secure and trusted, especially if we're in a hybrid world where we're gonna have applications working from cloud to data center, data center to cloud. Often in the past, we had vast sets of firewall rules to control us. And in many instances, controlling at the network level became confused. As people put in the rules, they then left the organization.
Nobody knew what the rules were. Whereas if we can now introduce rules at the, the operating system level application to application, it makes it a lot cleaner. So, so that's one of the great benefits of, of this kind of approach and are saying, if we do have devices on the network, let's check that they're up to date, make sure that they are correct and can be trusted. So what we're doing there again is we're, we are reducing the, the risk of there being an outdated device or device that we don't know about accessing our, our network, making sure that our centralized policy drives the level that is required for authentication and then making our network segmentation based on those trust levels and network segmentation is critical across all of these different areas, because the one thing we don't want is users going in with over the ability to move across a network so we can limit lateral movements and having loose control at that level could well enable lateral movement to any, any attack who got in, in terms of the risk.
I tend to start at the workforce because that is the biggest door going in. You'll look at studies, Verizon and people all say at about 80% of all breaches are through that front door, through the workforce. So that's a really easy place to start in terms of it being the best way to reduce risk. So I think that that's, that's probably, if we look at, look at that in terms of simplicity, that's probably where we should go for. So it's about increasing trust by reducing that technical debt. And we can do this by implementing new integrated solutions that are going to give us that centralized policy management and enable us to understand ownership a lot better control access, and make sure that devices at the very most basic level are up to date. So we don't have that debt of out date patching that needs to be done it to give you one instance of how this works back to those, those key questions.
I mentioned, I've spoke to one CISO who wanted to start looking at this across applications, because as he said, I can now work out who owns the applications. So it gives me a far better sense of visibility and control. And I can then put in sensible policy management the same at the workforce often when implemented, you'll find out devices that you didn't know about. So you get better visibility and control. And whether it's a, B Y O D device or a managed device, you can bring in different levels of control and different different levels of policy to define patching and so forth. So this is about patching, updating visibility control at the point of access, reducing that debt, and then reducing the principle. We can go down onto the final slide, go to the next slide, please. So how, how do we address this issue?
First of all, it's going to take a long time. It's going to be a journey. So start to think of where you can begin. And as I said, often, the workforce is the easiest place to start, because that is the place where you need to reduce the risk. The most, a lot of communication across stakeholders will be required, which is why I go back to that research from McKinsey to try and explain to people that you in fact are increasing the overhead the whole time by having this old technology around the place. What I think you can also do is, is by bringing in this framework, you can reassure them for example, that if an application switches from the data to enter to the cloud. So you're getting rid of that technology debt in the, in the data center, you will still be able to move quickly and quite easily.
As one CISO said to me, when we switch an application to the cloud, it should not be how do we get the users to access it, but rather when, who let's get it done tomorrow should be easy. So build that framework based on zero trust around that, if you start where the risk is highest, you will get buy in from the business, cuz you're talking, their language business is about risk and opportunity. And if you can reduce that debt, you can also provide more opportunity. So start thinking about a risk operational context and bring in those stakeholders, think about application development as well and how that is is operated. We can do a lot more checking for vulnerabilities and so forth through automated means nowadays. So how can we maintain and bring in a structured process of checking and testing, automating releases, making sure we get better definitions of what is required as well.
That goes back to communication with the stakeholders. And most of the last two points about centralized policy management of platform solutions are probably joined together because what we're finding now is platform solutions are becoming far more easy to manage. You don't build up security technology debt, where you have to go integrate all of these technologies and one changes. So you have to go back and do more integration work platform solutions are coming with integration already in place between different components. And when talking to CISOs about SASSI and these other new ideas that are coming in, they find that platform approach very useful because they don't have to do the integration. So, so try to make sure that you you're bringing in solutions that are already integrated in and this centralized policy manager church, I think I've said many times, it gives you first of all, the better visibility across the estate across, across what you're trying to protect, but also it enables you to bring in control very rapidly.
So for example, if you are worried about a particular piece of malware zero day or whatever, and you know, you need to patch, update across all your endpoints. You just bring in one simple policy control and every user thereafter will have to update what this means is that if your CMDB or your inventory is out of date, and I've often found that in big environments, you can mitigate that risk of lack of visibility and lack of knowledge by making sure that when people log in, they do that, that updating for you. So it's, it certainly helps reduce that, that debt and principle. So we go onto the next slide and I would just like to thank you all for listening, cause I hope it's has been of some interest to you. I think that technology debt and security debt are going to become topics of the future. So let's look at zero trust and how we can start to bring in integrated platform solutions across those three areas, the workload, the workforce and the workplace in order to mitigate against this, this issue, taking a risk based approach, bringing in all the stakeholders and see if we can help and support our, our organizations be me secure whilst they go through changes, developing hybrid environments and make sure that we are supporting them through that plan, build, deliver, and run process. So that's my few thoughts. Those thank you very much, indeed.
