August 15, 2023 • 39 mins
"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!
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Chris Romeo (00:09):
Yeah, I think we are.
Izar Tarandach (00:10):
Is this.
Chris Romeo (00:11):
I think we are.
I think we may have, we may havefigured this whole thing out
called the internet.
So welcome to the securitytable.
My name's Chris Romeo and, uh,joined by my good friends, Izar
Tarandach and Matt Coles.
And this is our first timetrying to use the internet, so
it's relatively new to us.
After, you know, multi decadesof being computer people, we're
(00:33):
trying to use the internet.
And so we've been doing thisshow, the security table for, I
don't know, a number of weeks atthis point.
I think we've got 10, 12, 13episodes, something like that.
We talk about things related toapplication security, product
security.
Sometimes we, we discuss civillyand nicely.
Other times things get moreheated when Matt tries to point
(00:55):
out another standard that Ishould read and understand.
I'm just kidding.
It's always, it's all in goodfun.
We we're here to have fun, butwe want to talk about AppSec,
prosec, general security things.
Just have a, and have a goodtime doing it around what we
call the security table, whichis a bit of a virtual table at
this point.
So, um, let's talk about Secureby design, though.
Seems like it's getting a lot ofattention.
(01:16):
Um, CISA came out with adocument secured by design,
secured by default.
Well, CISA and major governmentsfrom around the world came out
with a document to try to puttogether and, and focus our
thoughts on secure by design.
And so let's, let's talk aboutwhat it is first in case people
are out there going, I've heardof this thing, but it's a little
bit of a nebulous concept.
(01:37):
So Izar give us, give us somethoughts on
Izar Tarandach (01:40):
Oh, no, no, no, no, no, no.
The good one is Matt.
Matt defines and I refine.
Chris Romeo (01:46):
Well,
Matt Coles (01:47):
Well, so yeah, so I guess I'll, I'll kick it off
then.
So, uh, secure by design and ofcourse we should.
We should just let you knowusers, uh, viewers know of
course that it's Secure byDesign, secure by default,
right?
So if you're searching for thisdocument or set of documents,
it's, it's Secure by Design orsecure by and secured by
default.
What we mean by secure by designis, uh, that.
(02:10):
The system has been implementedwith secure design principles in
mind.
Uh, that it comes pre-hardened,that it comes pre-secured, and
uh, and that the things thatrather than relying on customers
to take something, install it,and, and configure it securely,
that it comes out of the boxthat way.
So secure by design, you buildin the, capabilities secure by
(02:34):
default, it's configuredcorrectly.
Chris Romeo (02:35):
Mm-hmm.
and, Izar happens to be writingthe, the Great American novel as
we...
Izar Tarandach (02:41):
no, I, I'm, I'm putting it, I'm, I'm putting
into the, into LinkedIn, the URLfor the doc so that people know
what you're talking about.
Chris Romeo (02:49):
...follow along.
Matt Coles (02:50):
You need a less clicky keyboard there, uh,
buddy.
Izar Tarandach (02:52):
I will never have a less clicky keyboard.
Chris Romeo (02:55):
All right, so Mr.
Refinement here.
uh, the definition's been set.
So how, how would you refine thesecure by design by default?
Izar Tarandach (03:06):
so I, I, I think that the keyboard here is
aspirational, right?
So we,
Matt Coles (03:12):
we,
Izar Tarandach (03:13):
We have been doing this thing for a long time
and we we always keep tellingpeople at some point people are
going to learn and do the rightthing and keep doing the right
thing and just ingrain the rightthing, into what they do.
And I think that the, thesecurity by default and security
by design is sort of taking thatone step up and saying, now
(03:35):
actively we have to startlooking from the beginning.
Take The thing that we havealways said about security is
not something that you bolt atthe end.
It's something that you bake in.
I I, I, I love that you bolt,but you bake, whatever, but uh,
Matt Coles (03:49):
Build in, build in.
Izar Tarandach (03:51):
Build in, build in.
But the, the, the thing is thatnow we want to start, you don't
want to start from zero.
You want to start from somethingthat you finally, after much
trial and error andcatastrophes, you have got into
that state where you know howthings, what things have to look
like in order to be secure.
be secure.
And now you define that as yourstarting point.
(04:12):
And you say this, this is whatgood looks like.
And anybody wanting to buildfrom here have to start at this,
at this level.
Have to, to start at thisminimal amount of, of security.
And, uh, you know, I, I thinkthat, that, that plays well with
something that we keep goingback to in the, in the podcast,
which is (04:33):
what's reasonable to do in terms of security.
And, uh, so far from what I haveseen, the, I I I, haven't
exactly seen anything like a, ahardening guide or configuration
guide or 10 best practices forsecure by design or whatnot.
But but the discussion is at aplace that put things in a very
(04:53):
reasonable starting point, Ithink.
Chris Romeo (04:57):
so.
Matt Coles (04:57):
It's interesting you bring up, uh, hardening guides,
in fact, uh, right, because ifyou look through that doc, those
documents, uh, you'll find, youknow, with the notion that you
start secure by design, that youbuild in security, you design it
in, right?
You don't just, you don't justbuild it in, but you design it
in, and then you deploy itsecurely.
Then the theory goes that youcan start looking at sort of
(05:20):
de-hardening guides as opposedto hardening guides.
Rather than have to build upfrom scratch, you can start
allowing If, well, if sodesired.
Chris Romeo (05:29):
please.
Matt Coles (05:30):
Chris is, Chris is shaking his head
Chris Romeo (05:31):
I, I remember when, so the three of us got a chance
to provide some feedback on theCISA document through our, our
Threat Modeling manifestocollective group, and that was
one of the things that I.
I wrote some strong feedback andI feel pretty strongly about
don't encourage anybody tocreate a de-hardening guide.
they wanna figure out how tode-harden something that's been
(05:53):
secured, let them figure it outon their own.
Don't give them a guide thatsays, here's how you, how you
back out of all the good, thesecurity goodness that's been
added to the product.
Izar Tarandach (06:03):
But, but that takes us to a, an interesting
place.
Why would somebody try to bringdown the, the security posture
of, of a system, especially whenit's already been like blessed
as secure,
Matt Coles (06:14):
Uh,
Izar Tarandach (06:15):
right?
Matt Coles (06:15):
The number one reason I think that, that I
think we've all heard over thecourses of our career is
performance, right?
Or accessibility.
Izar Tarandach (06:24):
So here's the interesting thing, I I, I
haven't heard performance asmuch 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 (06:39):
Yeah.
Or Compatibility.
We, we see this with old, youknow, we used to hear this with
old, old web browsers.
Right.
And secure, uh, you know, Httpsservices.
Izar Tarandach (06:47):
I, I hear that a lot with, uh, uh, uh, this
privilege.
I don't know what I'm going toneed this account to do
tomorrow, so I'm going to giveit a privileged role and
whatever it.
Chris Romeo (07:00):
Yep.
Izar Tarandach (07:01):
So that there's that forward looking idea of I
have to be permissive because Idon't know what I'm going to
need tomorrow.
Meanwhile, attackers are alreadyneeding having whatever they
need today.
But, uh, the, that, that'ssomething that I see a lot.
The, the thing to me is that themore I think about this, and,
and Matt and I have discussedthis a number of times.
Matt Coles (07:22):
a number of times,
Izar Tarandach (07:24):
It seems to me that as a security person, if I
have to look over the shoulderof a developer at the time that
they're developing, and I knowthat they start from a buttoned
up state, and now they areasking me to open that thing up,
thing up.
it's a great opportunity for mefor me to question that decision
that and help make it a betterdecision.
(07:48):
decision.
Mm-hmm.
Then the opposite situation whenI'm sitting behind that
developer and every keystroke Igo on their shoulder and say,
shoulder is, is this secure?
Is this secure?
Are, are you doing the rightthing?
Are you doing the thing that thetraining said that you should be
doing?
should be good.
Chris Romeo (08:02):
Yeah, but de-hardening, de-hardening is a
step removed from that Theconcept of de-hardening is
giving a guide to a customer Sothey can back out.
The security confi defaultchanges you added to the product
to somehow bring it into a lesssecure state.
And what I'm saying is I can'tthink of a reason why somebody.
With for good intentions andgood purposes, would want to
(08:25):
back out the security settingsbecause you can't tell me it
hasn't been tested because wehad to test it in this hardened
state.
Matt Coles (08:32):
Mm-hmm.
Chris Romeo (08: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 ofthis idea of having a guide that
tells people how to back out allthe things I've spent 26 years
saying, and you guys have donethe similar thing.
We've been saying these thingsover and over again for decades.
Like, don't, like, don't, don'terase something good that's
(08:53):
happening in the Secure byDesign movement.
That's all I'm saying.
Izar Tarandach (08:56):
Oh, but, but, then it goes to what Matt said
about compatibility, right?
Because you wrote that hardeningguide, and I want to believe
that you tried a.
number of configurations, butthere will always be that guy
that says, I'm running.
I don't know.
I have a firewall from 1980 infront of the thing, and I need
to bring it to SSL
Chris Romeo (09:17):
Yeah, but Secure by Design.
Izar Tarandach (09:19):
won't go.
Chris Romeo (09:20):
Secure by Design doesn't have a hardening guide.
Secure by default, there is nohardening guide.
There is nothing for the user toconfigure.
It comes out of the box secure,and what we, as the producers of
the product say, is a securestate.
So the user, they can't say,well, compatibility, it doesn't
work.
Well, no, it worked because wehad to, we had to test it to
order to release it, to provethat it did.
(09:40):
And we didn't lock it down sofar that it couldn't do its job.
It couldn't meet the, the, thefunctions that it, that it had
been called out to do.
So
Matt Coles (09:47):
Oh, it's, it, it's a, it's always those strange
configurations go like, like asIzar said, right?
There's old, older systems, uh,you know, it may be older web
browsers or older clients, youknow, this could be, let's just
say for a moment that, thatsomebody adopts this late in
their product life cycle in, in,you know, their like, you know,
release 10 or 12 or 14 orwhatever later, or a hundred or
(10:09):
whatever, and, you know, theystill ha wanna be able to
support systems from, you know,10, 20 years ago.
And, This actually was mentionedin the document as well about,
well, this may break backwardcompatibility and we have to be
comfortable as system designers.
You know, making those harddecisions about whether or not
to, to, say, yeah, cut Mr.
(10:29):
Customer, uh, you know, we'removing on.
Think about that, versus try tomaximize, uh, compatibility
across those.
Chris Romeo (10:39):
Yeah, we and, and we are, we're, we're comfortable
with breaking backwardcompatibility.
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 timeswhere product comes and says, we
can't make those guys crazy withthat amount of market share and,
uh, just downgrade the securityand 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 10years 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 anargument now.
Now, we used to hear that allthe time when I worked in a big
product company, but that's,that was 10 years ago, 15 years
ago.
The internet, The world, theexpectations for security have
changed so much though in thattime.
Izar Tarandach (11:24):
but but it's not only the expectations.
I think that we, we, are we areperhaps fortunate to say that we
have such a problem as alertfatigue and we get too many
alerts because now we have toomany 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, Idon't have something that will
(11:46):
tell me that something happenedtoday.
We have a lot of solutions andwe have a lot of ways to getting
the pulse of what's going on inour systems.
Not that that's a justificationfar away from it.
Um, I, I, I sit together withChris on the, the bus of.
Don't you touch that thing,nobody here presses the big red
(12:06):
button, but, uh, uh, I justthink that being pragmatic, if
it happens, we, we do haveenough logs and metrics and
traces, the whole observabilitysuit to to come and say, uh,
something unplanned is happeninghere.
And, uh, and yeah.
Perhaps we have to hit the bigred 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 alittle bit of a memory of, of
going through the document andreviewing it.
But, you know, when I thinkabout what they call, what they
think of as with secure bydesign and what the document
calls for, I mean, there's,there's a number of other
(12:51):
things, but for me, I alwayswanna bring it back to that
magic word (12:53):
design.
Secure by design.
Design.
What's the thing that, what'sthat thing that all three of us
love That that somehow playsinto 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 somuch.
And so when I think Secure bydesign though.
I know threat modeling is apiece of secure by design.
I dunno, what do you guys think?
Like where, where, how doesthreat modeling fit into Secure
By Design?
Is it secure by design?
Is it a layer below Secure bydesign?
(13:27):
Is it a piece?
What, how do, how do you see itfit in?
Matt Coles (13:31):
So I think that threat modeling is a, it is a
way to inform and in part tovalidate.
The design and its security,right?
So with threat modeling, we canlook at a design and we
generally, you know, wegenerally say that the best time
to do threat modeling is whenthe design is formed, but not
(13:54):
well baked, meaning not fixed.
You have time to change it.
And so you have an opportunityto use threat modeling to
influence the properties thatyou need and influence the, the
design to make it secure.
And to make those trade offdecisions about what you can and
can't enable or can and can'tsupport, uh, and, and.
And as I may as well remindfolks here, we have the threat
(14:17):
modeling manifesto when you havethe four question framework that
we leverage, right?
So we're gonna start with whatare we working on?
What can go wrong?
What are we gonna do about it?
That gives us the design, thedesign part, and the secure
design part.
And then did we do a good enoughjob later we can use threat
modeling to validate A, did weactually implement the things
that we need and, and did weeffectively address the, the,
(14:40):
the secure by design part.
Um, that will also feed into thesecure by default peeps because
we can, we can understand sortof 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 asbolted on, it's, it's configured
later to add securitycapabilities.
(15:02):
Or to enforce securitycapabilities.
So I think that's where threatmodeling really, really fits in
here is, is, is informing andthen, uh, validating that
security design practice.
Izar Tarandach (15:14):
So that's how the process of threat modeling
fits into the, the secure bydesign thing, let's say.
To me it's also about how thesecure by design thing fits into
threat model and, and, I.
What I want to say by that isthat many times in the past, you
(15:35):
know, we are asked again andagain, how do you threat model
in an agile situation?
How do you threat model in thecloud?
How do you threat model SAS?
How do you threat model this,that, and the other one?
And thing that we put in themanifesto is that threat
modeling is evolutionary,meaning it gets better every
time now.
(15:57):
If we look at all the situationsof development plus the thing
that we get better at all thetime, one thing that becomes
very clear to me is that we workin Deltas.
We don't always go back to zeroto to threat model, right?
We, we work on the changes onthe system and.
and.
It's funny'cause the, the, thething that immediately jumps to,
(16:21):
to my mind is that we as threatmodels, when we do threat
modeling, the things that exciteus are those things that you
guys are trying to do different.
This is a new thing.
This, this is a shiny new thingthat nobody has done before We
get bored.
you get bored by again looking,at, at the VPC and the
permissions and who's talking towhom and, uh, where is this
(16:42):
process running andauthenticating that, that,
that's, that's the stuff thatyou need to get off the ground.
And to me, security, security bydesign is going to bring that,
that thing in terms of they'regoing 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 nowfinally to look in depth at
(17:05):
things like business logic, andinnovation and things combined
today that weren't combinedyesterday, right?
And start focusing on that newstuff and that new attack
surface and let the stuff thathas already been explored,
already been turned intostandards.
This is how we run a securedatabase here.
This is how we run a secure asecure server of whatever here
(17:27):
whatever
Chris Romeo (17:28):
Yeah.
Izar Tarandach (17:29):
and now.
Just tell me what you're doingdifferent.
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, pullrequest moment or using a ullp
request.
You don't, you don't go review5,000 lines of code when there
were three lines changed.
You focus on the diff, you focuson the diff, and then the
context around it enough tounderstand did what they change
(17:55):
fix the problem or make thething go away.
And so yeah, it's like adifferential almost approach to,
uh, to looking at, at what'schanged 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 exceptionalthreat 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 withdifferential threat modeling.
I went for it.
I, I gave
Izar Tarandach (18:27):
no, no, no.
no.
I, I, I have a history withanything that is differential
integral.
I, I have a bad history withthat stuff.
Chris Romeo (18:34):
okay.
I don't even know what, I don'tactually even know what it
means, so I mean, I just, itsounded 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 thefuture 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 forthe rest of the time we're
talking.
Please don't drift off and starttyping 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 safeprogramming languages.
So you, you, you can argue thatthat is a design activity
because you had to design whatlanguage 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 thinkabout the, the the proliferation
of new languages like Rust andGo, which are replacing what we
used to use c and c plus, plusfour and Rust and go have
enhanced security mechanisms inplace to prevent problems that
(19:58):
were easy to stumble into andsee.
you know, secur doing properbounce checking and memory
management in the languageitself.
That's a, that's a step forward.
But that was a design decision.
And we realize if you have anexisting system, existing
product, you can't just go say,well, for from this point
(20:18):
forward, we're gonna use Rust.
Now we wrote the whole thing inC but from this point forward,
we're using Rust.
So if you're gonna make achange, you're making a Rust.
Like it's, it's it a, a.
Language choice is more ofsomething you can do upfront
with something new you'rebuilding.
It's a little harder to changeboth engines on the airplane at
30,000 feet, which is whatyou're effectively doing if
(20:41):
you're, if you're changing yourlanguage in, in the middle of a
program or product.
Matt Coles (20:46):
yeah, that's true.
I guess that's where, that'swhere a proper modular design
and having to be able to, tocreate wrappers or front ends or
other things that, uh, you know,Take that newer construct and
put it in front so that, that itprovides a level of, of defense
to your legacy modules until youhave time to replace'em.
(21:06):
Uh, not suggesting you know thatyou should leave old C code
around unless you make thatdecision to do so.
And then, but you could takeRust and build something around
it that works and that gives yousecurity capability, uh, you
know, defend the core.
Right?
And.
So it's an evolution.
Um, and I think we, we see whatthis memory, safe language
(21:28):
decision, especially, right?
That if you're not spendingtime.
Like Izar was just talkingabout, right.
With, with exceptional things.
If you're not spending time onsolving the problems of how do I
make interfaces secure Becausethe memory, the memory safety
can address that for me or moreimportant, or, or, or also that
(21:50):
language can also enforcecertain 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 logicdecisions and, and less so
worrying about, uh, you know,making sure my APIs only take
the proper data and all theoutput, the, the proper outputs,
(22:11):
right?
The language takes care of that.
Or at least lets me know whenI'm, when I, that I, what I need
to take care of, right?
And so it, it frees up thedeveloper from, from that
responsibility.
In part, they still have to makea conscious design choice,
right?
To use the language and how theybolted on how they How they
connect it together with theother pieces and how they might
(22:33):
replace portions of it.
Uh, but, but it gives'em someflexibility, some capability
there.
And so that's a good thing ingeneral.
Izar Tarandach (22:41):
Yeah, but Matt, keep me honest here'cause you
are much more experienced inthis than I am.
With the proliferation of Uh,iot And small devices and things
like that out there, right?
So one of the design choiceshere is actually what Chris
said.
Go to our memory safe language.
But because of limitations inthese devices, many times
because of memory,'cause of CPU,whatever, you, you don't have
(23:04):
that liberty.
You can't just go and startwriting on a different, there,
there, there's a bunch ofdevices out there that you can't
write in Java because there's nospace for the, the runtime.
Matt Coles (23:14):
Oh yeah.
Yeah, so, right.
You have space constraints oryou may have compiled targets
and other things that might be aproblem, right?
Yeah, exactly.
Izar Tarandach (23:20):
But then you can look at C again and say, okay, I
have to write in C becausethat's what runs in this device.
But I have the design choice ofusing, uh, uh, lib mallock that
does do all the, the protectionof memory spaces for me.
Matt Coles (23:35):
Yeah.
Izar Tarandach (23:36):
you can go, sorry.
you can go farther and you cansay, I can work on a processor
where the hardware already makesthat boundary checking.
check.
A more secure way.
I don't even know if that thingexists.
I think that I read somewherethat it does, but you start
having options at differentlevels for the same design that
(23:56):
at the end, impact everything.
Matt Coles (23:59):
Yeah, I think that the memory choice, the memory
safe language discussion wasreally, and, and this is like, I
guess this is research beingdone out of like MIT and, and
and NSA and and other folks,right?
That, that have, um, you know, alot of, a lot of brainpower put
into this, but thinking aboutWhat percentage of the
development population are, arewriting for specialized targets
(24:20):
like embedded IoT devices versusthose, you know, who are
writing, uh, uh, web, web orcloud-based code, right?
So there you're gonna get moregeneral, general purpose app,
uh, systems, more generalpurpose, uh, general, you know,
commodity processors andwhatnot.
And, and therefore switching tomemory safe languages frees up a
(24:42):
lot of developers time, uh, to,to, or well takes away the
choice of, of, uh, of, ofbuilding insecure code.
Um, and we're just talkingmemory safety, so we're only
really talking about bufferoverflows here, right?
And, and off by one errors and,and things like that.
Um, Uh, except for the newerlanguages that have also better
(25:02):
interfaces and, you know, uh,less undefined behavior and, and
whatnot.
So it's a little bit better inthat regard that to, to not
introduce new weaknesses.
Um, but you know, when you'retalking about, uh, going to
embedded devices, so I'm a bigproponent that C, C is very hard
to get correct.
You need proper diligence to getit correct and make it secure,
(25:25):
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 ispossible 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 alot of different layers of
bubble wrap to give me a safe Cworld where I don't have to
worry about buffer overflows andenergy overflows and all of
these things.
In the code that's being crankedout and like that's, I think is
the balance.
That's the balance though,right?
With these memory safelanguages.
(26:08):
Like that's why that you gottafind a way to build new IoT
devices not using C.
Like C is is a great language.
We can't completely poo poo itbecause 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 thehistory of computing for all
the, all the young whippersnappers 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 isabout 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 understandcorrectly, if I remember
correctly, that Rust is now partof 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 languagethat it doesn't.
It isn't bloat ware, right?
That it, it does do its thingin, in a concise way.
And that's important, right?
And so if we're looking at iotdevices that have memory
constraints, as long as we'recompiling to that, as long as we
can compile to that target,right?
So if we're looking at an ARMchip, right?
(27:29):
That has, has limitedcapabilities in terms of memory,
footprint and, and, and CPUpower.
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 orRust, as long as it compiles to,
to machine code, it can go onthat device.
(27:49):
Then the choice becomes where dowe put our engineering effort?
Do we put our engineering effortinto taking this, you know, 40
or 50 year old language thathas, that is hard to get
correct?
Or do we move to something thatthat's memory safe so that we
can free up again, free up ourdevelopers to work on hard
problems and not be be, youknow, shot by this, by this
(28:13):
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 ofdifferent times in different
episodes, and that's what we'retalking about.
A memory safe language is apaved road that you're providing
for the developers so that theydon't have to worry about memory
safety because the language isgonna enforce it.
And that's a, as we've allTalked about reasonable
(28:36):
security, reasonable AppSecpaved roads and guardrails are
reasonable.
They help.
They help us build a reasonablesystem that still lets
developers be creative andfreestyle and do cool things.
Izar Tarandach (28:49):
Yeah.
And, And, and and another thingthat I think that we, we, we
have to jump to here is that wehave been looking at secure by
this here in this conversation.
We have been looking at secureby design And.
secure by default as, okay, webuilt a secure base.
Now you guys go and show us howwe're going to screw it up.
(29:10):
And.
Now I'm thinking of, okay, thebase is there.
Fine.
Secure by design.
Secure by default.
Now let's see about this screwedup part.
Sorry, my Google in the otherroom heard the okay and went
crazy.
But, um, the, the point I'mtrying to make, I think is that
(29:31):
that there is a change inmindset when you start talking
secure by design, right?
That is less and, Adam, forgiveme here for the heresy, but I, I
think that it breaks a bit tothe model of the four questions
in the way that today, the fourquestions ask, what are we
(29:53):
building?
What could go wrong when youstart talking about secure by
design is, here's what I'mbuilding and here's why
nothing's gonna go wrong, gonnabecause you are already
incorporating in the design ofthe thing that you are designing
security.
security, you are shorteningeven that short jump from Yeah,
I, I, I, I, I said in thebeginning it might sound as
(30:15):
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, nooffense.
Uh, right.
We're all friends here.
We're all, We're all, friendshere.
The table, right.
Izar Tarandach (30:32):
too much monster.
Chris Romeo (30:34):
right?
business logic.
Like developers are building newfeatures.
Yes, they have a securefoundation, 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 notgoing to happen.
I'm not going to say that it'snot going to happen.
What I'm saying is that when yousay secure by design, okay, you
are taking that security isbolted on that.
We used to put way, way, waythere at the, uh, right of the
(31:05):
process.
Right, and that was brought leftby 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 designthing.
It's like I'm designing alreadywith security in mind.
And you know what?
Delusional, I'm willing to takeit.
Overly optimistic?
I think It's more appropriate.
Chris Romeo (31:29):
Overly optimistic.
I like that better thandelusional.
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 thissecure 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 gonnasolve all of our problems.
Izar Tarandach (32:06):
No, nothing's gonna solve all the problems.
'cause because exactly with whatyou said.
At the end of the day, we aredevelopers 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 livein a no-code, low-code world
where all you're doing isplugging Lego pieces together.
And then you're saying, this isthe best application.
Well, no, it's not in, there'sno, it's no more innovative than
the one next to it because itwas constrained by the boxes
that you only had the componentpieces.
(32:34):
You didn't have the ability toThink up and dream up something
new.
And so, I mean, I don't, I meanlow, low-code, no-code has its
place, but let's not let thatbecome 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'tgo there.
Izar Tarandach (32:51):
No, I already
Chris Romeo (32:52):
said too much today.
Let me bounce one more, one morein 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 inputtingqueries to avoid SQL injection.
We're, I mean, that, we've allbeen 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 lookingat that.
I'm going, is that secure bydesign?
Like, do I even have to, isthere a, there's no choice
there.
Is the fact that there's nochoice, 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 thingto 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'sjust 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 templateframeworks, 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 aboutsecurity.
You don't have the samechallenges, but there's still,
there's still a design choice.
I could make a bad choice.
(34:00):
I could choose a framework thatdoesn't care about that.
Ha, I won't say, doesn't careabout security, but hasn't
invested in security at the samelevel as some other framework.
I have a design choice.
What I'm saying is, do I reallyhave 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 adeveloper to use an ORM and I
have seen this repeatedly.
Developers are extremely smartpeople.
The problem is that sometimesthey are smarter than they need
to be.
So when they find out that evenusing an ORM you can write your
(34:36):
query as it is full string, passit to the ORM and your ORM will
usually have an evil call orwhatever whatever that that will
use that, that, that query, thatthe language that you're using
possibly help, helps you do in adynamic 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 anddashboarding 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 showsme an example and says, well,
the ORM through the ORM togenerate this dashboard in real
time takes four and a halfminutes.
(35:17):
And if we write a custom SQLquery, it takes, uh, a hundred
microseconds or milliseconds,whatever, something like that.
Like there's, I can't say youhave to use the ORM in that case
because I can't take four and ahalf minutes to render a
dashboard.
If that they won't be acustomer, they'll have already
left.
Izar Tarandach (35:34):
Right.
But I, I can't say that I'veseen that, but just putting
myself in the seat of adeveloper and I haven't been one
in a long time in thatparticular case, the query that
you are going to put together tosend to the engine to get your
dashboard back is probablysomething highly, uh, uh, um,
(35:54):
structured.
You have a start date, you havean end date, you have a bunch of
things that you want to see thedashboard.
It's not like, okay, I can't usethe ORM great thence in depth.
I'm going to validate the input.
Right?
It's not like one solution fitsall, 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 seendevelopers tell me I bypass the
(36:17):
ORM because I needed to, andthere are valid cases.
Chris Romeo (36:20):
So then maybe, maybe I'm starting to convince
myself that parameterizedqueries is a design decision,
and I would also say proper useof direct queries.
'cause we know there's a usecase for it.
We can't, I can't just say youhave to use ORM and you can't
ever use a raw query.
What I can say is you cannot usea raw query that takes input
from the outside world.
(36:42):
So if you need to dodashboarding, you need to use
the ORM for any processing ofdata that's coming from the
user.
And then your query can just bea string that doesn't, you just,
you figured out the query'causeyou needed an outer join, an
inner join, and something elsealtogether in one to make it
work that the ORM couldn'treplicate 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 usingan ORM is the right design
decision.
Okay?
If I am a, a, a security personin a company that has 300
different things that I have tobe responsible for, before, 299
of them will use ORM and be justhappy with it help There'll be
(37:22):
one that has an issue and now Ican ask them instead of, okay,
let's sit down and threat model300 things thing.
I can ask everybody, are youusing 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 thingthat is exceptional, the the one
(37:42):
that I'm.
That's The one that I'm going tosit down with and have a deep
conversation to see what elsecan we do to help you run this
thing securely?
Right?
So yeah, you just validatedexceptional threat modeling.
Thank you,
Chris Romeo (37:55):
that was my intention, this whole
conversation.
I was like, how am I gonna workit in?
How am I gonna get Izar'sexceptional threat modeling to
be the answer to something Isay.
I tried.
Izar Tarandach (38:06):
the only thing that can complement exceptional
threat modeling is continuousthreat modeling.
So you have to continuously lookfor 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 playwith that because I'm gonna go
look for it.
Chris Romeo (38:33):
No, it's all right.
Well, let's wrap up thisconversation on the security
table.
It was great to, uh, be livehere on LinkedIn and we'll do
that some more in the future.
And, uh, just talking aboutSecure by Design, and I think we
had some, some, we drew out somegood points about how Secure by
Design comes together.
What it is, we're gonna hearthis a lot more.
This is, this is a thing of thefuture and the present.
(38:55):
It's gonna become a lot moreprevalent in different scenarios
and different conversations.
So, uh, keep tuning into thesecurity table.
You can find us on wherever youget podcasts from, or YouTube if
you wanna watch episodes orLinkedIn.
Or maybe we'll show up on someother new social media platform
that no one's even thought ofyet.
Thanks for
Izar Tarandach (39:12):
We are everywhere.
Chris Romeo (39:13):
security table.
Yeah, I think we are.
Izar Tarandach (00:10):
Is this.
Chris Romeo (00:11):
I think we are.
I think we may have, we may havefigured this whole thing out
called the internet.
So welcome to the securitytable.
My name's Chris Romeo and, uh,joined by my good friends, Izar
Tarandach and Matt Coles.
And this is our first timetrying to use the internet, so
it's relatively new to us.
After, you know, multi decadesof being computer people, we're
(00:33):
trying to use the internet.
And so we've been doing thisshow, the security table for, I
don't know, a number of weeks atthis point.
I think we've got 10, 12, 13episodes, something like that.
We talk about things related toapplication security, product
security.
Sometimes we, we discuss civillyand nicely.
Other times things get moreheated when Matt tries to point
(00:55):
out another standard that Ishould read and understand.
I'm just kidding.
It's always, it's all in goodfun.
We we're here to have fun, butwe want to talk about AppSec,
prosec, general security things.
Just have a, and have a goodtime doing it around what we
call the security table, whichis a bit of a virtual table at
this point.
So, um, let's talk about Secureby design, though.
Seems like it's getting a lot ofattention.
(01:16):
Um, CISA came out with adocument secured by design,
secured by default.
Well, CISA and major governmentsfrom around the world came out
with a document to try to puttogether and, and focus our
thoughts on secure by design.
And so let's, let's talk aboutwhat it is first in case people
are out there going, I've heardof this thing, but it's a little
bit of a nebulous concept.
(01:37):
So Izar give us, give us somethoughts on
Izar Tarandach (01:40):
Oh, no, no, no, no, no, no.
The good one is Matt.
Matt defines and I refine.
Chris Romeo (01:46):
Well,
Matt Coles (01:47):
Well, so yeah, so I guess I'll, I'll kick it off
then.
So, uh, secure by design and ofcourse we should.
We should just let you knowusers, uh, viewers know of
course that it's Secure byDesign, secure by default,
right?
So if you're searching for thisdocument or set of documents,
it's, it's Secure by Design orsecure by and secured by
default.
What we mean by secure by designis, uh, that.
(02:10):
The system has been implementedwith secure design principles in
mind.
Uh, that it comes pre-hardened,that it comes pre-secured, and
uh, and that the things thatrather than relying on customers
to take something, install it,and, and configure it securely,
that it comes out of the boxthat way.
So secure by design, you buildin the, capabilities secure by
(02:34):
default, it's configuredcorrectly.
Chris Romeo (02:35):
Mm-hmm.
and, Izar happens to be writingthe, the Great American novel as
we...
Izar Tarandach (02:41):
no, I, I'm, I'm putting it, I'm, I'm putting
into the, into LinkedIn, the URLfor the doc so that people know
what you're talking about.
Chris Romeo (02:49):
...follow along.
Matt Coles (02:50):
You need a less clicky keyboard there, uh,
buddy.
Izar Tarandach (02:52):
I will never have a less clicky keyboard.
Chris Romeo (02:55):
All right, so Mr.
Refinement here.
uh, the definition's been set.
So how, how would you refine thesecure by design by default?
Izar Tarandach (03:06):
so I, I, I think that the keyboard here is
aspirational, right?
So we,
Matt Coles (03:12):
we,
Izar Tarandach (03:13):
We have been doing this thing for a long time
and we we always keep tellingpeople at some point people are
going to learn and do the rightthing and keep doing the right
thing and just ingrain the rightthing, into what they do.
And I think that the, thesecurity by default and security
by design is sort of taking thatone step up and saying, now
(03:35):
actively we have to startlooking from the beginning.
Take The thing that we havealways said about security is
not something that you bolt atthe end.
It's something that you bake in.
I I, I, I love that you bolt,but you bake, whatever, but uh,
Matt Coles (03:49):
Build in, build in.
Izar Tarandach (03:51):
Build in, build in.
But the, the, the thing is thatnow we want to start, you don't
want to start from zero.
You want to start from somethingthat you finally, after much
trial and error andcatastrophes, you have got into
that state where you know howthings, what things have to look
like in order to be secure.
be secure.
And now you define that as yourstarting point.
(04:12):
And you say this, this is whatgood looks like.
And anybody wanting to buildfrom here have to start at this,
at this level.
Have to, to start at thisminimal amount of, of security.
And, uh, you know, I, I thinkthat, that, that plays well with
something that we keep goingback to in the, in the podcast,
which is (04:33):
what's reasonable to do in terms of security.
And, uh, so far from what I haveseen, the, I I I, haven't
exactly seen anything like a, ahardening guide or configuration
guide or 10 best practices forsecure by design or whatnot.
But but the discussion is at aplace that put things in a very
(04:53):
reasonable starting point, Ithink.
Chris Romeo (04:57):
so.
Matt Coles (04:57):
It's interesting you bring up, uh, hardening guides,
in fact, uh, right, because ifyou look through that doc, those
documents, uh, you'll find, youknow, with the notion that you
start secure by design, that youbuild in security, you design it
in, right?
You don't just, you don't justbuild it in, but you design it
in, and then you deploy itsecurely.
Then the theory goes that youcan start looking at sort of
(05:20):
de-hardening guides as opposedto hardening guides.
Rather than have to build upfrom scratch, you can start
allowing If, well, if sodesired.
Chris Romeo (05:29):
please.
Matt Coles (05:30):
Chris is, Chris is shaking his head
Chris Romeo (05:31):
I, I remember when, so the three of us got a chance
to provide some feedback on theCISA document through our, our
Threat Modeling manifestocollective group, and that was
one of the things that I.
I wrote some strong feedback andI feel pretty strongly about
don't encourage anybody tocreate a de-hardening guide.
they wanna figure out how tode-harden something that's been
(05:53):
secured, let them figure it outon their own.
Don't give them a guide thatsays, here's how you, how you
back out of all the good, thesecurity goodness that's been
added to the product.
Izar Tarandach (06:03):
But, but that takes us to a, an interesting
place.
Why would somebody try to bringdown the, the security posture
of, of a system, especially whenit's already been like blessed
as secure,
Matt Coles (06:14):
Uh,
Izar Tarandach (06:15):
right?
Matt Coles (06:15):
The number one reason I think that, that I
think we've all heard over thecourses of our career is
performance, right?
Or accessibility.
Izar Tarandach (06:24):
So here's the interesting thing, I I, I
haven't heard performance asmuch 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 (06:39):
Yeah.
Or Compatibility.
We, we see this with old, youknow, we used to hear this with
old, old web browsers.
Right.
And secure, uh, you know, Httpsservices.
Izar Tarandach (06:47):
I, I hear that a lot with, uh, uh, uh, this
privilege.
I don't know what I'm going toneed this account to do
tomorrow, so I'm going to giveit a privileged role and
whatever it.
Chris Romeo (07:00):
Yep.
Izar Tarandach (07:01):
So that there's that forward looking idea of I
have to be permissive because Idon't know what I'm going to
need tomorrow.
Meanwhile, attackers are alreadyneeding having whatever they
need today.
But, uh, the, that, that'ssomething that I see a lot.
The, the thing to me is that themore I think about this, and,
and Matt and I have discussedthis a number of times.
Matt Coles (07:22):
a number of times,
Izar Tarandach (07:24):
It seems to me that as a security person, if I
have to look over the shoulderof a developer at the time that
they're developing, and I knowthat they start from a buttoned
up state, and now they areasking me to open that thing up,
thing up.
it's a great opportunity for mefor me to question that decision
that and help make it a betterdecision.
(07:48):
decision.
Mm-hmm.
Then the opposite situation whenI'm sitting behind that
developer and every keystroke Igo on their shoulder and say,
shoulder is, is this secure?
Is this secure?
Are, are you doing the rightthing?
Are you doing the thing that thetraining said that you should be
doing?
should be good.
Chris Romeo (08:02):
Yeah, but de-hardening, de-hardening is a
step removed from that Theconcept of de-hardening is
giving a guide to a customer Sothey can back out.
The security confi defaultchanges you added to the product
to somehow bring it into a lesssecure state.
And what I'm saying is I can'tthink of a reason why somebody.
With for good intentions andgood purposes, would want to
(08:25):
back out the security settingsbecause you can't tell me it
hasn't been tested because wehad to test it in this hardened
state.
Matt Coles (08:32):
Mm-hmm.
Chris Romeo (08: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 ofthis idea of having a guide that
tells people how to back out allthe things I've spent 26 years
saying, and you guys have donethe similar thing.
We've been saying these thingsover and over again for decades.
Like, don't, like, don't, don'terase something good that's
(08:53):
happening in the Secure byDesign movement.
That's all I'm saying.
Izar Tarandach (08:56):
Oh, but, but, then it goes to what Matt said
about compatibility, right?
Because you wrote that hardeningguide, and I want to believe
that you tried a.
number of configurations, butthere will always be that guy
that says, I'm running.
I don't know.
I have a firewall from 1980 infront of the thing, and I need
to bring it to SSL
Chris Romeo (09:17):
Yeah, but Secure by Design.
Izar Tarandach (09:19):
won't go.
Chris Romeo (09:20):
Secure by Design doesn't have a hardening guide.
Secure by default, there is nohardening guide.
There is nothing for the user toconfigure.
It comes out of the box secure,and what we, as the producers of
the product say, is a securestate.
So the user, they can't say,well, compatibility, it doesn't
work.
Well, no, it worked because wehad to, we had to test it to
order to release it, to provethat it did.
(09:40):
And we didn't lock it down sofar that it couldn't do its job.
It couldn't meet the, the, thefunctions that it, that it had
been called out to do.
So
Matt Coles (09:47):
Oh, it's, it, it's a, it's always those strange
configurations go like, like asIzar said, right?
There's old, older systems, uh,you know, it may be older web
browsers or older clients, youknow, this could be, let's just
say for a moment that, thatsomebody adopts this late in
their product life cycle in, in,you know, their like, you know,
release 10 or 12 or 14 orwhatever later, or a hundred or
(10:09):
whatever, and, you know, theystill ha wanna be able to
support systems from, you know,10, 20 years ago.
And, This actually was mentionedin the document as well about,
well, this may break backwardcompatibility and we have to be
comfortable as system designers.
You know, making those harddecisions about whether or not
to, to, say, yeah, cut Mr.
(10:29):
Customer, uh, you know, we'removing on.
Think about that, versus try tomaximize, uh, compatibility
across those.
Chris Romeo (10:39):
Yeah, we and, and we are, we're, we're comfortable
with breaking backwardcompatibility.
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 timeswhere product comes and says, we
can't make those guys crazy withthat amount of market share and,
uh, just downgrade the securityand 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 10years 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 anargument now.
Now, we used to hear that allthe time when I worked in a big
product company, but that's,that was 10 years ago, 15 years
ago.
The internet, The world, theexpectations for security have
changed so much though in thattime.
Izar Tarandach (11:24):
but but it's not only the expectations.
I think that we, we, are we areperhaps fortunate to say that we
have such a problem as alertfatigue and we get too many
alerts because now we have toomany 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, Idon't have something that will
(11:46):
tell me that something happenedtoday.
We have a lot of solutions andwe have a lot of ways to getting
the pulse of what's going on inour systems.
Not that that's a justificationfar away from it.
Um, I, I, I sit together withChris on the, the bus of.
Don't you touch that thing,nobody here presses the big red
(12:06):
button, but, uh, uh, I justthink that being pragmatic, if
it happens, we, we do haveenough logs and metrics and
traces, the whole observabilitysuit to to come and say, uh,
something unplanned is happeninghere.
And, uh, and yeah.
Perhaps we have to hit the bigred 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 alittle bit of a memory of, of
going through the document andreviewing it.
But, you know, when I thinkabout what they call, what they
think of as with secure bydesign and what the document
calls for, I mean, there's,there's a number of other
(12:51):
things, but for me, I alwayswanna bring it back to that
magic word (12:53):
design.
Secure by design.
Design.
What's the thing that, what'sthat thing that all three of us
love That that somehow playsinto 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 somuch.
And so when I think Secure bydesign though.
I know threat modeling is apiece of secure by design.
I dunno, what do you guys think?
Like where, where, how doesthreat modeling fit into Secure
By Design?
Is it secure by design?
Is it a layer below Secure bydesign?
(13:27):
Is it a piece?
What, how do, how do you see itfit in?
Matt Coles (13:31):
So I think that threat modeling is a, it is a
way to inform and in part tovalidate.
The design and its security,right?
So with threat modeling, we canlook at a design and we
generally, you know, wegenerally say that the best time
to do threat modeling is whenthe design is formed, but not
(13:54):
well baked, meaning not fixed.
You have time to change it.
And so you have an opportunityto use threat modeling to
influence the properties thatyou need and influence the, the
design to make it secure.
And to make those trade offdecisions about what you can and
can't enable or can and can'tsupport, uh, and, and.
And as I may as well remindfolks here, we have the threat
(14:17):
modeling manifesto when you havethe four question framework that
we leverage, right?
So we're gonna start with whatare we working on?
What can go wrong?
What are we gonna do about it?
That gives us the design, thedesign part, and the secure
design part.
And then did we do a good enoughjob later we can use threat
modeling to validate A, did weactually implement the things
that we need and, and did weeffectively address the, the,
(14:40):
the secure by design part.
Um, that will also feed into thesecure by default peeps because
we can, we can understand sortof 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 asbolted on, it's, it's configured
later to add securitycapabilities.
(15:02):
Or to enforce securitycapabilities.
So I think that's where threatmodeling really, really fits in
here is, is, is informing andthen, uh, validating that
security design practice.
Izar Tarandach (15:14):
So that's how the process of threat modeling
fits into the, the secure bydesign thing, let's say.
To me it's also about how thesecure by design thing fits into
threat model and, and, I.
What I want to say by that isthat many times in the past, you
(15:35):
know, we are asked again andagain, how do you threat model
in an agile situation?
How do you threat model in thecloud?
How do you threat model SAS?
How do you threat model this,that, and the other one?
And thing that we put in themanifesto is that threat
modeling is evolutionary,meaning it gets better every
time now.
(15:57):
If we look at all the situationsof development plus the thing
that we get better at all thetime, one thing that becomes
very clear to me is that we workin Deltas.
We don't always go back to zeroto to threat model, right?
We, we work on the changes onthe system and.
and.
It's funny'cause the, the, thething that immediately jumps to,
(16:21):
to my mind is that we as threatmodels, when we do threat
modeling, the things that exciteus are those things that you
guys are trying to do different.
This is a new thing.
This, this is a shiny new thingthat nobody has done before We
get bored.
you get bored by again looking,at, at the VPC and the
permissions and who's talking towhom and, uh, where is this
(16:42):
process running andauthenticating that, that,
that's, that's the stuff thatyou need to get off the ground.
And to me, security, security bydesign is going to bring that,
that thing in terms of they'regoing 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 nowfinally to look in depth at
(17:05):
things like business logic, andinnovation and things combined
today that weren't combinedyesterday, right?
And start focusing on that newstuff and that new attack
surface and let the stuff thathas already been explored,
already been turned intostandards.
This is how we run a securedatabase here.
This is how we run a secure asecure server of whatever here
(17:27):
whatever
Chris Romeo (17:28):
Yeah.
Izar Tarandach (17:29):
and now.
Just tell me what you're doingdifferent.
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, pullrequest moment or using a ullp
request.
You don't, you don't go review5,000 lines of code when there
were three lines changed.
You focus on the diff, you focuson the diff, and then the
context around it enough tounderstand did what they change
(17:55):
fix the problem or make thething go away.
And so yeah, it's like adifferential almost approach to,
uh, to looking at, at what'schanged 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 exceptionalthreat 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 withdifferential threat modeling.
I went for it.
I, I gave
Izar Tarandach (18:27):
no, no, no.
no.
I, I, I have a history withanything that is differential
integral.
I, I have a bad history withthat stuff.
Chris Romeo (18:34):
okay.
I don't even know what, I don'tactually even know what it
means, so I mean, I just, itsounded 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 thefuture 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 forthe rest of the time we're
talking.
Please don't drift off and starttyping 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 safeprogramming languages.
So you, you, you can argue thatthat is a design activity
because you had to design whatlanguage 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 thinkabout the, the the proliferation
of new languages like Rust andGo, which are replacing what we
used to use c and c plus, plusfour and Rust and go have
enhanced security mechanisms inplace to prevent problems that
(19:58):
were easy to stumble into andsee.
you know, secur doing properbounce checking and memory
management in the languageitself.
That's a, that's a step forward.
But that was a design decision.
And we realize if you have anexisting system, existing
product, you can't just go say,well, for from this point
(20:18):
forward, we're gonna use Rust.
Now we wrote the whole thing inC but from this point forward,
we're using Rust.
So if you're gonna make achange, you're making a Rust.
Like it's, it's it a, a.
Language choice is more ofsomething you can do upfront
with something new you'rebuilding.
It's a little harder to changeboth engines on the airplane at
30,000 feet, which is whatyou're effectively doing if
(20:41):
you're, if you're changing yourlanguage in, in the middle of a
program or product.
Matt Coles (20:46):
yeah, that's true.
I guess that's where, that'swhere a proper modular design
and having to be able to, tocreate wrappers or front ends or
other things that, uh, you know,Take that newer construct and
put it in front so that, that itprovides a level of, of defense
to your legacy modules until youhave time to replace'em.
(21:06):
Uh, not suggesting you know thatyou should leave old C code
around unless you make thatdecision to do so.
And then, but you could takeRust and build something around
it that works and that gives yousecurity capability, uh, you
know, defend the core.
Right?
And.
So it's an evolution.
Um, and I think we, we see whatthis memory, safe language
(21:28):
decision, especially, right?
That if you're not spendingtime.
Like Izar was just talkingabout, right.
With, with exceptional things.
If you're not spending time onsolving the problems of how do I
make interfaces secure Becausethe memory, the memory safety
can address that for me or moreimportant, or, or, or also that
(21:50):
language can also enforcecertain 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 logicdecisions and, and less so
worrying about, uh, you know,making sure my APIs only take
the proper data and all theoutput, the, the proper outputs,
(22:11):
right?
The language takes care of that.
Or at least lets me know whenI'm, when I, that I, what I need
to take care of, right?
And so it, it frees up thedeveloper from, from that
responsibility.
In part, they still have to makea conscious design choice,
right?
To use the language and how theybolted on how they How they
connect it together with theother pieces and how they might
(22:33):
replace portions of it.
Uh, but, but it gives'em someflexibility, some capability
there.
And so that's a good thing ingeneral.
Izar Tarandach (22:41):
Yeah, but Matt, keep me honest here'cause you
are much more experienced inthis than I am.
With the proliferation of Uh,iot And small devices and things
like that out there, right?
So one of the design choiceshere is actually what Chris
said.
Go to our memory safe language.
But because of limitations inthese devices, many times
because of memory,'cause of CPU,whatever, you, you don't have
(23:04):
that liberty.
You can't just go and startwriting on a different, there,
there, there's a bunch ofdevices out there that you can't
write in Java because there's nospace for the, the runtime.
Matt Coles (23:14):
Oh yeah.
Yeah, so, right.
You have space constraints oryou may have compiled targets
and other things that might be aproblem, right?
Yeah, exactly.
Izar Tarandach (23:20):
But then you can look at C again and say, okay, I
have to write in C becausethat's what runs in this device.
But I have the design choice ofusing, uh, uh, lib mallock that
does do all the, the protectionof memory spaces for me.
Matt Coles (23:35):
Yeah.
Izar Tarandach (23:36):
you can go, sorry.
you can go farther and you cansay, I can work on a processor
where the hardware already makesthat boundary checking.
check.
A more secure way.
I don't even know if that thingexists.
I think that I read somewherethat it does, but you start
having options at differentlevels for the same design that
(23:56):
at the end, impact everything.
Matt Coles (23:59):
Yeah, I think that the memory choice, the memory
safe language discussion wasreally, and, and this is like, I
guess this is research beingdone out of like MIT and, and
and NSA and and other folks,right?
That, that have, um, you know, alot of, a lot of brainpower put
into this, but thinking aboutWhat percentage of the
development population are, arewriting for specialized targets
(24:20):
like embedded IoT devices versusthose, you know, who are
writing, uh, uh, web, web orcloud-based code, right?
So there you're gonna get moregeneral, general purpose app,
uh, systems, more generalpurpose, uh, general, you know,
commodity processors andwhatnot.
And, and therefore switching tomemory safe languages frees up a
(24:42):
lot of developers time, uh, to,to, or well takes away the
choice of, of, uh, of, ofbuilding insecure code.
Um, and we're just talkingmemory safety, so we're only
really talking about bufferoverflows here, right?
And, and off by one errors and,and things like that.
Um, Uh, except for the newerlanguages that have also better
(25:02):
interfaces and, you know, uh,less undefined behavior and, and
whatnot.
So it's a little bit better inthat regard that to, to not
introduce new weaknesses.
Um, but you know, when you'retalking about, uh, going to
embedded devices, so I'm a bigproponent that C, C is very hard
to get correct.
You need proper diligence to getit correct and make it secure,
(25:25):
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 ispossible 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 alot of different layers of
bubble wrap to give me a safe Cworld where I don't have to
worry about buffer overflows andenergy overflows and all of
these things.
In the code that's being crankedout and like that's, I think is
the balance.
That's the balance though,right?
With these memory safelanguages.
(26:08):
Like that's why that you gottafind a way to build new IoT
devices not using C.
Like C is is a great language.
We can't completely poo poo itbecause 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 thehistory of computing for all
the, all the young whippersnappers 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 isabout 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 understandcorrectly, if I remember
correctly, that Rust is now partof 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 languagethat it doesn't.
It isn't bloat ware, right?
That it, it does do its thingin, in a concise way.
And that's important, right?
And so if we're looking at iotdevices that have memory
constraints, as long as we'recompiling to that, as long as we
can compile to that target,right?
So if we're looking at an ARMchip, right?
(27:29):
That has, has limitedcapabilities in terms of memory,
footprint and, and, and CPUpower.
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 orRust, as long as it compiles to,
to machine code, it can go onthat device.
(27:49):
Then the choice becomes where dowe put our engineering effort?
Do we put our engineering effortinto taking this, you know, 40
or 50 year old language thathas, that is hard to get
correct?
Or do we move to something thatthat's memory safe so that we
can free up again, free up ourdevelopers to work on hard
problems and not be be, youknow, shot by this, by this
(28:13):
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 ofdifferent times in different
episodes, and that's what we'retalking about.
A memory safe language is apaved road that you're providing
for the developers so that theydon't have to worry about memory
safety because the language isgonna enforce it.
And that's a, as we've allTalked about reasonable
(28:36):
security, reasonable AppSecpaved roads and guardrails are
reasonable.
They help.
They help us build a reasonablesystem that still lets
developers be creative andfreestyle and do cool things.
Izar Tarandach (28:49):
Yeah.
And, And, and and another thingthat I think that we, we, we
have to jump to here is that wehave been looking at secure by
this here in this conversation.
We have been looking at secureby design And.
secure by default as, okay, webuilt a secure base.
Now you guys go and show us howwe're going to screw it up.
(29:10):
And.
Now I'm thinking of, okay, thebase is there.
Fine.
Secure by design.
Secure by default.
Now let's see about this screwedup part.
Sorry, my Google in the otherroom heard the okay and went
crazy.
But, um, the, the point I'mtrying to make, I think is that
(29:31):
that there is a change inmindset when you start talking
secure by design, right?
That is less and, Adam, forgiveme here for the heresy, but I, I
think that it breaks a bit tothe model of the four questions
in the way that today, the fourquestions ask, what are we
(29:53):
building?
What could go wrong when youstart talking about secure by
design is, here's what I'mbuilding and here's why
nothing's gonna go wrong, gonnabecause you are already
incorporating in the design ofthe thing that you are designing
security.
security, you are shorteningeven that short jump from Yeah,
I, I, I, I, I said in thebeginning it might sound as
(30:15):
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, nooffense.
Uh, right.
We're all friends here.
We're all, We're all, friendshere.
The table, right.
Izar Tarandach (30:32):
too much monster.
Chris Romeo (30:34):
right?
business logic.
Like developers are building newfeatures.
Yes, they have a securefoundation, 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 notgoing to happen.
I'm not going to say that it'snot going to happen.
What I'm saying is that when yousay secure by design, okay, you
are taking that security isbolted on that.
We used to put way, way, waythere at the, uh, right of the
(31:05):
process.
Right, and that was brought leftby 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 designthing.
It's like I'm designing alreadywith security in mind.
And you know what?
Delusional, I'm willing to takeit.
Overly optimistic?
I think It's more appropriate.
Chris Romeo (31:29):
Overly optimistic.
I like that better thandelusional.
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 thissecure 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 gonnasolve all of our problems.
Izar Tarandach (32:06):
No, nothing's gonna solve all the problems.
'cause because exactly with whatyou said.
At the end of the day, we aredevelopers 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 livein a no-code, low-code world
where all you're doing isplugging Lego pieces together.
And then you're saying, this isthe best application.
Well, no, it's not in, there'sno, it's no more innovative than
the one next to it because itwas constrained by the boxes
that you only had the componentpieces.
(32:34):
You didn't have the ability toThink up and dream up something
new.
And so, I mean, I don't, I meanlow, low-code, no-code has its
place, but let's not let thatbecome 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'tgo there.
Izar Tarandach (32:51):
No, I already
Chris Romeo (32:52):
said too much today.
Let me bounce one more, one morein 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 inputtingqueries to avoid SQL injection.
We're, I mean, that, we've allbeen 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 lookingat that.
I'm going, is that secure bydesign?
Like, do I even have to, isthere a, there's no choice
there.
Is the fact that there's nochoice, 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 thingto 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'sjust 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 templateframeworks, 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 aboutsecurity.
You don't have the samechallenges, but there's still,
there's still a design choice.
I could make a bad choice.
(34:00):
I could choose a framework thatdoesn't care about that.
Ha, I won't say, doesn't careabout security, but hasn't
invested in security at the samelevel as some other framework.
I have a design choice.
What I'm saying is, do I reallyhave 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 adeveloper to use an ORM and I
have seen this repeatedly.
Developers are extremely smartpeople.
The problem is that sometimesthey are smarter than they need
to be.
So when they find out that evenusing an ORM you can write your
(34:36):
query as it is full string, passit to the ORM and your ORM will
usually have an evil call orwhatever whatever that that will
use that, that, that query, thatthe language that you're using
possibly help, helps you do in adynamic 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 anddashboarding 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 showsme an example and says, well,
the ORM through the ORM togenerate this dashboard in real
time takes four and a halfminutes.
(35:17):
And if we write a custom SQLquery, it takes, uh, a hundred
microseconds or milliseconds,whatever, something like that.
Like there's, I can't say youhave to use the ORM in that case
because I can't take four and ahalf minutes to render a
dashboard.
If that they won't be acustomer, they'll have already
left.
Izar Tarandach (35:34):
Right.
But I, I can't say that I'veseen that, but just putting
myself in the seat of adeveloper and I haven't been one
in a long time in thatparticular case, the query that
you are going to put together tosend to the engine to get your
dashboard back is probablysomething highly, uh, uh, um,
(35:54):
structured.
You have a start date, you havean end date, you have a bunch of
things that you want to see thedashboard.
It's not like, okay, I can't usethe ORM great thence in depth.
I'm going to validate the input.
Right?
It's not like one solution fitsall, 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 seendevelopers tell me I bypass the
(36:17):
ORM because I needed to, andthere are valid cases.
Chris Romeo (36:20):
So then maybe, maybe I'm starting to convince
myself that parameterizedqueries is a design decision,
and I would also say proper useof direct queries.
'cause we know there's a usecase for it.
We can't, I can't just say youhave to use ORM and you can't
ever use a raw query.
What I can say is you cannot usea raw query that takes input
from the outside world.
(36:42):
So if you need to dodashboarding, you need to use
the ORM for any processing ofdata that's coming from the
user.
And then your query can just bea string that doesn't, you just,
you figured out the query'causeyou needed an outer join, an
inner join, and something elsealtogether in one to make it
work that the ORM couldn'treplicate 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 usingan ORM is the right design
decision.
Okay?
If I am a, a, a security personin a company that has 300
different things that I have tobe responsible for, before, 299
of them will use ORM and be justhappy with it help There'll be
(37:22):
one that has an issue and now Ican ask them instead of, okay,
let's sit down and threat model300 things thing.
I can ask everybody, are youusing 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 thingthat is exceptional, the the one
(37:42):
that I'm.
That's The one that I'm going tosit down with and have a deep
conversation to see what elsecan we do to help you run this
thing securely?
Right?
So yeah, you just validatedexceptional threat modeling.
Thank you,
Chris Romeo (37:55):
that was my intention, this whole
conversation.
I was like, how am I gonna workit in?
How am I gonna get Izar'sexceptional threat modeling to
be the answer to something Isay.
I tried.
Izar Tarandach (38:06):
the only thing that can complement exceptional
threat modeling is continuousthreat modeling.
So you have to continuously lookfor 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 playwith that because I'm gonna go
look for it.
Chris Romeo (38:33):
No, it's all right.
Well, let's wrap up thisconversation on the security
table.
It was great to, uh, be livehere on LinkedIn and we'll do
that some more in the future.
And, uh, just talking aboutSecure by Design, and I think we
had some, some, we drew out somegood points about how Secure by
Design comes together.
What it is, we're gonna hearthis a lot more.
This is, this is a thing of thefuture and the present.
(38:55):
It's gonna become a lot moreprevalent in different scenarios
and different conversations.
So, uh, keep tuning into thesecurity table.
You can find us on wherever youget podcasts from, or YouTube if
you wanna watch episodes orLinkedIn.
Or maybe we'll show up on someother new social media platform
that no one's even thought ofyet.
Thanks for
Izar Tarandach (39:12):
We are everywhere.
Chris Romeo (39:13):
security table.
Popular Podcasts
Dateline NBC
Current and classic episodes, featuring compelling true-crime mysteries, powerful documentaries and in-depth investigations. Follow now to get the latest episodes of Dateline NBC completely free, or subscribe to Dateline Premium for ad-free listening and exclusive bonus content: DatelinePremium.com
24/7 News: The Latest
The latest news in 4 minutes updated every hour, every day.
Therapy Gecko
An unlicensed lizard psychologist travels the universe talking to strangers about absolutely nothing. TO CALL THE GECKO: follow me on https://www.twitch.tv/lyleforever to get a notification for when I am taking calls. I am usually live Mondays, Wednesdays, and Fridays but lately a lot of other times too. I am a gecko.