Beau Friedlander (2:23)

But underneath all that frustration was a bigger question, one that goes beyond bad advice. If individuals and small organizations can't realistically carry the full burden of staying secure, why are we still pretending they should? That question led Bob somewhere unexpected, not deeper into cybersecurity culture, but into history. Specifically to a book about cars. I'm Beau Friedlander, and this is what the hack, the podcast that asks, in a world where your data is everywhere, how do you stay safe online? Hey, do you have a copy of Ralph Nader's Unsafe at Any Speed there? I bet you do. You seem like you like him.

Bob Lord (3:17)

I do. So I have multiple copies of Unsafe at Any Speed, the Designed Endangers of the American Automobile.

Beau Friedlander (3:25)

And that was about the Corvair. That was about this wobbly.

Bob Lord (3:28)

So, yeah, so this is, that's the one I had. This is the red one that if you go on ebay, you can find a copy. Unfortunately, they'll charge you 80 to $100 for it and it will look like it was sitting in somebody's, you know, submerged basement for a decade. So unfortunately, that's, that's how it's going to go.

Jack Cable (3:44)

My book on safe and easy speed, which is. This is. This is the original. See, originally it was 595. How quaint. Then this was the 72 update, which dealt with the progress under the law. And then this is the one that just came out on the 25th anniversary.

Bob Lord (4:10)

I, in reading this, found a lot of similarities to the ways in which the automotive industry acted back in the 60s and the kinds of things that we see with software now.

Jack Cable (4:22)

A lot of times this book is described as a book that exposed the Corvair as if the entire book was on the Corvair. The entire book was not on the Corvair, as many of you know. It was just on the first, on the first chapter.

Bob Lord (4:36)

And so I put a little sticky next to every reference that I thought could possibly pertain to the. The software industry. So it's just chock full of stickies that, that are, that are just similarities. And it really shouldn't, I guess, be a surprise to me because whenever you see a new market growing, the vendors have to compete based on a variety of things, and safety wasn't a consideration. And so we see very similar processes and work here where customers may not even know that the safety of your car is determined by things in the design itself. And back then, they didn't even understand the, that the likelihood that you were going to get into an accident was in part driven by the design and implementation of the car. And the amount of damage to your body that would happen was also a function of the design of the car. And software is the same thing. So software can be made far more safe than it. Than it generally is across the board. I'm making a broad sweeping Generalization. So this is not true of every company, but we do know how to make certain kinds of software far safer than they are today. We need the customers to start to actually ask for software that's going to be implicated in fewer intrusions, that's going to be harder for bad guys to break into. This is something that we've done in the past, and I think it's something that we can do with software.

Beau Friedlander (6:06)

But, you know, and that's a big difference is, you know, I've heard privacy by design, I've heard security by design, secure by design, secure by demand is a different beast.

Bob Lord (6:18)

Back in 1962, if you had a beautiful new Corvair car that you had just purchased, and if you knew what you were doing, you would also know that the Corvair had some interesting performance characteristics, such that in gusty winds or in tight turns, you might actually flip the car over and cause lots of damage to your body.

Jack Cable (6:37)

The swing axle Corvair was put into production despite the strongest, most vocal pleading against it by the engineering staff, experts on vehicle handling and suspension.

Bob Lord (6:47)

And so, good news is, you could go into a store, buy a magazine, and in the back of the magazine, you could look at an ad, and the ad would be for a thing called a camber compensator. And this was a device that you could order. They would send it to you, and then you'd bolt it onto the bottom after you had received it, if you knew how to do such a thing.

Jack Cable (7:05)

Mr. Knudsen told me that as Chevrolet general manager, he had to threaten to quit before the corporation would approve replacing the dangerous swing axle with a slightly more expensive, safer design in 1965.

Bob Lord (7:19)

That is not how we expect cars to work today. We expect that the cars to have built in safety mechanisms. When there is a car crash, we expect that the car will do its darndest to absorb the energy of that collision and keep the passengers safe. This is a transformation that we need to make in the world of software. We need to make sure that that the burden of staying cybersafe is shouldered by those most capable of ensuring that which is not the individual is not you. It is not me. It is not the small businesses who may not even have an IT person. It is the manufacturers who understand how the attacks and the problems and the failure modes work at scale and in great detail, and those who can build it into the system so that there are fewer bits of hacklore floating around, see how these things are connected.

