Secure by Design

"Secure by Design" has garnered attention with the release of a document by CISA. What does it mean? How does it fit with Threat Modeling? And do you know if Secure by Design will answer our need for secure software?

"Secure by Design" means a system is designed with secure principles. The system should come pre-hardened and pre-secured, ensuring users don't have to configure it for security after installation. On the other hand, "Secure by Default" means that the system is configured correctly for security right out of the box.

The hosts explore what it means to be secure by design. Systems can be implemented with security principles rather than relying on users to configure settings post-installation. Matt raises the concept of "de-hardening" guides for compatibility and other situations. But Chris Romeo strongly opposes the idea, fearing it might provide a roadmap for undoing the security measures put in place.

They also discuss how Threat Modeling fits with Secure by Design as a guide at the beginning and in the verification process. The episode concludes with the hosts emphasizing the importance of continuous threat modeling and the need to stay updated with the evolving security landscape.

FOLLOW OUR SOCIAL MEDIA:

➜Twitter: @SecTablePodcast
➜LinkedIn: The Security Table Podcast
➜YouTube: The Security Table YouTube Channel

Thanks for Listening!

Transcript

Chris Romeo: 0:09

Yeah, I think we are.

Izar Tarandach: 0:10

Is this.

Chris Romeo: 0:11

I think we are. I think we may have, we may have figured this whole thing out called the internet. So welcome to the security table. My name's Chris Romeo and, uh, joined by my good friends, Izar Tarandach and Matt Coles. And this is our first time trying to use the internet, so it's relatively new to us. After, you know, multi decades of being computer people, we're trying to use the internet. And so we've been doing this show, the security table for, I don't know, a number of weeks at this point. I think we've got 10, 12, 13 episodes, something like that. We talk about things related to application security, product security. Sometimes we, we discuss civilly and nicely. Other times things get more heated when Matt tries to point out another standard that I should read and understand. I'm just kidding. It's always, it's all in good fun. We we're here to have fun, but we want to talk about AppSec, prosec, general security things. Just have a, and have a good time doing it around what we call the security table, which is a bit of a virtual table at this point. So, um, let's talk about Secure by design, though. Seems like it's getting a lot of attention. Um, CISA came out with a document secured by design, secured by default. Well, CISA and major governments from around the world came out with a document to try to put together and, and focus our thoughts on secure by design. And so let's, let's talk about what it is first in case people are out there going, I've heard of this thing, but it's a little bit of a nebulous concept. So Izar give us, give us some thoughts on

Izar Tarandach: 1:40

Oh, no, no, no, no, no, no. The good one is Matt. Matt defines and I refine.

Chris Romeo: 1:46

Well,

Matt Coles: 1:47

Well, so yeah, so I guess I'll, I'll kick it off then. So, uh, secure by design and of course we should. We should just let you know users, uh, viewers know of course that it's Secure by Design, secure by default, right? So if you're searching for this document or set of documents, it's, it's Secure by Design or secure by and secured by default. What we mean by secure by design is, uh, that. The system has been implemented with secure design principles in mind. Uh, that it comes pre-hardened, that it comes pre-secured, and uh, and that the things that rather than relying on customers to take something, install it, and, and configure it securely, that it comes out of the box that way. So secure by design, you build in the, capabilities secure by default, it's configured correctly.

Chris Romeo: 2:35

Mm-hmm. and, Izar happens to be writing the, the Great American novel as we...

Izar Tarandach: 2:41

no, I, I'm, I'm putting it, I'm, I'm putting into the, into LinkedIn, the URL for the doc so that people know what you're talking about.

Chris Romeo: 2:49

...follow along.

Matt Coles: 2:50

You need a less clicky keyboard there, uh, buddy.

Izar Tarandach: 2:52

I will never have a less clicky keyboard.

Chris Romeo: 2:55

All right, so Mr. Refinement here. uh, the definition's been set. So how, how would you refine the secure by design by default?

Izar Tarandach: 3:06

so I, I, I think that the keyboard here is aspirational, right? So we,

Matt Coles: 3:12

we,

Izar Tarandach: 3:13

We have been doing this thing for a long time and we we always keep telling people at some point people are going to learn and do the right thing and keep doing the right thing and just ingrain the right thing, into what they do. And I think that the, the security by default and security by design is sort of taking that one step up and saying, now actively we have to start looking from the beginning. Take The thing that we have always said about security is not something that you bolt at the end. It's something that you bake in. I I, I, I love that you bolt, but you bake, whatever, but uh,

Matt Coles: 3:49

Build in, build in.

