October 17, 2023 • 54 mins
The Security Table gathers to discuss the evolving landscape of application security and its potential integration with development. Chris posits that application or product security will eventually be absorbed by the development sector, eliminating the need for separate teams. One hindrance to this vision is the friction between security and engineering teams in many organizations.
Many people think that security incidents have negative implications on brand reputation and value. Izar points out that, contrary to popular belief, major security breaches, such as those experienced by Sony and MGM, do not have a lasting impact on stock prices. Chris counters this by highlighting the potential for upcoming privacy legislation in the U.S., which could shift the focus and importance of security in the corporate world.
Chris envisions a future where the security team is dissolved and its functions are absorbed across various business units. This would lead to better alignment, reduced infighting, and more efficient budget allocation. Security functions need to be placed where they can have the most significant impact, without the potential conflicts that currently exist between security teams and other business units.
The second topic of discussion is the "shift left" movement in the realm of application security. There is ambiguity and potential misuse of the term. What exactly is being shifted and from where does the shift start? The term "shift left" suggests moving security considerations earlier in the development process. However, the hosts point out that the phrase has been co-opted and weaponized for marketing purposes, often without a clear understanding of its implications. For instance, they highlight that while it's easy to claim that a product or process "shifts left," it's essential to define what is being shifted, how much, and the tangible benefits of such a shift.
Matt emphasizes the idea of not just shifting left but starting left, meaning that security considerations should begin from the requirements phase of a project. Chris mentions that the concept of shifting left isn't new and cites Joe Jarzombek's late 90s initiative called "Building Security In" as a precursor to the current shift left movement. The hosts also humorously liken the shift left movement to a game of Frogger, suggesting that if one shifts too much to the left, they might miss the mark entirely. The discussion underscores the need for clarity and purpose when adopting the shift left philosophy, rather than just using it as a buzzword.
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:10):
Hey folks, welcome to The Security Table.
This is Chris Romeo joined byIzar Tarandach and Matt Coles,
and we are going to jump rightin, skip all the witty banter,
so you can just remember wittybanter from a previous episode,
uh, that usually happens here,uh, in this little segment.
We're going to dive right backinto where we picked up from, or
picked up from, where we leftoff from, be the right
(00:32):
expression, where we left off inthat last episode, and I kind of
left off at the cliffhanger.
But I gave you guys a week tothink about this, so I'm, I'm
expecting some brilliant, uh,solutions have been crafted
inside of your brains.
So the issue that I left us withat the, at the conclusion, which
was based on an interview I didwith somebody else, and kind of
(00:54):
some of their opinions.
The future of applicationsecurity.
I want to offer a hypothesis, Iguess.
Maybe not a hypothesis, just aprediction.
I think that in the next numberof years, I'm not sure if it's
going to be 5 or 10 or how longit's going to take, but I think
application slash productsecurity is going to be eaten by
(01:16):
development.
I think it's going to beabsorbed.
And when I say eaten, I meanit's going to be absorbed.
Um, because, and the premisebeing, we have a lot of
friction.
in our day here between securityand engineering.
Different levels of friction, Iwould say, in different
(01:37):
companies, but I've seen somecompanies where the friction
level is, there might be a fighthere shortly, all the way down
to, eh, we just, you know, wejust don't really listen to what
they say and stuff like that.
So I'm imagining a world wheresecurity becomes part of
engineering and then Everybodyreports to the same boss, the
(01:59):
CTO, the VP of engineering, thewhatever.
Uh, and so let's dive in there.
I want to see, what do you guysthink about this?
Do you think this is possible?
Do you think it's irrational?
Do you, where does it sit on thescale here, Matt?
You go first.
Matt Coles (02:14):
Well, um, so first rule of Security Fight Club is
you don't talk about SecurityFight Club.
Um, so, uh, it's interestingactually, uh, it's an
interesting premise.
Uh, I, I may answer it with aquestion or two.
So.
Quality engineering is part ofengineering.
(02:34):
It is not a distinct function,although it's not, well, maybe
not best done in by developers,you know, uh, cause you do want
to check and balance in place,but it's part of an engineering
discipline.
And so the requisite knowledgeand experience and training and
capability can all be served outof the engineering organization,
(02:57):
right?
That exists, has existed fordecades, right?
Uh, um, certainly in ourindustry.
So.
Uh, both hardware and softwarerelated, right?
You can do, have qualityengineering and software
engineering as side by sidefunctions.
What you're suggesting is makingsecurity engineering one of
those functions.
Uh, and in that regard, forcertainly for product
(03:22):
development, I, it soundsreasonable.
Are we there yet?
Probably not, uh, but, but are,should we be there?
Uh, that's an interestingquestion, uh, because what that
means is that engineeringorganizations would have all the
functions within them tobasically govern their own
(03:43):
destiny, uh, and, and, They knowalready have structures in place
for handling requirements andreporting and, uh, and, you
know, and working with otherparts of the business.
Do you really need a check andbalance on from security?
Uh, is there any benefit tohaving security outside of that
(04:03):
organization is what you'reproposing?
Uh, so actually reallyinteresting.
I wonder, I wonder if that wouldwork.
Chris Romeo (04:10):
Governance is where I, is kind of the, one of the
sticking points, because...
Matt Coles (04:14):
Well, also, uh, response, uh, so things like,
you have customer support thatis not part of, of the
engineering function, right?
People to handle fielding bugsand working with customers.
So, similarly, wouldvulnerability and incident
response be outside of thatfunction?
So, would it be as...
Chris Romeo (04:30):
Maybe they become a part of customer success or
customer service.
Maybe become a function there.
Matt Coles (04:34):
Right.
So, but, but either way,security as a whole probably
can't be consumed by theengineering organization, but it
sounds like, I mean, if you usequality as an, as a, as a, by
comparison, engineering alreadycontains quality functions.
Could it contain securityfunctions too?
Maybe.
And that might really work.
(04:55):
Izar, what do you, what are youthinking there?
Izar Tarandach (05:01):
I have to agree with you and the thing is that
for for a long time we have beenusing that pithy thing that says
that if we do our job bad or jobright then we're going to work
ourselves out of a job and weusually say that when we're
training developers and ortraining other security people.
(05:22):
And for a while, I think it wascute, but now we are seeing the,
we are seeing what success lookslike looming over us.
But, uh, I think that one thingthat I can for sure say is that
if that ever happens, and asMatt says, I said that, I think
that for a certain portion ofthe work, that's definitely the
(05:46):
way that things are going.
It's not going to happen becauseof tools.
It's not going to happen becausethe magical AI in the sky is
doing its whole thing.
It's going to happen because atthe end of the day, developers
are going to understand thatsecure code is quality code.
(06:06):
They're going to incorporate thethings that we have been talking
for years upon years of all theprinciples and all the
specifics.
And all that stuff.
But at the same time, there willbe other developers who will
develop new ways of things thatcould go wrong.
So there will be aspects ofsecurity that will still be very
(06:32):
much needed, namely designarchitecture.
And I think that at the end ofthe day, what we're going to see
is it's a sort of acommoditization of security
knowledge, where developers knowjust enough to get by day after
day without perhaps, uh,security and application
(06:55):
security engineers sitting ontheir shoulder.
But there will still be securityfunctions out there beyond GRC,
which I completely agree withMatt.
It's always going to be aproblem.
And, uh.
Not a problem, but it's alwaysgoing to require more expertise
than a developer probably wantsyou to put there.
(07:16):
One thing, though, that I wantto throw in the mix.
Throughout this whole cyclewhere we teach, we teach, they
learn, we measure, we get toconclusions.
We never really got to ask them,do you want to do this?
And I have the feeling that mostdevelopers, I won't say most,
(07:41):
but many...
A large percentage of thedevelopers that I have met
through the years are not reallyinterested in getting security
as a process, as aresponsibility to themselves.
Matt Coles (07:57):
Uh, can we just, uh, talk a little bit about
DevSecOps then?
Um,
Izar Tarandach (08:03):
Do we have to?
Matt Coles (08:05):
Well, so for, so for, so first off, let me, let
me just jump in a little bit,something you're describing.
Yeah, you use the worddevelopers a lot.
Um, in when my description, whenI was talking about this, I
wasn't thinking developersspecifically.
I was thinking engineeringorganizations.
So that includes non developerswithin that organization.
Um, I agree with you, mostengineers probably don't want to
(08:28):
take on security responsibility,although DevSecOps, we kind of
give them that responsibility.
Uh, although I, I think at timesI, I, At times, I have a sense
that it's, give them a lot ofresponsibility, but not a lot
authority or capability.
Uh, and so, um, and that's notuniversally, you know, it's not
universal, but it's, it'ssometimes there's observations
(08:51):
there that, that seems tosuggest that.
Uh, but the, um, The notion thatan engineering organization, not
necessarily the engineersthemselves, may take a function,
take that function, right?
We don't, developers get taughthow to write quality code, but
they don't often get taught howto do quality engineering.
(09:15):
Likewise, we would, we trainengineers how to write secure
code, but not necessarily on thefunction of, of ensuring
security.
Izar Tarandach (09:24):
There is
Matt Coles (09:24):
And if you look at it that way.
I think that's where theengineering organization as a
whole can pick up those, thosetasks, as opposed to having a
dedicated security organizationsort of do it for them.
And, and that's where I was,that's where I was going with.
So I just want to clarify thatbecause developers may want to
take on that responsibility orthey may not, but the
(09:46):
engineering function as a wholeshould.
Chris Romeo (09:49):
And when I, when I think about this model, I'm not
envisioning what we think of asthe people that are on an AppSec
team or on a ProdSec team todayas going away.
They just don't report to theCISO anymore.
They're part of the engineeringorganization and they're
deployed.
So it's not like we don't, it'snot like we're taking all the
security people and saying,you're just done.
(10:10):
The developers are replacingyou, the product managers are
replacing you, the programmanagers are replacing you.
We're bringing them into thefold.
It's just we don't have, we'reeliminating, one of the big
pluses of this is we'reeliminating any potential
political fighting between twoseparate organizations by
putting them under oneorganization in one management
(10:31):
chain that can make riskmanagement decisions at the end
of the day.
They can, they can decide whatare we going to do for security.
And I think we've come farenough in our history.
Like this would have, would nothave worked 20 years ago.
Would not have worked 10 yearsago.
And when I first started insecurity, people were still
saying, Hmm, no.
Like we, we'd go to engineering,they'd be like, you need to do
this.
No, we don't, we don't have todo that.
(10:52):
We're not there anymore.
Right.
And that's why I can start tothink about this new world
approach.
Because I know I don't havepeople that are just going to
tell me we're not doing it.
Matt Coles (11:01):
They have to be equal partners to your
organization, again, along thesame lines of quality
engineering and other aspects,and, but it would certainly help
with things like funding, right?
So you'd have, you know, feweropportunities for cross charging
and whatnot, uh, and, andcertainly would help with
reporting.
Uh, and, uh, the only downsideis the check and balance part,
(11:24):
right?
The GRC function, audit, uh, wetalked about vulnerability and
instant response, um, wherethose functions go, how they're
managed, right?
There's still some cross crossorg communications that have to
happen.
Chris Romeo (11:38):
So that's one threat.
You've identified one potentialthreat.
Izar Tarandach (11:41):
There is more.
So again, in a perfect world,assuming that the cow is a
perfect sphere, that wouldreally work.
But now throw into the mix thefact that if you get that team,
bring it into the engineeringteam.
(12:04):
you are most probably going toput them under, as Matt said,
engineering management.
Now, engineering management hasvery set ways of measuring
performance, measuring goals,measuring achievements, that
don't really mesh with the waythat we measure things at
security.
And sometimes that's even a verybig source of friction.
(12:28):
So now we are taking anoverloaded management level,
giving them a bunch of peoplethat speak a completely
different language.
And saying, for the good ofeverybody, play nice, kids.
Historically, it doesn't worklike that.
Chris Romeo (12:45):
Historically.
But we're, we're, we're, we'rereaching new places now in
Izar Tarandach (12:51):
that's going be a new place that has nothing to
do with security itself, but alot to do with management, uh,
uh, culture.
And I'm not touching that onewith, uh...
Matt Coles (13:05):
Well, let's talk about the language.
Let's talk about that languagethat you were talking, that you
were describing, right?
So the language of securitytoday versus if, imagine a world
where security is part of theengineering function, Where,
like, how different, first off,would it be the same language as
we have today?
And, and if not, what might itlook like?
(13:30):
So, and I'm thinking, and again,I'm using quality as a, as a
analog here, um, right?
Developers talk about, you know,there's code complexity, but
there's also code velocity, um,you know, number of lines of
code, uh, produced and, andfeatures implemented, etc.
Well, quality engineering isabout, You know, test case
(13:52):
developed, you know, casesdeveloped, cases executed, pass
rate, uh, or fail rate, um,defects of quality defects or a
performance defects, or, youknow, basically failure to meet,
uh, requirements of validationand verification.
If security was part of the, um,as part of the engineering
(14:17):
function, why wouldn't they bejust translated into those
terms?
Where, where would there need tobe, what translation would need
to happen, do you think?
Izar Tarandach (14:29):
Let me give you an extreme example, okay?
And maybe even a very weak one.
But let's say that you justbrought a security researcher
slash pen tester into the teamand that person just went over
what came out of the sprint didtheir thing.
Now they look at their managerand at their engineering manager
(14:49):
and say I didn't find anything.
Now the engineering manager willsay oh, that's good we don't
have any risks.
We don't have any problems,right?
And the security person is goingto look at them and say I didn't
say that I said I didn't findanything.
Chris Romeo (15:04):
But doesn't that force a cultural shift either
break or it will make thingsvery successful?
Izar Tarandach (15:12):
What is cheaper?
To do a cultural shift or forthe manager, for the engineering
manager to say he didn't findanything, there's nothing to be
found and we are good, ship it.
Matt Coles (15:25):
So, uh, I'm going to ask a naive question here.
When this researcher did theirresearch, did they follow a
process for this?
And again, about, I'm thinkingabout the, let's talk about, if
we talk about QA for a moment,right?
So QA runs through all theirtests and doesn't find any bugs.
They go to their engineeringmanager and go, we didn't find
(15:46):
any bugs.
We ran all these tests.
We had X amount of codecoverage, right?
Maybe we covered 80 percent ofthe code.
We didn't find any bugs.
Engineering manager willprobably look at that and go, we
have quality code.
Izar Tarandach (16:00):
But QA testing for spec.
They're testing a positive case.
Yes, the code does what the specsays that the code should be
doing.
The security person is doing thenegative case.
Hey, I clicked some stuff and itexploded.
If it doesn't explode, does itmean that it won't explode if I
click two things?
No, it doesn't.
Chris Romeo (16:18):
In your example, though, you're, you're
extracting an isolation mode,meaning you're not considering
any of the other things thatwould be happening in any
process that would be part ofany program any of the three of
us would build.
We wouldn't rely...
Izar Tarandach (16:32):
If we run DAST, we know that everything works,
but, uh,
Matt Coles (16:35):
Boom!
Chris Romeo (16:37):
And we'd have WAFs, WAFs blocking our traffic and
the hampster wheel...
Matt Coles (16:42):
You would be scanning scanning and fixing
Chris Romeo (16:44):
scanning and fixing
Izar Tarandach (16:45):
AI reading the code.
Chris Romeo (16:47):
Up issues.
But the point is, though...
We wouldn't, this wouldn't be anisolated incident where the pen
test that like the only thingthe engineering manager has as
data is the result of the pentesters work.
And now they're going to say,we're good.
No, they're going to have, youknow, pipelines that are part of
code builds happening that aredoing software composition
analysis.
They're doing SAST.
(17:08):
They're doing, um, other, youknow, their runtime stuff
Izar Tarandach (17:13):
so now you asking the engineering manager
to become aware of those things,understand their limitations,
understand the output they putout, interpret all that, and
come out with a risk assessmenton top of all the other things
that they already do every day.
Chris Romeo (17:30):
No, I mean, I'm thinking let's put a security
person on their team.
Like they're not experts in Theydon't, don't
Izar Tarandach (17:37):
Which at the end of the day will come to the
engineering manager and say,looking at all the stuff that we
have, we didn't find much.
So the guy is going to ask, arewe secure?
That means that we're secure,right?
And the guy says, I didn't saythat.
Chris Romeo (17:51):
Engineering managers don't ask that.
That's executives that ask that.
Izar Tarandach (17:53):
But the language is different.
The language is different.
Chris Romeo (17:57):
Immediately go up to, are we secure?
Izar, are we secure?
Izar Tarandach (18:02):
We don't measure things with the same stick and
we don't take risks with thesame stick, right?
In our book, Matt and I saidthat engineering moves at the
speed of innovation and securitymoves at the speed of caution.
You can't drive the same car attwo speeds at the same time.
Chris Romeo (18:25):
Well, we just have to make a super highway and we
got to merge everybody togetheronto the same highway.
Izar Tarandach (18:29):
But you know what this whole conversation
reminds me of?
Your last LinkedIn post.
Because basically what we'resaying here is, hey, we have
achieved left maximum, criticalmass, right?
We went left all the way.
I say we have shift left so muchthat we are falling off of the
(18:51):
table.
I mean, it's, it's...
Chris Romeo (18:55):
So we're falling left.
That's a new one.
I haven't heard that one yet.
So, um, yeah.
So, I mean, I think
Izar Tarandach (19:02):
it, yeah.
Chris Romeo (19:03):
just to, to kind of wrap up, put a bow on the future
of AppSec and then we cantransition and talk about shift
left.
Uh, you guys have challenged mythinking in good ways here
because you made me think, Matt,specifically about like where
does GRC sit?
Where does audit sit?
(19:23):
And I think it's possible forthose things to live on in the
finance organization.
I think it's possible.
Matt Coles (19:28):
Or legal.
Chris Romeo (19:29):
Were just going to do away with a separate security
department.
We know that privacy is alreadypretty much embedded with the
legal side.
By, that's just by nature wherethey've landed.
Izar Tarandach (19:38):
Sad as that is.
Matt Coles (19:40):
And, and, and by the way, we're not talking about
things like IT security, right?
We're talking about AppSec,development security, ProdSec...
Chris Romeo (19:47):
I mean, InfoSec should, like, you could even
pull this thread more and saywhy does InfoSec exist?
Why doesn't it live in IT?
Why isn't, why don't we justhave people in IT thinking about
security?
Versus having a separate groupthat thinks about security
versus a group who just thinksabout building network
architectures.
Why do we have two separateteams doing this at the same
(20:08):
time?
Izar Tarandach (20:09):
We keep talking about this and I keep thinking
who watches the watchers.
But not, not in terms of whowatches people doing stuff,
but...
There's a, there's a functionhere that the output is risk.
Chris Romeo (20:23):
That's governance.
That's GRC though, right?
Izar Tarandach (20:24):
no, no, no, no, no, no, no, no, no.
People are building stuff.
That stuff carries risk.
And we are saying, rather thanhaving two teams, one that
builds and one that checks whatgot built, let's get the one
that checks what got built andput it together with the one
that builds.
And, and, and let's have it likebe consumed by all the processes
(20:44):
in that team.
And to me it goes back to, now Idon't have a function that
actually independently checkswhat's coming out and giving me
an output of risk that's, thatcan be RTP on.
Matt Coles (20:56):
Think about the com com.
Think about the qualityengineering as, uh, analogy
again here.
Developers write code, qualityengineering validates the code
that they write.
And because they're, they are arisk avoidance function too.
Just not the same risk.
So, there is a check and balancewithin a single engineering
organization for qualityengineering to exist side by
(21:17):
side with developers,
Chris Romeo (21:19):
there's even, there's even another function
that exists in a lot of most bigcompanies now that we haven't
even touched on yet.
There are groups now calledenterprise risk.
They're not part of cyber.
They're not part of IT.
They're looking at risk acrossthe entire organization from
legal risk, regulatory risk, uh,reputational risk.
(21:39):
Cyber security is a small, youknow, it's a piece of what
they're considering.
But I know big companies, I knowpeople that are doing that job
now and they're not part ofcyber, they're not part of the
security stack, because they'rethinking risk.
Izar Tarandach (21:49):
And they wouldn't recognize a line of
code if it beat them in the ass.
Chris Romeo (21:52):
Yeah, but their job is to It's to think though
Izar Tarandach (21:55):
They're interested in that risk index
that comes out of the functionof security that says, Today,
our developmental risk is blah,blah, blah.
Chris Romeo (22:04):
But you're, but part, I mean, part of your
objection here is that we don'thave anybody watching.
I would argue we don't haveanybody watching now.
Izar Tarandach (22:11):
No, but
Chris Romeo (22:12):
If somebody wants to sneak code into something,
most likely they they can getaway and do it today.
Izar Tarandach (22:18):
Yes, but that goes to a different discussion,
which we already sort of touchedupon, which is, we have nice
tools, we don't have tools thatembrace everything, and that
seems to be changing, thatthere's a lot of stuff out there
that's worrying about this kindof stuff, and even sign commits
and whatnot.
I think that my point was that,uh, We keep trying to overload
(22:44):
developers and sorry, Matt,engineers.
And I don't remember which wordI was thinking about using, but
we keep trying to overload themwith the security thing without
me really seeing, uh, no, I'mgoing to contradict myself here.
Matt Coles (23:06):
We've done our job.
We're done.
Chris Romeo (23:07):
Yeah.
Victory victory.
I I
Izar Tarandach (23:10):
This week is really, really easy to get me in
a loop.
The thing here is that I thinkthat engineers should know
security.
But we shouldn't expect them toknow more security than they
need to be able to do theirjobs.
Because at some point securitytakes a jump, both in level, in
(23:32):
depth, and even in breadth, thatwe shouldn't be expecting them
to be able to by themselvesexplore and embrace and own.
So that's why I think that therewill always be a place to the
security professional, at somany different tasks, who will
pick up that thing that happensafter basic development
(23:56):
happened.
And again, Matt, to qualitycontrol, it's a nice parallel,
it's not an analogy, I think,because, you know, in the set of
things that are being soughthere, theirs is a closed set,
security is an open set.
We don't know the size of theset of things that we are
(24:17):
looking for.
They are testing for spec.
We are testing for how can thisgo wrong.
Chris Romeo (24:23):
I mean, they're testing further than spec.
Right.
They're testing for performanceusually through the same
function.
Izar Tarandach (24:30):
So performance there with
Chris Romeo (24:31):
You have a non-perfrmance
Matt Coles (24:33):
with chaos engineering, now have, you know,
you'll have quality engineersrunning, chaos engineering type
tests.
Right.
So
Izar Tarandach (24:39):
Chaos is a new thing and it's great, but still,
and I'm speaking here from aposition of ignorance.
I think that at the end of theday, it comes down to a gorilla
banging on a keyboard, right?
You're just throwing stuff outthere and seeing it, if it
breaks or not.
Matt Coles (24:58):
All my QA engineering friends are going to
be like, ah, what did I justtalk to?
Izar Tarandach (25:01):
Fuzz, fuzz world, right?
I love the idea of fuzzing theworld.
We all know the limitations of afuzzing system.
So, yeah, I think that my bottomline is.
It's great to push things left.
They shouldn't go, not too manythings should go too left and
(25:24):
there will always be a place forthe security professional
somewhere in there.
What can and might and I hopehappens is that we are going to
have to elevate our own game tobe able to answer these coming
challenges in a way thatactually brings value.
Matt Coles (25:44):
know, one, Oh, sorry, Chris, just
Chris Romeo (25:46):
just want to closing arguments.
That was his closing arguments,your
Matt Coles (25:49):
Oh, I actually have one additional point I wanted to
Chris Romeo (25:52):
Go long it's on my side, you're fine to share it.
Matt Coles (25:55):
Oh, I don't know if it's, I just to be on, um, the
question that always comes downto.
should, should secure, shouldsecurity be part of a, um, which
cost center should, should,should security engineering be
part of?
(26:15):
Should it be part of a revenue,you know, revenue stream, or
should it be, uh, part of, youknow, operations?
Izar Tarandach (26:23):
I don't know about you, it's part of my
revenue stream!
Chris Romeo (26:28):
Yeah, it's gotta part.
I mean, it should be part ofrevenue stream.
Too many people treat it as anoperational expense and that's,
I But that's the classic route.
That's the 20, that's what wedid 25 years ago.
Was, it was an operationalexpense.
It didn't make money.
Security is not supposed to makemoney.
If I heard people, how manytimes I've heard that in my
career.
Matt Coles (26:46):
We're revenue protection.
Chris Romeo (26:48):
We're here to protect the, the, the fort and
whatnot.
It's like, no, well, not in a,not in a product focused
company.
Like if you're a product focusedcompany, security, if you, you
don't have revenue if you don'thave security and privacy.
Your revenue goes away in the,in the world that we live in
now.
You can't build a SAST solutionthat doesn't consider security
and privacy.
Izar Tarandach (27:07):
So here's the funny thing, I used to think
like that too.
Until I saw the statistics, andI think that it's still true.
We used to tell people, hey, ifyou, if you have a security
incident, your brand is going tobe impacted and your stock price
is going to be impacted.
It isn't.
They have like blips and theyjust go back exactly to where
they were.
(27:27):
You look at the big ones, Sony,MGM, all that good stuff, or the
big data breaches, some telcosand whatnot.
The stock price just go rightback to where it was.
Chris Romeo (27:41):
Yeah, that's, that is a,
Izar Tarandach (27:45):
Sad,
Chris Romeo (27:45):
it's a sad state of affairs though, right?
Let that, so you're basically, Imean, with that conclusion,
you're saying a company canwillfully slash woefully.
Decide not to focus, not to do,not to focus on security and get
away with it.
Izar Tarandach (28:03):
Yeah.
Matt Coles (28:05):
Well, and then you'll, but then you'll have,
uh, you know, regulatoryenvironments that will say
otherwise, right?
Especially in criticalinfrastructure, private-public
partnerships, etc.
Izar Tarandach (28:15):
But everybody is there.
Chris Romeo (28:16):
Yeah, critical is a whole, whole other kind of
set...
I think people understand therisks of critical
infrastructure.
I don't, I mean, I think mostpeople understand.
Oh, we talked about that before.
I think we concluded most peopleprobably don't understand how
much danger there is the watersupply, for example, or,
Izar Tarandach (28:34):
oh God, don't, don't even go there.
Chris Romeo (28:36):
Yeah.
I don't want to go
Izar Tarandach (28:37):
Just to give you an example, Matt.
You're totally right, and wetalked about this in one of our
first episodes, the utilityvalue of things, right?
But one of the biggest wirelesscarriers, that thing is breached
every day that ends with Y.
Now, they sent me an emailsaying, oh, you are in our auto
pay thing, so in order for youto continue on this, you're
(29:01):
going to have to use a bankaccount rather than a credit
card.
So that took me to having toopen a new account.
with a separate number and aseparate card to once a month
put money into that accountenough to pay that specific bill
and that whole account is justfor that bill.
Why?
Because I don't trust my my bankaccount number, like my everyday
(29:26):
account number, with thatspecific company.
Matt Coles (29:28):
Yep.
Izar Tarandach (29:30):
And they don't care.
Matt Coles (29:32):
And nobody, and, but how many other people would have
done that isolation?
Probably very few.
Izar Tarandach (29:38):
I hope many.
Matt Coles (29:39):
But probably pretty, pretty few.
Izar Tarandach (29:41):
I told everybody that I know works with them, but
at the end of the day the pointis They don't care for, for, for
that point 00005 fee that theyhave to pay for the credit card
every month.
They are going to elevate yourrisk to a point that they don't
care.
(30:01):
Because they're not hit.
Chris Romeo (30:04):
You're going to make me an advocate for
regulation now.
I can't believe that's going tohappen.
By the way, my name is ChrisRomeo and I'm running for
Congress.
Izar Tarandach (30:14):
By the way, my name is Zartan and I'm running
to blah.
Anyway, uh,
Chris Romeo (30:20):
Hey,
Izar Tarandach (30:20):
people know what I'm running.
You people know what I'm runningfor.
Chris Romeo (30:23):
uh, days from
Matt Coles (30:24):
I'm not running unless somebody's chasing me, so
I don't know what you guys aredoing.
Chris Romeo (30:29):
They're going to have be, they're going to have
to be bigger than you two,right?
Like, I'm not running ifsomebody's smaller than me.
Matt Coles (30:34):
Remember, you don't have to be the fastest.
Izar Tarandach (30:37):
just faster than the last guy.
Chris Romeo (30:39):
That's, I that's the, that's the rule of bears,
you know, running, running awaya bear.
You don't have be faster thanthe bear.
Just gotta be faster than yourfriend.
Alright, so did we, did we, Idon't know I didn't get
Matt Coles (30:54):
Oh, we mangled this topic.
Chris Romeo (30:56):
Let me.
Izar Tarandach (30:56):
We, we didn't go left.
Chris Romeo (30:57):
We will, we will, but I have to provide my closing
arguments.
You had your closing
Izar Tarandach (31:01):
Oh yeah, please.
Chris Romeo (31:02):
So my closing argument, um, I mean, when I
think about the valueproposition of taking a separate
organization and meldingtogether, yes, I understand
there will be pain in figuringall those things out.
So that's why I don't think it'sgoing to happen now.
I think it may happen 10 yearsin the future.
It may happen further, but Ithink the future world is one
(31:25):
where.
The security team is dissolvedand is absorbed by various
functions across the business.
So, the AppSec people andProdSec people are in
engineering.
The, uh, people, the kind of,GRC would have to be, it's,
you'd have to take GRC and dropit under finance.
Like I said, leave privacyunder, under legal or maybe
(31:46):
bring privacy engineering.
Back to engineering and let,having the, let legal deal with
the privacy issues on the side.
But I think the valueproposition in this is we, we're
not, there's no longerinfighting.
There is, to Matt's point,there's budgetary alignment
because I can now just align onthe The things that I need to
(32:07):
build us to, to, to build thebest possible product.
And yes, the, the, your evidenceabout data breach is stark and
scary, but it's the truth.
Uh, but I think over timethere's going to be, you know,
when we get a privacylegislation here in the United
States, and I think it's coming,I just don't know when it's
(32:28):
going to happen.
I don't know if it's going to beGDPR for USA, but I think it's
coming.
I think we, we're, we need it.
Um, I think that can drive a lotof the focus here, but I just
think at the end of the day,it'll save once we get this,
once we had this new system upand running, it'll save a lot of
arguments, budgetarydisagreements, uh, and we'll put
(32:53):
things in the right place in mymind, put it where, where it put
those functions where they canhave the biggest impact.
without the potential infightingthat occurs at, uh, between
security teams and various otherfunctions within the business.
And so with that, Your Honor, Irest my case.
Wait, no, I want to call awitness.
(33:14):
I don't know who I would call.
Who would I call as a witness?
I don't I don't have anywitnesses myself.
Um, okay, let's spend a coupleof minutes having some fun with
this idea of shift left.
So, I got this new idea.
I want to bounce this off youguys.
I'm going to start a marketingcampaign.
Okay.
I'm going to try to geteverybody in our industry to
(33:36):
believe something that we weretalking about in the late
nineties, but I'm going tosummarize it in such a way in a
very simple thing.
It's going to be called shiftleft and I'm going to try to get
them to, I'm trying to reinventthis thing right before your
eyes, but that's.
Partially a joke, like, it's, Imean, I, I wrote a post on
LinkedIn.
It's getting a lot of attentionnow and I called it, it's time
(33:58):
to stop shifting left.
Um, and the point of it is like,I remember, do you guys remember
Joe Jarzombek?
From the Department of HomelandSecurity.
Were you guys, you guys wereprobably in kindergarten when,
when Joe was at DHS.
Izar Tarandach (34:13):
I'm older than you.
Chris Romeo (34:15):
This is the late, no you weren't, but you guys
were all about the same age, butlate nineties um, Joe Jarzombek
was at Department of HomelandSecurity and he started this
revolution for security, forsoftware security.
And he called it BuildingSecurity In.
You could go tobuildingsecurityin.gov and Joe
and his team were writing allabout software security and
secure code, you know, things.
(34:37):
And they were, they did a prettygood job.
But, but that's really...
What sh what shift left is likeShift left isn't anything new.
It's the same thing Joe was wastalking about back in the late
nineties and I looked it up.
Okay.
Larry Smith in 2001 was thefirst person to use this term
shift left, and he used it inthe context of shifting left in
(34:57):
the project cycle.
So he was like a program projectperson.
Izar Tarandach (35:00):
Wait, Perl, Perl, Larry Smith?
Chris Romeo (35:04):
Ooh, is that the same one?
Izar Tarandach (35:05):
I'm asking.
Chris Romeo (35:07):
Now I don't know.
Now you've got me now I'm, it'ssuch a common name though.
Larry Smith.
Um, I'm going to,
Izar Tarandach (35:13):
I don't know.
Izar Tarandach is the only thingthat I have to think about how
common it is.
Chris Romeo (35:19):
Yeah, uh, let me do a quick check on that to see my
sources at Wikipedia see if itwas in fact Pearl.
Um, Larry Smith.
Was it Larry Smith that didPerl?
Izar Tarandach (35:31):
No, it was Larry.
Something else.
Chris Romeo (35:33):
Yeah, I don't think it was.
So, but yeah, so I mean at theend of the day, this individual
created, Larry Smith createdthis idea in 2001.
And, you know, it's like 2017 or18 or so when somehow the,
somebody in AppSec found itsomewhere and kinda, I can't
figure out exactly who the firstperson was to use it in the
AppSec space, but it wasn't...
(35:55):
Oh, I thought you were sayingMatt.
Matt was the first one.
Izar Tarandach (35:58):
Larry Wall.
Chris Romeo (36:00):
Larry Wall is the Perl guy.
Yes.
How could I not remember that?
That was my first programminglanguage.
Izar Tarandach (36:04):
Sorry, my bad.
Chris Romeo (36:05):
Try to program.
Let's do some regularexpressions in Perl, shall we?
Come on.
It was so painful.
It never worked.
Okay, I'm, I'm off on a wholeother tangent.
So, I mean, Matt, I know you'vebeen maybe not as fond of the
shift left terminology from itsvery early days.
Give us your, how do you reallyfeel about this, about this term
(36:28):
Shift Left?
Matt Coles (36:29):
Uh, I think I have this quote in our book,
actually, uh, don't, don't shiftleft, start left, uh, right
thinker, think from requirementsonwards, not, uh, and, and I
think we've fallen, wetraditionally, or historically
fall into this trap of securitycomes later, right?
And, and I'm looking at thearticle that you're talking
(36:50):
about from shift left, uh, from2001 from Larry, uh, Larry
Smith, he's talking specificallyabout shifting quality left and
we've adopted this practicefrom, from a security standpoint
for the exact same reasons,right?
So test driven developments andhaving QA be part of the
(37:10):
process.
If you have requirements, whynot involve QA?
Well, again, if you haverequirements, why not involve
security?
Security should be, as astakeholder, should be
introducing requirements andwhen requirements are known,
that's the moment, as soon asrequirements are known, or a
concept has been developed,that's the, that's the moment
(37:32):
when security can start to beeffective and the time where you
can most cheaply impact thesecurity of a system.
And so you really don't want to,in my opinion, you don't really
want to shift left, becauseshift left assumes you're
starting from somewhere, meaningyou started from as far right as
(37:53):
possible, and you're workingyour way through the development
lifecycle back towardsrequirements, but, or, or
towards concept, but along theway, maybe that maybe you stop
at, at, um, whatever yourquality gate is, your code
freeze, your functional freezedate.
Well, you've already builtstuff.
And now you have, okay, what doI, how do I retrofit or how I
(38:14):
patch?
Well, I have to patch after thefact, after, after I ship or I
have to delay shipment.
And that's very costly.
So I'm going to stop now.
I'm going to ship, keep shiftingleft.
I'm going to stop atdevelopment.
Now I'm going to find bugs incode, but I'm, again, I've
already architected a system.
So I'm going to continueshifting left, and I'm now going
to stop at architecture.
(38:35):
Well, but now I've already setmy requirements, so I built an
architecture around thoserequirements, um, and I can't
really retrofit those, or I'vedone concept development, and so
I've gone down a certain pathwhere it may be too late to make
some security alterations.
But if you had started left...
(38:56):
then you could be most effect,effective and most efficient.
from a resource cost, et cetera,standpoint.
Chris Romeo (39:02):
Isn't that just SDL though?
Matt Coles (39:04):
Well, that's what the program, an SDL program or
an SDLC that has security, uh,milestones and activities is how
you, how you implement this.
And, and yes, uh, anorganization that has a good
security, that has a gooddevelopment life cycle that
includes security at each, ateach phase of their life cycle,
uh, has effectively already donethe shifting, right?
(39:29):
Uh, uh, now this getschallenging if, you know, and
again, you know, we're no longerreally in a waterfall model
anymore, right?
Even those companies that dowaterfall aren't doing
waterfall.
But then again, companies thatare doing agile aren't
necessarily doing agile, pureagile anymore either.
So where is left in an iterativeprocess or a spiral or?
(39:49):
So it gets a little bitchallenging there.
But basically anytime you haveconcept and requirements, that's
the time to get securityinvolved because it's the exact
same time you would get, it goesback to, it's like quality.
It's enough like quality thatyou can use it as a, as a
placeholder.
If you're going to involvequality, involve security.
Chris Romeo (40:09):
Yeah, and I think the, the, the, the, the, the
part that's bothered me is thishas been taken as a marketing
term.
It doesn't really mean, like, itstill has its core meaning, but
now you have, if you look invarious sources, you have Shift
Left, you have Shift Right.
You have shift everywhere.
I even found shift up and shiftdown, down references.
(40:32):
where is that going?
Like, we shifting up to the moonand you're going to run a secure
product on the moon?
Matt Coles (40:39):
Actually,
Izar Tarandach (40:39):
Don't give them ideas, please!
Matt Coles (40:41):
We do, we do, well, so if, if we were going to look
at those terms, I mean, we, wesee this with shifting down the
stack or up the stack, right?
So traditionally, software,software security is software
security, it's applicationdevelopment, as opposed to
moving into the platform ormoving into the hardware, right?
(41:01):
And so you're moving down thestack, I guess don't
Chris Romeo (41:04):
you legitimizing their term here?
Matt Coles (41:07):
No, absolutely not.
Uh, just at least, or, or if ithasn't been coined, then maybe
I'm coining it now, but, uh,
Chris Romeo (41:14):
No, people have, I've found using shift up and
shift down, but they didn'treally have a good explanation
for what it meant.
They were just, it was justanother kind of marketing.
Let's, let's, let's do somethinga little different than what the
rest of the pack is doing,shifting left by we're going to
shift up or shift down and
Matt Coles (41:31):
Yeah.
I can imagine shifting down as alot, a lot easier to as a
concept.
Like if you are starting withapplications already, there,
there is no up, right.
But there's probably a down.
Izar Tarandach (41:45):
There's always a down.
Matt Coles (41:46):
And, and there could be an out, I guess there could
be an out as well, you know,looking
Chris Romeo (41:50):
Shift out?
Matt Coles (41:51):
Well, looking beyond your application, Now to the
things around it, yourecosystem, customer base.
Chris Romeo (41:58):
I hope there aren't any marketers listening to this
and they're like, Ooh, that's agood idea.
We should shift out.
That's our new campaign.
We're gonna, our product shiftsout right out of the building.
Like, it's not even thereanymore.
Matt Coles (42:07):
Need, we need some, it's some, it's some, it's some
four dimensional chess thing...
Izar Tarandach (42:10):
We call it Elvis!
Matt Coles (42:11):
We need some four, we need need a fourth dimension
there
Chris Romeo (42:13):
Shift Elvis.
Elvis has left the building.
Matt Coles (42:17):
Well, instead of, of directional, instead of, you
know, directional, so now weneed time.
So shift, shift later.
Or shift sooner or...
Chris Romeo (42:26):
Why can't we time shift?
Izar Tarandach (42:29):
But why do we have to shift at all?
Like it goes together with whatwe were talking behind,
Matt Coles (42:34):
As a Rocky Horror Picture Show, uh, quote going on
here.
We need to get introduced
Chris Romeo (42:38):
Matt's singing.
Izar Tarandach (42:39):
To tell you the truth.
Okay, confession time.
The first time that I heard theterm shift left as applied to
security to development, theimage that I had in my mind was
a bunch of developers doing theshuffle.
Matt Coles (42:53):
The time warp.
It's a time warp.
Izar Tarandach (42:55):
It is not something I want to ever see
again.
Matt Coles (42:58):
As opposed to Thriller.
We could do the Thriller.
It's it perfect for Halloween!
Chris Romeo (43:03):
Oh, the time warp.
Izar Tarandach (43:06):
But, uh,
Chris Romeo (43:08):
Whew.
Izar Tarandach (43:08):
I think that where this goes together with
what we were talking before,like, we already touched it a
bit in there, is that, uh, firstof all, it sounds good.
Like, you say shift left, peoplecan have this mental image of
things tipping towards thebeginning of a timeline and
(43:30):
whatnot.
So, it's useful as a mentalframework to think about how am
I organizing my pipeline andstuff like that, right?
But, I think that every timethat we say shift left, again,
we...
We.
People.
All of us.
The industry.
I love that term, the industry.
It sounds like the mafia.
(43:51):
Uh, the industry, it, it, it, itjust doesn't, it's very easy to
say shift left.
And it's very easy to say myproduct, my process, my way
shifts left.
But what are we shifting?
(44:12):
How much are we shifting?
How are we proving that it'sshifting?
And how are we showing that thefact that we shifted gives you a
better result?
That we haven't quite worked outyet.
Matt Coles (44:21):
The problem is shift is a relational term.
When you shift, you start fromsome place and you go to some
place.
And when you say shift left,what are you shifting and where
did you start from?
We make the assumption when yousay shift left, it means, well,
I didn't shift left originallyand now I'm going to shift left,
so I probably wait until theend.
(44:43):
As opposed to, well, I could beshifting from the middle
somewhere and shifting left.
Izar Tarandach (44:48):
No, I, I think that you put it well, when, when
it reminded us that both boltingon security is very much still a
thing, unfortunately for, forall the efforts that we have
done in the past years.
And, and I think that youpointed out to that people
adopted the shift left mentalitybecause we were so much bolting
in, but now that, with what youjust said to me comes the
(45:08):
question, how much is gettingaway from bolting things on in
the end?
How much of that, how much ofshifting from that is a
meaningful shift to the left?
Chris Romeo (45:23):
Now we're
Matt Coles (45:23):
I think unless you're, unless you're
introducing it, jumping in atrequirements and concepts,
you're still bolting on.
Izar Tarandach (45:30):
Because that's
Matt Coles (45:30):
You're going to have to, you're going to have to bolt
on, right?
You're going to have to bolt onat the end because you're going
to miss stuff, right?
Izar Tarandach (45:36):
Won't we have to bolt on something almost always
because there will always be afinding that happened after the
thing is out and deployed?
Matt Coles (45:49):
Well, so I wouldn't say patching.
I would not say patching asbolt-on.
Izar Tarandach (45:52):
No, patching no, but changing stuff at the end.
Matt Coles (45:56):
Well, so here's an interesting question on that.
So bolting on, I think, in mymind, at least, is seen as a,
oops, I forgot to, I forgotabout this thing.
And now somebody reminds me Ineed to do it.
And so I'm going to bolt it on.
Or as opposed to, I have aconcept and, uh, I want to make
(46:17):
this thing modular.
And so this is a new and now anadd on addition that can improve
capability or, or whatever, andI, and maybe I can charge for
extra or not.
Um, but, but you making aninformed decision.
So a lot of our work is aboutmaking informed decisions, risk
decisions, or businessdecisions.
And so if I.
(46:38):
If an organization or, or, youknow, product team, for
instance, um, makes a decisionto bolt on as an add on
capability, that may be stillacceptable compared to the
traditional bolt on of, Oh, weforgot.
And now we're in recover, we'rein reactive mode.
So proactive bolt on versus areactive bolt on.
Izar Tarandach (47:01):
So let me put something out there, and this is
going to be convoluted becauseit's that kind week, so I
apologize from the beginning.
10 years from now, when we haveapplication and development and
deployment security peopleinside the engineering, because
(47:28):
they have shifted left so much,if at the end of the pipeline it
is found that, hey, we forgotsomething or we didn't think
about this at the securitylevel, that means that What was
needed, the knowledge or thefinesse needed to figure out, to
identify that thing wasn'tpresent in the engineering
(47:52):
framework that created thething.
So it's almost like we needsomebody with even more of a
security background from thosepeople that are in the pipeline
to say, whoops, we forgot thisthing, or hey, I just thought
about this threat, or I justthought this use case.
So have, have we just like.
(48:12):
close the wheel and going backto where we started and packaged
everything.
Matt Coles (48:17):
No, and I'm going to use another quality analogy
here.
When you make a mistake and youship something and you discover
that you ship something, you gothrough an RCA process, right?
Some sort of quality controlprocess.
And as long as that process isconsistently applied, or at
least consistently devised,right?
(48:40):
Um, then, then that would worktoo.
In other words, you don'tnecessarily need to have the
foreknowledge that to know thatyou missed something because
regulations will change orcustomers will ask for something
new or somebody will decide touse your product in a way that
wasn't originally intended forand now it's suddenly it is
intended for.
(49:01):
Um, you just have have theprocess to, to bring that
feedback back into the, intoyour life cycle and make the
adjustment adjustments.
Izar Tarandach (49:09):
But, but the trigger for that is an
exception.
For that is, as you said, itwent out and somebody corrected
us.
What I'm is, in between, inbetween that, that event of it
going out and somebody beingable to create an exception,
there needs to be a differentlevel that looks at different
things that probably we don'tlook at today to say, hey,
Matt Coles (49:31):
Uh,
Izar Tarandach (49:31):
be the last gate before this thing shipped.
Matt Coles (49:34):
So I wonder, we do, I think in engineering
organizations, we, we call themtechnologists, right?
We have CTO organizations thatdo, advanced R&D, you know,
advanced concept development.
I, I think you have thoseopportunities to re, to take
those functions, the outcomes oftheir work and feed them into
(49:54):
this process.
And if you...
Izar Tarandach (49:56):
Oh god, that's what they do?
I never knew.
Matt Coles (49:59):
I think so, uh, and so if you put security into
those functions, so if you takethe security folks and put them,
like take security researchersand put them in that function
and have appropriate feedbackand communication channels,
right, That, that may solve theproblem that you're, you're
highlighting.
Izar Tarandach (50:19):
God, I disagree with that at so many levels.
Matt Coles (50:23):
Chris, do I have ally here?
Izar Tarandach (50:24):
CTO organizations, in my experience,
they are some kind of like thegods in the Olympus saying we
are looking forward 20 years andwe are talking quantum
cryptography and we are talkinghomomorphic, uh, uh, operations.
Matt Coles (50:39):
We've
Izar Tarandach (50:39):
While you, you poor people are PHP code.
why do people, you poor peopleare still writing PHP code.
Don't, don't, come bother uswith your thing.
We, we, we are somewhere else.
Chris Romeo (50:52):
CTO organizations in the context that we're
talking about them here, let'sbe honest, a good part of their
work is outbound.
They're out speaking atconferences and they're thought
leaders that like this ideawhere you can have 75 CTOs
inside of an org...
you know, it's, it's a chief,you're a chief technical
officer.
There's only one CTO in acompany.
(51:15):
And maybe, I mean, you, maybeyou have one at the business
unit level.
That's truly making technologydecisions, but I see a lot of
the folks that, that wear thetitle of CTO.
Now they're not really, they maybe influencing the product a
little bit, but they'reprimarily out trying to
demonstrate technical dominancein the industry of ideas and
thoughts and things there, youknow.They're like a developer
(51:38):
advocate, developer relationstype of role.
But I think, you know, kind of,I want to wrap whole thing up
here and try to put a bow on it.
Shift left, build security inwhatever we want to call it.
It's not perfect.
It's never going to be perfect.
Like even if you, and I'm noteven going to say shift left,
(52:01):
but if you built security infrom the very beginning, you
started left, to Matt's point,it still doesn't, it's still,
it's still a process that'sbeing executed by people that
aren't perfect.
That's being, that is executingtools that are not perfect.
That's, uh, building softwareand hardware that's not perfect.
So at the end of the day, Theseare preventative measures.
(52:24):
There are things that we can doto try to get ahead of as many
things as we possibly can, butwe're still going to have
challenges.
There's still going to beproblems that come out of it, no
matter where you start in theprocess.
And what we've learnedcollectively over decades of
experience, all the way back towhat Jarzombek was doing at DHS
is if you start thinking aboutthe security things when you
(52:45):
start building the product,you're going to have a better
security outcome when you ship.
That's really all that matters.
And I what's happened in ourindustry is this shift left has
just been, it's beenmanipulated, weaponized, and
used as a, as a term for peopleto try to demonstrate that their
(53:05):
product is the best one outthere.
And I think they missed themark.
I think they, I think they tooksomething and they twisted it.
And they didn't, it doesn'treally, at the end of the day,
it doesn't really say anythingabout what you do because you
don't, you don't really shiftleft.
Your, uh, your SAST tool doesn'tshift left.
Izar Tarandach (53:23):
I think that when you say, when you say miss
the mark, I think that's, that'sexactly the thing.
When you point something way toomuch to the left, you will miss
the mark that's in front of you.
And that's what keeps happening.
Miss, like shift left became amarketing thing.
I'm leftier than you in thetimeline.
So therefore I am better thanyou.
(53:45):
I'm saving more money than you.
Matt Coles (53:47):
It's kinda like a of fr...
It's kinda like a game ofFrogger.
You're shifting across andthere's stuff coming from the
side.
Izar Tarandach (53:54):
Yep,
Chris Romeo (53:55):
I.
Izar Tarandach (53:56):
And that's why I said we're shifting ourselves
right off the table.
Chris Romeo (53:59):
I mean, I tell what, with that, there's no way
we can continue.
We're going to, thanks folks forjoining us at security table.
We have to wrap with thatanalogy.
Shift left
Izar Tarandach (54:08):
Wait, wait, wait, wait.
What was the Frogger song?
yeah, yeah,
Matt Coles (54:10):
Oh, no.
Izar Tarandach (54:14):
yeah, yeah, yeah.
I thinking of the Pac Man one.
No, yeah, you're
Matt Coles (54:18):
so you get run over and it.
Chris Romeo (54:19):
Yeah.
Izar Tarandach (54:20):
Splat.
Chris Romeo (54:21):
That's what happens when you shift left too much,
you get ran over and squashed.
So, all right, folks, thanks forlistening to security table.
Hopefully you found some, somevalue in this conversation.
Um, I think we ourselves, we'vemade some progress moving
forward.
So, uh, we look forward tojoining, you joining us again in
the future weeks to hear usdebate, discuss, and pick apart
(54:44):
just about anything we can thinkof in the world of security.
So thanks for listening.
Hey folks, welcome to The Security Table.
This is Chris Romeo joined byIzar Tarandach and Matt Coles,
and we are going to jump rightin, skip all the witty banter,
so you can just remember wittybanter from a previous episode,
uh, that usually happens here,uh, in this little segment.
We're going to dive right backinto where we picked up from, or
picked up from, where we leftoff from, be the right
(00:32):
expression, where we left off inthat last episode, and I kind of
left off at the cliffhanger.
But I gave you guys a week tothink about this, so I'm, I'm
expecting some brilliant, uh,solutions have been crafted
inside of your brains.
So the issue that I left us withat the, at the conclusion, which
was based on an interview I didwith somebody else, and kind of
(00:54):
some of their opinions.
The future of applicationsecurity.
I want to offer a hypothesis, Iguess.
Maybe not a hypothesis, just aprediction.
I think that in the next numberof years, I'm not sure if it's
going to be 5 or 10 or how longit's going to take, but I think
application slash productsecurity is going to be eaten by
(01:16):
development.
I think it's going to beabsorbed.
And when I say eaten, I meanit's going to be absorbed.
Um, because, and the premisebeing, we have a lot of
friction.
in our day here between securityand engineering.
Different levels of friction, Iwould say, in different
(01:37):
companies, but I've seen somecompanies where the friction
level is, there might be a fighthere shortly, all the way down
to, eh, we just, you know, wejust don't really listen to what
they say and stuff like that.
So I'm imagining a world wheresecurity becomes part of
engineering and then Everybodyreports to the same boss, the
(01:59):
CTO, the VP of engineering, thewhatever.
Uh, and so let's dive in there.
I want to see, what do you guysthink about this?
Do you think this is possible?
Do you think it's irrational?
Do you, where does it sit on thescale here, Matt?
You go first.
Matt Coles (02:14):
Well, um, so first rule of Security Fight Club is
you don't talk about SecurityFight Club.
Um, so, uh, it's interestingactually, uh, it's an
interesting premise.
Uh, I, I may answer it with aquestion or two.
So.
Quality engineering is part ofengineering.
(02:34):
It is not a distinct function,although it's not, well, maybe
not best done in by developers,you know, uh, cause you do want
to check and balance in place,but it's part of an engineering
discipline.
And so the requisite knowledgeand experience and training and
capability can all be served outof the engineering organization,
(02:57):
right?
That exists, has existed fordecades, right?
Uh, um, certainly in ourindustry.
So.
Uh, both hardware and softwarerelated, right?
You can do, have qualityengineering and software
engineering as side by sidefunctions.
What you're suggesting is makingsecurity engineering one of
those functions.
Uh, and in that regard, forcertainly for product
(03:22):
development, I, it soundsreasonable.
Are we there yet?
Probably not, uh, but, but are,should we be there?
Uh, that's an interestingquestion, uh, because what that
means is that engineeringorganizations would have all the
functions within them tobasically govern their own
(03:43):
destiny, uh, and, and, They knowalready have structures in place
for handling requirements andreporting and, uh, and, you
know, and working with otherparts of the business.
Do you really need a check andbalance on from security?
Uh, is there any benefit tohaving security outside of that
(04:03):
organization is what you'reproposing?
Uh, so actually reallyinteresting.
I wonder, I wonder if that wouldwork.
Chris Romeo (04:10):
Governance is where I, is kind of the, one of the
sticking points, because...
Matt Coles (04:14):
Well, also, uh, response, uh, so things like,
you have customer support thatis not part of, of the
engineering function, right?
People to handle fielding bugsand working with customers.
So, similarly, wouldvulnerability and incident
response be outside of thatfunction?
So, would it be as...
Chris Romeo (04:30):
Maybe they become a part of customer success or
customer service.
Maybe become a function there.
Matt Coles (04:34):
Right.
So, but, but either way,security as a whole probably
can't be consumed by theengineering organization, but it
sounds like, I mean, if you usequality as an, as a, as a, by
comparison, engineering alreadycontains quality functions.
Could it contain securityfunctions too?
Maybe.
And that might really work.
(04:55):
Izar, what do you, what are youthinking there?
Izar Tarandach (05:01):
I have to agree with you and the thing is that
for for a long time we have beenusing that pithy thing that says
that if we do our job bad or jobright then we're going to work
ourselves out of a job and weusually say that when we're
training developers and ortraining other security people.
(05:22):
And for a while, I think it wascute, but now we are seeing the,
we are seeing what success lookslike looming over us.
But, uh, I think that one thingthat I can for sure say is that
if that ever happens, and asMatt says, I said that, I think
that for a certain portion ofthe work, that's definitely the
(05:46):
way that things are going.
It's not going to happen becauseof tools.
It's not going to happen becausethe magical AI in the sky is
doing its whole thing.
It's going to happen because atthe end of the day, developers
are going to understand thatsecure code is quality code.
(06:06):
They're going to incorporate thethings that we have been talking
for years upon years of all theprinciples and all the
specifics.
And all that stuff.
But at the same time, there willbe other developers who will
develop new ways of things thatcould go wrong.
So there will be aspects ofsecurity that will still be very
(06:32):
much needed, namely designarchitecture.
And I think that at the end ofthe day, what we're going to see
is it's a sort of acommoditization of security
knowledge, where developers knowjust enough to get by day after
day without perhaps, uh,security and application
(06:55):
security engineers sitting ontheir shoulder.
But there will still be securityfunctions out there beyond GRC,
which I completely agree withMatt.
It's always going to be aproblem.
And, uh.
Not a problem, but it's alwaysgoing to require more expertise
than a developer probably wantsyou to put there.
(07:16):
One thing, though, that I wantto throw in the mix.
Throughout this whole cyclewhere we teach, we teach, they
learn, we measure, we get toconclusions.
We never really got to ask them,do you want to do this?
And I have the feeling that mostdevelopers, I won't say most,
(07:41):
but many...
A large percentage of thedevelopers that I have met
through the years are not reallyinterested in getting security
as a process, as aresponsibility to themselves.
Matt Coles (07:57):
Uh, can we just, uh, talk a little bit about
DevSecOps then?
Um,
Izar Tarandach (08:03):
Do we have to?
Matt Coles (08:05):
Well, so for, so for, so first off, let me, let
me just jump in a little bit,something you're describing.
Yeah, you use the worddevelopers a lot.
Um, in when my description, whenI was talking about this, I
wasn't thinking developersspecifically.
I was thinking engineeringorganizations.
So that includes non developerswithin that organization.
Um, I agree with you, mostengineers probably don't want to
(08:28):
take on security responsibility,although DevSecOps, we kind of
give them that responsibility.
Uh, although I, I think at timesI, I, At times, I have a sense
that it's, give them a lot ofresponsibility, but not a lot
authority or capability.
Uh, and so, um, and that's notuniversally, you know, it's not
universal, but it's, it'ssometimes there's observations
(08:51):
there that, that seems tosuggest that.
Uh, but the, um, The notion thatan engineering organization, not
necessarily the engineersthemselves, may take a function,
take that function, right?
We don't, developers get taughthow to write quality code, but
they don't often get taught howto do quality engineering.
(09:15):
Likewise, we would, we trainengineers how to write secure
code, but not necessarily on thefunction of, of ensuring
security.
Izar Tarandach (09:24):
There is
Matt Coles (09:24):
And if you look at it that way.
I think that's where theengineering organization as a
whole can pick up those, thosetasks, as opposed to having a
dedicated security organizationsort of do it for them.
And, and that's where I was,that's where I was going with.
So I just want to clarify thatbecause developers may want to
take on that responsibility orthey may not, but the
(09:46):
engineering function as a wholeshould.
Chris Romeo (09:49):
And when I, when I think about this model, I'm not
envisioning what we think of asthe people that are on an AppSec
team or on a ProdSec team todayas going away.
They just don't report to theCISO anymore.
They're part of the engineeringorganization and they're
deployed.
So it's not like we don't, it'snot like we're taking all the
security people and saying,you're just done.
(10:10):
The developers are replacingyou, the product managers are
replacing you, the programmanagers are replacing you.
We're bringing them into thefold.
It's just we don't have, we'reeliminating, one of the big
pluses of this is we'reeliminating any potential
political fighting between twoseparate organizations by
putting them under oneorganization in one management
(10:31):
chain that can make riskmanagement decisions at the end
of the day.
They can, they can decide whatare we going to do for security.
And I think we've come farenough in our history.
Like this would have, would nothave worked 20 years ago.
Would not have worked 10 yearsago.
And when I first started insecurity, people were still
saying, Hmm, no.
Like we, we'd go to engineering,they'd be like, you need to do
this.
No, we don't, we don't have todo that.
(10:52):
We're not there anymore.
Right.
And that's why I can start tothink about this new world
approach.
Because I know I don't havepeople that are just going to
tell me we're not doing it.
Matt Coles (11:01):
They have to be equal partners to your
organization, again, along thesame lines of quality
engineering and other aspects,and, but it would certainly help
with things like funding, right?
So you'd have, you know, feweropportunities for cross charging
and whatnot, uh, and, andcertainly would help with
reporting.
Uh, and, uh, the only downsideis the check and balance part,
(11:24):
right?
The GRC function, audit, uh, wetalked about vulnerability and
instant response, um, wherethose functions go, how they're
managed, right?
There's still some cross crossorg communications that have to
happen.
Chris Romeo (11:38):
So that's one threat.
You've identified one potentialthreat.
Izar Tarandach (11:41):
There is more.
So again, in a perfect world,assuming that the cow is a
perfect sphere, that wouldreally work.
But now throw into the mix thefact that if you get that team,
bring it into the engineeringteam.
(12:04):
you are most probably going toput them under, as Matt said,
engineering management.
Now, engineering management hasvery set ways of measuring
performance, measuring goals,measuring achievements, that
don't really mesh with the waythat we measure things at
security.
And sometimes that's even a verybig source of friction.
(12:28):
So now we are taking anoverloaded management level,
giving them a bunch of peoplethat speak a completely
different language.
And saying, for the good ofeverybody, play nice, kids.
Historically, it doesn't worklike that.
Chris Romeo (12:45):
Historically.
But we're, we're, we're, we'rereaching new places now in
Izar Tarandach (12:51):
that's going be a new place that has nothing to
do with security itself, but alot to do with management, uh,
uh, culture.
And I'm not touching that onewith, uh...
Matt Coles (13:05):
Well, let's talk about the language.
Let's talk about that languagethat you were talking, that you
were describing, right?
So the language of securitytoday versus if, imagine a world
where security is part of theengineering function, Where,
like, how different, first off,would it be the same language as
we have today?
And, and if not, what might itlook like?
(13:30):
So, and I'm thinking, and again,I'm using quality as a, as a
analog here, um, right?
Developers talk about, you know,there's code complexity, but
there's also code velocity, um,you know, number of lines of
code, uh, produced and, andfeatures implemented, etc.
Well, quality engineering isabout, You know, test case
(13:52):
developed, you know, casesdeveloped, cases executed, pass
rate, uh, or fail rate, um,defects of quality defects or a
performance defects, or, youknow, basically failure to meet,
uh, requirements of validationand verification.
If security was part of the, um,as part of the engineering
(14:17):
function, why wouldn't they bejust translated into those
terms?
Where, where would there need tobe, what translation would need
to happen, do you think?
Izar Tarandach (14:29):
Let me give you an extreme example, okay?
And maybe even a very weak one.
But let's say that you justbrought a security researcher
slash pen tester into the teamand that person just went over
what came out of the sprint didtheir thing.
Now they look at their managerand at their engineering manager
(14:49):
and say I didn't find anything.
Now the engineering manager willsay oh, that's good we don't
have any risks.
We don't have any problems,right?
And the security person is goingto look at them and say I didn't
say that I said I didn't findanything.
Chris Romeo (15:04):
But doesn't that force a cultural shift either
break or it will make thingsvery successful?
Izar Tarandach (15:12):
What is cheaper?
To do a cultural shift or forthe manager, for the engineering
manager to say he didn't findanything, there's nothing to be
found and we are good, ship it.
Matt Coles (15:25):
So, uh, I'm going to ask a naive question here.
When this researcher did theirresearch, did they follow a
process for this?
And again, about, I'm thinkingabout the, let's talk about, if
we talk about QA for a moment,right?
So QA runs through all theirtests and doesn't find any bugs.
They go to their engineeringmanager and go, we didn't find
(15:46):
any bugs.
We ran all these tests.
We had X amount of codecoverage, right?
Maybe we covered 80 percent ofthe code.
We didn't find any bugs.
Engineering manager willprobably look at that and go, we
have quality code.
Izar Tarandach (16:00):
But QA testing for spec.
They're testing a positive case.
Yes, the code does what the specsays that the code should be
doing.
The security person is doing thenegative case.
Hey, I clicked some stuff and itexploded.
If it doesn't explode, does itmean that it won't explode if I
click two things?
No, it doesn't.
Chris Romeo (16:18):
In your example, though, you're, you're
extracting an isolation mode,meaning you're not considering
any of the other things thatwould be happening in any
process that would be part ofany program any of the three of
us would build.
We wouldn't rely...
Izar Tarandach (16:32):
If we run DAST, we know that everything works,
but, uh,
Matt Coles (16:35):
Boom!
Chris Romeo (16:37):
And we'd have WAFs, WAFs blocking our traffic and
the hampster wheel...
Matt Coles (16:42):
You would be scanning scanning and fixing
Chris Romeo (16:44):
scanning and fixing
Izar Tarandach (16:45):
AI reading the code.
Chris Romeo (16:47):
Up issues.
But the point is, though...
We wouldn't, this wouldn't be anisolated incident where the pen
test that like the only thingthe engineering manager has as
data is the result of the pentesters work.
And now they're going to say,we're good.
No, they're going to have, youknow, pipelines that are part of
code builds happening that aredoing software composition
analysis.
They're doing SAST.
(17:08):
They're doing, um, other, youknow, their runtime stuff
Izar Tarandach (17:13):
so now you asking the engineering manager
to become aware of those things,understand their limitations,
understand the output they putout, interpret all that, and
come out with a risk assessmenton top of all the other things
that they already do every day.
Chris Romeo (17:30):
No, I mean, I'm thinking let's put a security
person on their team.
Like they're not experts in Theydon't, don't
Izar Tarandach (17:37):
Which at the end of the day will come to the
engineering manager and say,looking at all the stuff that we
have, we didn't find much.
So the guy is going to ask, arewe secure?
That means that we're secure,right?
And the guy says, I didn't saythat.
Chris Romeo (17:51):
Engineering managers don't ask that.
That's executives that ask that.
Izar Tarandach (17:53):
But the language is different.
The language is different.
Chris Romeo (17:57):
Immediately go up to, are we secure?
Izar, are we secure?
Izar Tarandach (18:02):
We don't measure things with the same stick and
we don't take risks with thesame stick, right?
In our book, Matt and I saidthat engineering moves at the
speed of innovation and securitymoves at the speed of caution.
You can't drive the same car attwo speeds at the same time.
Chris Romeo (18:25):
Well, we just have to make a super highway and we
got to merge everybody togetheronto the same highway.
Izar Tarandach (18:29):
But you know what this whole conversation
reminds me of?
Your last LinkedIn post.
Because basically what we'resaying here is, hey, we have
achieved left maximum, criticalmass, right?
We went left all the way.
I say we have shift left so muchthat we are falling off of the
(18:51):
table.
I mean, it's, it's...
Chris Romeo (18:55):
So we're falling left.
That's a new one.
I haven't heard that one yet.
So, um, yeah.
So, I mean, I think
Izar Tarandach (19:02):
it, yeah.
Chris Romeo (19:03):
just to, to kind of wrap up, put a bow on the future
of AppSec and then we cantransition and talk about shift
left.
Uh, you guys have challenged mythinking in good ways here
because you made me think, Matt,specifically about like where
does GRC sit?
Where does audit sit?
(19:23):
And I think it's possible forthose things to live on in the
finance organization.
I think it's possible.
Matt Coles (19:28):
Or legal.
Chris Romeo (19:29):
Were just going to do away with a separate security
department.
We know that privacy is alreadypretty much embedded with the
legal side.
By, that's just by nature wherethey've landed.
Izar Tarandach (19:38):
Sad as that is.
Matt Coles (19:40):
And, and, and by the way, we're not talking about
things like IT security, right?
We're talking about AppSec,development security, ProdSec...
Chris Romeo (19:47):
I mean, InfoSec should, like, you could even
pull this thread more and saywhy does InfoSec exist?
Why doesn't it live in IT?
Why isn't, why don't we justhave people in IT thinking about
security?
Versus having a separate groupthat thinks about security
versus a group who just thinksabout building network
architectures.
Why do we have two separateteams doing this at the same
(20:08):
time?
Izar Tarandach (20:09):
We keep talking about this and I keep thinking
who watches the watchers.
But not, not in terms of whowatches people doing stuff,
but...
There's a, there's a functionhere that the output is risk.
Chris Romeo (20:23):
That's governance.
That's GRC though, right?
Izar Tarandach (20:24):
no, no, no, no, no, no, no, no, no.
People are building stuff.
That stuff carries risk.
And we are saying, rather thanhaving two teams, one that
builds and one that checks whatgot built, let's get the one
that checks what got built andput it together with the one
that builds.
And, and, and let's have it likebe consumed by all the processes
(20:44):
in that team.
And to me it goes back to, now Idon't have a function that
actually independently checkswhat's coming out and giving me
an output of risk that's, thatcan be RTP on.
Matt Coles (20:56):
Think about the com com.
Think about the qualityengineering as, uh, analogy
again here.
Developers write code, qualityengineering validates the code
that they write.
And because they're, they are arisk avoidance function too.
Just not the same risk.
So, there is a check and balancewithin a single engineering
organization for qualityengineering to exist side by
(21:17):
side with developers,
Chris Romeo (21:19):
there's even, there's even another function
that exists in a lot of most bigcompanies now that we haven't
even touched on yet.
There are groups now calledenterprise risk.
They're not part of cyber.
They're not part of IT.
They're looking at risk acrossthe entire organization from
legal risk, regulatory risk, uh,reputational risk.
(21:39):
Cyber security is a small, youknow, it's a piece of what
they're considering.
But I know big companies, I knowpeople that are doing that job
now and they're not part ofcyber, they're not part of the
security stack, because they'rethinking risk.
Izar Tarandach (21:49):
And they wouldn't recognize a line of
code if it beat them in the ass.
Chris Romeo (21:52):
Yeah, but their job is to It's to think though
Izar Tarandach (21:55):
They're interested in that risk index
that comes out of the functionof security that says, Today,
our developmental risk is blah,blah, blah.
Chris Romeo (22:04):
But you're, but part, I mean, part of your
objection here is that we don'thave anybody watching.
I would argue we don't haveanybody watching now.
Izar Tarandach (22:11):
No, but
Chris Romeo (22:12):
If somebody wants to sneak code into something,
most likely they they can getaway and do it today.
Izar Tarandach (22:18):
Yes, but that goes to a different discussion,
which we already sort of touchedupon, which is, we have nice
tools, we don't have tools thatembrace everything, and that
seems to be changing, thatthere's a lot of stuff out there
that's worrying about this kindof stuff, and even sign commits
and whatnot.
I think that my point was that,uh, We keep trying to overload
(22:44):
developers and sorry, Matt,engineers.
And I don't remember which wordI was thinking about using, but
we keep trying to overload themwith the security thing without
me really seeing, uh, no, I'mgoing to contradict myself here.
Matt Coles (23:06):
We've done our job.
We're done.
Chris Romeo (23:07):
Yeah.
Victory victory.
I I
Izar Tarandach (23:10):
This week is really, really easy to get me in
a loop.
The thing here is that I thinkthat engineers should know
security.
But we shouldn't expect them toknow more security than they
need to be able to do theirjobs.
Because at some point securitytakes a jump, both in level, in
(23:32):
depth, and even in breadth, thatwe shouldn't be expecting them
to be able to by themselvesexplore and embrace and own.
So that's why I think that therewill always be a place to the
security professional, at somany different tasks, who will
pick up that thing that happensafter basic development
(23:56):
happened.
And again, Matt, to qualitycontrol, it's a nice parallel,
it's not an analogy, I think,because, you know, in the set of
things that are being soughthere, theirs is a closed set,
security is an open set.
We don't know the size of theset of things that we are
(24:17):
looking for.
They are testing for spec.
We are testing for how can thisgo wrong.
Chris Romeo (24:23):
I mean, they're testing further than spec.
Right.
They're testing for performanceusually through the same
function.
Izar Tarandach (24:30):
So performance there with
Chris Romeo (24:31):
You have a non-perfrmance
Matt Coles (24:33):
with chaos engineering, now have, you know,
you'll have quality engineersrunning, chaos engineering type
tests.
Right.
So
Izar Tarandach (24:39):
Chaos is a new thing and it's great, but still,
and I'm speaking here from aposition of ignorance.
I think that at the end of theday, it comes down to a gorilla
banging on a keyboard, right?
You're just throwing stuff outthere and seeing it, if it
breaks or not.
Matt Coles (24:58):
All my QA engineering friends are going to
be like, ah, what did I justtalk to?
Izar Tarandach (25:01):
Fuzz, fuzz world, right?
I love the idea of fuzzing theworld.
We all know the limitations of afuzzing system.
So, yeah, I think that my bottomline is.
It's great to push things left.
They shouldn't go, not too manythings should go too left and
(25:24):
there will always be a place forthe security professional
somewhere in there.
What can and might and I hopehappens is that we are going to
have to elevate our own game tobe able to answer these coming
challenges in a way thatactually brings value.
Matt Coles (25:44):
know, one, Oh, sorry, Chris, just
Chris Romeo (25:46):
just want to closing arguments.
That was his closing arguments,your
Matt Coles (25:49):
Oh, I actually have one additional point I wanted to
Chris Romeo (25:52):
Go long it's on my side, you're fine to share it.
Matt Coles (25:55):
Oh, I don't know if it's, I just to be on, um, the
question that always comes downto.
should, should secure, shouldsecurity be part of a, um, which
cost center should, should,should security engineering be
part of?
(26:15):
Should it be part of a revenue,you know, revenue stream, or
should it be, uh, part of, youknow, operations?
Izar Tarandach (26:23):
I don't know about you, it's part of my
revenue stream!
Chris Romeo (26:28):
Yeah, it's gotta part.
I mean, it should be part ofrevenue stream.
Too many people treat it as anoperational expense and that's,
I But that's the classic route.
That's the 20, that's what wedid 25 years ago.
Was, it was an operationalexpense.
It didn't make money.
Security is not supposed to makemoney.
If I heard people, how manytimes I've heard that in my
career.
Matt Coles (26:46):
We're revenue protection.
Chris Romeo (26:48):
We're here to protect the, the, the fort and
whatnot.
It's like, no, well, not in a,not in a product focused
company.
Like if you're a product focusedcompany, security, if you, you
don't have revenue if you don'thave security and privacy.
Your revenue goes away in the,in the world that we live in
now.
You can't build a SAST solutionthat doesn't consider security
and privacy.
Izar Tarandach (27:07):
So here's the funny thing, I used to think
like that too.
Until I saw the statistics, andI think that it's still true.
We used to tell people, hey, ifyou, if you have a security
incident, your brand is going tobe impacted and your stock price
is going to be impacted.
It isn't.
They have like blips and theyjust go back exactly to where
they were.
(27:27):
You look at the big ones, Sony,MGM, all that good stuff, or the
big data breaches, some telcosand whatnot.
The stock price just go rightback to where it was.
Chris Romeo (27:41):
Yeah, that's, that is a,
Izar Tarandach (27:45):
Sad,
Chris Romeo (27:45):
it's a sad state of affairs though, right?
Let that, so you're basically, Imean, with that conclusion,
you're saying a company canwillfully slash woefully.
Decide not to focus, not to do,not to focus on security and get
away with it.
Izar Tarandach (28:03):
Yeah.
Matt Coles (28:05):
Well, and then you'll, but then you'll have,
uh, you know, regulatoryenvironments that will say
otherwise, right?
Especially in criticalinfrastructure, private-public
partnerships, etc.
Izar Tarandach (28:15):
But everybody is there.
Chris Romeo (28:16):
Yeah, critical is a whole, whole other kind of
set...
I think people understand therisks of critical
infrastructure.
I don't, I mean, I think mostpeople understand.
Oh, we talked about that before.
I think we concluded most peopleprobably don't understand how
much danger there is the watersupply, for example, or,
Izar Tarandach (28:34):
oh God, don't, don't even go there.
Chris Romeo (28:36):
Yeah.
I don't want to go
Izar Tarandach (28:37):
Just to give you an example, Matt.
You're totally right, and wetalked about this in one of our
first episodes, the utilityvalue of things, right?
But one of the biggest wirelesscarriers, that thing is breached
every day that ends with Y.
Now, they sent me an emailsaying, oh, you are in our auto
pay thing, so in order for youto continue on this, you're
(29:01):
going to have to use a bankaccount rather than a credit
card.
So that took me to having toopen a new account.
with a separate number and aseparate card to once a month
put money into that accountenough to pay that specific bill
and that whole account is justfor that bill.
Why?
Because I don't trust my my bankaccount number, like my everyday
(29:26):
account number, with thatspecific company.
Matt Coles (29:28):
Yep.
Izar Tarandach (29:30):
And they don't care.
Matt Coles (29:32):
And nobody, and, but how many other people would have
done that isolation?
Probably very few.
Izar Tarandach (29:38):
I hope many.
Matt Coles (29:39):
But probably pretty, pretty few.
Izar Tarandach (29:41):
I told everybody that I know works with them, but
at the end of the day the pointis They don't care for, for, for
that point 00005 fee that theyhave to pay for the credit card
every month.
They are going to elevate yourrisk to a point that they don't
care.
(30:01):
Because they're not hit.
Chris Romeo (30:04):
You're going to make me an advocate for
regulation now.
I can't believe that's going tohappen.
By the way, my name is ChrisRomeo and I'm running for
Congress.
Izar Tarandach (30:14):
By the way, my name is Zartan and I'm running
to blah.
Anyway, uh,
Chris Romeo (30:20):
Hey,
Izar Tarandach (30:20):
people know what I'm running.
You people know what I'm runningfor.
Chris Romeo (30:23):
uh, days from
Matt Coles (30:24):
I'm not running unless somebody's chasing me, so
I don't know what you guys aredoing.
Chris Romeo (30:29):
They're going to have be, they're going to have
to be bigger than you two,right?
Like, I'm not running ifsomebody's smaller than me.
Matt Coles (30:34):
Remember, you don't have to be the fastest.
Izar Tarandach (30:37):
just faster than the last guy.
Chris Romeo (30:39):
That's, I that's the, that's the rule of bears,
you know, running, running awaya bear.
You don't have be faster thanthe bear.
Just gotta be faster than yourfriend.
Alright, so did we, did we, Idon't know I didn't get
Matt Coles (30:54):
Oh, we mangled this topic.
Chris Romeo (30:56):
Let me.
Izar Tarandach (30:56):
We, we didn't go left.
Chris Romeo (30:57):
We will, we will, but I have to provide my closing
arguments.
You had your closing
Izar Tarandach (31:01):
Oh yeah, please.
Chris Romeo (31:02):
So my closing argument, um, I mean, when I
think about the valueproposition of taking a separate
organization and meldingtogether, yes, I understand
there will be pain in figuringall those things out.
So that's why I don't think it'sgoing to happen now.
I think it may happen 10 yearsin the future.
It may happen further, but Ithink the future world is one
(31:25):
where.
The security team is dissolvedand is absorbed by various
functions across the business.
So, the AppSec people andProdSec people are in
engineering.
The, uh, people, the kind of,GRC would have to be, it's,
you'd have to take GRC and dropit under finance.
Like I said, leave privacyunder, under legal or maybe
(31:46):
bring privacy engineering.
Back to engineering and let,having the, let legal deal with
the privacy issues on the side.
But I think the valueproposition in this is we, we're
not, there's no longerinfighting.
There is, to Matt's point,there's budgetary alignment
because I can now just align onthe The things that I need to
(32:07):
build us to, to, to build thebest possible product.
And yes, the, the, your evidenceabout data breach is stark and
scary, but it's the truth.
Uh, but I think over timethere's going to be, you know,
when we get a privacylegislation here in the United
States, and I think it's coming,I just don't know when it's
(32:28):
going to happen.
I don't know if it's going to beGDPR for USA, but I think it's
coming.
I think we, we're, we need it.
Um, I think that can drive a lotof the focus here, but I just
think at the end of the day,it'll save once we get this,
once we had this new system upand running, it'll save a lot of
arguments, budgetarydisagreements, uh, and we'll put
(32:53):
things in the right place in mymind, put it where, where it put
those functions where they canhave the biggest impact.
without the potential infightingthat occurs at, uh, between
security teams and various otherfunctions within the business.
And so with that, Your Honor, Irest my case.
Wait, no, I want to call awitness.
(33:14):
I don't know who I would call.
Who would I call as a witness?
I don't I don't have anywitnesses myself.
Um, okay, let's spend a coupleof minutes having some fun with
this idea of shift left.
So, I got this new idea.
I want to bounce this off youguys.
I'm going to start a marketingcampaign.
Okay.
I'm going to try to geteverybody in our industry to
(33:36):
believe something that we weretalking about in the late
nineties, but I'm going tosummarize it in such a way in a
very simple thing.
It's going to be called shiftleft and I'm going to try to get
them to, I'm trying to reinventthis thing right before your
eyes, but that's.
Partially a joke, like, it's, Imean, I, I wrote a post on
LinkedIn.
It's getting a lot of attentionnow and I called it, it's time
(33:58):
to stop shifting left.
Um, and the point of it is like,I remember, do you guys remember
Joe Jarzombek?
From the Department of HomelandSecurity.
Were you guys, you guys wereprobably in kindergarten when,
when Joe was at DHS.
Izar Tarandach (34:13):
I'm older than you.
Chris Romeo (34:15):
This is the late, no you weren't, but you guys
were all about the same age, butlate nineties um, Joe Jarzombek
was at Department of HomelandSecurity and he started this
revolution for security, forsoftware security.
And he called it BuildingSecurity In.
You could go tobuildingsecurityin.gov and Joe
and his team were writing allabout software security and
secure code, you know, things.
(34:37):
And they were, they did a prettygood job.
But, but that's really...
What sh what shift left is likeShift left isn't anything new.
It's the same thing Joe was wastalking about back in the late
nineties and I looked it up.
Okay.
Larry Smith in 2001 was thefirst person to use this term
shift left, and he used it inthe context of shifting left in
(34:57):
the project cycle.
So he was like a program projectperson.
Izar Tarandach (35:00):
Wait, Perl, Perl, Larry Smith?
Chris Romeo (35:04):
Ooh, is that the same one?
Izar Tarandach (35:05):
I'm asking.
Chris Romeo (35:07):
Now I don't know.
Now you've got me now I'm, it'ssuch a common name though.
Larry Smith.
Um, I'm going to,
Izar Tarandach (35:13):
I don't know.
Izar Tarandach is the only thingthat I have to think about how
common it is.
Chris Romeo (35:19):
Yeah, uh, let me do a quick check on that to see my
sources at Wikipedia see if itwas in fact Pearl.
Um, Larry Smith.
Was it Larry Smith that didPerl?
Izar Tarandach (35:31):
No, it was Larry.
Something else.
Chris Romeo (35:33):
Yeah, I don't think it was.
So, but yeah, so I mean at theend of the day, this individual
created, Larry Smith createdthis idea in 2001.
And, you know, it's like 2017 or18 or so when somehow the,
somebody in AppSec found itsomewhere and kinda, I can't
figure out exactly who the firstperson was to use it in the
AppSec space, but it wasn't...
(35:55):
Oh, I thought you were sayingMatt.
Matt was the first one.
Izar Tarandach (35:58):
Larry Wall.
Chris Romeo (36:00):
Larry Wall is the Perl guy.
Yes.
How could I not remember that?
That was my first programminglanguage.
Izar Tarandach (36:04):
Sorry, my bad.
Chris Romeo (36:05):
Try to program.
Let's do some regularexpressions in Perl, shall we?
Come on.
It was so painful.
It never worked.
Okay, I'm, I'm off on a wholeother tangent.
So, I mean, Matt, I know you'vebeen maybe not as fond of the
shift left terminology from itsvery early days.
Give us your, how do you reallyfeel about this, about this term
(36:28):
Shift Left?
Matt Coles (36:29):
Uh, I think I have this quote in our book,
actually, uh, don't, don't shiftleft, start left, uh, right
thinker, think from requirementsonwards, not, uh, and, and I
think we've fallen, wetraditionally, or historically
fall into this trap of securitycomes later, right?
And, and I'm looking at thearticle that you're talking
(36:50):
about from shift left, uh, from2001 from Larry, uh, Larry
Smith, he's talking specificallyabout shifting quality left and
we've adopted this practicefrom, from a security standpoint
for the exact same reasons,right?
So test driven developments andhaving QA be part of the
(37:10):
process.
If you have requirements, whynot involve QA?
Well, again, if you haverequirements, why not involve
security?
Security should be, as astakeholder, should be
introducing requirements andwhen requirements are known,
that's the moment, as soon asrequirements are known, or a
concept has been developed,that's the, that's the moment
(37:32):
when security can start to beeffective and the time where you
can most cheaply impact thesecurity of a system.
And so you really don't want to,in my opinion, you don't really
want to shift left, becauseshift left assumes you're
starting from somewhere, meaningyou started from as far right as
(37:53):
possible, and you're workingyour way through the development
lifecycle back towardsrequirements, but, or, or
towards concept, but along theway, maybe that maybe you stop
at, at, um, whatever yourquality gate is, your code
freeze, your functional freezedate.
Well, you've already builtstuff.
And now you have, okay, what doI, how do I retrofit or how I
(38:14):
patch?
Well, I have to patch after thefact, after, after I ship or I
have to delay shipment.
And that's very costly.
So I'm going to stop now.
I'm going to ship, keep shiftingleft.
I'm going to stop atdevelopment.
Now I'm going to find bugs incode, but I'm, again, I've
already architected a system.
So I'm going to continueshifting left, and I'm now going
to stop at architecture.
(38:35):
Well, but now I've already setmy requirements, so I built an
architecture around thoserequirements, um, and I can't
really retrofit those, or I'vedone concept development, and so
I've gone down a certain pathwhere it may be too late to make
some security alterations.
But if you had started left...
(38:56):
then you could be most effect,effective and most efficient.
from a resource cost, et cetera,standpoint.
Chris Romeo (39:02):
Isn't that just SDL though?
Matt Coles (39:04):
Well, that's what the program, an SDL program or
an SDLC that has security, uh,milestones and activities is how
you, how you implement this.
And, and yes, uh, anorganization that has a good
security, that has a gooddevelopment life cycle that
includes security at each, ateach phase of their life cycle,
uh, has effectively already donethe shifting, right?
(39:29):
Uh, uh, now this getschallenging if, you know, and
again, you know, we're no longerreally in a waterfall model
anymore, right?
Even those companies that dowaterfall aren't doing
waterfall.
But then again, companies thatare doing agile aren't
necessarily doing agile, pureagile anymore either.
So where is left in an iterativeprocess or a spiral or?
(39:49):
So it gets a little bitchallenging there.
But basically anytime you haveconcept and requirements, that's
the time to get securityinvolved because it's the exact
same time you would get, it goesback to, it's like quality.
It's enough like quality thatyou can use it as a, as a
placeholder.
If you're going to involvequality, involve security.
Chris Romeo (40:09):
Yeah, and I think the, the, the, the, the, the
part that's bothered me is thishas been taken as a marketing
term.
It doesn't really mean, like, itstill has its core meaning, but
now you have, if you look invarious sources, you have Shift
Left, you have Shift Right.
You have shift everywhere.
I even found shift up and shiftdown, down references.
(40:32):
where is that going?
Like, we shifting up to the moonand you're going to run a secure
product on the moon?
Matt Coles (40:39):
Actually,
Izar Tarandach (40:39):
Don't give them ideas, please!
Matt Coles (40:41):
We do, we do, well, so if, if we were going to look
at those terms, I mean, we, wesee this with shifting down the
stack or up the stack, right?
So traditionally, software,software security is software
security, it's applicationdevelopment, as opposed to
moving into the platform ormoving into the hardware, right?
(41:01):
And so you're moving down thestack, I guess don't
Chris Romeo (41:04):
you legitimizing their term here?
Matt Coles (41:07):
No, absolutely not.
Uh, just at least, or, or if ithasn't been coined, then maybe
I'm coining it now, but, uh,
Chris Romeo (41:14):
No, people have, I've found using shift up and
shift down, but they didn'treally have a good explanation
for what it meant.
They were just, it was justanother kind of marketing.
Let's, let's, let's do somethinga little different than what the
rest of the pack is doing,shifting left by we're going to
shift up or shift down and
Matt Coles (41:31):
Yeah.
I can imagine shifting down as alot, a lot easier to as a
concept.
Like if you are starting withapplications already, there,
there is no up, right.
But there's probably a down.
Izar Tarandach (41:45):
There's always a down.
Matt Coles (41:46):
And, and there could be an out, I guess there could
be an out as well, you know,looking
Chris Romeo (41:50):
Shift out?
Matt Coles (41:51):
Well, looking beyond your application, Now to the
things around it, yourecosystem, customer base.
Chris Romeo (41:58):
I hope there aren't any marketers listening to this
and they're like, Ooh, that's agood idea.
We should shift out.
That's our new campaign.
We're gonna, our product shiftsout right out of the building.
Like, it's not even thereanymore.
Matt Coles (42:07):
Need, we need some, it's some, it's some, it's some
four dimensional chess thing...
Izar Tarandach (42:10):
We call it Elvis!
Matt Coles (42:11):
We need some four, we need need a fourth dimension
there
Chris Romeo (42:13):
Shift Elvis.
Elvis has left the building.
Matt Coles (42:17):
Well, instead of, of directional, instead of, you
know, directional, so now weneed time.
So shift, shift later.
Or shift sooner or...
Chris Romeo (42:26):
Why can't we time shift?
Izar Tarandach (42:29):
But why do we have to shift at all?
Like it goes together with whatwe were talking behind,
Matt Coles (42:34):
As a Rocky Horror Picture Show, uh, quote going on
here.
We need to get introduced
Chris Romeo (42:38):
Matt's singing.
Izar Tarandach (42:39):
To tell you the truth.
Okay, confession time.
The first time that I heard theterm shift left as applied to
security to development, theimage that I had in my mind was
a bunch of developers doing theshuffle.
Matt Coles (42:53):
The time warp.
It's a time warp.
Izar Tarandach (42:55):
It is not something I want to ever see
again.
Matt Coles (42:58):
As opposed to Thriller.
We could do the Thriller.
It's it perfect for Halloween!
Chris Romeo (43:03):
Oh, the time warp.
Izar Tarandach (43:06):
But, uh,
Chris Romeo (43:08):
Whew.
Izar Tarandach (43:08):
I think that where this goes together with
what we were talking before,like, we already touched it a
bit in there, is that, uh, firstof all, it sounds good.
Like, you say shift left, peoplecan have this mental image of
things tipping towards thebeginning of a timeline and
(43:30):
whatnot.
So, it's useful as a mentalframework to think about how am
I organizing my pipeline andstuff like that, right?
But, I think that every timethat we say shift left, again,
we...
We.
People.
All of us.
The industry.
I love that term, the industry.
It sounds like the mafia.
(43:51):
Uh, the industry, it, it, it, itjust doesn't, it's very easy to
say shift left.
And it's very easy to say myproduct, my process, my way
shifts left.
But what are we shifting?
(44:12):
How much are we shifting?
How are we proving that it'sshifting?
And how are we showing that thefact that we shifted gives you a
better result?
That we haven't quite worked outyet.
Matt Coles (44:21):
The problem is shift is a relational term.
When you shift, you start fromsome place and you go to some
place.
And when you say shift left,what are you shifting and where
did you start from?
We make the assumption when yousay shift left, it means, well,
I didn't shift left originallyand now I'm going to shift left,
so I probably wait until theend.
(44:43):
As opposed to, well, I could beshifting from the middle
somewhere and shifting left.
Izar Tarandach (44:48):
No, I, I think that you put it well, when, when
it reminded us that both boltingon security is very much still a
thing, unfortunately for, forall the efforts that we have
done in the past years.
And, and I think that youpointed out to that people
adopted the shift left mentalitybecause we were so much bolting
in, but now that, with what youjust said to me comes the
(45:08):
question, how much is gettingaway from bolting things on in
the end?
How much of that, how much ofshifting from that is a
meaningful shift to the left?
Chris Romeo (45:23):
Now we're
Matt Coles (45:23):
I think unless you're, unless you're
introducing it, jumping in atrequirements and concepts,
you're still bolting on.
Izar Tarandach (45:30):
Because that's
Matt Coles (45:30):
You're going to have to, you're going to have to bolt
on, right?
You're going to have to bolt onat the end because you're going
to miss stuff, right?
Izar Tarandach (45:36):
Won't we have to bolt on something almost always
because there will always be afinding that happened after the
thing is out and deployed?
Matt Coles (45:49):
Well, so I wouldn't say patching.
I would not say patching asbolt-on.
Izar Tarandach (45:52):
No, patching no, but changing stuff at the end.
Matt Coles (45:56):
Well, so here's an interesting question on that.
So bolting on, I think, in mymind, at least, is seen as a,
oops, I forgot to, I forgotabout this thing.
And now somebody reminds me Ineed to do it.
And so I'm going to bolt it on.
Or as opposed to, I have aconcept and, uh, I want to make
(46:17):
this thing modular.
And so this is a new and now anadd on addition that can improve
capability or, or whatever, andI, and maybe I can charge for
extra or not.
Um, but, but you making aninformed decision.
So a lot of our work is aboutmaking informed decisions, risk
decisions, or businessdecisions.
And so if I.
(46:38):
If an organization or, or, youknow, product team, for
instance, um, makes a decisionto bolt on as an add on
capability, that may be stillacceptable compared to the
traditional bolt on of, Oh, weforgot.
And now we're in recover, we'rein reactive mode.
So proactive bolt on versus areactive bolt on.
Izar Tarandach (47:01):
So let me put something out there, and this is
going to be convoluted becauseit's that kind week, so I
apologize from the beginning.
10 years from now, when we haveapplication and development and
deployment security peopleinside the engineering, because
(47:28):
they have shifted left so much,if at the end of the pipeline it
is found that, hey, we forgotsomething or we didn't think
about this at the securitylevel, that means that What was
needed, the knowledge or thefinesse needed to figure out, to
identify that thing wasn'tpresent in the engineering
(47:52):
framework that created thething.
So it's almost like we needsomebody with even more of a
security background from thosepeople that are in the pipeline
to say, whoops, we forgot thisthing, or hey, I just thought
about this threat, or I justthought this use case.
So have, have we just like.
(48:12):
close the wheel and going backto where we started and packaged
everything.
Matt Coles (48:17):
No, and I'm going to use another quality analogy
here.
When you make a mistake and youship something and you discover
that you ship something, you gothrough an RCA process, right?
Some sort of quality controlprocess.
And as long as that process isconsistently applied, or at
least consistently devised,right?
(48:40):
Um, then, then that would worktoo.
In other words, you don'tnecessarily need to have the
foreknowledge that to know thatyou missed something because
regulations will change orcustomers will ask for something
new or somebody will decide touse your product in a way that
wasn't originally intended forand now it's suddenly it is
intended for.
(49:01):
Um, you just have have theprocess to, to bring that
feedback back into the, intoyour life cycle and make the
adjustment adjustments.
Izar Tarandach (49:09):
But, but the trigger for that is an
exception.
For that is, as you said, itwent out and somebody corrected
us.
What I'm is, in between, inbetween that, that event of it
going out and somebody beingable to create an exception,
there needs to be a differentlevel that looks at different
things that probably we don'tlook at today to say, hey,
Matt Coles (49:31):
Uh,
Izar Tarandach (49:31):
be the last gate before this thing shipped.
Matt Coles (49:34):
So I wonder, we do, I think in engineering
organizations, we, we call themtechnologists, right?
We have CTO organizations thatdo, advanced R&D, you know,
advanced concept development.
I, I think you have thoseopportunities to re, to take
those functions, the outcomes oftheir work and feed them into
(49:54):
this process.
And if you...
Izar Tarandach (49:56):
Oh god, that's what they do?
I never knew.
Matt Coles (49:59):
I think so, uh, and so if you put security into
those functions, so if you takethe security folks and put them,
like take security researchersand put them in that function
and have appropriate feedbackand communication channels,
right, That, that may solve theproblem that you're, you're
highlighting.
Izar Tarandach (50:19):
God, I disagree with that at so many levels.
Matt Coles (50:23):
Chris, do I have ally here?
Izar Tarandach (50:24):
CTO organizations, in my experience,
they are some kind of like thegods in the Olympus saying we
are looking forward 20 years andwe are talking quantum
cryptography and we are talkinghomomorphic, uh, uh, operations.
Matt Coles (50:39):
We've
Izar Tarandach (50:39):
While you, you poor people are PHP code.
why do people, you poor peopleare still writing PHP code.
Don't, don't, come bother uswith your thing.
We, we, we are somewhere else.
Chris Romeo (50:52):
CTO organizations in the context that we're
talking about them here, let'sbe honest, a good part of their
work is outbound.
They're out speaking atconferences and they're thought
leaders that like this ideawhere you can have 75 CTOs
inside of an org...
you know, it's, it's a chief,you're a chief technical
officer.
There's only one CTO in acompany.
(51:15):
And maybe, I mean, you, maybeyou have one at the business
unit level.
That's truly making technologydecisions, but I see a lot of
the folks that, that wear thetitle of CTO.
Now they're not really, they maybe influencing the product a
little bit, but they'reprimarily out trying to
demonstrate technical dominancein the industry of ideas and
thoughts and things there, youknow.They're like a developer
(51:38):
advocate, developer relationstype of role.
But I think, you know, kind of,I want to wrap whole thing up
here and try to put a bow on it.
Shift left, build security inwhatever we want to call it.
It's not perfect.
It's never going to be perfect.
Like even if you, and I'm noteven going to say shift left,
(52:01):
but if you built security infrom the very beginning, you
started left, to Matt's point,it still doesn't, it's still,
it's still a process that'sbeing executed by people that
aren't perfect.
That's being, that is executingtools that are not perfect.
That's, uh, building softwareand hardware that's not perfect.
So at the end of the day, Theseare preventative measures.
(52:24):
There are things that we can doto try to get ahead of as many
things as we possibly can, butwe're still going to have
challenges.
There's still going to beproblems that come out of it, no
matter where you start in theprocess.
And what we've learnedcollectively over decades of
experience, all the way back towhat Jarzombek was doing at DHS
is if you start thinking aboutthe security things when you
(52:45):
start building the product,you're going to have a better
security outcome when you ship.
That's really all that matters.
And I what's happened in ourindustry is this shift left has
just been, it's beenmanipulated, weaponized, and
used as a, as a term for peopleto try to demonstrate that their
(53:05):
product is the best one outthere.
And I think they missed themark.
I think they, I think they tooksomething and they twisted it.
And they didn't, it doesn'treally, at the end of the day,
it doesn't really say anythingabout what you do because you
don't, you don't really shiftleft.
Your, uh, your SAST tool doesn'tshift left.
Izar Tarandach (53:23):
I think that when you say, when you say miss
the mark, I think that's, that'sexactly the thing.
When you point something way toomuch to the left, you will miss
the mark that's in front of you.
And that's what keeps happening.
Miss, like shift left became amarketing thing.
I'm leftier than you in thetimeline.
So therefore I am better thanyou.
(53:45):
I'm saving more money than you.
Matt Coles (53:47):
It's kinda like a of fr...
It's kinda like a game ofFrogger.
You're shifting across andthere's stuff coming from the
side.
Izar Tarandach (53:54):
Yep,
Chris Romeo (53:55):
I.
Izar Tarandach (53:56):
And that's why I said we're shifting ourselves
right off the table.
Chris Romeo (53:59):
I mean, I tell what, with that, there's no way
we can continue.
We're going to, thanks folks forjoining us at security table.
We have to wrap with thatanalogy.
Shift left
Izar Tarandach (54:08):
Wait, wait, wait, wait.
What was the Frogger song?
yeah, yeah,
Matt Coles (54:10):
Oh, no.
Izar Tarandach (54:14):
yeah, yeah, yeah.
I thinking of the Pac Man one.
No, yeah, you're
Matt Coles (54:18):
so you get run over and it.
Chris Romeo (54:19):
Yeah.
Izar Tarandach (54:20):
Splat.
Chris Romeo (54:21):
That's what happens when you shift left too much,
you get ran over and squashed.
So, all right, folks, thanks forlistening to security table.
Hopefully you found some, somevalue in this conversation.
Um, I think we ourselves, we'vemade some progress moving
forward.
So, uh, we look forward tojoining, you joining us again in
the future weeks to hear usdebate, discuss, and pick apart
(54:44):
just about anything we can thinkof in the world of security.
So thanks for listening.
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.