Beau Friedlander (8:09)

So if Ralph Nader were coming up today, if he had been born, I don't know, in the 60s and not in the. Whenever he was born, 40s probably, he'd be working at CISA, he'd be working at a think tank. He'd be, I mean, cause it is a different world. But you're doing the kind of thing right now with secure by design and demand that was happening with the Corvair back then.

Bob Lord (8:32)

Yeah, I think that there is reason to believe that if he were in this space today that he would be leading a secure by design initiative somewhere, wherever that is, I don't know. But I think we can all look to history to try to figure out how to, how to get better at these things.

Jack Cable (8:50)

So as someone said in Car and Driver, the Corvair presents a real challenge to driving expertise. And so I am convinced just from that deduction that in this room are some of the best drivers in America.

Bob Lord (9:06)

We need to look outside the world of software in order to figure out how to improve software. So we have norms and habits and we have these general improvements in all sorts of other sectors where we have improved safety for customers as well as the general public. So planes, trains and automobiles and medical safety and food safety, there's lots of different things there's that exist in our world where we've made huge improvements. So I'm confident we can do the same thing with security, but we need to make sure that we are really focused on it.

Beau Friedlander (9:48)

So, Bob, today we were lucky enough to be able to get a colleague of yours from CISA and elsewhere on the show to help us unravel this new area, new to us anyway, security by design. And so without further ado, we have with us Lauren Zabrick.

Lauren Zabrick (10:08)

Thank you, Beau. What a cool podcast name.

Beau Friedlander (10:12)

It's. It works for us. Lauren and Bob were the primary architects and the public faces of cybersecurity and infrastructure security agencies Secure by Design initiative that was launched in April of 2023 and it was. You know, I don't usually think of movements happening within organizations like the Department of Homeland Security, but I'll say the movement that they started, it aimed to shift the burden of cybersecurity from people like us to the people who make software for people like us. Software manufacturers arguing that security should be a foundational requirement rather than an sort of add on or something that you have to take care of the minute you start using something.

Bob Lord (11:01)

Yeah, that's exactly right. So a common theme running through all of these initiatives that I like to work on is the idea that we shouldn't be giving Advice to thousands of people or millions of people or billions of people. We want to be able to start to move the responsibility for staying cybersafe upstream to the technology companies that can best eliminate the risks at the source.

Beau Friedlander (11:28)

Now, Lauren, you have a reputation for your work in national security, a good reputation for your work in national security. You were the former director of the Cyber Project at Harvard's Belfer Center. And so what was your take? As I understand it, you were more on the policy and strategy side of Secure by design, is that right?

Lauren Zabrick (11:48)

I'll be honest, I don't. Even though Bob and I have worked together now for what, two and a half years, the story of why he sort of came to me, I'm still not quite clear on it, but I still, I just feel so lucky that he did. And I do think of myself as a strategic leader, having had, you know, I'm over 22 years in national security, between the military, the intelligence community, academia, private sector, and then of course, the opportunity to jump back into government at CISA and, you know, be a senior advisor there.

Beau Friedlander (12:25)

And together the two of you, along with Jack Cable, created the Secure by Design pledge.

Bob Lord (12:31)

So the pledge is really a series of very specific things that companies can work towards. And so it includes things like making sure that within a year of signing the pledge, your company is going to demonstrate actions to take measurable increase in the use of multi factor authentication across the products. You would think that that would be a given, and yet we found that it was not. Or default passwords is another thing. So there's still a lot of systems that are shipped with the same default password. And if you just Google the name of the product, you'll find the default password in the manual. And so there are these series of things where we wanted to see what can we do to go from a world in which companies claim to take all security matters very seriously to very specific things, seven very specific things that they can do. And we asked them to measure their progress, things like security patches. Some companies don't actually measure how many customers have adopted the latest security patches. And so some of them already were, but some of them had to start a program to start to measure that. And you know, you can't improve what you don't measure. So they started that program and a lot of that was in response to the items in this pledge.