Izar Tarandach: 3:51

Build in, build in. But the, the, the thing is that now we want to start, you don't want to start from zero. You want to start from something that you finally, after much trial and error and catastrophes, you have got into that state where you know how things, what things have to look like in order to be secure. be secure. And now you define that as your starting point. And you say this, this is what good looks like. And anybody wanting to build from here have to start at this, at this level. Have to, to start at this minimal amount of, of security. And, uh, you know, I, I think that, that, that plays well with something that we keep going back to in the, in the podcast, which is: what's reasonable to do in terms of security. And, uh, so far from what I have seen, the, I I I, haven't exactly seen anything like a, a hardening guide or configuration guide or 10 best practices for secure by design or whatnot. But but the discussion is at a place that put things in a very reasonable starting point, I think.

Chris Romeo: 4:57

so.

Matt Coles: 4:57

It's interesting you bring up, uh, hardening guides, in fact, uh, right, because if you look through that doc, those documents, uh, you'll find, you know, with the notion that you start secure by design, that you build in security, you design it in, right? You don't just, you don't just build it in, but you design it in, and then you deploy it securely. Then the theory goes that you can start looking at sort of de-hardening guides as opposed to hardening guides. Rather than have to build up from scratch, you can start allowing If, well, if so desired.

Chris Romeo: 5:29

please.

Matt Coles: 5:30

Chris is, Chris is shaking his head

Chris Romeo: 5:31

I, I remember when, so the three of us got a chance to provide some feedback on the CISA document through our, our Threat Modeling manifesto collective group, and that was one of the things that I. I wrote some strong feedback and I feel pretty strongly about don't encourage anybody to create a de-hardening guide. they wanna figure out how to de-harden something that's been secured, let them figure it out on their own. Don't give them a guide that says, here's how you, how you back out of all the good, the security goodness that's been added to the product.

Izar Tarandach: 6:03

But, but that takes us to a, an interesting place. Why would somebody try to bring down the, the security posture of, of a system, especially when it's already been like blessed as secure,

Matt Coles: 6:14

Uh,

Izar Tarandach: 6:15

right?

Matt Coles: 6:15

The number one reason I think that, that I think we've all heard over the courses of our career is performance, right? Or accessibility.

Izar Tarandach: 6:24

So here's the interesting thing, I I, I haven't heard performance as much in that context. If by accessibility you mean, because the thing is so buttoned up, it's difficult to do A, B, C, D.

Matt Coles: 6:39

Yeah. Or Compatibility. We, we see this with old, you know, we used to hear this with old, old web browsers. Right. And secure, uh, you know, Https services.

Izar Tarandach: 6:47

I, I hear that a lot with, uh, uh, uh, this privilege. I don't know what I'm going to need this account to do tomorrow, so I'm going to give it a privileged role and whatever it.

Chris Romeo: 7:00

Yep.

Izar Tarandach: 7:01

So that there's that forward looking idea of I have to be permissive because I don't know what I'm going to need tomorrow. Meanwhile, attackers are already needing having whatever they need today. But, uh, the, that, that's something that I see a lot. The, the thing to me is that the more I think about this, and, and Matt and I have discussed this a number of times.

Matt Coles: 7:22

a number of times,

Izar Tarandach: 7:24

It seems to me that as a security person, if I have to look over the shoulder of a developer at the time that they're developing, and I know that they start from a buttoned up state, and now they are asking me to open that thing up, thing up. it's a great opportunity for me for me to question that decision that and help make it a better decision. decision. Mm-hmm. Then the opposite situation when I'm sitting behind that developer and every keystroke I go on their shoulder and say, shoulder is, is this secure? Is this secure? Are, are you doing the right thing? Are you doing the thing that the training said that you should be doing? should be good.

Chris Romeo: 8:02

Yeah, but de-hardening, de-hardening is a step removed from that The concept of de-hardening is giving a guide to a customer So they can back out. The security confi default changes you added to the product to somehow bring it into a less secure state. And what I'm saying is I can't think of a reason why somebody. With for good intentions and good purposes, would want to back out the security settings because you can't tell me it hasn't been tested because we had to test it in this hardened state.

Matt Coles: 8:32

Mm-hmm.

Chris Romeo: 8:33

our release cycle to, to prove it was ready to go out to the world. So I, I'm, I'm not a big fan of this idea of having a guide that tells people how to back out all the things I've spent 26 years saying, and you guys have done the similar thing. We've been saying these things over and over again for decades. Like, don't, like, don't, don't erase something good that's happening in the Secure by Design movement. That's all I'm saying.

Izar Tarandach: 8:56

