<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=1076912843267184&amp;ev=PageView&amp;noscript=1">

CISA Secure by Design/Secure by Default is HARD

August 31, 2023
In this episode, Matt explains why CISA's Secure by Design, Secure by Default policy is great in concept, but is actually difficult to execute in the real-world. This is because the policy can really only be applied to new software that hasn't been released yet to the market.

 

Learn More


Episode Transcript

Hi, everyone. Welcome back to another episode of ReversingGlass. I'm Matt Rose, Field CISO at ReversingLabs, and today's episode is CISA's Secure by Design, Secure by Default. It's hard. It's a lot harder than we expected. Reason being is there's a little bit of an issue with the concept of by design or by default.

This assumes, and I'm going to use a little graphical imagery here, that your applications, your software, is a newborn baby. It's brand new. It has its life ahead of itself. It has not had any bad things happen to it. It hasn't been influenced by people or society. And I'm not getting on a soapbox. But this is not true.

Modern pieces of software and applications are not a newborn baby. They are something else. What are they? They're Mr. Frank, Frankenstein. They are Frankenstein's monster. They've evolved over time. They've been in existence through many upgrades, many version releases, feature releases, bug releases. So this is an entity that already exists.

Modern applications are not simplistic to understand. You have geographically dispersed teams around the world writing first party code, the open source code, dependencies, APIs connecting to other systems. Software and applications are complicated and they're being released faster and faster than ever before.

So thinking about that, let's grab the little board here. How can you design something We'll do design to production that is secure if it already exists. So going back in time and re architecting a product, a little homework assignment thinking about the applications and the software you're using in your organization or you're creating for your customers.

What version are you on? The versions are probably way up there, and with modern CI/CD processes, they're constantly changing. So to go back and re architect something from the beginning is very difficult. It's not as easy as just saying, sprinkle some magic security dust on this, and now it's secure by default, secure by design.

A little analogy I like to use here, and this is way off the reservation. One of my favorite historic vehicles out there is the Land Rover Defender. This is an iconic off road car. Guess what? It's a very unique car, and it was important to the U.S., stopped in 1997. Anybody want to know why?

Because they didn't want to put airbags in it. Land Rover decided it's just not beneficial to re architect the car to account for the new airbag rules in the United States. So production was still existing around the world, but important to U.S. was basically stopped in 1997 and if you can find one of these in decent shape, they're worth a ton of money now, just because of that issue.

So think about that in conjunction with secure by default secure by design. If somebody doesn't have a problem or a known problem about their application or piece of software, are they going to go back in and re architect and retrofit, let's just say hypothetically, an airbag like the Defender itself?

So when you think about Secure by Default, Secure by Design, it's only really works for new applications. And I've done, I've been doing this a long time. I've been talking to people and, the whole concept, which I am totally against because of just the complexity of shift left. If you shift everything left, you're only going to find things on the left.

And that really insinuates that there's a beginning. There's just the process, the existence. So if somebody has an application that their customers are using, they're selling to customers, they're using in many different ways... are they going to go back and re architect something to be Secure by Default, Secure by Design, when they don't even know if there's an issue to begin with?

It's a lot easier to do that with new applications. And again, that unofficial metric. I would talk to people around the world about their applications. I'm like, how many net new applications are you building or software are you building right now? And there's a lot of head scratching. And they're like, I think we built a mobile app a couple years ago.

Applications and softwares just exist and evolve and are a constant state of change. So to re architect it from the beginning is very difficult, which is why Secure by Default, Secure by Design is great in concept, but very hard to execute in real life. I'm Matt Rose. Hope you enjoyed this episode. Have a great day, everybody.

Matt Rose

About Author: Matt Rose

Field CISO at ReversingLabs. Matt Rose has an extensive background in application security, object-oriented programming, multi-tier architecture design and implementation, and internet/intranet development. His areas of expertise include Application Security, SAST, DAST, IAST, SCA, DevSecOps, and Threat Modeling. Matt is an accomplished public speaker and has been quoted in 50+ AST industry media publications.

Related episodes

ReversingGlass

Development Secrets

Artificial Intelligence (AI)/Machine Learning (ML)

ReversingGlass: EO on AI: What security teams need to know

ReversingGlass

Shift Up Your SBOM

ReversingGlass

Who is ReversingLabs?

Artificial Intelligence (AI)/Machine Learning (ML)

AI and Software Supply Chain Security: Proceed with Caution

ReversingGlass

What the heck is an SBOM?

ReversingGlass

What is ReversingGlass?

Subscribe

Sign up now to receive the latest weekly
news from ReversingLabs

Get Started
Request a DEMO

Learn more about how ReversingLabs can help your company reduce attack surface risks with deep software and file threat analysis to speed release and response. 

REQUEST A DEMO