Beau Friedlander (13:45)

So when, when it comes to the way that this is rolled out, the Secure by Design pledge, which was a voluntary commitment which gathered signatures from over 200, maybe 250 major tech companies including Microsoft, Google, Amazon and others, just those are some big ones was that you're doing or your part of your contribution was to sort of think about how this gets rolled out.

Lauren Zabrick (14:12)

What I think was one of the biggest things about this pledge, and of course this is an extension of the whole secure by design movement, was that it articulated that security is a customer need and a customer requirement. The government is here, we're saying this officially because I'll be honest, I don't think that generally the industry thinks of security as a customer requirement of software. Right. But I think a lot of customers think that it's implied that they're already getting it right. So there's something kind of lost in translation. But then what it did was not only to articulate that and say that we are demanding it, right, Created this market, right? So now it's visible, now it's an explicit requirement, explicit need rather than implicit. And so we're talking about not only that, but how to achieve it, kind of with the resources and the knowledge that we have right now. And then also giving customers the language to talk about it and to ask for things.

Beau Friedlander (15:21)

Now you also included in there, secure by default, the idea that products should be secure, quote unquote, out of the box. Right. You know, so that's not everything comes out of a box, sometimes it's a click. But the idea that that's not something that would require extensive configuration was also part of the pledge, I think. And then another thing that I really, I think is important is the hardening guide. The idea that the built in complexity of hardening a target should be reduced. The pledge. Seems like it's easier to say the pledge and then say, well, I meant to. What has been the actual experience? So I take this pledge, it's voluntary, which means that there's no, we're not in the EU where I might actually get fined if I don't do something.

Bob Lord (16:11)

So I think we. So the main observation is that we have to start someplace. And again, I don't know how many times I've seen a company say the phrase we take all security matters very seriously. But what does that really mean? And so what does it mean from them from their standpoint? How are they going to start changing their development processes? How are they going to start changing the way that they think about the products so that they take responsibility for the customer's security outcomes? So within the secure by design paper, there are three core principles and that's the first one. Take ownership of the customer security outcomes. So what exactly. Does that mean. So you have to start somewhere. So the pledge was an opportunity from. For us to come together with a few hundred of our closest friends. It started off as, I think, 68, but then it expanded to a few hundred for us to come together and say, what does good look like today? And there's certainly a lot of stuff that I'd like to see on the pledge, but companies just can't agree to it. So this was the list that they could agree to. Now, CISA is not going to be issuing report cards. They're not going to be naming and shaming. That's not the role of the government. But I do think that there is an opportunity for folks to go back and take a look at some of these products and, and ask if the companies have made reasonable progress.

Lauren Zabrick (17:32)

The things that made up the pledge were, by and large, the things that we saw that were causing a lot of issues. Right, with incidents and breaches and things like that show that they are going to make progress while also working with them internally and then looking to the public. Right. The third parties, the civil society, to then shine a light, like, or the media, for instance. Are these companies actually upholding pledge? And what we wanted them to do was provide artifacts so that customers and these outside parties could sort of look at them and say, okay, they are making progress or they're not, and then hold them to account because that just wasn't something that CISA was able to do. But ultimately we know that it's, you know, the pledge is the. Not the panacea. It's a bridge to something bigger from a policy perspective.

Beau Friedlander (18:30)

After the break, we're going to hear exactly what needs. It's a historically hideous season.

Bob Lord (18:36)

It's our 100th ugly house. And if these walls could talk. Do you cry a lot?

Lauren Zabrick (18:42)

I do.

Bob Lord (18:44)

Ugliest house in America. All new Wednesday at 8 on HGTV.

Beau Friedlander (18:48)

Be to be fixed. Okay, so we're about to talk about something super, super duper complicated to you who are waiting for a crime. Well, this is how the crimes are committed. And that's sort of cool, right? Interesting. Anyway, 70% of all serious software vulnerabilities stem from something called a memory safety weakness. Now. Okay, what's that? That's what most of those security patches are about. And the reason they matter is because hackers can use them to get into a system. Now, why do they exist? Because languages like C and C, which you're going to hear us talking about, trigger alert, C and C require manual memory management, which means Even the best engineers in the entire universe are going to screw up and when they do, there's going to be openings, openings for hackers to get through. And so yeah, it doesn't exist in other languages like Rust and Go. Anyway, that's the terror territory we're talking about. We're talking about memory and how hackers exploit it. Definitely not Proustian. More on the tech side of things.