Oh, but, but, then it goes to what Matt said about compatibility, right? Because you wrote that hardening guide, and I want to believe that you tried a. number of configurations, but there will always be that guy that says, I'm running. I don't know. I have a firewall from 1980 in front of the thing, and I need to bring it to SSL

Chris Romeo: 9:17

Yeah, but Secure by Design.

Izar Tarandach: 9:19

won't go.

Chris Romeo: 9:20

Secure by Design doesn't have a hardening guide. Secure by default, there is no hardening guide. There is nothing for the user to configure. It comes out of the box secure, and what we, as the producers of the product say, is a secure state. So the user, they can't say, well, compatibility, it doesn't work. Well, no, it worked because we had to, we had to test it to order to release it, to prove that it did. And we didn't lock it down so far that it couldn't do its job. It couldn't meet the, the, the functions that it, that it had been called out to do. So

Matt Coles: 9:47

Oh, it's, it, it's a, it's always those strange configurations go like, like as Izar said, right? There's old, older systems, uh, you know, it may be older web browsers or older clients, you know, this could be, let's just say for a moment that, that somebody adopts this late in their product life cycle in, in, you know, their like, you know, release 10 or 12 or 14 or whatever later, or a hundred or whatever, and, you know, they still ha wanna be able to support systems from, you know, 10, 20 years ago. And, This actually was mentioned in the document as well about, well, this may break backward compatibility and we have to be comfortable as system designers. You know, making those hard decisions about whether or not to, to, say, yeah, cut Mr. Customer, uh, you know, we're moving on. Think about that, versus try to maximize, uh, compatibility across those.

Chris Romeo: 10:39

Yeah, we and, and we are, we're, we're comfortable with breaking backward compatibility. I speak for...

Izar Tarandach: 10:43

uh,

Chris Romeo: 10:43

the industry. I speak for all of us.

Izar Tarandach: 10:46

No you don't. Because we've seen enough times where product comes and says, we can't make those guys crazy with that amount of market share and, uh, just downgrade the security and it's gonna be fine. never fine.

Chris Romeo: 11:01

I mean risk, the risk tolerance in the world now is so much different than 10 years ago when

Izar Tarandach: 11:06

But on the other hand,

Chris Romeo: 11:07

hear that as a good, I would, I don't think that's happening as much as an argument now. Now, we used to hear that all the time when I worked in a big product company, but that's, that was 10 years ago, 15 years ago. The internet, The world, the expectations for security have changed so much though in that time.

Izar Tarandach: 11:24

but but it's not only the expectations. I think that we, we, are we are perhaps fortunate to say that we have such a problem as alert fatigue and we get too many alerts because now we have too many eyes looking at what, what's going on, right? going on. So I. Once upon a time, we would say, I can't downgrade security, because if something happens, I don't have something that will tell me that something happened today. We have a lot of solutions and we have a lot of ways to getting the pulse of what's going on in our systems. Not that that's a justification far away from it. Um, I, I, I sit together with Chris on the, the bus of. Don't you touch that thing, nobody here presses the big red button, but, uh, uh, I just think that being pragmatic, if it happens, we, we do have enough logs and metrics and traces, the whole observability suit to to come and say, uh, something unplanned is happening here. And, uh, and yeah. Perhaps we have to hit the big red button again.

Chris Romeo: 12:31

Okay, so there's more to secure by design that de-hardening guides, that that, was just, Matt set me off on a tangent there of, of, it was a little bit of a memory of, of going through the document and reviewing it. But, you know, when I think about what they call, what they think of as with secure by design and what the document calls for, I mean, there's, there's a number of other things, but for me, I always wanna bring it back to that magic word: design. Secure by design. Design. What's the thing that, what's that thing that all three of us love That that somehow plays into design and makes it, oh, there, wait, there's a book,

Izar Tarandach: 13:06

I scream.

Chris Romeo: 13:07

Ice Cream. We do all love ice cream. I mean,'cause it's tough not to, but you know, Izar and Matt wrote a book about it. They love threat modeling so much. And so when I think Secure by design though. I know threat modeling is a piece of secure by design. I dunno, what do you guys think? Like where, where, how does threat modeling fit into Secure By Design? Is it secure by design? Is it a layer below Secure by design? Is it a piece? What, how do, how do you see it fit in?

Matt Coles: 13:31

