Analyst Chat
Analyst Chat #64: Applying The Zero Trust Principle To The Software Supply Chain
Martin Kuppinger is one of the founders and the principal analyst of KuppingerCole and he is steering the overall development of the topics covered in KC's research, events and advisory. He joins Matthias to talk about the importance of extending Zero Trust to cover software security, for software in any form (embedded, COTS, as-a-service) and regardless of whether it’s home-grown or externally procured.
Welcome to the KuppingerCole analyst chat. I'm your host. My name is Matthias. I'm not I'm lead advisor and senior analyst at KuppingerCole analysts. My guest today is Martin Kuppinger. He's one of the founders and the principal analyst of KuppingerCole he's steering the overall development of the topics covered in our research events and that we do our advisory in. Hi Martin. Welcome.
Hi, welcome.
Great to have you, and we want to talk about a topic that has come to our attention also in the aftermath of recent cyber security events that we have seen early this year. Uh, but we want to have a look at that topic with a rather different twist. We want to talk about the way that many organizations are currently doing business, and that is by doing a closer focus on their actual core business. They focus on what they are best at, where they Excel in, where they can provide the solutions, which really help the customers. And on the other hand, they rely on a large cyber supply chain where they consume services from, which are just the foundation layer for creating their services. So it's really buying something on the market, incorporating that into a product and then adding their special added value to that. What does that mean when it comes to looking at cybersecurity and looking at supply chain management Martin?
Um, I think Matthias, when we look at what he trusts that, um, this not to blame you, but this already probably includes, uh, the misconcept, which leads to a lot of challenges. And that misconception is that businesses still believe that it they're waiting to software to incorporate software. It's not part of their core business. So there's the saying of every business is a software business these days, which is wasn't factually correct. There are a lot of businesses which aren't, but more and more businesses are software businesses. If you look at the car off today, if you look at many devices you have done, if you look at, um, the factory automation, other areas, there's so much software in everywhere that you are a software business and that's one part of that. And the other thing is that also to be good in digital transformation, to be good in how you do your business, you rely on software and software in a certain area is important, or is it to your competitive advantage as a business? Um, having said this, we can't just say we nor what is the software? We just procure it and assume it will work. It is too important. It's too important at all levels of most organizations already. So we do need to understand what software means, what the risk in software is to our organizations. We need to take a different perspective here,
Right? So we need to apply proper scrutiny when it comes to what we incorporate with, into our products and to our service offerings. Um, there has been this new term being coined, um, called cyber supply chain risk management. Um, but that actually is not really something new. We have seen that earlier before, and this, these, these events have happened before. Um, let's talk a bit about the history behind that. I remember in 2014, there was this event that, um, was named Heartbleed. Um, is this the same and more?
Yeah, I think then two, two elements in history. They want to read the cyber security part of that. And the other is the supply chain, risk management part of it. So the cyber security risk management or the cyber security part in cybersecurity risk management, um, that is clearly one element where we had incidents before heartbeat was a perfect example. Um, another good full allotment. That sounds because it was a major issue, but it has proven that if you trust you certain types of software libraries, you are at risk because you can sort of inherited risks from these libraries. And if you go back even further in the, in the history, then we might end up with the book of Mark Ellis bag, which is called. And that is a book with dressing dates back to the many years. At least I would already have to check how, how old it is, but this describes similar scenarios, effecting infects, really, um, all of Europe by attacking the energy system in Europe.
And so the risk is not new. And on the other hand, we have to supply chain risk management saying, and that also is not new. So I remember when I worked in many, many years ago, um, for awhile in a, in a software development company, we built, so that helped tracking the quality of certain types of supplies to automotive manufacturers. That's way more than 20 years ago. It was a topic back then and supply chain risk management is something which is therefore for relatively long time. The point is with software becoming more and more relevant with cyber risks increasing, it is apparent that we need to add the cybersecurity angle to the entire supply chain, risk management methodology, to the processes. We need to extend it because this is what really can put every business at major risk. So it is not new. No, but it is more important than ever before.
And I think SolarWinds into them has clearly proven that again, that we need to be far more Seraph on software. And you don't want to put this, look at this, that it means we need to understand what to do in my perspective is the most important thing really is that we, when we look at it from a cybersecurity perspective, you all notice concept and this term of zero trust, and we need to apply the principles of zero trust on that part as well. It's not only networks, it's not only identity, it's not only access address things. It's also software. We must not trust software that we approach you. We must verify. And B must verify when we poke you and we must verify continuously. And also that idea of trust just as a side note, it's not that w that you, if you look at, I don't think it's the trauma and the law for, for trade. Um, there's something in around verification and of software. So that is therefore endless times more or less, right?
So if we look at any of our mobile applications that we have on our, on our smartphone, and we look in the about section, we will end up with a, with a large list of open source libraries that have been incorporated just to name them because they had to be named or two to give you credit to those who provided it. Um, but what you're saying means you need to go far beyond that. You need to verify that the software is properly developed and not just take any library from the more or less uncontrolled open-source market. Um, what else is included in this zero trust approach towards software procurement? What else needs to be done? Do we really have to check each line of code that we consume?
Um, I think no one does check all lines of code and check all lines of code. And, um, so I think that brings, it was applied to every type of software versus commercial software off the shelf or open source or whatever else. Um, I think there are a couple of elements we can look at. It starts with the ones who are upgrading software and dare it's about applying these well-known principles of secure by design and the coding practices around to everything which has done in software internally and externally. If we ask someone to develop a software for us, that must be a part of the requirements. So if I say too much, he has much, he has to deliver some piece of soft for me for that on that. And I pay you X Euro. Then I should also ask you and force you to follow the security sign and coding practices, and to prove that you do, and we may need something like, like an ISO standard on that as well, where we say, okay, this is where we really, um, that have our certifications suppliers.
Then the next thing isn't also ha must happen with both analysts. And it can happen to that those times. So that design the coding assumption that you you've kind of regressed, which is relatively difficult to verify that the bigger your software is the harder it is, but the next in like software can position analyze instead of something you can do, um, also for yourself and everyone, every provider should do it. So I know that a lot of software companies are not exactly aware of which for instance, open source libraries, other external libraries are used in which Russian and et cetera, Dany to node. Um, you need to understand that as far as you can. So what I'd libraries, which versions are doesn't own rules or abilities and patches, et cetera. So that would be a second step and done. There are tools for static, for dynamic code on a license that you kind of like clearly your organizational controls as well. So on both ends, really, I was asking to controls, define and enforce that you do to right tracks and all these things. And then there are security analytics at the end. You also need to observe how software behaves and if there are anomalies, you must react. And so there's a lot of technology out there, but so we need to, as a persons for dev ops to, to look at, um, how can we integrate so to speak security, telemetry security forensics in this concept, the technology is there. We just need to do it.
We agreed because if we look at modern, um, built chains for software development, and that is also something that users of unique systems of Linux system see in their daily work, because when they do an upgrade, this, this upgrade, um, incorporates pulling updates of basic libraries from their original repositories in the most recent version. And who knows that this most recent version does not come with more bugs than the version before maybe fixing one, but incorporating two new ones and that needs to be properly tracked. And that is also the case for many software developers, which have modern built chains, modern tool, which as well pull always the newest version that that's for good reasons. But nevertheless, you need to monitor what is actually, um, in the back when you finally, um, compile the final solution. And that is of course, something also that the solar winds incidents showed because there were some changes that were, um, yeah, undesirable and really not expected and dangerous to, to the, to the customers. And along the supply chain
Requesting you, your customer to, to deactivate, uh, whatever anti-malware for installs clearly should always be a sign off. Okay. Maybe we, we, we look at more strict controls in that case. That would be for me, you clear new no-go if you're honest having disaster scenarios and yes, um, we need to do it better and we can do it better. And the good thing at the end of the day is we have all principles available. We have all technologies available. We know how to do, to set up an IMS, how to run an IMS for the information security management system. We know how to do cyber security, supply chain, risk management. We specifically know how to do supply chain, risk management. We have a lot of cybersecurity tools. We have tools for static and dynamic code analyzers. We have increasingly good technology for security monitoring for automated response and other things.
All these things are there. And we have the F a lot of knowledge about good coding practices, secure by design, et cetera. We just need to do it. And yes, when we look at a reality of coding, we see certain organizations which really are strict good coding practices and still have their issues. But we see also ton of organizations with developers, which don't follow these rules and is the point we have everything on hand, you just need to use it. And we need to get better on death because going back to what I said at the beginning, every business is a software business and somebody, at least many businesses are. So that is about also protecting the core of our business, protecting the ability to act on the true transformation, protecting and securing and deliberate, the safety of goods you deliver that incorporate software. That is what we need to do, and its latest time to act now,
Right? And that is an ongoing effort. And in the end, it's also a liability issue because when you produce software, no matter what is incorporated in there in the end, you are liable for what this piece of software does no matter which component actually caused the issue. That might be an issue to these one man show software developer, unicorn companies, but for modern, um, larger scale organizations who are using software within their own boundaries or as a software, which is provided to end users, they really should follow the principles that you just mentioned. Uh, I think that's a great summary for, for this episode of this podcast because it's really, um, making sure that people understand their responsibility, their liability, but also the tasks that need to be executed over time. Any final additions from your side to that
Low trust repeating it's about extending our zero trust approach to the cyber security supply chain, risk management, and always keep in mind don't blindly trust software, but verify it. And then,
And again, we are at, as you mentioned at the zero trust approach. So don't trust, verify every time. Thank you very much, Martin, always a pleasure to have you here and to hear your insight looking forward to having you in upcoming episodes again, and thank you for your time being here today.
Thank you. Bye-bye.
Hi, welcome.
Great to have you, and we want to talk about a topic that has come to our attention also in the aftermath of recent cyber security events that we have seen early this year. Uh, but we want to have a look at that topic with a rather different twist. We want to talk about the way that many organizations are currently doing business, and that is by doing a closer focus on their actual core business. They focus on what they are best at, where they Excel in, where they can provide the solutions, which really help the customers. And on the other hand, they rely on a large cyber supply chain where they consume services from, which are just the foundation layer for creating their services. So it's really buying something on the market, incorporating that into a product and then adding their special added value to that. What does that mean when it comes to looking at cybersecurity and looking at supply chain management Martin?
Um, I think Matthias, when we look at what he trusts that, um, this not to blame you, but this already probably includes, uh, the misconcept, which leads to a lot of challenges. And that misconception is that businesses still believe that it they're waiting to software to incorporate software. It's not part of their core business. So there's the saying of every business is a software business these days, which is wasn't factually correct. There are a lot of businesses which aren't, but more and more businesses are software businesses. If you look at the car off today, if you look at many devices you have done, if you look at, um, the factory automation, other areas, there's so much software in everywhere that you are a software business and that's one part of that. And the other thing is that also to be good in digital transformation, to be good in how you do your business, you rely on software and software in a certain area is important, or is it to your competitive advantage as a business? Um, having said this, we can't just say we nor what is the software? We just procure it and assume it will work. It is too important. It's too important at all levels of most organizations already. So we do need to understand what software means, what the risk in software is to our organizations. We need to take a different perspective here,
Right? So we need to apply proper scrutiny when it comes to what we incorporate with, into our products and to our service offerings. Um, there has been this new term being coined, um, called cyber supply chain risk management. Um, but that actually is not really something new. We have seen that earlier before, and this, these, these events have happened before. Um, let's talk a bit about the history behind that. I remember in 2014, there was this event that, um, was named Heartbleed. Um, is this the same and more?
Yeah, I think then two, two elements in history. They want to read the cyber security part of that. And the other is the supply chain, risk management part of it. So the cyber security risk management or the cyber security part in cybersecurity risk management, um, that is clearly one element where we had incidents before heartbeat was a perfect example. Um, another good full allotment. That sounds because it was a major issue, but it has proven that if you trust you certain types of software libraries, you are at risk because you can sort of inherited risks from these libraries. And if you go back even further in the, in the history, then we might end up with the book of Mark Ellis bag, which is called
And so the risk is not new. And on the other hand, we have to supply chain risk management saying, and that also is not new. So I remember when I worked in many, many years ago, um, for awhile in a, in a software development company, we built, so that helped tracking the quality of certain types of supplies to automotive manufacturers. That's way more than 20 years ago. It was a topic back then and supply chain risk management is something which is therefore for relatively long time. The point is with software becoming more and more relevant with cyber risks increasing, it is apparent that we need to add the cybersecurity angle to the entire supply chain, risk management methodology, to the processes. We need to extend it because this is what really can put every business at major risk. So it is not new. No, but it is more important than ever before.
And I think SolarWinds into them has clearly proven that again, that we need to be far more Seraph on software. And you don't want to put this, look at this, that it means we need to understand what to do in my perspective is the most important thing really is that we, when we look at it from a cybersecurity perspective, you all notice concept and this term of zero trust, and we need to apply the principles of zero trust on that part as well. It's not only networks, it's not only identity, it's not only access address things. It's also software. We must not trust software that we approach you. We must verify. And B must verify when we poke you and we must verify continuously. And also that idea of trust just as a side note, it's not that w that you, if you look at, I don't think it's the trauma and
So if we look at any of our mobile applications that we have on our, on our smartphone, and we look in the about section, we will end up with a, with a large list of open source libraries that have been incorporated just to name them because they had to be named or two to give you credit to those who provided it. Um, but what you're saying means you need to go far beyond that. You need to verify that the software is properly developed and not just take any library from the more or less uncontrolled open-source market. Um, what else is included in this zero trust approach towards software procurement? What else needs to be done? Do we really have to check each line of code that we consume?
Um, I think no one does check all lines of code and check all lines of code. And, um, so I think that brings, it was applied to every type of software versus commercial software off the shelf or open source or whatever else. Um, I think there are a couple of elements we can look at. It starts with the ones who are upgrading software and dare it's about applying these well-known principles of secure by design and the coding practices around to everything which has done in software internally and externally. If we ask someone to develop a software for us, that must be a part of the requirements. So if I say too much, he has much, he has to deliver some piece of soft for me for that on that. And I pay you X Euro. Then I should also ask you and force you to follow the security sign and coding practices, and to prove that you do, and we may need something like, like an ISO standard on that as well, where we say, okay, this is where we really, um, that have our certifications suppliers.
Then the next thing isn't also ha must happen with both analysts. And it can happen to that those times. So that design the coding assumption that you you've kind of regressed, which is relatively difficult to verify that the bigger your software is the harder it is, but the next in like software can position analyze instead of something you can do, um, also for yourself and everyone, every provider should do it. So I know that a lot of software companies are not exactly aware of which for instance, open source libraries, other external libraries are used in which Russian and et cetera, Dany to node. Um, you need to understand that as far as you can. So what I'd libraries, which versions are doesn't own rules or abilities and patches, et cetera. So that would be a second step and done. There are tools for static, for dynamic code on a license that you kind of like clearly your organizational controls as well. So on both ends, really, I was asking to controls, define and enforce that you do to right tracks and all these things. And then there are security analytics at the end. You also need to observe how software behaves and if there are anomalies, you must react. And so there's a lot of technology out there, but so we need to, as a persons for dev ops to, to look at, um, how can we integrate so to speak security, telemetry security forensics in this concept, the technology is there. We just need to do it.
We agreed because if we look at modern, um, built chains for software development, and that is also something that users of unique systems of Linux system see in their daily work, because when they do an upgrade, this, this upgrade, um, incorporates pulling updates of basic libraries from their original repositories in the most recent version. And who knows that this most recent version does not come with more bugs than the version before maybe fixing one, but incorporating two new ones and that needs to be properly tracked. And that is also the case for many software developers, which have modern built chains, modern tool, which as well pull always the newest version that that's for good reasons. But nevertheless, you need to monitor what is actually, um, in the back when you finally, um, compile the final solution. And that is of course, something also that the solar winds incidents showed because there were some changes that were, um, yeah, undesirable and really not expected and dangerous to, to the, to the customers. And along the supply chain
Requesting you, your customer to, to deactivate, uh, whatever anti-malware for installs clearly should always be a sign off. Okay. Maybe we, we, we look at more strict controls in that case. That would be for me, you clear new no-go if you're honest having disaster scenarios and yes, um, we need to do it better and we can do it better. And the good thing at the end of the day is we have all principles available. We have all technologies available. We know how to do, to set up an IMS, how to run an IMS for the information security management system. We know how to do cyber security, supply chain, risk management. We specifically know how to do supply chain, risk management. We have a lot of cybersecurity tools. We have tools for static and dynamic code analyzers. We have increasingly good technology for security monitoring for automated response and other things.
All these things are there. And we have the F a lot of knowledge about good coding practices, secure by design, et cetera. We just need to do it. And yes, when we look at a reality of coding, we see certain organizations which really are strict good coding practices and still have their issues. But we see also ton of organizations with developers, which don't follow these rules and is the point we have everything on hand, you just need to use it. And we need to get better on death because going back to what I said at the beginning, every business is a software business and somebody, at least many businesses are. So that is about also protecting the core of our business, protecting the ability to act on the true transformation, protecting and securing and deliberate, the safety of goods you deliver that incorporate software. That is what we need to do, and its latest time to act now,
Right? And that is an ongoing effort. And in the end, it's also a liability issue because when you produce software, no matter what is incorporated in there in the end, you are liable for what this piece of software does no matter which component actually caused the issue. That might be an issue to these one man show software developer, unicorn companies, but for modern, um, larger scale organizations who are using software within their own boundaries or as a software, which is provided to end users, they really should follow the principles that you just mentioned. Uh, I think that's a great summary for, for this episode of this podcast because it's really, um, making sure that people understand their responsibility, their liability, but also the tasks that need to be executed over time. Any final additions from your side to that
Low trust repeating it's about extending our zero trust approach to the cyber security supply chain, risk management, and always keep in mind don't blindly trust software, but verify it. And then,
And again, we are at, as you mentioned at the zero trust approach. So don't trust, verify every time. Thank you very much, Martin, always a pleasure to have you here and to hear your insight looking forward to having you in upcoming episodes again, and thank you for your time being here today.
Thank you. Bye-bye
Video Links
Stay Connected
Related Videos
How can we help you