Lauren Zabrick (20:10)

And so looking at the different attacks or an incidents that have happened because of that very prevalent class of weakness and then you know, trying to explain how this is actually preventable, right? It's well known, it's preventable and yet look at how responsible it is for all of these things that have happened. Doesn't have to be that way, right? So kind of coming at it from that perspective, I think rather than going into the sort of nitty gritty, you know, okay, read and write, you know, buffer and crashes and things like that, people aren't necessarily going to understand that. But at least knowing that again, this is a well understood error and there are fixes for it, and yet they are not, you know, for the most part being applied and all these incidents are happening because of it.

Bob Lord (21:03)

The way that I think about this is imagine that you have a shopping list and you have 10 slots for items to go shopping. What happens when you add an 11th? Does the code know what to do because you only have 10 slots for it? Or how about if you ask for slot 73 but you only have 10 slots allocated? Or how about if you ask for slot negative 5 million, what happens? And is the, is the software going to be able to figure out that those are nonsensical in a world where I have 10 items on my shopping list? And so some languages already have built in capabilities to prevent bad things from happening and so they have to rely on the software developer to make sure that those problems don't happen. When multiple big companies do long term analysis of their, of the code and the code is the choice of programming languages is actually an ingredient in the product. It is the manufacturing process that they used. And when they take a look at the code bases that were the portion of the code bases that were in C and C, 70% of the vulnerabilities were tied to memory unsafe code. And we're talking about super smart people with very good tooling. And so if you say if the best and the brightest with the budgets to have all the right tools and the right training, if they're still unable to really move the needle on that particular Number, maybe it's not the software developer. Maybe you don't need to go back and yell at the developers to think more deeply. Maybe it's a tooling problem. Don't blame them. Look at the tools.

Lauren Zabrick (22:43)

Yeah, and then I was just going to say, you know, we know that humans, right. We make mistakes. And so as we look to this issue and you know, we've looked at other industries. Well, how have other industries made things safer over time? Part of that is knowing that it's the design of the thing, right. To then reduce the impact of human error because we know it's going to happen. Right. That makes things safer over time, whether it's sort of an internal thing. Right. So like a developer ecosystem or the actual product itself. And that goes to the heart of secure by design.

Beau Friedlander (23:25)

Well, you know, yeah, but also the, the, the thing that just hopped out at me when you said look at the tooling, Bob and Lauren, your, your response also just pushed me in this direction more. Is the, the. We're talking about the way things are built. We're talking about basically manufacturing. Like if we were to look in old terms, like I would prefer to have a car that had a steel frame rather than a copper one. I don't want a copper frame chassis because I feel like it won't perform as well if I get in an accident.

Lauren Zabrick (24:04)

The parallels between the cybersecurity and the software development industry and the automobile industry back in the 60s is stunning. And you know, I'm so glad that you brought up Ralph Nader and this work because he goes into detail about how the very specific designs of the car itself is what led to these really horrific ways that, that people could get maimed and killed. And then without those things, right, if we can secure those things, if we can make those things demonstrably safer, then people are safer. And that's what we're trying to do here. And then of course he goes on to kind of talk about how, you know, the, the company's like, ah, it's going to cost too much. And you know, oh, we're trying this and you know that it was like very, the, the, the testing and the data collection and it was all very siloed the way it is today. You know, again, people are talking about costs and you know, but, but you know, to Bob's point earlier, we're not really recording those costs. We don't understand what those costs are compared to the economic costs. Right. For all of us that we're all paying as a result of this. So and then to your point about why, when we talk about costs and you know, is this part of that issue, ultimately it's a business decision and that's why it has to go to the leaders. Right? All of these decisions on quality have to be made at the top.

Bob Lord (25:44)