So I think that threat modeling is a, it is a way to inform and in part to validate. The design and its security, right? So with threat modeling, we can look at a design and we generally, you know, we generally say that the best time to do threat modeling is when the design is formed, but not well baked, meaning not fixed. You have time to change it. And so you have an opportunity to use threat modeling to influence the properties that you need and influence the, the design to make it secure. And to make those trade off decisions about what you can and can't enable or can and can't support, uh, and, and. And as I may as well remind folks here, we have the threat modeling manifesto when you have the four question framework that we leverage, right? So we're gonna start with what are we working on? What can go wrong? What are we gonna do about it? That gives us the design, the design part, and the secure design part. And then did we do a good enough job later we can use threat modeling to validate A, did we actually implement the things that we need and, and did we effectively address the, the, the secure by design part. Um, that will also feed into the secure by default peeps because we can, we can understand sort of what's, what's, a, a built in characteristic versus what's a, uh, a configuration layer that, that gets added on. And it, it's not the same as bolted on, it's, it's configured later to add security capabilities. Or to enforce security capabilities. So I think that's where threat modeling really, really fits in here is, is, is informing and then, uh, validating that security design practice.

Izar Tarandach: 15:14

So that's how the process of threat modeling fits into the, the secure by design thing, let's say. To me it's also about how the secure by design thing fits into threat model and, and, I. What I want to say by that is that many times in the past, you know, we are asked again and again, how do you threat model in an agile situation? How do you threat model in the cloud? How do you threat model SAS? How do you threat model this, that, and the other one? And thing that we put in the manifesto is that threat modeling is evolutionary, meaning it gets better every time now. If we look at all the situations of development plus the thing that we get better at all the time, one thing that becomes very clear to me is that we work in Deltas. We don't always go back to zero to to threat model, right? We, we work on the changes on the system and. and. It's funny'cause the, the, the thing that immediately jumps to, to my mind is that we as threat models, when we do threat modeling, the things that excite us are those things that you guys are trying to do different. This is a new thing. This, this is a shiny new thing that nobody has done before We get bored. you get bored by again looking, at, at the VPC and the permissions and who's talking to whom and, uh, where is this process running and authenticating that, that, that's, that's the stuff that you need to get off the ground. And to me, security, security by design is going to bring that, that thing in terms of they're going to cover the whole boring stuff and give us time and, and, and liberty to play in that sandbox of the new shiny thing. We're going to Be able now finally to look in depth at things like business logic, and innovation and things combined today that weren't combined yesterday, right? And start focusing on that new stuff and that new attack surface and let the stuff that has already been explored, already been turned into standards. This is how we run a secure database here. This is how we run a secure a secure server of whatever here whatever

Chris Romeo: 17:28

Yeah.

Izar Tarandach: 17:29

and now. Just tell me what you're doing different.

Chris Romeo: 17:32

Yeah. Yeah. That's, I mean, looking at, at, at the, the diffs is how you do code review in a, in a, pull request moment or using a ullp request. You don't, you don't go review 5,000 lines of code when there were three lines changed. You focus on the diff, you focus on the diff, and then the context around it enough to understand did what they change fix the problem or make the thing go away. And so yeah, it's like a differential almost approach to, uh, to looking at, at what's changed and, and applying that in the model.

Izar Tarandach: 18:06

You heard it first here on the security table, live on LinkedIn. I'm calling this exceptional threat modeling because

Chris Romeo: 18:15

I tried to,

Izar Tarandach: 18:15

threat

Chris Romeo: 18:16

I tried to rebrand it for you.

Izar Tarandach: 18:17

modeling, just

Matt Coles: 18:18

plug.

Izar Tarandach: 18:19

the exceptions.

Chris Romeo: 18:20

But I tried to, I tried to rebrand it for you right on the fly. You didn't catch it with differential threat modeling. I went for it. I, I gave

Izar Tarandach: 18:27

no, no, no. no. I, I, I have a history with anything that is differential integral. I, I have a bad history with that stuff.

Chris Romeo: 18:34

okay. I don't even know what, I don't actually even know what it means, so I mean, I just, it sounded good.

Izar Tarandach: 18:38

to keep away from those things as much as I can, but you know what? Exceptional, I can play with

Chris Romeo: 18:43

That makes Well, it's, I mean, it's, it's a first. There could be a new book in the future hanging on the wall behind these guys

Izar Tarandach: 18:49

It is going to be on, on threat modeling. Connect in about 10 minutes.

Chris Romeo: 18:52

ah, perfect. Well try to pay attention for the rest of the time we're talking. Please don't drift off and start typing his, his blog post here trying to get credit. I mean, because this is live, someone else could be typing that blog post right now with

Izar Tarandach: 19:05

It won't be the first time.

Chris Romeo: 19:07

