[Paul] Welcome back everybody to Exploited: the Cyber Truth. I am Paul Ducklen joined by Joe Saunders, CEO and founder of RunSafe Security. Now, Joe, you’re on the road this week, aren’t you, in New York City of all places?
[Joe] Yes. I’m in New York City. I’m in the heart of both the financial district, and I’m also in a coworking spot in an upscale part of town. So it’s fantastic.
[Paul] I like my life in suburban Oxford, which is a city with its own attractions. But I do envy you a little bit sitting on Manhattan Island, living the high life.
[Paul] However, Joe, we have some important material to cover in this episode. And our title is software assurance at mission speed. Now the subtitle is securing code without delaying programs. And I think, Joe, that we’ve been set up by our chums in the marketing department with what is essentially a pun, programs as in binaries, as in software firmware, the actual apps that get delivered, but also programs as in business plans or a program of delivery. And both of those are important parts of this story, aren’t they?
[Joe] I think they’re both important. And if you think about the programs on the delivery side, when we talk about the aerospace industry and even defense programs, they’re usually programs of record that represent, concerted efforts to build certain kinds of outcomes, certain kind of systems, certain kinds of weapon systems, and the like. And so program of record and programs in general, the US Department of Defense, for example, is organized around programs and program executive offices or what we call PEOs. And so one PEO may have 100 programs and that and those 100 programs are both delivery, like you say, and they represent a bunch of software programs underneath that represent that overall target system they’re trying to build.
[Paul] Yes. Because there’s almost no military hardware these days, in the same way that there’s no automotive hardware, almost no medical hardware these days, that doesn’t have firmware and software somewhere in it to control it. The days of a simple switch that turns a light on and off are days of the past, aren’t they?
[Joe] They are days of the past, and I guess it’s been a dozen years or so since Marc Andreessen said software’s eating the world. If you think about military systems and how long they last and then also systems that get deployed in other parts of critical infrastructure, like energy infrastructure, that technology, as we’ve said many times, endures for a long, long time. And so with that, there are efforts to modernize programs across all of these, elements of critical infrastructure.
[Joe] And one part of modernization is a result of these items being connected, and another part of that is certainly advances in new digital techniques and technology and and architecture to make better mousetraps, if you will.
[Paul] There’s a strong element here of what’s good for the goose is good for the gander. Maybe I really mean what’s good for the goose can also be quite bad for the goose.
[Joe] Yes. And and I would say the goose and the gander in this case. Let’s say the goose is is resilience and the gander is innovation. What we really wanna know is, can you have resilient systems that are innovative so that different companies, different countries, different militaries can be using the most advanced technology in a way that those systems are secure and doesn’t compromise whatever operation they’re trying to build? The US Department of Defense since World War two has been a tremendous innovator in putting r and d dollars towards new technologies, modernizing systems. And that has changed tremendously over the years. And one of the things that has come along is the bureaucracy or maybe better stated all the steps one has to go through in order to deliver on new systems.
[Joe] There’s a lot of things that go into making an innovative product resilient and ready for prime time, ready for the market. As you’ve heard me say before, there’s a good thing that new model cars take three years or more to produce because you wouldn’t want a car produced in a day or a week because it probably wouldn’t be very safe. And so what is that right balance in innovation and resilience and safety given constrained resources?
[Paul] Absolutely. We made a joke, didn’t we, in a previous episode? That old school motto that says, move fast and break things, could hardly be a less appropriate metaphor for the automotive industry, or for the aeronautics industry for that matter. Because that’s exactly what you don’t want to do. You might want the product to move fast, but you certainly don’t want it to break while you’re in the middle of using it.
[Joe] Absolutely. And I guess the joke that keeps on giving over and above that is our medieval castle. And that is that if we didn’t modernize, then we would be stuck in the dark ages potentially. Progress forward on new systems, new technology makes companies more efficient, makes employees more productive, makes systems more effective, and you can achieve outcomes, you know, faster and better. The trick though, as you say is, how do you do that, in a secure way? How do you do that safely? And how do you apply the best techniques and get the right approvals to get some stuff done?
[Joe] I think that’s where standard processes come into place and testing procedures and ways to get approvals to release new technology, including updates to software where there may be vulnerabilities.
[Paul] Regulations and standards often sound like the boring part of cybersecurity or computer science or product development, don’t they? And they sound like, oh, it’s just some petty regulator getting in the way and standing against innovation. But particularly in, say, defense products, where you’re not just perhaps looking at a few products that one country might want to put together and use, you’re actually looking for components that might work between a whole raft of allies, all of whom have developed those products largely independently, then it really, really matters, doesn’t it?
[Joe] Yeah. A 100%. In the defense industry, there’s this notion of authority to operate. And if you make changes to, let’s say, an airplane or, I don’t know, a ship or a submarine or some kind of rocket launcher. Well, if you make changes to it, you need to seek authority again. And that means you go through a lot of those compliance checks, a lot of those reviews, a lot of testing.
[Joe] You have to check the safety compliance side of it. You have to check the security elements. And it may take in an in an old world, say, ten years ago, it may take six to twelve months to design and implement a new feature, and then it may take another six or twelve months to test it, and then it may take another six months to get all the additional approvals for the authority to operate. Well, that’s two and a half years from innovation day or idea or concept before that even makes it out onto a program. And is that fast enough for the US military to remain competitive?
[Joe] And a lot of people would say no, and I would even agree that takes too long. So that’s where faster software development processes, the notion of DevOps and DevSecOps and building in automated security testing and scanning and finding ways to automate those steps where you’re breaking down the bureaucracy into technical advantage with mature software development processes. And this isn’t strictly unique to the US Department of Defense. It would be true in any military around the world, but also it’s true in other industries. And we’ve already mentioned the automotive industry.
[Joe] The aviation industry has safety of flight.
[Paul] And development teams may be much more compact, which is an important part of innovation. You’re actually able to do go ahead stuff. Then you’re sort of stuck by the fact that small development teams don’t build the whole project, do they? They rely on a network of suppliers and possibly on software and firmware components that would develop, say, by hobbyist groups or open source teams or people from other countries that they’re not necessarily sure of.
[Paul] How do you deal with that?
[Joe] You’re exactly right. The software ecosystem, software development ecosystem, the software supply chain is filled with many players. And it an organization that produces a car just like in the automotive industry, you have tier one suppliers that are shipping components that get assembled in the final assembly plant in the auto industry, a lot of the product manufacturers who are producing devices that get shipped into critical infrastructure, let’s say the energy grid, those product manufacturers, they’re actually OEMs, original equipment manufacturers, who are getting components from third parties. And they’re using open source software.
[Joe] They’re using third party suppliers. They’re using third party developers, as well as their own software development team. And I think the statistic is roughly 20% of devices, 20% of software is written by that manufacturer producing the final product.
[Paul] So I guess the way to read that is 80% of it comes from, potentially, personal persons unknown.
[Joe] Exactly right. What that means is that final group that assembles the final product has to account for the quality of all the clones that they do incorporate. So they do need to come up with standards with their name suppliers, but to the point that you have, in the open source world, there there are two sides to it. On the one hand, you get very innovative products where you have lots of developers whose eyes are on it, and you have mature components developed by open source teams where they have input from thousands of organizations around the world, and they find vulnerabilities, and they fix them. And then you may have other open source components that may not have a huge distribution and only a couple people working on it, and that represents risk.
[Joe] I’ll tell you an example. We have a customer whom I won’t mention who analyzed their software bill of materials, and they found in a firmware product over a thousand components.
[Paul] Oh, that’s just one component had a further 1,000 bits in it.
[Joe] Exactly right.
[Paul] Imagine a gearbox with a thousand moving parts.
[Joe] Exactly right. And 80% of those components were open source. And so you need to have good robust ways to test and review software for bugs and test and review software for vulnerabilities. And in that example where I said, maybe there’s thousands of people working on one open source project and another one might only have two or three. Well, the ones with only two or three represent a pretty significant risk. One, they may not have as robust process to issue updates.
[Joe] So when you do find a vulnerability, it may take much longer for something to get updated. And two, you may be very dependent on just a couple of people. What if they decide not to develop the product anymore? In that example, with the company with a thousand libraries and components, they did identify one where they were dependent on a single individual user who was not paid by the company. If you’re looking at your software supply chain and you’re leveraging a software bill of materials, you start to get insights about who the contributors are to those components.
[Joe] You can assess risk. That responsibility is, in fact, the responsibility of the company that’s producing the final product if they’re gonna stand behind it.
[Paul] And ideally, everyone in the chain would have done something similar in their turn, so that those bills of materials can be compared just in case somebody missed something.
[Joe] Exactly right. And in the automotive industry, there are some regulations that say you need to go four layers deep if you’re the auto OEM, meaning you need to go tier one, tier two, tier three suppliers, and maybe even a fourth step to make sure that you understand all those components that are in your final products.
[Joe] The key is you need to understand your software billing materials and all the dependencies in your software that you produce and those dependencies to third party libraries and dynamic libraries and and static libraries that you’re pulling from outside your organization, you really need to understand the risk associated with those individual components that comprise your software product.
[Paul] And you have to be ready to take bad news and act on it quickly, don’t you? So that if you reason that this particular component I’m using has been maintained by one guy in Minnesota for the last twelve years and he’s decided he’s getting out of software engineering, then either you have to take it over and invest in it yourself, or you have to find something else. Alternatively, you might find that a supplier or the creator of a component includes people in their team that you either, by regulations, are not allowed to trust or that you are inclined to distrust either because of their anti patriotic leanings or their history of incompetent or irrational behavior or whatever it might be. There are lots of things that can suddenly throw a spanner in the works.
[Joe] Yes. What you’re ultimately looking for is determinism in the outcomes and the way that software behaves so that you know all the potential actions that the software can take. And so in some of those areas where you might have riskier components or less mature software processes behind them, You better test and and ensure you understand how those components behave. And so software development isn’t just as simple as writing some code and throwing it out there and seeing if it works. And in the Internet age, if you go back, the idea was to produce code fast.
[Joe] And where it broke, you would just fix it fast. You can’t afford that in critical infrastructure, so you need to go the other way. You need to make sure that the software behaves in a deterministic way and in a safe way.
[Paul] And yet everyone still wants to achieve the move fast, but it’s move fast, but don’t break anything, which is a much more challenging way of working, but ultimately much more satisfactory both intellectually and practically, isn’t it?
[Joe] It is. And so it’s a fun set of tensions there when you try to be resilient and innovative. At RunSafe, we try to help people be both resilient and innovative so they can push technology onto systems faster knowing that they’re safe, knowing that they’re secure. And we do that in a couple different ways, leveraging software build materials and understanding everything in there so you have good visibility into your software supply chain, and you can communicate transparently to your customers what’s in there and what you’ve done, and then adding in exploit prevention even when a patch is not available.
[Paul] Because the advanced runtime protection products that RunSafe provides are designed, if you like, to retrofit security protections to products where maybe you just have a big lump of source code and an old compiler that can’t be updated, or you have a device where you can’t just go and change the code all the time, and you can’t add more and more and more layers of protection like we’ve had in operating systems like macOS and Windows. Oh, let’s add ASLR.
[Paul] Let’s add another wrapper around the program. Because that device might have a very specific function where the way its performance is measured is not how fast it can do things, but how predictably, deterministically, and reliably it can do them within set times, which is a very different prospect.
[Joe] It is a different prospect, and there are safety standards out there in aviation. The one everybody talks about is referred to by letters and numbers as as we do in the industry, d o one seventy eight. And in the automotive industry, there’s ISO 2,262 and the ASIL, ASIL, the ASIL standard for all of this to ensure that systems operate safely.
[Joe] And you need that determinism. And what we’re doing is ensuring that our technology at RunSafe is qualified under those safety standards. So if you are a product manufacturer, then you can inherit our compliance to those standards so that you can add in the security protections and maintain that safety compliance standard.
[Paul] And that’s done without taking an existing product and wrapping it in a whole load of extra code, extra memory use, extra runtime, but instead by rearranging the program carefully so that it is much less likely that somebody will be able to craft an attack against it. And if they try, that you will be able to shut it down in a measured and useful way from which you can learn what went wrong.
[Paul] But without, for example, changing the time that it takes for a valve to be slammed shut in an emergency.
[Joe] It’s a 100% right, and the determinism is the key. And if you can deploy technology without compromising deterministic outcomes in softwar., The great promise of software is you can produce one copy, you can produce a million copies. They should operate exactly the same way, and that works to the advantage of the user. It also works in the advantage of the attacker.
[Paul] Absolutely.
[Joe] If you add in security to prevent that determinism for the attacker without compromising the determinism for the customer or for the manufacturer, then the manufacturer and the customer get what they want. They get resilient systems, and they get the most innovative systems.
[Paul] Joe, do you think it’s fair to say that a lot of people, when they hear of terms like real time programming or real time operating systems, tend to confuse that notion or that concept with speed? In other words, to do something in real time, it just means you have to be able to do it fast enough that you don’t have to wait for the results.
[Paul] So it’s like if you send an email, it will just essentially arrive immediately, and you don’t have to wait till tomorrow morning. But it’s quite the opposite with many real time systems. Isn’t it? It’s not the speed. It is the reliability, the predictability, and as you’ve said, the determinism that matters.
[Paul] So something could happen slowly, provided that you know exactly how long it will take and not a zillisecond longer.
[Joe] If you add to that the notion that a cyber attack compromises the speed, compromises the reliability, compromises the determinism.
[Paul] Of course. Yes.
[Joe] So it’s really a fun conversation when you talk about safety standards.
[Joe] And then and so at RunSafe, we don’t wanna compromise any change in behavior or anything that might slow down a system. But let’s be realistic. The attackers changes to systems do slow it down and create that non deterministic outcome, putting airworthiness at risk, putting safety certified autonomous driving at risk. And so cyber is a big deal because it gets to safety, and with that, the goal is to make those systems resilient as best as possible.
[Paul] Now, Joe, in a few recent episodes that we’ve done, you’ve talked about CICD as a development process for software that can make sure you don’t fall behind in testing.
[Paul] That’s continuous integration, continuous development. Do you want to say something about the form that that takes and why it’s a useful discipline to have when you’re trying to move fast but not break things?
[Joe] Yeah. I think part of the key is incorporating the right tools when you’re writing software and building systems where you have automation. You have automated tools that will produce repeatable build processes without manual intervention and also produces automated testing processes so that every time a developer commits new code, it wants to put that through the build process, so it’s ready for testing and then ready for deployment.
[Joe] It’s fully automated. So we talked about build tool chains. And in embedded systems, those build tool chains will include some form of Git repository for maintaining versions of source code and whatnot, certainly the development environment. And then naturally, when you’re working with native code that starts with source code and has to be produced into a binary, it goes through a compiler. Compilers are very sophisticated set of tools to ensure that you can convert source code into a software binary.
[Joe] But there’s still other steps, and some of those other steps can be then the automated testing. So when that binary gets produced, you can scan it for vulnerabilities. You can subject it to dynamic analysis, testing of different types, might even do fuzz testing, and the like. That is a very complex process. But if you can commit code and have all those steps automated, then you save a lot of time, and you really look at the outcome of all those automated tests and say, are there any findings?
[Joe] Are there any vulnerabilities? Are there any bugs I need to address? And it becomes an iterative process that’s repeatable. You wanna really look at those steps where you’re testing the quality of the code, testing for vulnerabilities, ensuring that you produce software that that will be reliable when it gets released out into the market.
[Paul] And that also ensures that you can easily, rapidly, and essentially deterministically rebuild the very build environment.
[Paul] So it actually keeps the entire system, well, honest and consistent, you might say, doesn’t it?
[Joe] In The UK, GCHQ did a lot of analysis on some telecommunications related software coming out of China. On the surface, it looked like everybody was using the exact same source code, using the same build environment, and yet there was a slight change in the build environment where the compiler was doing had a slightly different setting. And so you do have to be very, very cautious because that setting ended up grabbing maybe one other component that then changed the overall outcome of of the system. It opened up a backdoor into some telecom equipment.
[Paul] And we have seen attacks where what got built in the end, the actual final product, had the right hash passed all its tests, but there was some process in the build process that had actually compromised the build environment. So in those cases, the attackers aren’t so much concerned about one particular final product. Their goal might be to introduce vulnerabilities into the build process so they can steal intellectual property, wander around through source code, and perhaps in the future, sneak in commits code changes that somehow get accepted, the system will then make sure get baked into every future product. So there’s a lot at stake here.
[Joe] SolarWinds is a good example of that.
[Paul] I shouldn’t laugh, Joe, but
[Joe] And it looks like there were some legitimate changes to software when in fact they were not legitimate changes, but they got approved as if they were legitimate. So vulnerabilities were built in.
[Paul] Yes. And that’s crazy, isn’t it? Because that means removing the vulnerabilities will actually create a security warning.
[Paul] Oh, no. The program’s not coming out correctly anymore. You go, no. No. Now it’s coming out correctly for the first time.
[Paul] So, Joe, clearly, there is a hugely important role to be played by technology leadership in companies that build, well, software and firmware products of any sort, but especially those in industries such as defense, automotive, aeronautics. How does the world go around building that strong leadership?
[Joe] Ironically, I think the faster you produce software may be suggestive of higher quality software because you have more mature processes, you have automation. Now it doesn’t mean you can do it super fast. What I’m getting at is you need mature processes that enable you to respond quickly, to test, to iterate quickly, and to improve software.
[Joe] If you’re taking several weeks to make a merge request or you’re taking several weeks to test things and you’re doing it manually, you’re likely gonna miss things.
[Paul] Yes.
[Joe] One of the key elements is to have very mature software processes to automate as much as possible and to really empower developers to act on vulnerabilities and bugs right away. We really need to have mature software processes, but also then mature ways to communicate and share. And I think transparency is the key term there.
[Paul] Yes.
[Joe] You end up building trust and confidence. Your your customers will gain confidence in your processes as you’re showing them your weaknesses. And it seems counterintuitive, but it is quite powerful in that sense. And that’s part of the reason why you need to have full visibility in the software supply chain.
[Joe] And I I maintain that having a full, complete, accurate software bill of materials, a 100% complete, a 100% correct software bill of materials is the foundation for transparent communications because you can then share with your customers, you can then identify risk within your supply chain, and then you can associate all the things that you’ve done to improve the process. So everybody gains that confidence through your transparency.
[Paul] Yes. If you’re not willing to confront and to reveal and to deal with the weaknesses and the vulnerabilities in your software or your firmware, you can bet your boots that cyber criminals or state sponsored actors are going to do it for you.
[Joe] Yeah. The state sponsored actors are actually very well funded security researchers looking for those missteps you might take in your coding process that could create a vulnerability.
[Paul] And they’re not going to brag about them. They’re just going to keep them for a time when they might be useful.
[Joe] Yes. They’re not exactly transparent.
[Paul] Quite the opposite.
[Joe] They’re looking for ways to take advantage of that because their motivation may be much more than generating that ransom payout. It might be to collect information or monitor systems or crash systems and things that might advance their intelligence objectives or their nation state objectives against an adversary. It’s much easier if you find them and communicate them. And I think a lot of these organizations that are producing technology that goes into critical infrastructure, the ones that are the most innovative and most mature in the software development processes probably produce code faster with fewer vulnerabilities.
[Joe] And it it does seem counterintuitive, but I do believe that through automation, through mature software development practices, through generating a full visible understanding of your full software supply chain and all the components in your product, and ensuring you build in security before you ship product, A lot of organizations take a lot of pride in doing that really well. And so you want leaders who have a culture to create robust, mature processes. And what we want are resilient systems that produce innovative technology in ways that don’t slow down developers, but accelerate product that really schedules.
[Paul] In other words, if the phrase secure by design doesn’t mean anything to you yet, and you’re a software vendor, then it probably should. Because what that is saying is not just move fast, but don’t break things.
[Paul] It’s saying move as fast as you like, but do it right in the first place. And the flip side of that, secure by demand, is where the people who are buying or consuming those software products are actually favoring or preferring the companies that operate that way. So there is hope for us all in software engineering provided that both the producers and the consumers meet in the middle in saying, let’s be secure before we start developing, while we’re developing, and after we’ve developed a product.
[Joe] And if I had a way to wrap it up, Paul, I would say, in order to achieve resilient innovative systems, you need mature processes that are transparent, that rely on a deep understanding of everything that goes into your product, all the while investing in great testing and adding security into the process to prevent exploits.
[Paul] Very well said, Joe.
[Paul] I think that is a fantastic way to wrap it up. Thank you so much for your deep thoughtfulness. You obviously care very, very greatly about this to the point that although you’re the CEO and founder of a company that sells cybersecurity related products, you’ve actually spent the entire time we’ve been recording this episode talking about what we as a community can and should be doing for each other to make sure that we don’t get, if you like, hoist by our own petard in the future. So, Joe, thank you so much for your time. That’s a wrap for this episode of Exploited the Cyber Truth.
[Paul] Thanks to everybody who tuned in and listened. If you find this podcast insightful, please subscribe so you can keep up with each week’s episode. Please also share with your colleagues, with your friends, and on social media. And remember, stay ahead of the threat. See you next time.