So when we talk about costs, we should ask, costs to whom, cost to whom, and under what, what circumstances is something we need to keep asking. And you know, just to go back, we've been touching on one topic, but we haven't actually really teased it out. There's this concept that a lot of people are not familiar with, which is the idea of classes of vulnerability. So when we think about a software vulnerability that can cause some harm, they are not unique snowflakes. They are categorized into specific buckets and they have specific numbers. And we know what they are unique. You mentioned memory safety. There are actually many different kinds of memory safety vulnerabilities and they all have names and numbers, they're all categorized. I'm sure nobody in the audience will care to go a little bit all up.

Beau Friedlander (26:33)

Some will, some will.

Bob Lord (26:34)

But yes, we need to start talking about these categories or classes of vulnerabilities and not just assume that the vendor could not possibly have foreseen a cross site scripting vulnerability or a SQL injection vulnerability or directory traversal vulnerability, all of which have been at the top of the list for the last 20 years or so.

Beau Friedlander (26:55)

Now, 20 years is a long time for something to be at the top of the list as a problem. And it's a long time for a hacker to be able to say, to sit at a desk and say, I wonder what happens if I change this variable. I wonder what happens if this bucket is a problem at this company? And isn't that essentially what now, it can be automated to a large degree, but that's the danger is that there's a huge catalog of vulnerabilities that can be tested one by one.

Bob Lord (27:31)

That's exactly right. And many companies have internal teams who run the same kind of tools to try to determine if their software has those kinds of vulnerabilities. But sometimes you, you can't just in the same way that with physical manufacturing, you can't QA quality into a product. Does that make sense? You can't just inspect quality. So we need to go back and think about what is it that is going to be required to remove this kind of vulnerability entirely. So rather than playing whack a mole, where the software company is made aware that there is a vulnerability, they produce a fix, they run it through their qa, they publish a version and now the burden is on the customer. And that could be an end user, could be you or me, and it could be enterprises. And having worked at a, at a small, not for profit, I will tell you it is very, very, very difficult to figure out how to apply all the patches for all the things. It's just not economical. So back to the question of cost. Whose cost are we talking about? So anyway, click. Classes of vulnerability is one of these topics that just doesn't get enough air. So I just wanted to toss it into the ring. That are built into the design, you can't retrofit those in to an existing.

Beau Friedlander (28:48)

That's what you just said. You just said the whole thing right there is that they were two things you can't build them in afterwards. And also the technology to build these things existed long before they were to people started to, to CEOs said we're going to do that. Right?

Lauren Zabrick (29:10)

In order to make this transformation towards quality, that decision actually has to come from the top. But it's more than just a decision. It's putting in place the incentives, like the incentive structures so that people, the workers can sort of orient around that. And more than that, it's resources as well. Right? So it's, it's the structure, it's the incentives and it's the goals that they are putting into place. And in industries or companies that aren't doing that, those smaller departments that are sort of responsible for quality or you know, maybe in this case it's security, they're always going to have to be fighting for that thing instead of it being a company priority.

Bob Lord (30:09)

Looking to create the bath you've always dreamed of without all the hassle. The Home Depot makes it easier. Shop fully styled rooms and curated collections to bring your value vision to life. Use digital tools to preview flooring and finishes in your space and get everything you need from tubs to tile delivered fast and priced right. The Home Depot Dream Baths built here. This is pro linebacker TJ Watt and I'm back with YPB by Abercrombie for another activewear drop.

Beau Friedlander (30:45)

My second co design collection has new.

Bob Lord (30:47)

Shorts and tanks that keep up with all my in season and workouts.

Beau Friedlander (30:50)

And their new Restore collection is a.

Bob Lord (30:52)

Game changer off the field too, because even pro athletes like me need rest days. Shop YPB by Abercrombie in the app, online and in stores because your personal best is greater than anything. I think it's time we talk about incentives because we've been Kind of dancing around it.

Beau Friedlander (31:17)

So the CFPB was the answer to what do you do about a problem like bad products in the finance world? So when are we going to get a cfpb? Is it cisa? I mean, when are we going to get a CFPB that has teeth, that has the ability to fine, has the ability to say you, you lose and you owe us $10 million?