so secure by design is more than threat modeling. And, but, but, but it is design

Izar Tarandach: 19:13

in hand with.

Chris Romeo: 19:14

It does go hand in hand, but I'm looking at what the CISA document talks about. First of all, memory safe programming languages. So you, you, you can argue that that is a design activity because you had to design what language you were gonna use to build something. Now does that

Izar Tarandach: 19:31

because the language that you're using changes the design.

Matt Coles: 19:33

the design Right. It influences the design.

Chris Romeo: 19:36

Yeah, definitely. Like, and, and when you think about the, the the proliferation of new languages like Rust and Go, which are replacing what we used to use c and c plus, plus four and Rust and go have enhanced security mechanisms in place to prevent problems that were easy to stumble into and see. you know, secur doing proper bounce checking and memory management in the language itself. That's a, that's a step forward. But that was a design decision. And we realize if you have an existing system, existing product, you can't just go say, well, for from this point forward, we're gonna use Rust. Now we wrote the whole thing in C but from this point forward, we're using Rust. So if you're gonna make a change, you're making a Rust. Like it's, it's it a, a. Language choice is more of something you can do upfront with something new you're building. It's a little harder to change both engines on the airplane at 30,000 feet, which is what you're effectively doing if you're, if you're changing your language in, in the middle of a program or product.

Matt Coles: 20:46

yeah, that's true. I guess that's where, that's where a proper modular design and having to be able to, to create wrappers or front ends or other things that, uh, you know, Take that newer construct and put it in front so that, that it provides a level of, of defense to your legacy modules until you have time to replace'em. Uh, not suggesting you know that you should leave old C code around unless you make that decision to do so. And then, but you could take Rust and build something around it that works and that gives you security capability, uh, you know, defend the core. Right? And. So it's an evolution. Um, and I think we, we see what this memory, safe language decision, especially, right? That if you're not spending time. Like Izar was just talking about, right. With, with exceptional things. If you're not spending time on solving the problems of how do I make interfaces secure Because the memory, the memory safety can address that for me or more important, or, or, or also that language can also enforce certain structures or constructs, you know, programming constructs. So I don't have, as a developer, I don't have to worry about those sort of things. I can spend time making. In interesting business logic decisions and, and less so worrying about, uh, you know, making sure my APIs only take the proper data and all the output, the, the proper outputs, right? The language takes care of that. Or at least lets me know when I'm, when I, that I, what I need to take care of, right? And so it, it frees up the developer from, from that responsibility. In part, they still have to make a conscious design choice, right? To use the language and how they bolted on how they How they connect it together with the other pieces and how they might replace portions of it. Uh, but, but it gives'em some flexibility, some capability there. And so that's a good thing in general.

Izar Tarandach: 22:41

Yeah, but Matt, keep me honest here'cause you are much more experienced in this than I am. With the proliferation of Uh, iot And small devices and things like that out there, right? So one of the design choices here is actually what Chris said. Go to our memory safe language. But because of limitations in these devices, many times because of memory,'cause of CPU, whatever, you, you don't have that liberty. You can't just go and start writing on a different, there, there, there's a bunch of devices out there that you can't write in Java because there's no space for the, the runtime.

Matt Coles: 23:14

Oh yeah. Yeah, so, right. You have space constraints or you may have compiled targets and other things that might be a problem, right? Yeah, exactly.

Izar Tarandach: 23:20

But then you can look at C again and say, okay, I have to write in C because that's what runs in this device. But I have the design choice of using, uh, uh, lib mallock that does do all the, the protection of memory spaces for me.

Matt Coles: 23:35

Yeah.

Izar Tarandach: 23:36

you can go, sorry. you can go farther and you can say, I can work on a processor where the hardware already makes that boundary checking. check. A more secure way. I don't even know if that thing exists. I think that I read somewhere that it does, but you start having options at different levels for the same design that at the end, impact everything.

Matt Coles: 23:59

Yeah, I think that the memory choice, the memory safe language discussion was really, and, and this is like, I guess this is research being done out of like MIT and, and and NSA and and other folks, right? That, that have, um, you know, a lot of, a lot of brainpower put into this, but thinking about What percentage of the development population are, are writing for specialized targets like embedded IoT devices versus those, you know, who are writing, uh, uh, web, web or cloud-based code, right? So there you're gonna get more general, general purpose app, uh, systems, more general purpose, uh, general, you know, commodity processors and whatnot. And, and therefore switching to memory safe languages frees up a lot of developers time, uh, to, to, or well takes away the choice of, of, uh, of, of building insecure code. Um, and we're just talking memory safety, so we're only really talking about buffer overflows here, right? And, and off by one errors and, and things like that. Um, Uh, except for the newer languages that have also better interfaces and, you know, uh, less undefined behavior and, and whatnot. So it's a little bit better in that regard that to, to not introduce new weaknesses. Um, but you know, when you're talking about, uh, going to embedded devices, so I'm a big proponent that C, C is very hard to get correct. You need proper diligence to get it correct and make it secure, and that's not. Alright, you're given that face, Do you disagree that C is not possible to make secure? Because I, I, I, I think it is possible if somebody takes the time to, to do the effort.

