---
title: "John Martin — Preventing a Cyberpocalypse"
url: https://appsecpodcast.com/john-martin-preventing-a-cyberpocalypse/
date: 2020-03-15
duration_seconds: 2538
guests: ["John Martin"]
topics: ["Threat Modeling"]
audio: https://www.buzzsprout.com/1730684/episodes/8122611-john-martin-preventing-a-cyberpocalypse.mp3
transcript: true
---

# John Martin — Preventing a Cyberpocalypse

*March 15, 2020 · 42 min*

with [John Martin](https://appsecpodcast.com/guests/john-martin/)

on [Threat Modeling](https://appsecpodcast.com/topics/threat-modeling/)

[Audio](https://www.buzzsprout.com/1730684/episodes/8122611-john-martin-preventing-a-cyberpocalypse.mp3)

## Show notes

What happens when society’s dependence on software grows faster than its ability to make that software safe? John Martin, a commercial software security practitioner and SAFECode contributor, calls that widening gap a possible cyberpocalypse. He explains the combined pressures of vulnerable legacy code, expanding connectivity, and increasingly capable attackers. The hosts challenge his proposed responses, exploring software liability, standards, quality measurements, and the risk of constraining innovation. The discussion compares software assurance with product safety and building inspections, while questioning whether following a development process is enough evidence of a safe outcome. This is an exploratory debate about responsibility and incentives, with John urging the industry to confront systemic software risk before its consequences become harder to contain.

The Application Security Podcast is brought to you by [Security Journey](https://www.securityjourney.com/).

About Security Journey  
Security Journey provides application security education for developers and everyone in the software development lifecycle.  
→ [Learn more about Security Journey](https://www.securityjourney.com/)

Connect with John Martin:  
→ [John Martin on LinkedIn](https://www.linkedin.com/in/johnmartin-public/)

Mentioned in this episode:  
→ [SAFECode](https://safecode.org/)  
→ [Cloud Security Alliance](https://cloudsecurityalliance.org/)

Chapters:  
00:00 Preventing a cyberpocalypse with John Martin  
01:45 John’s security origin story  
04:26 Connecting breaking and building software  
09:27 What John means by cyberpocalypse  
12:28 Sudden catastrophe or accumulating harm  
16:15 Technical debt and deferred responsibility  
17:38 Ways to improve software outcomes  
19:54 Measuring software quality  
21:27 Liability and defining safe software  
25:39 Could safety requirements constrain innovation?  
27:51 The difficulty of a meaningful safety standard  
31:29 Measuring process versus results  
36:43 Software assurance and independent inspection  
38:21 Where the industry conversation is happening

## Transcript

*6,695 words · assemblyai*

**0:00 Chris Romeo:** John Martin has focused on software supply chain, DevSecOps security champions, and cloud security monitoring. He's a frequent speaker on the topic of commercial software security and a contributor on many SafeCode and CSA efforts. John joins us to discuss the prevention of a cyberpocalypse. You heard it correctly. Now tune in to learn what the heck a cyberpocalypse actually is and why you need to care about it. We hope you enjoy this conversation with John Martin. Are you trying to build a security champions program? Everyone is these days. One challenge of rolling out security champions is, how do we educate all these new folks? Security Journey has your answer. We provide a security dojo environment with level-based security education that gives your newfound champions a path to follow.

**0:51 Robert Hurlbut:** And the best part? It requires almost zero administration by you.

**0:55 Chris Romeo:** Visit www.securityjourney.com to set up demo and learn how you can use the Security Dojo to connect with your security champions.

**1:04 Robert Hurlbut:** Hey folks, welcome to this episode of the Application Security Podcast. This is Chris Romeo, CEO of Security Journey and co-host of the podcast. I'm also joined by Robert. Hey, Robert.

**1:26 Chris Romeo:** Hey, Hey, Chris. Yeah, it's Robert Hurlbut, Threat Modeling Architect. Good to be here.

**1:30 Robert Hurlbut:** Yeah, great to have you back with us here again. And today we're going to talk about a word that I don't even know if it's a real word, but we're going to figure it out as we go.

**1:41 Chris Romeo:** And that is this idea of a cyberpocalypse, but we'll get there.

**1:45 Robert Hurlbut:** But first, we're going to have our guest, John Martin, answer the question that you're all waiting to hear. And that is, John, How did you get started in this wacky, wacky world of security?

**1:57 John Martin:** Well, hi, Chris. Hey, guys. Um, so, so like most people, I started out as a child.

**2:03 Robert Hurlbut:** You started as a child? Okay, that's good. Were you doing security at that point as a consultant, or—

**2:10 John Martin:** So, so seriously, um, back in, back in the days of dial-up and all of that good stuff, bulletin board systems, I just discovered I had a talent for taking things apart and putting them back together. So pretty much that talent's led me over to cybersecurity. Back in the early '90s, I formed, as far as I know, one of the very first cybersecurity consulting businesses. We had a number of clients in the North Dallas area. And many of those clients led us to the ability to really sharpen our talents and to really start discovering very early that companies, systems, people, their lives can be changed by simple security oversights, by the way we build software and how— and really how that impacts Gosh, just, just everything people do and say. And this is back in the '90s, right? At one point, we were able to attack and as a result of that attack, harden Alliance Airport. We were able to go through and compromise every router at the airport. Now, if you don't know, if you remember in the old days, routers always had a telephone jack in the back of them.

**3:36 Robert Hurlbut:** Oh, yeah.

**3:37 John Martin:** And It was simple to inject commands into that. You own one, then you own the whole network of them because they all shared, you know, if they were passworded, they all shared the same password. And so we were able to compromise businesses. We were able to do a lot of stuff just through single simple faults and configuration vulnerabilities. And I think part of the reason why we're here today is because those experiences are just magnified today, right? The sophistication of not just software, but the hacking community, the defensive community, the white hats, the black hats, the gray hats, the, you know, the no hats. It's just gotten, frankly, way out of hand. And I think that that's why we're here today to talk about some of this stuff.

**4:26 Robert Hurlbut:** And so it sounds like kind of the way you're describing your history that You came from the kind of the more the breaker side of the world of cybersecurity. And so have you had experience kind of on the builder side as well, or has your history been primarily breaker, which then translated into helping bigger style companies set policy and do that type of stuff?

**4:54 John Martin:** Well, I mean, if you're going to break something and put it back together, then you have to know how it works, right? And the logical extension of that is leading different organizations, leading different companies to build software smarter, better, and faster, including securing it better, including building software right the first time. One of the real challenges in modern software development is a concept that I think of as deferred responsibility. It's the need to realize income today, off of a current product so that you can improve the product down the line. At least that's the concept. How that plays out in the real world is that we build a— build the software, we deliver the software, but we know we can't do anything about any defects. So we write in the contracts that you, the user of the software, have no rights. And if you do discover a problem, you have to report it back to us and not to You know, the press or the public. We we have a real, I think, moral issue in software development today. And to your question, I think along the way I've I've built security champion programs, agile software development programs back in the day, DevSecOps programs currently. I've advised a dozen or so companies on. on how to really pull their bootstraps up and create a modern software development environment where they were really struggling before. If you're going to break it, you got to be able to fix it.

**6:39 Robert Hurlbut:** That's something that you just said that really spoke to me here, the idea, because I think that's the way it should be. When I look across our offensively minded community, I don't know if that's actually the case though. Like, people, everybody's so gung-ho and excited about breaking and let's, you know, I want to be on a red team and I want to be a pen tester.

**7:04 Chris Romeo:** And all of those are good things.

**7:06 Robert Hurlbut:** But one of the soapboxes I keep coming back to is there's a lot more to this than the flashy find the vulnerabilities and, you know, hack the Gibson. There's just more to putting it back together.

**7:20 John Martin:** You're so right. You're so right. And I'm glad Robert's on the call because one of the least sexy things And yet one of the most critical things is what Robert specializes in, and that's threat modeling. If I don't know what my software environment that it's going to be published in, if I don't know what the impact of bad code is going to be, why am I building the software? It's morally indefensible.

**7:45 Robert Hurlbut:** Yeah, I'm trying to get Robert to wear a t-shirt that says threat modeler for life or threat modeling for life or something.

**7:51 John Martin:** Now, I shouldn't have a side conversation with Robert. Because, because I don't think threat modeling goes far enough today. I really think that it needs to be more inclusive of the full spectrum of threats and privacy issues. Oh, sure. Yeah, definitely.

**8:06 Chris Romeo:** And I think I already own that shirt.

**8:08 John Martin:** That's awesome.

**8:11 Robert Hurlbut:** Well, yeah, we should, we should sell them. If we sold anything on the Application Security Podcast website, which we don't, that would be it. That would be— maybe we'll, maybe we'll make one of those shirts just for the fun of it.

**8:23 John Martin:** I think you should go for it.

**8:24 Robert Hurlbut:** I think we should too. I'm gonna have to assign that as homework to somebody else.

**8:28 Chris Romeo:** But the topic here, John, that we wanted to talk with you about is something that you're calling the cyberpocalypse.

**8:37 Robert Hurlbut:** And so I don't know if this is actually a word, but just so our listeners know, we had Steve Lipner on to talk about the history of SDL a number of episodes ago here. And after that, John and Steve, John kind of sent an email to Steve just to say, hey, you know, loved the podcast and happened to CC me.

**8:57 Chris Romeo:** And they began what turned into a multi-email, hundreds, perhaps thousands of words at different times, of a debate about the need for legislation to say how software had to be protected.

**9:13 Robert Hurlbut:** And it was just a fascinating debate for me. And I just sat there like a lurker and didn't even respond or anything and just read this dialogue back and forth. But then I got to the end and I said, We got to talk about this in a podcast. And so that's why we're here today.

**9:27 Chris Romeo:** And so, John, what is this idea of a cyberpocalypse?

**9:31 John Martin:** That's, that's, that's a great question. And, and in truth, I did not invent the term. In fact, I think that the first use of cyberpocalypse, I remember, it's like at a Black Hat or something around 2013, 2014. There was a giant Lego apocalypse thing that they were calling the cyberpocalypse. So, so I didn't invent the term, but I think it's, it's, it's appropriate for what we're facing today. If we think about things like technology debt, right? How much old code is currently in use? How much old vulnerable code is currently exploitable today? If we think about new code that's, that's being pushed out into production and the sheer volumes of, of that code, the sheer volumes of software. that's going live today. If we think about the breadth and depth of that software, our cars run on it, our homes run on it, infrastructure runs on it. I can't get electricity without it. Then it becomes, I think, truly stunning how dependent our entire civilization is at this point, in every continent on the planet, how dependent we are on software. And the software is apparently pretty bad. And I mean, the evidence for that is pretty clear. Just 10 years ago, the cybersecurity business was a total of about, what, $30 billion or something like that? And now, I mean, now it's projected out to be something like $100 billion or $200 billion by the end of next year. It's it's it's an incredible, incredible waste of money. I read on Forbes and you know the the Wall Street Journal how how this is a new emerging market and how that's a really good thing that that we can invest money in this and make money. But they're ignoring the elephant in the room, and and that is that that these problems should not exist. Every breach that I've ever seen, every penetration that I've ever seen, every Every cyber bad thing that I've ever seen really comes down to one or more of 3 things: bad code, poor configurations of systems in the code, and of course people. So if we can solve any one of those 3, we're in much better shape than we were, right? So if I can solve the bad code problem, then we just have to worry about 2 of those things: configurations and people. If we could solve configurations and code, then all we have to do is worry about people. And if we can inform people, we're all pretty good at training stuff. I know you guys are expert at it. We can work on the people thing kind of organically, the way that we as people are built to do. But first, we got to get a handle around the software, the configurations of the software.

**12:28 Robert Hurlbut:** And so when you think cyberpocalypse, are you thinking there's like a flash, there's like a big event that happens. Like, it's almost like it's only a matter of time until the wheels fall off on this, our dependence we have on software, and we have some type of a big problem or issue.

**12:48 Chris Romeo:** Is that kind of what you're thinking of?

**12:50 John Martin:** I think that that's inevitable. Again, if we look at the sheer volumes of software being produced, and kind of put that on a graph, there comes a point, an inflection point, where the problems are rising faster than the solutions are. There becomes an inflection point somewhere in the next 7 or 8 years where we're not going to be able to manage software. Where as soon as we publish something, it will be owned, and the results of it being owned is people's lives, people's jobs, people's retirements, people's memories, How many of you have your pictures stored on your hard drive? And there was, there was a couple years ago, an older woman friend of mine called me up and she said, she said that she couldn't access her pictures anymore. The only picture she had of her husband, who had died a few years back, were on her hard drive. And, and I went over there and got her computer and put it in my little lab here and realized that that she had had some ransomware, some one of the early ransomware variants, had encrypted her hard drive. All the pictures that she had were inaccessible. She had taken it to a local repair shop before she called me. They had wiped the drive and then reinstalled Windows on the drive. In the process of wiping the drive, they, they erased the crypt store, which, which that particular ransomware variant used to store the encryption keys. The net result is all of her memories of her husband were gone. All of those pictures were gone. All their— all of her childhood was gone. This, this affects people's lives. This is not just a number, you know, how much profit we can make on, on software today. This affects people's lives. I believe the number I read was 40% of all companies that get a ransomware attack go out of business. That's not my number. Check it, Google it, make sure I'm right. But if that's true, then how many jobs are being lost? How many jobs are being lost in 5 years? How many jobs are being lost 10 years from now? I believe that we're reaching an inflection point. I don't know if it's a cyberpocalypse. That might be a bit of hyperbole. But regardless, we're reaching a point of almost no return. If we don't get our hand arms around this pretty soon, we're going to be in real problem.

**15:23 Robert Hurlbut:** Whenever I speak to a room full of high school students or college, early college students, and they ask, hey, what do you think we should go into? I'm like, application/product security, because in 50 years from now, we will not have solved this thing, and you can then retire a happy and very wealthy individual.

**15:44 John Martin:** Chris, I hope to God you're Wrong.

**15:47 Chris Romeo:** I do too. I do too.

**15:48 Robert Hurlbut:** But the realist in me says, you know, things—

**15:52 John Martin:** Man, I gotta tell you, the stupidest career— I think it's just absolutely stupid that we need this many cybersecurity experts. I think as a society, we're just doing stupid stuff. We're shooting ourselves in the foot. And then, and then, you know, saying, hey, congratulations, you can now wear different shoes. It's wrong.

**16:15 Robert Hurlbut:** You mentioned deferred responsibility a little bit earlier, but I'd love to hear more about that. How do deferred responsibility and Moore's Revenge then play into what seems like this societal technical debt that you're describing?

**16:29 John Martin:** Sure. Moore's Revenge is a term a journalist came up with, I would guess, 4 or 5 years ago to describe Moore's Law says that the complexity of transistors on a chip is gonna double every period, right, or quadruple, whatever that is, and that's gonna grow our computing power nearly in an exponential manner. And that's held pretty true. Moore's Revenge says that for every doubling of computer power, we have a quadrupling of the attack surface. And so as our computing capabilities just grow and grow and grow, the attack surface on those capabilities grows even faster. So far, Moore's Revenge is actually holding pretty true. And what happens is, is that unless we can start reducing the attack surface, unless we can start actively eliminating the ways that software can be compromised, we're going to quickly be in a position where any software that gets published gets compromised at the point of publication. Does that make sense?

**17:38 Robert Hurlbut:** Yeah, definitely a scary proposition to think about though, the idea that any software in the future could— we could reach a point where software is compromised right upon release. What are some of the ways that you're thinking about that we can prevent this? I don't even want to call it dystopian. That's the wrong word. I don't know, this Very frightening future world where software vulnerabilities just completely run amok throughout all of technology.

**18:09 John Martin:** That's, I think, the million-dollar question. And most major companies have been advocating, you know, good code in their supply chains. They send out questionnaires to make sure that their suppliers follow, you know, software development— prescribed software development life cycles. As buyers of software, most large companies are trying to do the right thing. Their challenge is, is that they don't have the contractual ability to validate that their suppliers are actually doing the right thing. So, for example, the company I used to work for, my teams would send out questionnaires to a software supplier. Inevitably, some junior sales clerk fills out the questionnaire and sends it back. My analysts look at it and say, oh no, no, no, no, no, no, no, that's not right. And so we are now in a dialogue with this supplier. Almost 100%— initially it was 96% of all the software that we were purchasing, when we put it on the bench and did pen tests against it, we found one or more egregious defects, defects that could compromise the entire implementation. In anything that was trusted by that software. That, that improved. We began to work with our suppliers— this going back about 14 years— we began to work with our suppliers one-on-one to make their software better, to help them to sort of see the light, to help them to understand that we were not going to accept bad code. The good news is, is that over the years we've seen a fivefold increase in the quality of software. The bad news is, is that that's still 70-some percent fail rate.

**19:54 Robert Hurlbut:** How do you measure the quality of software when you say 5x increase? What are the metrics you're using to be able to, to make that judgment?

**20:02 John Martin:** One or more defects that would compromise the implementation. That if you've got, if you've got a defect significant enough to compromise the implementation, to compromise, compromise anything that's trusted by that implementation of software, then you fail. That simple. So we did obviously a lot of pen testing, a lot of deconstructing on software, and we did a lot of discussions with a lot of vendors. Remember that, and paradoxically, the security vendors seem to be the worst. So I'm not going to give you any numbers, but just anecdotally, I will tell you that our findings said that security vendors were more than 3 to 1 more likely to have a significant defect than, say, an engineering software.

**20:50 Robert Hurlbut:** I can tell you, and I know you know already, but I can tell you kind of from my perspective why that is, because I've heard that statement so many times in a previous professional setting. Oh, well, we're actually a security product. That's the excuse that people would say. And I'd be like, Yeah, and that means you need to follow our secure development lifecycle even tighter than other people do. But that was the part that they didn't hear.

**21:19 John Martin:** Yeah, it's like arresting a lawyer.

**21:20 Robert Hurlbut:** Yeah, good luck with that. They're already writing briefs and motions in the backseat of the car.

**21:27 John Martin:** Exactly. So, so because of all of that, you know, your original question was, what do I think we should be doing? Right? I think we've gone past the point of saying, of giving guidance to the industry. I think we've gotten well past that. The industry is motivated, financially motivated, to be bad actors. They're financially motivated to be morally bankrupt. They're financially motivated to defer responsibility to the next generation. So I think that, that in order to get around that, we need to do a couple of things. And I think that unfortunately that starts with legislation. I am I am the person least likely to ever recommend a legislative answer to anything, but I think that that makes really good sense in the same way that we legislate minimum quality for automobile tires. I remember my grandfather had a car. He used to carry 4 or 5. We lived way out in the country. And he used to carry sometimes 4 or 5 spare tires in the vehicle because he knew that on any significant journey we'd have a fair number of blowouts. You don't see that today. I don't have a spare tire in my car at all. And the reason for that is, is that we legislate minimum quality on tire manufacturers. There's a minimum standard that's, that's got to be met. And more importantly, I think there's a good, clear definition of what liability is for a bad tire, right? If a bad— if a tire blows out, that manufacturer is at least in part responsible for the consequences of that blowout. And, you know, I hate the thought of legislating, but maybe that's what we need to legislate. So if we're going to do that, I think we've got to do really 4 things. I think we've got to define in that legislation, we've got to define what safe software means, right? What's the actual definition of safe software, right? What's, what's a quality tire built out of, right? What are the standards for that? Then we've got to turn around and we've got to say, okay, given that, that we know what's, what good means, given that we know what quality means, What does liability mean in this context? And I think that that's a key concept that's got to be understood, and that's something that's got to be, I think, legislated. If we rely on the courts, well, we went through, what, 50 years of court cases on tires with no good result. I think it's got to be legislated. And then third, I think we've got to establish a set of minimum test and production standards for software, just the way they do with tires and automobiles and aircraft engines, etc. Anything that's critical infrastructure has a minimum standard architecture that's set. So we've got to establish what that looks like. And finally, that legislation has got to provide a method of oversight. And a potential penalty for missing those targets, for missing that. And that would include recall capability. I think that if we go to the very fundamentals of software development, we've got a chance of dealing with this. We still have decades on decades of legacy code. We've got all that technology debt still out there. But we can say from this point forward, we're going to start doing the right thing. So I don't know if that's the greatest solution, but frankly, it's the only one I can think of.

**25:20 Robert Hurlbut:** Yeah, I've got a lot of things that are rushing through my mind right now. But I'll just kind of— I'll throw one at you that is going to be an obvious, very early response to this kind of a proposal.

**25:35 John Martin:** More than what Lippner did?

**25:37 Chris Romeo:** Yeah, more than that.

**25:39 Robert Hurlbut:** I don't even, you know, I just read his kind of from a summary perspective. But when I think about innovation, right, what does this do to innovation and the ability to create new things? Does this squash innovation in any way? Because that's, that's one of the initial things I would see any company coming back at this type of a, of a setup and saying, well, You're gonna, you're gonna squash our ability to create anything new and cool, and you're going to cause us to stagnate as an organization.

**26:09 John Martin:** So I think it's the antithesis of that. Um, look at what automobiles have done over the last, we'll call it, 10 years. Um, we have gone from a very, very standard way to build cars, and now we're seeing, you know, complete revolutions in, in Personal transport. Just in my house, there's what three electric bicycles, an old pickup, a a modern hybrid car. You know, the the just just the personal transport world has has changed dramatically, and this is in a highly regulated environment. My experience is is that people that complain the most about the new regulations are rarely the innovators. The people that complain the most are usually those who are heavily invested in the status quo. And my answer to them was innovate. If you find a market, hit the market. Just don't do it in a way that compromises the rest of us. If you can find a cleaner way to produce a coal furnace and factory, go for it. Just don't compromise the rest of us.

**27:22 Robert Hurlbut:** Now, when I think about your 4 the 4 points here. I think of, you know, the 2, 3, and 4, I think, are the easy parts, right? The liability and what does that mean? What are the limits? What are the levels? Minimum test and production standards. You could argue that we have that in the industry now. We'd have to, you know, probably document it a different way. And then even method of oversight, penalty for missing. I mean, we've got lots of government agencies that are good at doing that type of stuff.

**27:51 John Martin:** Mm-hmm.

**27:51 Robert Hurlbut:** I think the real difficult part of this is, how do you define safe software? Because you can't say safe software is vulnerability-free software, because that's like saying safe software is bug-free software. And I truly believe, as long as human beings are behind writing software, that we will never reach a nirvana point of human There are no vulnerabilities in this product. I just don't think you can get there unless— we did formal methods back in the '70s and '80s in the government space. And look where that got us, some really super high-level secure systems that nobody could do anything fun with.

**28:34 John Martin:** Nobody could use.

**28:35 Robert Hurlbut:** Yeah. I mean, those things are filled up a warehouse somewhere, those systems that were rated as— I think we did— we ever get to an A1 system? I know there were some B1s. I think there was one A1 system, going back to the Orange Book and the trusted computing systems kind of days when I first got my start in computing or in security. And those A1 systems, I don't know where anybody ever used them because you really couldn't do much with it, right? But you had the formal methods to back it up. So how do we even get there, John, from kind of this perspective of defining safe software?

**29:07 John Martin:** So if you think about the Rainbow Series, it was mostly about Yeah, or huge chunks of that were devoted to things like access control and who can do what and, you know, elevation of privileges and that sort of thing, right? Elevation, degradation of privileges, privilege management, all that stuff. In fact, I've got a copy of the, of the whole series here if you want.

**29:27 Robert Hurlbut:** I've still got an Orange Book on my shelf over here too.

**29:30 John Martin:** So, so the definition of safe, I think, I think I could come up with 3 or 4 definitions. I'm sure you could as well. The question is, what can we come up with collectively that makes sense, does not stifle innovation, and at the same time is manageable by us as humans, right? Or even through our automation. So, you're right, the definition of safe is huge. It's really, it's a difficult thing to do, but it's a doable thing to do. We managed to do that. You know, I'll say this, we managed to do that in, in all sorts of things. We all buy electrical outlets, they're UL listed as being safe. We all purchase— I just had to rewire my house and put in a new big panel. It was inspected after the job was complete and deemed safe.

**30:31 Robert Hurlbut:** Okay.

**30:31 John Martin:** Right?

**30:32 Robert Hurlbut:** Yep.

**30:33 John Martin:** We have civil codes, we have all sorts of codes that we can rely on to say, this is what we mean by safe in the legal sense. The liability part of that is the part that is probably going to be the most controversial because now we're talking dollars. Now we're talking the ability of a software company to be able to acquire angel financing, to be able to, you know, start up to acquire financing, an established company to be able to introduce a new product line. Once we start getting the lawyers involved, things get complicated. That's just how it is. Look at the FCC as a great example of that. And so, so from a practical point of view, I think, I think the liability statements are, are really much more difficult. From a philosophical point of view, it's pretty simple. You You damage somebody, you're liable for the damage.

**31:29 Robert Hurlbut:** I think if I had to solve this problem and I only had 1 or 2 minutes to describe my explanation, which I'm sure we'd have weeks, if not months, to actually formulate this, but I'm almost thinking about the secure development lifecycle as your building code. And so, it's going to change. What defines a proper secure development lifecycle is going to change just like the building codes change. over time. But I would be more interested in defining, hey, what is the process and standard that you have to comply with? Because I know you're never going to be able to say, hey, no vulnerabilities, right? That just, that just starts to break down. But if we had assurance that you were doing the right things from an SDL perspective, that would get us, I think, 90% of the way there towards a much more secure future.

**32:17 John Martin:** Chris, Chris, I've got to tell you, I disagree. And here's why. We've been testing software for a long, long, long time. Most of the company software that we've been testing have established SDLs. They're proud of their stuff. They're proud of the way it's developed. Yet we keep finding problems with it. I think sometimes we conflate the ideal with the results. We say, if you use this process, we guarantee the results are going to be this shape. It's sort of that ISO 9001 kind of viewpoint. If I build parts for an aircraft according to this process, there will be no rejected parts when the aircraft manufacturer receives those parts. And yet, as we all know, whether it's an automobile or an aircraft or a furnace, there's tons of rejected parts produced by ISO-certified manufacturing facilities. So, I think we've got to somehow figure out a way to measure results, with samples of results, right? So let's say you've got a highly automated DevOps production line, you've got trusted, trusted repositories, you've got trusted, trusted componentry sitting in those repositories. You can build code from trusted, trusted pieces and put it all together in a really, really bad way and produce the most vulnerable stuff that's ever been written. especially when we start talking about protocol integration and stuff like that. Anything that reaches outside the software, anything in that extended chain of trust becomes extremely vulnerable. So, I totally agree with the concept, and in the ideal world, you're absolutely correct.

**34:01 Robert Hurlbut:** Now, I do agree with you that everybody's got an SDL, but the point I will make is Is everybody using the SDL with everything that they're creating to the same level of rigor and measuring that process? And in my experience, the answer is not even close.

**34:21 John Martin:** No.

**34:21 Robert Hurlbut:** So the, the SDL is a picture on the website that we share with customers that says we take security seriously. But if you dig in and say, okay, well, is this 100% across the board? So that's what I'm saying is I think SDL could get you to the solution, not in the way that it's done today where it's more of a sales feature without the traceability that gets me back to the fact that, hey, this is actually being implemented. So I believe in the concept. I think where we fall down today is we don't have the traceability to say this is actually being used in 100% of the things that a given supplier is providing.

**35:01 John Martin:** Exactly. And, you know, Robert, this is where you jump in and say, yeah, but threat modeling will help that, because you're absolutely— and I hope you do, because it's absolutely the truth. Absolutely. A good threat model says these are the things that we need to be looking at in terms of security features, in terms of secure production, in terms of testing at the middle and end of production. These are the elements that we need, that need to be trustworthy in this computing system, whether it's a privacy concern, whether it's a hacking concern, whether it's a trust issue, whether it's data disclosure issues, whether it's the potential for bad configurations to be automatically produced At every endpoint. You know, the promise of DevSecOps is that, that we can produce secure code very, very quickly, and we can misconfigure it every time.

**36:00 Robert Hurlbut:** I don't see that. That's never put on the tagline. I never see that advertised.

**36:05 John Martin:** So, so the, the prevention, I think, is, is all about, is all about testing and certification. I can't, I can't make a major change to my house without that being certified by numerous groups, you know, and an inspector comes out and says, yeah, you've done it right. How much more important is the software that we all use, that we all rely on, that's embedded in everything we do, from the, from the systems that's recording this conversation, doing the transcriptions, all the way out to, to my automated door locks?

**36:43 Robert Hurlbut:** So it sounds like you're, you're saying If we draw this, this parallel to the building world where you have standards and then you have inspectors who are coming out and validating that you did the work correctly, is that, is that kind of where you're landing from a recommendation perspective about how this could actually be done?

**37:03 John Martin:** Yeah, yeah. If we look at the industry as a whole, we can't, we can't do advisory sorts of things. That's— we, we have a long history of failing at that. How many ISO standards, how many NIST recommendations can we ignore and still produce software? Because we've been ignoring them for years and years and years. ISO 27034 is a great example of that. It's how to build software securely. I cannot think of a single shop that embraces all of ISO 27034, including the shops of the, of the people that that authored the document. So I think legislatively is what we've got to do. I just don't see a way around it. So I think that, you know, where do we go from here? If indeed that's the case, right? And I think that that's just something we should have a great discussion about. But if that's the case, then where do we go from here, right? How do we begin to craft a solution that's going to be acceptable to the world, something that's legislateable. We can't go on producing documents and advisories that nobody reads or uses. That's just not good business.

**38:21 Robert Hurlbut:** So, is there a place where there is some type of dialogue happening about this topic right now? If we have some passionate listeners who who are listening to us yelling into their— to the speakers trying to get the message back to us. Is there someplace that that's happening right now, anywhere in the world?

**38:38 John Martin:** If there is, I don't know about it. I do know that organizations like safecode.org and organizations like Cloud Security Alliance are a great place to begin talking to people. This is, you know, on the technical advisory groups within those 2 organizations, we have a lot of discussion around root causes and things like that. So, if you want to get involved, to our audience, if you want to get involved and you need— and you as your organization need to do this under an NDA, then join safecode.org. That's the one way that you can have these discussions and maintain the confidentiality required to be candid about the discussions. If you have no, no, no big need for, for, you know, corporate type of privacy, then join Cloud Security Alliance. I think that that's, that's probably where the best discussions are going to be happening over the short term. I'd like to be— to see a lot of this kind of discussion going on in IEEE and some of the other organizations, but I haven't seen it yet.

**39:48 Robert Hurlbut:** John, thank you for taking the time today to introduce us to this idea of cyberpocalypse and the different things that can happen. I know you've kind of stretched my brain here a little bit as we're thinking about the ramification of, of this, and it's definitely something that we as a community need to embrace and get in front of because it's not something we want legislators sending to us and saying, well, we thought about what safe software is and here's our definition that we wrote. And so we got to grab a hold of this and do something with it ourselves.

**40:19 John Martin:** Yeah, yeah, we've gone through a lot of that, the Royce Amendment and a whole bunch of things. There's a, there's a group over in, in Northern Virginia advocating for if you write code, you must sign your code, and we'll have a packing list of signatures that go out with every software product. But, you know, if you're signing bad code, you're already— the company's already compromised. And that's like saying, you know, we captured that murderer after he killed 22 people. Aren't we cool?

**40:45 Robert Hurlbut:** Yeah, it doesn't really give you that type of satisfaction. You know, you caught the person, but it would have been nice if you would have caught them before. Kind of the, the Tom Cruise movie— was it Minority Report?— where they could tell if you were going to commit a crime in the future.

**40:58 John Martin:** Right, right. So, so we need a little bit of Minority Report. And, and we, we, regardless of what else we do, we need to get a moral sea change. We need to We need to stop endorsing the concepts of deferred responsibility. We need to— we as software, in some cases manufacturers of software, builders of coders, we need to subscribe to the clear moral principle of fix it now and I don't have to fool with it later.

**41:31 Robert Hurlbut:** Yeah, that's a great summary of our conversation today. Well, John, thanks for taking the time to be with us here, and we look forward to continuing this dialogue with you in the future.

**41:41 John Martin:** Yeah, it's a plan, man. Thanks for having me. Appreciate it.

**41:45 Chris Romeo:** Thanks for listening to the Application Security Podcast. You'll find the show on Twitter @AppSecPodcast or on the web at www.securityjourney.com/application-security-podcast. You can also find Chris on Twitter @edgeroute and Robert @roberthurlbut. Remember, security is a journey, not a destination.

---

Source: https://appsecpodcast.com/john-martin-preventing-a-cyberpocalypse/