Bob Lord (31:47)

There's a whole bunch in there. So a few things. One is again, looking outside the world of software. If a company is aware that they have a product defect that might be a safety defect, they're obliged, generally speaking, to report that. And that is not the truth. That's not how software works. And so there's a voluntary program that I spend a lot of time every week thinking about and working with other people on. It's called the CVE program and it's fantastic. But it is a voluntary organization, it's a voluntary program. And a lot of companies do a very good job of reporting their vulnerabilities and some not so much. And so that is one of the issues. Another issue is that there are liability protections that software companies enjoy. And so in most other sectors, if you have a product, you buy that product and because of a manufacturing or design defect, you were injured by that, you can sue them. And that is not true in the world of software. It comes as a great shock to people, even people who've been in the software industry for many years, they, they simply are unaware that that is, that that is the case. And so things like the end user license agreements say, things like this product is, is sold, is licensed, is not sold, it is not fit for any purpose. There's no warranty, express or implied. There's, you know, they're all, but those are some of the common themes that you'll see in them. And so what ends up happening is, and there are other incentives we could talk about as well, but what ends up happening is we've come used to the idea that the burden is on us as both end consumers as well as people who maintain networks and enterprises. The burden is on us to stay cyber safe. And what we're trying to do is really just introduce these concepts, the exact changes that need to get made. I don't know, I have some ideas. But the main point is we're not having the conversation. And so the more that we can have the conversation about the realities you'd mentioned, the ingredients and the processes in the factories that make software, we need to have a much more robust conversation about all of those things to figure out what we as a society are willing to tolerate, what changes are we willing to make to improve the safety outcomes so that you're not constantly in a situation where if you don't patch this thing on Thursday night, by Friday morning, you're going to have your, your entire organization compromised. That's, that's not how we do things in other sectors. And we need to learn from those other sectors. That's the way the legal system is currently constructed. And again, there are some products and companies who make those products who have made tremendous improvements in cybersecurity for their customers. So it's not like this is a hopeless thing. In fact, we have existence proofs of products that just have fewer and fewer of various kinds of defects over the years. So we know that we can do this, but we have to start with the conversation. And this is like in 1965 when Ralph Nader published Unsafe at Any Speed. People bought cars based on lifestyle, on performance and sleek design, and, and all sorts of things other than safety. And so safety wasn't a part of the conversation. And so the customer didn't have the opportunity to say, I'd like a safer car, because they were all built to serve a certain audience and safety wasn't part of that. And so that changed. And it changed in a bunch of different ways, including regulation, legislation, all sorts of things like that. But public awareness was a major component as well.

Beau Friedlander (35:26)

Now we don't have an education system that starts children at the age of 10 to 13 along the path of understanding basic cybersecurity and cyber hygiene. We don't have, you know, along with like learning how to boil an egg, we don't have. That should be part of Home ec. How do you balance a checkbook? How do you keep yourself cyber safe? What is privacy? How do you make sure that you have privacy if you want it, and here's why you want it. You know, there's all of that should be taught and it's not. Um, there should be a law, as people like to say. Let's talk about what, let's talk about not talking about these things. Let's talk about what needs to happen.

Bob Lord (36:14)

The, the software industry does not have to. If you're a software manufacturer, if you take money for your product, you do not have to declare vulnerabilities in your product. That seems out of step with common sense. And it's out of step other norms in literally every other sector. And so I would say that would be a really good thing. And then that would give us data. So one of the things that we don't have in a voluntary program is data that is true that gives us insights over time and across the industry. So we want to separate the kinds of classes of coding error that some companies just seem to make all the time, but the rest of the industry does not. We want to separate those from, from some of the harder memory safety problems which it turns out nobody is able to figure that out. And so that's a tooling problem and there's an opportunity for a different kind of remediation or different kind of plan to deal with those kinds. But some companies just seem to have directory traversal problems all the time. They have command injection problems all the time. They don't properly, properly determine if the person who is asking for advanced privileges in this particular product that they actually should get those. They have those all the time. And so having a lot of data would give us the ability to be much more strategic in how we think about regulation, legislation, things like that. One other thing I'll mention is most of these end user license agreements for these enterprise software and probably consumer, they say things like, you cannot reverse engineer this product in order to determine its performance characteristics or its security posture. And that doesn't seem right either because if I buy any other product I can take it apart and see what's going on in there. And if it had some sort of systemic problem, I could go write a blog or go to some legislator, whatever, I have options. But that's not true for many software products. So there are some of these things that are just built into the system that most people don't understand is just fundamentally different from other sectors and we could start to nudge the world of software closer to those other sectors.