Izar Tarandach: 25:41

Nice recovery,

Matt Coles: 25:44

I was always on that track. I was always on that track.

Chris Romeo: 25:48

gotta wrap it. You gotta have to wrap it in a lot of different layers of bubble wrap to give me a safe C world where I don't have to worry about buffer overflows and energy overflows and all of these things. In the code that's being cranked out and like that's, I think is the balance. That's the balance though, right? With these memory safe languages. Like that's why that you gotta find a way to build new IoT devices not using C. Like C is is a great language. We can't completely poo poo it because C's the foundation of everything that we have now.

Izar Tarandach: 26:24

Sandler is what

Chris Romeo: 26:26

But Unix and C were kind of side by side with each other. Like through, that's, that's the history of computing for all the, all the young whipper snappers out there and on the, in the internet land. Right. But that's the truth. Like that's where it came from. But it's secure by design is about raising the bar

Matt Coles: 26:43

Right?

Chris Romeo: 26:43

Constantly raising the bar. And we have

Izar Tarandach: 26:44

Because of all the lessons that we learned in the past,

Chris Romeo: 26:48

Yeah.'cause

Matt Coles: 26:48

right.

Izar Tarandach: 26:49

we,

Matt Coles: 26:50

right. And so and so, I mean, it's, it's very encouraging now that Rust is part of, if I understand correctly, if I remember correctly, that Rust is now part of the Linux kernel. So it, so it can be done. You can build, you know, uh, tight privileged code.

Izar Tarandach: 27:06

Yep.

Matt Coles: 27:06

That's designed to run against multiple targets, uh, from this newer language that it doesn't. It isn't bloat ware, right? That it, it does do its thing in, in a concise way. And that's important, right? And so if we're looking at iot devices that have memory constraints, as long as we're compiling to that, as long as we can compile to that target, right? So if we're looking at an ARM chip, right? That has, has limited capabilities in terms of memory, footprint and, and, and CPU power. As long as we can compile code, you know, to that target, it doesn't matter if it's, I mean, so in terms of just having it be possible, whether it's in C or Rust, as long as it compiles to, to machine code, it can go on that device. Then the choice becomes where do we put our engineering effort? Do we put our engineering effort into taking this, you know, 40 or 50 year old language that has, that is hard to get correct? Or do we move to something that that's memory safe so that we can free up again, free up our developers to work on hard problems and not be be, you know, shot by this, by this obvious problem. Right.

Chris Romeo: 28:14

folks can go back and listen. We've, we've been talking about. paved roads and guardrails. It's come up A number of different times in different episodes, and that's what we're talking about. A memory safe language is a paved road that you're providing for the developers so that they don't have to worry about memory safety because the language is gonna enforce it. And that's a, as we've all Talked about reasonable security, reasonable AppSec paved roads and guardrails are reasonable. They help. They help us build a reasonable system that still lets developers be creative and freestyle and do cool things.

Izar Tarandach: 28:49

Yeah. And, And, and and another thing that I think that we, we, we have to jump to here is that we have been looking at secure by this here in this conversation. We have been looking at secure by design And. secure by default as, okay, we built a secure base. Now you guys go and show us how we're going to screw it up. And. Now I'm thinking of, okay, the base is there. Fine. Secure by design. Secure by default. Now let's see about this screwed up part. Sorry, my Google in the other room heard the okay and went crazy. But, um, the, the point I'm trying to make, I think is that that there is a change in mindset when you start talking secure by design, right? That is less and, Adam, forgive me here for the heresy, but I, I think that it breaks a bit to the model of the four questions in the way that today, the four questions ask, what are we building? What could go wrong when you start talking about secure by design is, here's what I'm building and here's why nothing's gonna go wrong, gonna because you are already incorporating in the design of the thing that you are designing security. security, you are shortening even that short jump from Yeah, I, I, I, I, I said in the beginning it might sound as heresy, but

Matt Coles: 30:16

I I, think you're off base.

Chris Romeo: 30:17

it's not heresy. It's just wrong.

Matt Coles: 30:20

I think you're, I think you're I think you're, I

Izar Tarandach: 30:22

I'm open to being wrong. Totally open

Chris Romeo: 30:23

I mean,

Matt Coles: 30:24

I I think, I think there's a bit of a delusion going on. There is our, no, no, no offense. Uh, right. We're all friends here. We're all, We're all, friends here. The table, right.

Izar Tarandach: 30:32

too much monster.

Chris Romeo: 30:34

right? business logic. Like developers are building new features. Yes, they have a secure foundation, but business logic can still go wrong. They can still

Izar Tarandach: 30:44

No, no, it can, it can definitely. Totally, totally. I'm not saying that it's not going to happen. I'm not going to say that it's not going to happen. What I'm saying is that when you say secure by design, okay, you are taking that security is bolted on that. We used to put way, way, way there at the, uh, right of the process. Right, and that was brought left by things like threat modeling

Chris Romeo: 31:11

Mm-hmm.

Izar Tarandach: 31:12

And now it's not even left. Now, it's part of the design thing. It's like I'm designing already with security in mind. And you know what? Delusional, I'm willing to take it. Overly optimistic? I think It's more appropriate.

Chris Romeo: 31:29

Overly optimistic. I like that better than delusional. Yeah. I mean, it's,

Izar Tarandach: 31:33

We need to take the delusional.

Chris Romeo: 31:34

It's, it's not gonna solve, it's not gonna solve all, like, like this secure by design doesn't solve all of our problems. It doesn't result in.

Izar Tarandach: 31:42

Delusion

Chris Romeo: 31:43

I mean, we need to get a

Matt Coles: 31:44

Too much Monster

Chris Romeo: 31:45

need a sponsorship

Matt Coles: 31:46

much monster.

Chris Romeo: 31:46

monster. Energy Drinks. If you're out there, monster, there's a sponsorship for you here. Just send Izar a

Izar Tarandach: 31:52

taking sponsorships here.

Chris Romeo: 31:53

so we'll take it from anywhere. But no, I mean, I think it's, it's, you know, paved roads and guardrails. They provide the right pieces, the right things. But secure by design isn't gonna solve all of our problems.

Izar Tarandach: 32:06

No, nothing's gonna solve all the problems.'cause because exactly with what you said. At the end of the day, we are developers developing stuff. We will make mistakes.

Chris Romeo: 32:12

We want that. We want that innovation. We don't want to be, you know, we don't wanna live in a, the worst possible thing is we live in a no-code, low-code world where all you're doing is plugging Lego pieces together. And then you're saying, this is the best application. Well, no, it's not in, there's no, it's no more innovative than the one next to it because it was constrained by the boxes that you only had the component pieces. You didn't have the ability to Think up and dream up something new. And so, I mean, I don't, I mean low, low-code, no-code has its place, but let's not let that become how we build software everywhere.

Izar Tarandach: 32:46

So, yeah, no, let, let me not go there,

Chris Romeo: 32:49

Yeah. This is a live stream, so don't go there.

Izar Tarandach: 32:51

No, I already

Chris Romeo: 32:52

said too much today. Let me bounce one more, one more in here. That, and then we'll, we'll, uh, we'll wrap up for this, this week's episode. They put parameterized queries, use parameterized queries rather than including user inputting queries to avoid SQL injection. We're, I mean, that, we've all been saying that for

Matt Coles: 33:08

20 years

Chris Romeo: 33:09

but is that a design? Is that, that's why I'm looking at that. I'm going, is that secure by design? Like, do I even have to, is there a, there's no choice there. Is the fact that there's no choice, is that a, is that a secure by design tactic to use

Izar Tarandach: 33:25

Only if doing the right thing is a tactic because that's the right thing to do the right thing to do

Chris Romeo: 33:32

Yeah.

Izar Tarandach: 33:33

for, for more than security reasons. It, it is just the right, it's just the right way of structuring your queries. plan.

Chris Romeo: 33:39

Yeah, and to put it in perspective, the, the one right before web template frameworks, use frameworks with automatic user input, escaping, and to avoid web attacks like cross-site scripting. That's a design choice. Now, the frameworks have got, are getting better every day. Frameworks are caring about security. You don't have the same challenges, but there's still, there's still a design choice. I could make a bad choice. I could choose a framework that doesn't care about that. Ha, I won't say, doesn't care about security, but hasn't invested in security at the same level as some other framework. I have a design choice. What I'm saying is, do I really have a design choice at parameterized queries?

Izar Tarandach: 34:15