Lauren Zabrick (38:26)

So something I'm thinking a lot about is, you know, as we're looking at our geopolitical sort of situation, right, we're, we're constantly trying to build our innovative capacities and capabilities and that's, that's great. And I think that's especially true in the technology sector and I just mentioned a few minutes ago, innovation at what cost and things like that. Part of that is this idea that we can have this really interesting cool technology that does interesting things, but if it's all sort of built on insecure foundations, then it's not really going to serve us in the long term. And to that idea of the foundations, something that we haven't necessarily mentioned, but this is one of our biggest points, is that we've really based our society, our national security, our economy, our public health, and safety on software. And so, you know, Bo, you mentioned, like, why, why aren't we teaching this to, you know, in schools and having that fundamental knowledge? I think there's, there's an interesting point you make there, because increasingly our society is just run on software, and yet we don't really acknowledge that from an educational or safety perspective. And I think we need to really do that to really make the point, like making sure that we understand it and know that, you know, whether it's insecure or not or, you know, what harms may be done because of it. You know, we have a responsibility, and everyone does, to understand that and to move us toward a system where the things that we're basing our society on are safe and they are secure. One of the driving factors behind the secure by demand part of the movement to be able to surface the things that customers should be asking for and giving them the language to do so. Because again, we would hear from the companies, well, our customers aren't demanding it. And again, that, that to me didn't sit right like there. I think that the signal itself was quite diffuse, but I think it was there and so secure by demand helped to concentrate that demand signal. So to your point about the education aspect, I think that the part of that is giving people the language and the tools to do that, to continue to signal demand, while we're also working on the policy, the environment, the systemic issues.

Bob Lord (41:18)

So part of what we have to do is take a look at what we call the four V's words that start with the letter V. And the first is that as a society, we tend to glamorize what the villains did well, the ways that they attacked. We use fancy names for them and we have these terms like zero day vulnerability. And it's all very glamorous. And so we truly glamorize the villains. And then we turn around and we shame the victims for not having patched face fast enough, either as individuals or as businesses. And we say, how could you, how could you have not put MFA on this administrator account? But what we really need to do is shift the spotlight of people's attention to the vendors who make the software where these, these intrusions are not just possible, but in many cases inevitable because it's just too easy to break in. And the fourth word that starts with the letter V are the visionaries. So we know that there are people who have been advocating for safer design for many, many decades. We need to put the spotlight on them. We need to start listening to what they've been trying to tell us literally for decades and turn that knowledge into the processes by which software gets made. So I'm very hopeful, I'm ultimately very optimistic that we can do this. But it is a mindset change more than anything else.

Lauren Zabrick (42:49)

I think we would be remiss. We've talked a lot about these ideas and the things that we're trying to make happen. But I also want to recognize the people who are largely still at CISA who are continuing the work as best they can right now. And of course, this team that we worked with while, while we were there to get some really incredible things done. And I just want to make sure that we are recognizing them because, you know, were it not for them, right, we, I don't think we would have had, I think the, the impact and the reach that we did. So obviously we're the, we're kind of the, the faces of the movement. There's a whole team behind there and many of them are still at C.

Bob Lord (43:39)

We've based our economy and our national security on software. That software is often riddled with defects that are well understood, and we know that those are driven by economic incentives. And so these are not the fault of people who need to get yelled at. This is a series of very complicated, interwoven incentives that create the world of the breach du jour. But again, we have people who have been on the right side of history for a long time. They've been telling us what to do, and we have some existence proofs. The fact that not to go too far into memory safety, but Rust is now in the Linux kernel, it is now in the Windows kernel, it is now being used in a lot of different programs, products. And so we know that we can do hard things. So I just wanted to really just punch that thesis that that is one of the core elements of what it is that we believe. You know, one of the things I, I think we've tried to do is try to explain the, the story of why software is unsafe. And if you want a video that will help walk you through it, on CISA's Secure by Design website, there is a little video that Jack Cable and I did, and it really kind of walks through the story of unsafe software.