Yes, because one of the examples that I have seen in the past, whenever I, I ask a developer to use an ORM and I have seen this repeatedly. Developers are extremely smart people. The problem is that sometimes they are smarter than they need to be. So when they find out that even using an ORM you can write your query as it is full string, pass it to the ORM and your ORM will usually have an evil call or whatever whatever that that will use that, that, that query, that the language that you're using possibly help, helps you do in a dynamic way.

Chris Romeo: 34:53

Hmm.

Izar Tarandach: 34:53

So you're taking the ORM, you're going through it and.

Chris Romeo: 34:57

In their defense, there are situations where the ORM is not performant enough. For example, in reporting and dashboarding and whatnot. I've seen so many times where I, I preach the same thing. Everyone should use the ORM. But then there's, somebody shows me an example and says, well, the ORM through the ORM to generate this dashboard in real time takes four and a half minutes. And if we write a custom SQL query, it takes, uh, a hundred microseconds or milliseconds, whatever, something like that. Like there's, I can't say you have to use the ORM in that case because I can't take four and a half minutes to render a dashboard. If that they won't be a customer, they'll have already left.

Izar Tarandach: 35:34

Right. But I, I can't say that I've seen that, but just putting myself in the seat of a developer and I haven't been one in a long time in that particular case, the query that you are going to put together to send to the engine to get your dashboard back is probably something highly, uh, uh, um, structured. You have a start date, you have an end date, you have a bunch of things that you want to see the dashboard. It's not like, okay, I can't use the ORM great thence in depth. I'm going to validate the input. Right? It's not like one solution fits all, and that's all, We have those things in the, in the way, but yeah, no, I totally see what you, what you mean. I, as I said, I've, I've seen developers tell me I bypass the ORM because I needed to, and there are valid cases.

Chris Romeo: 36:20

So then maybe, maybe I'm starting to convince myself that parameterized queries is a design decision, and I would also say proper use of direct queries.'cause we know there's a use case for it. We can't, I can't just say you have to use ORM and you can't ever use a raw query. What I can say is you cannot use a raw query that takes input from the outside world. So if you need to do dashboarding, you need to use the ORM for any processing of data that's coming from the user. And then your query can just be a string that doesn't, you just, you figured out the query'cause you needed an outer join, an inner join, and something else altogether in one to make it work that the ORM couldn't replicate then I can see that as a scenario.

Izar Tarandach: 37:01

But he, here's the beauty of the thing, because Secure by Design says that using an ORM is the right design decision. Okay? If I am a, a, a security person in a company that has 300 different things that I have to be responsible for, before, 299 of them will use ORM and be just happy with it help There'll be one that has an issue and now I can ask them instead of, okay, let's sit down and threat model 300 things thing. I can ask everybody, are you using ORM or 299 will say, yes I am fine. Go away. You've been threat modeled, you've been blessed. But that guy that has the thing that is exceptional, the the one that I'm. That's The one that I'm going to sit down with and have a deep conversation to see what else can we do to help you run this thing securely? Right? So yeah, you just validated exceptional threat modeling. Thank you,

Chris Romeo: 37:55

that was my intention, this whole conversation. I was like, how am I gonna work it in? How am I gonna get Izar's exceptional threat modeling to be the answer to something I say. I tried.

Izar Tarandach: 38:06

the only thing that can complement exceptional threat modeling is continuous threat modeling. So you have to continuously look for exceptions.

Chris Romeo: 38:14

Uh, wait. Exceptions with an A or an E. Exceptions. Like I need, I'm kidding. I'm kidding. Um, a different kind of

Matt Coles: 38:25

think it's the end of the day for some people.

Chris Romeo: 38:27

that's true. All right. Well,

Izar Tarandach: 38:28

not, it's not, it's not my mother tongue, so don't bring don't, don't play with that because I'm gonna go look for it.

Chris Romeo: 38:33

No, it's all right. Well, let's wrap up this conversation on the security table. It was great to, uh, be live here on LinkedIn and we'll do that some more in the future. And, uh, just talking about Secure by Design, and I think we had some, some, we drew out some good points about how Secure by Design comes together. What it is, we're gonna hear this a lot more. This is, this is a thing of the future and the present. It's gonna become a lot more prevalent in different scenarios and different conversations. So, uh, keep tuning into the security table. You can find us on wherever you get podcasts from, or YouTube if you wanna watch episodes or LinkedIn. Or maybe we'll show up on some other new social media platform that no one's even thought of yet. Thanks for

Izar Tarandach: 39:12

We are everywhere.

Chris Romeo: 39:13

security table.