Jack Cable (45:04)

The same was true of the Corvair heater. Many people, Chuck Hughes for one, objected violently to a direct engine air heater without an intermediate safety shield, because it's well known that all engine gaskets and exhaust systems will deteriorate and leak in time. So that the car would eventually inevitably become a carbon monoxide death trap. There is no telling how many people have been injured or killed by these deadly fumes, either dulling their reflexes so that their safe driving ability was impaired or actually causing a monoxide inhalation death. This would have been avoided with a sense of responsibility and concern for our public. Certainly we were forewarned by many of our engineers. Once again, we can expect expect much more expensive litigation so that the few cents the shield might have cost will be insignificant. And that was the end of his career. That letter. When Murphy got that letter, DeLorean's name was crossed out.

Beau Friedlander (46:04)

Lauren Zabrick Bob Lord, thank you so much for joining what the hack this week.

Lauren Zabrick (46:09)

Thank you Bo. Really appreciate you having us on.

Bob Lord (46:13)

Thanks so much. It's been a pleasure.

Lauren Zabrick (46:15)

Sam Foreign.

Beau Friedlander (46:45)

And now it's time for the Tin Foil Swan, our paranoid takeaway to keep you safe on and offline. This week's conversation about secure by design hits on a fundamental flaw in our digital lives. For too long, safety has been an aftermarket problem. Just like the 1960s car culture where you had to bolt on safety parts yourself or remove things that were going to kill you in a crash. We've been forced to improvise our own privacy. But we're finally seeing a shift from the hacklore of individual responsibility to the reality of tooling. When it comes to personal information removal, the tools you choose matter. This is the one field where competitors actually cheer each other on. Why? Because we care about privacy first. That said, not all services are built alike. After 15 years on the front lines of online privacy protection, hopefully you'll understand why we welcomed the first large scale attempt to build a mandatory digital privacy seatbelt. And of course, California. Now about us like right, delete me covers 750 more than 750 brokers globally and has learned the ins and outs of handling the stickiest data with people who you can actually talk to and customer movals that work that stick actually. So DeleteMe's reporting is like a monthly checkup. You get the evidence and the recurring manual verification that your data is actually gone. And security one and done doesn't exist. Right? It just doesn't. Whack a mole is the rule. The emerging public tools out there are awesome and you should totally use them. They're free and represent progress. But sticky data needs ongoing monitoring, special tools. Verification requires reporting. It's a different game because you're not just a consumer, you're a secure by design advocate believer, true believer and that means choosing the right tool when best in class matters. However you do it, and you can actually do it yourself. There's plenty of actually. There's do it yourself information on the Delete Me website. Here's the deal. Stop letting opportunists make bank on your personal information. It's not cool. It's not cool and it's not safe either. So get to it. It's early January still. Time to make this a thing you got done in 2026. Stay safe out there. Talk to you next week. What the Hack is produced by Beau Friedlander. That's me and Andrew Stephen, who also edits the show. What the Hack is brought to you by Deleteme Deleteme makes it quick and easy and safe to remove your personal data online and was recently named the number one pick by a New York Times wirecutter for personal information removal. You can learn more about Deleteme if you go to join deleteme.com wth that's joindeleteme.com wth and if you sign up there on that landing page, you will get a 20% discount. I kid you not. A 20% discount. So yes, color me fishing. But it's worth it.

Bob Lord (50:05)

Hello, this is Jack Wilson, the host of the History of Literature podcast. For the past 10 years, I've been talking to novelists, biographers, and scholars about the greatest books in the history of the world and the men and women who wrote them. Like our recent episodes on Dante in Love, a starter pack of 10 Indian classics, the pop culture that influenced Sylvia Plath, and a talk with scientist and novelist Alan Lightman about the wonders of nature. Join us at the History of Literature podcast wherever you get your podcasts.