Building an application security program is really about ensuring
that security is built into that software development life cycle,
but not just into the software development lifecycle.
But also, how do we respond to vulnerabilities or findings as
we move along? That development pipeline all
the way into the operational environment.
Hey everyone. My name is Henry Surya with
Robin. And you're listening to the
technology, you know, podcast the show where I'll be bringing
you the greatest technical leaders practitioners and
thought leaders in the industry to discuss about their Journey
ideas and practices that we all can learn and apply to build a
highly performing technical team and to make an impact in your
personal work. So let's dive into our Journal.
Hey everyone, welcome to the Tecla.
You know, podcast the podcast where you can learn about
technical leadership and Excellence from my
conversations, with great thought leaders in the tech
industry. If you haven't, please follow
the show on your podcast app and social media on LinkedIn.
Twitter and Instagram for video content.
Steckle Journal is also now available on YouTube and
Tick-Tock. And if you want to support my
work by me, a coffee at technology.
Not deaths. Last tip or subscribe as a
patron at technology node. Death, /, Patron.
My guest for today's episode is Derek Fisher.
Derek is the author of application security, program
handbook, and also a security instructor at Temple University,
in this episode, direct shared about building, an application,
security program, and how to implement it in our
organization. First, we discussed some
security fundamental, concepts such as shift, left, CIA Triad
and threat modeling direct then outline how to start an
application security program and measure the programs.
Success, direct also touch on the security program maturity
model and gave his tips on how to build and higher application
security teams towards the end. Direct also give his insights on
how to address zero day vulnerabilities, when it becomes
prominent I think we don't need a reminder.
That security is very important to get, right?
And regardless, if you're building an application or just
using an application, there is an inherent security, risks in
the Technologies and software, we use.
And I hope you enjoy listening to this episode and learning a
few things about building application security program.
And if you do, it will be really awesome.
If you can share this with your colleagues, your friends and
communities and also leave a five star rating and review on
Apple podcast and Spotify. It may sound Simple, but it will
help me a lot in getting more people.
Discover, the podcasts on the platforms.
Let's go to the conversation with Derek after our sponsor
message. Are you looking for a new cool
swag? Taglit Journal.
Now offers you some swags that you can purchase online?
These wax are printed on demand based on your preference and
will be delivered safely to you all over the world where
shipping is available. Check out all the cool swag is
available by visiting technology.
You know dot f / shop and don't Get to break yourself.
Once you receive any of those tracks, hey everyone.
Welcome back to another new episode of the technology.
You know, today I have with me, a guest named Derek Fisher.
He's the author of a book titled, application security
program handbook, as you can tell from the title itself will
be talking a lot about application security and how to
build a program within your company or within your team in
order to put security at the Forefront of the software
development that you do. So direct.
Thank you so much for Time. And I'm looking forward for our
discussion today. We have thank you, Henry.
Thank you for having me on and looking forward to discussing
this topic. So Derek, I always love to ask
my guess to share about himself or herself was in the beginning.
So maybe if you can spend a bit of time, telling us who you are
and what are your highlights or turning points that you think
are worth to share your, so in engineering for probably close
to 30 years. Of this point, I started out and
Hardware engineering actually designing the circuit boards and
working in mechanical engineering.
I then moved on to software engineering after pursuing a
bachelor's degree in computer science.
And while I was working in software engineering got
introduced to someone product security officer at Siemens, who
then got me interested in to cybersecurity and decided to
pursue a master's degree in cyber security from Boston
University. At that point got into security
engineering security, architecture and started leading
a team and never look back. So I currently run a product
security Not a leading Financial technology company.
I teach software security at Temple University.
As you know, I've written the book on building an application
security program and also have written several children's books
on cybersecurity as well. Try to stay active in the
community. There's always a lot going on
and I tend to keep myself busy, but it's been a good journey.
The Foley go to actually your book, the application security
handbook. I'm interested when you say, you
also wrote a book for children about cybersecurity, maybe he
can tell us Little bit more about that book.
What made you wrote the book and what kind of content that you
are sharing to the kids here? Yeah.
I think we like to use the term shift left in cybersecurity and
I think you're going to shift left, it doesn't get any further
left and add so the reason I wrote the it's a series but it
follows a couple children as they can introduce the
technology and some of the pitfalls that you have to deal
with. Obviously, you know, being able
to set up a device securely password hygiene staying away
from strangers, using game. Some being able to not get
scammed during games, so there's a lot of different things.
So there's like I said, three books.
So, there's a couple things that Concepts that we've through
those books, but it's intended to be kind of light-hearted and
want a story format. So it's not the typical textbook
that. I think we're all kind of
accustomed to reading it's developed for children that are
in the six two nine, six to ten year old range, they called
middle gray chapter book. So it's meant for that date
range of 6 to 10 and you know we look at the way we are.
In society today, and a lot of children that age are obviously
getting their own devices if they're not using their parents.
And so, I think it's important to try to impart some of that
security Concepts to them as early as possible.
Thank you for sharing that. So, yeah, you are right.
Some, it is always better to have the shift left mentality,
right? So, in case of software
development, lifecycle shift life means in the earlier
process, but I think you go beyond like earlier face of
life, right? So teaching kids about
cybersecurity, I hope they also get it that these days, we all
have to be aware. About security and make sure
your data or privacy and security.
Best practices being implemented in our day-to-day life, right?
Including talking to strangers. Sharing out identity, sharing
our data and things like that. Which brings us to the topic
today that we would like to talk about which is to implement
application security program in a particular for example
company, right? As we all know application
security has been at the Forefront.
We have seen in the news about security breaches hacking and
things like that. Maybe if you can give a little
bit of background What is the current urgency for people to
start thinking about building application security program
within their company here? I think in the book, the
application security program handbook.
I talked about how every company is a software company and
whether you're actually developing software or using
software, you don't companies that their core product may not
be software, but they're certainly utilizing it.
And so, I think that all of us that work in the software space
and understand how software gets made knows that at the very
least, there's Body issues, if not security issues.
And so these companies that utilize that software will
oftentimes collect data from again, even if their core
function is in software, they're collecting data about their
clients. About the customers about their
product. They may have IP that they're
trying to maintain and all this is being housed and utilized by
the software that they bring into their organization and it's
only getting more complex. When all of these different
products talk to each other and And integrate with each other
and send data to. And from each other, there's
opportunity there for weaknesses or vulnerabilities and so that
exposes the organization suppose the data, that their housing to
malicious activity. So again, even if your core
competency is not software development and if your product
isn't in-house, develop software, you still have
exposure to this and it's critical to understand.
What are those vulnerabilities? And how do you resolve those
vulnerabilities? When they are detected.
Yeah. And I read in one particular
chapter, you also mentioned even though the company is seems to
have just a little bit of Technology like enabling website
or maybe just exposing something to the internet, right?
They also have this kind of risk so that for example, they are
being defaced or something data is being leaked out, right?
So all this becomes very relevant, even though you may
not be a technology pure company, but once you introduce
some kind of Technology, especially internet, right?
So things are Coming more dangerous.
So to speak you mentioned about building security program.
So maybe four people here who are not yet familiar, because we
always think security is somebody else's job.
Maybe if you can explain to us a little bit more, what do you
mean by building application security program?
If you're have any familiarity with the security organization
within your company or if you're already working in a security
organization, you're probably pretty familiar with the fact
that we are very good at being able to protect the perimeter.
And that's an old kind of mentality because I see things
shift to the cloud. And as we have more sass tools
that were using where things are kind of decentralized and not
house within a data center, we understand where those entry
points are into our system. We understand kind of how the
controls around that, but when your core competency is
developing software and when your core product is a
internally developed software product, its on that
organization to ensure, Sure that we're building security
into that product and protecting the data that were collecting
and using in order to protect our clients building, an
application security program is really about ensuring that
security is built into that software development life cycle,
but not just into the software development lifecycle.
But also, how do we respond to vulnerabilities or findings as
we move along? That development pipeline all
the way into the operational environment.
So when you develop software and Push it out into a production
environment for development, that's not where it ends, right?
There's a constant iteration you're constantly getting
feedback from your clients, you have defects that you have to
resolve and so forth. And those get pulled into the
next set of requirements and development and security is no
different one. We find vulnerabilities and
operations, or if we find a new 0 days or so forth, those things
need to be pulled back into the development environment and
resolve. So having a program in place
that is able to really look at that, That entire software
development life cycle and integrate security.
As part of that entire cycle is what building an application
security program is all about. Yeah.
So I think I do get what you mean by saying traditionally, we
always try to protect the perimeter right, whether it's in
pesos the outright and maybe it will class time.
But I guess these days and security threats have becoming
much more sophisticated, not to mention, there might be also
inside a security threat, but I think these days, there are so
many entry points where it's at The vulnerability is can be
found and even if you don't do anything sometimes it could also
happen that security vulnerabilities are being
exposed. Think of like the log4j
vulnerability last time, right? Even though you didn't change
anything. But yeah, you still exposed
once. These vulnerabilities is found
which brings us to the phrase that we commonly hear in the
security world and also separate development world, is that you
quoted this in the book saying that fixing issues in production
is significantly more expensive than fixing prior to production.
So this comes back to our Our discussion earlier about
shifting left, right? Maybe if you can explain a
little bit more about this philosophy, what does it mean by
shifting lab, and why do we always have to care about fixing
it earlier than the production? Today, if you look at
discovering a vulnerability in the production environment,
there's a long path. I mean it's a long and actually
relative depending on the organization what type of
release methodology that they're in.
But there's a path from the code being developed on a development
environment and then all the way to production and there's tools.
There's people there's processes that are all in place along that
entire Pipeline. And that can involve QA
individuals, there could be scrum, Masters project managers
leadership that are all involved.
In the process of getting that code from a development
environment into production and that's real cost, right?
If you think of, we're looking at code going from development
to production, but think about it.
But vulnerability going from development, environment into
production and all along that pipeline.
There's been people that have been involved with that code
that is potentially vulnerable going along, until it gets into
that production environment. Then when it's discovered in
production, you now have support individuals that have to get on
bridge calls to figure out what The issue is security, people
are called in. You might have to get pull in
incident, response forensics depending on the severity of the
vulnerability. You now have a very costly of
vulnerability. Of course, results May Vary.
You may find a vulnerability and production that's relatively
easy to resolve or get to a good spot with and you may have ones
that are very extreme, right? But the goal of Shifting left
and the goal of being able to push the discovery of that
vulnerability earlier in the process is really About bringing
security and detection as early in the process as possible.
And the way we do that is through training developers to
number one, not real. Its security vulnerabilities in
the first place, or at least be able to understand the code
patterns that result in Secure software.
Additionally, try to layer in security scanning tools as early
as possible, so that could be things like static analysis,
software, or what we call SCA, or We're composition analysis to
look for those vulnerabilities is early in the process as
possible. Things like Secrets, management
secrets of Discovery tools. All these can be kind of used
early in the process to detect any potential security issues
that could manifest in a production environment and then
all along that pipeline, you can also integrate other scanning
tools that are designed for runtime environments like
Dynamic scanners or integrated software testing.
So the goal there, Is to just continue to implement security
tools along that path to discover those vulnerabilities
before they get to a production environment and there's many
different ways of doing that. Now, not to kind of step on the
term shift left here, but we're starting to move away
application security, the individuals are starting to move
away from the term shift left, just because not that we don't
want to focus on discovering those vulnerabilities early, but
we don't want to forget that. There's other methods of
detecting. Ting, vulnerabilities, and
ensuring, that security is integrated across the entire
life cycle. Because I think we're now trying
to kind of over. Correct for the term shift, left
and pushing everything into left hand side at the development
lifecycle and sometimes forgetting about the rest of it.
Yeah, you made a good point, right?
Security. He's not finished just by having
so-called secure code and secure development practices, right?
Once you put the code into production, that's where the
rubber hits the road. So to speak that way, you have a
Because maybe constantly trying to look for vulnerabilities or
things where they can attack. And I think I even see it within
my company from day to day, they are some just anomalies
traffic's like trying to attack by injection or attacked by
other means, right? And there are so many security
scanning tools, as well, like hacking tools that people are
exposed with easily so that they can use free software to scan
any kind of internet port websites and things like that.
So I think you are right that we should not be relaxed.
Once we adopt secure coding practices, Element pipeline
practices. But always try to look
holistically before we actually go into all these techniques
that you implement in the program, right?
One thing is for people to understand the risk and normally
the risks associated with security is summarized as a CIA
Triad, this thing about confidentiality integrity and
availability, so can you also explain to us what this CIA
Triad is? And can all security risk
actually be summarized into these three components only.
I mean it's not just Those three components, there are other
acronyms that leverage the CIA to also include things like
authentication accountability. But when you look at what we do
from a security standpoint, it does pretty much come back to
ensuring that data is secure and not expose to somebody.
That should be that the data is not corrupted and is known to be
trusted and that data is available and I say data.
But it the application, the system, it's confidential the
data and there's confidential the data The systems are running
the way they should be. And that there hasn't been
anything tampered with the system when you look at the CIA.
A lot of it comes back to those three kind of main principles.
And when we talk about the different ways of trying to
integrate security to ensure that we're maintaining the
confidentiality integrity and availability, just from a high
level with confidentiality primarily.
We're talking about encryption making sure that data is
encrypted at rest and Transit and in use with Integrity were
ensuring that we have. Of hashing and check sums being
used. Just to ensure that the data
that was sent is the same data that was received and with
availability your building, highly redundant, highly
available types of systems to ensure that when something is
needed, it's available. I used to work in healthcare
space and I think the CIA was definitely I think more
prominent in the healthcare space than I would say in some
of the other fields that I've worked in.
Not that it's not elsewhere but definitely when you Talk about
using clinical applications, that doctors are using to make
decisions on patients potentially life and death types
of situations. You want to make sure that that
prescription that the medication that the doctor is prescribing,
is what the doctor. Prescribed, as what's actually
being administered in operating room, you want to make sure that
the systems are up and running so that the doctor can get
access to that information when they need it and you want to
make sure that patient data is well protected and not release
again in other fields. Obviously the CIA is still
critical but it was very abundantly clear when I worked
in the healthcare space, how critical the CIA was, thanks for
explaining that. So now assuming that people
understand security risk and you know why it is wise to actually
Implement some kind of security program?
Where do people start fighting in your book?
You mentioned about this thing, called threat modeling as the
first step. So maybe if you can explain us,
what does it mean to do track modeling and what does it
entail? Yeah, there's a couple different
ways. Of doing threat modeling.
And I think that we do threat modeling on a daily basis
whether we know it or not, we get in our car and we start
driving and our mind is already doing whether we consciously
think about it or not, we're doing threat modeling.
Yo am I going the right direction?
Is you're going to traffic is this person going to stop at
this? Stop sign that I'm about to go
through and you build in certain mitigation and you determine
like whether you're doing the right thing on the basic level
threat modeling is essentially asking what can go wrong.
There's a lot of Normal processes around threat
modeling, including using tools to do threat models.
But It ultimately comes down to asking that, basic question what
can go wrong and once you identify what that wrong is, you
start developing those mitigation and Remediation
efforts. But if you want to get started
with threat modeling, there's a couple different tools that I
usually recommend. One is the Microsoft threat
model tool, which is free to download a wasp also has called
a threat Dragon, which is also a threat model tool.
Purpose-built for Designing threat models.
Other individuals and organizations will use things
like PowerPoint or Vizio or something like that, just
because essentially, when you're doing a threat model is that
you're drawing out the architecture of the system and
you want to understand what the different touch points are in
that system, whether the third-party Integrations, or
whether they're internal users or external users, you want to
know, basically what that attack surface looks like for that
system and then start asking those questions on each one of
those integration. Ask the question.
What can go wrong? Can somebody spoof this call?
Can somebody tampered with the data that's coming through?
Can someone perform at the denial of service?
Can someone change their access level from a simple user to an
admin user? And you go through that with
each one of those interactions with the system and as you do
that and identify like, oh yeah well somebody can perform a
denial service while is this high enough risk for us to
integrate highly available system for us to be able to to
mitigate or remediate that denial of service attack.
And so that's the basic process of threat modeling is designing
that architecture. Identifying the interaction
points and start asking those questions about what are the
different attacks that could be performed.
And then what are we going to do about that?
Now, there's also a more what we would call like a manual threat
model process, which is essentially getting a bunch of
individuals into a room with a whiteboard and doing the same
thing where you draw out the architecture, you start asking
those questions. But the tools using something
like owasp threat dragon or Microsoft, threat model tool, or
there's commercial off-the-shelf, threat model
tools as well that exist. But using any of these tools
means that an individual or a very small group of individuals
can work on that threat model. You can put into maybe a central
location where you can store those threat models their
digital format. So they're easy to maintain and
handout that's the benefit of using a tool for threat
modeling. But when you look at doing a
manual threat model on a whiteboard, It's more time
consuming you can't really take your white board and check it
into a repository somewhere, but you're going to tend to get
better results in those manual type of threat model
environments because you're going to get more collaborative
responses from the people that are in the conversation but it
doesn't scale as well. So yeah, there's some
trade-offs. But again, it all comes down to
ask that question. What can go wrong and what are
we going to do about it? Thanks by explaining about
threat modeling. So, for people who haven't done
this before, how frequent should they do this?
Exercise is it like every time there's a new thing in the
architecture or is it like periodic thing like maybe every
quarter every month is that some kind of advice that you want to
give people when they should do track modeling, and after we
collect all these threat, modeling findings, how should
people collect and prioritize? This and also explaining to the
whole company or maybe the management that okay.
At some of these are real risk that we should work on here.
Are it comes down to understanding what the risk
level risk tolerances of the Organization.
And that's a very key component that I think we're missing in
many companies is, how do you really know what the risk is of
the findings that you find in your software?
And we don't always do a good job of that.
We know generally what our Flagship products are if you're
working inside an organization, you know what your Flagship
products are you know where your crown jewels are in terms of
data, you know what, the critical workflows are and So
you can determine like, okay, well this vulnerability that we
found impacts this application has potential to compromise this
data, that's high risk. So we should tackle that
however, again we're not great at being able to make that
decision quickly and in a very calculated way, it tends to be
more individuals making. I don't want to say gut
reaction, but it sort of is people saying, oh, this is our
Flagship product with a lot of sensitive data there.
For, it's got to be high risk. But risk really comes down to
technical risk and business risk.
There's technical risk of, are we going to lose confidentiality
the Integrity of the data, the availability of the system?
And then from the business side, do we have compliance concerns?
Do we have contractual concerns? Do we have dollar amounts that
are assigned to downtime for this application and marrying
those two together? Really?
Give you the overall risk of what that vulnerability might be
in the context of that application.
I think we're kind of missing that context and a lot of
organizations, in terms of, how do we frame those into those
vulnerabilities that we find? How do we frame them into the
right context of the, we know what we're tackling because
prior to zation and really understanding how we prioritize,
the vulnerabilities that come in need to be put through that lens
of risk. But the other side of that is
from a technical standpoint is, what's the exploitability of
this vulnerability. And that's another kind of piece
that we're not as a An industry, graded getting to, and we can
find application. Security teams can find
vulnerabilities. All day penetration testers can
find vulnerabilities all day two, and we have no shortage of
ability to be able to find vulnerabilities and talk about
like, hey, I found 10 new vulnerabilities today.
Great. What are we going to do about?
It are these really actual issues that we need to be
concerned about? Are they going to actually go
into a production environment if they go into that production
environment? Are they actually going to
Exploited because if in any mature organization, you're
going to have runtime protection, you're going to have
segmentation, you're going to have all these other controls in
place that may make that vulnerability on exploitable.
So understanding, how to prioritize, vulnerabilities and
understanding. How to really contextualize them
is not easy, it's understanding. What is the organization's risk?
What's the exploitability of that vulnerability?
And, you know, putting that together and making it a
decision quickly? When you do find those, and you
find one that hey, this phone, Ability here is in a very
high-risk application. It has potential to expose a lot
of data which is going to put us at compliance risk.
And yes, it is exploitable because we have no mitigations
in front of it. That should be a, I don't want a
slam dunk, but I think that's a typically, a slam-dunk for
organizations and say, hey, that's the one we need to go
after not the other 50 that we found that are unexplainable.
And I think, for most of organizations getting to that
point and being able to show like, hey, here's a valid
vulnerability, that Is going to be impactful.
That's what they want to chase. They don't want to chase the
other 50 that are just not, you know, of a concern and you.
All right. Oh so like we can always find
vulnerabilities, right? But what to do about it because
sometimes it could be in hundreds and thousands depending
on what tools you integrate. And speaking about tools, you
earlier mentioned things like Dynamic equation, security
testing, static analysis of a composition analysis.
What are the possible things that actually a company or
organization can introduce within their security program
up? Art from those that you have
mentioned. And where should people start?
Because we have so many. Right.
I don't think any new company can easily just introduce all of
them, but where should people prioritize?
Maybe start as the easiest one first, or maybe the most
impactful ones, maybe you can give us some guidance here,
securing the development, life cycle can be done, a hundred
different ways, and there could be any combination of calls and
I know talking to some of my peers and looking at others in
the industry, you can see where some are doing things that are
completely Different and some are doing things that are very
similar to what I'm doing my company.
And I think it really comes down to a few things.
One is, what's the budget tolerance?
You know, if you're on a shoestring budget, when you
don't have a lot of cash, it just throw it problem, then you
have to be creative. If you are less constrained in
that area, then you can have a little bit more leeway and being
able to build a more robust security development program,
but it does come down to at some point finding more
vulnerabilities isn't making you more secure and but in fact it
made Make you you're not going to get invited to the Christmas
party and stuff like that because all you're doing is
finding more vulnerabilities and making everybody angry.
So I think at some point you have to get quality over
quantity and you know with all that being said, I think it
really does depend on the organization.
What is the business budget tolerance and what is your risk
as an organization? If you're a company that has no
sense of data, you are not processing credit cards, you're
not holding client data. There's no It's information.
You're not going to want to integrate all the security tools
that Gardener puts out there and layer them all into your
development pipeline. You're going to be a little bit
more measured in that sense. But if you're a large
organization with high risk data, high-risk workflows, then,
yeah, you're going to have a little different context.
But the way I usually try to approach it is that think about
what are you trying to discover? And if you're looking to
discover vulnerabilities, the way to start with, that is in
those runtime type of, to Tools. So dashed or I asked the other
thing is get a penetration test. If you're going to use a
third-party that's fine, if you have people in house that can do
it, that's great. But you want to find out what
are our surface vulnerabilities that we need to be concerned
about ones, that would actually show up in an environment and
those tools Bast. And I asked and using a
penetration testing engagement, will help you get that
information relatively quickly, but there's the concerns around
scope. Like that, we get everything.
When the application, are there any hidden Corners that didn't
get caught by the scans? And then SCA software
composition analysis. To me, it should always be
integrated. It's very low friction, usually
low cost, there are open source, tools out there, that can help
you. You can build your own based on
some open apis for access to things like the nvd national
vulnerability database to get, just basically look at your
libraries and understand which one of these libraries He's have
known vulnerabilities in it, that we need to replace.
And that again, to me is just low-hanging fruit set, aside the
code that we're developing, the code that we're pulling from
repositories and third, parties. Are those vulnerable and tools,
like, SCA will certainly help with that.
And so I think those, you know, the getting the surface level
vulnerabilities, and getting the vulnerabilities that exist in
the libraries are using our core application security planks.
I would say, in terms of building, Program.
And then you start turning the screws are a little bit looking
at static analysis because they tend to be noisy.
And they tend to turn out a lot of vulnerabilities but you can
integrate them in the development environment and if
you have a properly tuned, if you're using a good tool and if
you have Smart engineers and smart application security
individuals, then you can get some value out of those and be
able to try to head off things before they go into a production
environment. Additionally, started looking at
your training program, your security retraining program and
making sure that Engineers are getting the security training
that will help them try to again, reduce adding those
vulnerabilities. And last thing I would say is
like security Champions program, which is really a sign of a
mature application security program when you're firing up a
championship program because that's usually where the tools
are integrated, you're getting the vulnerabilities.
Now, you need additional help in trying to resolve those
vulnerabilities and that's kind of where Champions team comes
in. Yeah speaking abuzz SCA, So if I
composition analysis, I think these days, I just want to
highlight, like we all use many software that are open source or
are free to download, and it's not just in terms of libraries
or Frameworks, right? Sometimes also the container
images, your VM images, and things like that.
There are so many things that people have built.
I'm not saying that open source is not secure, but they are
always points where maybe some kind of hackers include some
kind of malicious software inside those open source tools.
And hence, having this SCA is actually very important.
And I think I I heard maybe last time that people called it, the
software that you write in an organization, maybe even like
more than a half of it is actually coming from these open
source under the party libraries, right?
So that is actually the potential risks that you are.
Assuming if you use a lot of Open Source, software tools,
these are a lot of attack surface.
And speaking about maturity, you mentioned just now.
When we talk about maturity it's always coming to this maturity
model. Is there something like maturity
model for implementing security program within an Action.
Yeah, there are beasts M and Sam are the two that probably come
to mind for most people. And they're two different ways
of looking at a maturity model and be Sim building Security in
maturity model, is what be some stands for is looking at other
organizations and doing basically an assessment of that
organization and saying? Well, here's where this
organization is from the maturity standpoint and you as
your organization can then look at that and say well where are
we at? It's essentially measuring
yourself. I'm up against your peers and
understanding. Okay, what are the other
organizations of my size in my industry?
What is the one or two? Three things that they that
everybody in this category is doing?
Am I doing those things, right? And so that's a good way of
looking at, okay. Are we doing things that our
peers are doing with owasp Sam? That's more of classic maturity
model, where? Okay, here's the level that
you're starting at and here are the things you need to do to get
the One and then here's the things you need to do to get the
level 2 and so forth. And the goal there is to really
look at those steps in the maturity model and having
targets for where you want to be.
You may not have to be at the highest level of maturity.
Again going back to understanding what your
organization does if you're not processing credit cards, if
you're not holding client sensitive data and into your not
a critical app, you don't need to be at the highest level.
Maybe level one level two is just fine.
But what that does is it allows you to look at That if we want
to get the level to hear the things we need to do, you can
build out a roadmap that says, here are the steps were going to
take to get to that level. And here's a timeline that we're
going to go to be there. Personally, I have the Derek
maturity model so it's a little different.
I think be Sim is more valuable to me than Sam.
And the reason is I want to know what are the other organizations
doing are we in line with that? But sometimes just having
conversations with your peers is just as relevant.
I've had conversations with peers and just trying to see
what they're doing, compared to what I am doing and we'll kind
of exchange notes and you get that sense of like, hey okay
we're doing mostly well but at the same time, we had the same
challenges trying to figure out how we deal with the
vulnerabilities that we detect and so forth.
And just having conversations with your peers is just as
helpful I think I like the direction of maturity model so
you just even speaking in conferences or in networking or
even within PS, right? I think you can also maybe find
insights of what kind of security practices you should
include. And speaking about building this
program, obviously we need people, right?
But like I mentioned in the beginning, sometimes the mindset
is that we always assume security is somebody else's
problem. In this case, it's like
application security team in your experience.
How should people go about hiring this application?
Security team and what's the ratio size?
And from my experience as well, hiring a good security Engineers
are really really tough, and it's not just that they are
highly in demand, but the supply is also not that many So what
would you go about building the security teams?
How do we find good security engineers?
And yeah, how do we scale this with an organization?
I think the first thing to realize is you're never going to
scale to what you need. Don't even bother.
It's not possible. I've had very large teams, I've
had very small teams my team right now.
I would say it's relatively large compared to what I've had
in the past and anybody that follows Miriam has heard me on
other conversations, I'll say it again.
Like I could double the size of my team and it probably still
wouldn't be sufficient. And a lot of it is because
application security is very different than Security
operation centers. Very different than network
security and so forth. The way I always describe it is
that application security teams are the sidecar to engineering.
We are the ones that have to be part of that development
process, to ensure that security is integrated.
Now, that doesn't mean it has to be an individual and if it is an
individual doesn't have to be an application security individual,
which is why things like champions.
G for security education. Programs are very helpful in the
sense that you're helping to drive security education across
the engineering organization. But you are tasked with building
an application security team, it comes down to asking the
question. What do we want to do?
Do we want to just be a team of penetration testers?
Do we want to just be a team of Engineers that are working with
the developers in engineering and helping?
Them to create secure code, do we just want to integrate tools
and not do anything other than create integrate tools?
Find, vulnerabilities, and tell some a go fix them.
So it really comes down to understanding what is your
organization going to tolerate and what are the actual needs
for the team? So every organization is going
to have a different kind of view on that and it really comes down
to understanding. What is the budget, tolerance?
What is the need from an organization perspective?
And what is the road map for the And security team is it again
just developing integrating tools and finding
vulnerabilities. Do we want to get more proactive
in terms of blue, teaming and purple, teaming and red, teaming
to determine discover those vulnerabilities or are we just
going to stick to architecture and design?
So there's a lot of different ways of tackling that but again,
I go back to my first comment is that being able to hire the
quote unquote, right size in terms of individuals that you're
not going to do it. And I don't recall the numbers
off the top of my head, but I know be simple.
Had some numbers around what is the right size but again, it
varies it could be for every engineer.
You have or for every 100 Engineers, you have one knapsack
person for every 50, you have one.
It really depends on the organization but when it comes
down to hiring, one of the things that I typically try to
look for is somebody that has some type of development
background because if you can speak the language with the
development team, then, you know, you're already at a
disadvantage, not that you can be an application security
because obviously, We have plenty of people that didn't
come out of development that are in application security but it's
certainly helpful to have those individuals on your team to be
able to really translate these vulnerabilities that come out of
these tools and penetration testing and go back to the
development team and say, looking at your code, here's
exactly what the problem is. And here's exactly how you can
resolve it. I think that goes a long way,
not just in making the organization more secure and
making the application more secure.
But also building that relationship between
development, I meant team and the application security team
where we both understand each other.
Therefore, we're on somewhat Common Ground there.
So I do, typically look for people that have either come out
of the development space or have some type of development
background. I would say that I agree with
your opinion as well, that we should hire a security engineer
with some development background.
What I find in the industry. Typically is, there are so many
security so-called experts, but they are mainly specialize in
tools. Like, I'm a specialist of these
tools. I know how to implement these
two. And use it, but not necessarily
going back into the development lifecycle and even advising
developers. Okay, you should not do this or
even looking at the code, right? How things should be prevented
in the first place? So I think you're having this
kind of knowledge of development, background will be
first of all like you mentioned, right?
Build a good relationship. But obviously if we can prevent
security issues in the earlier, phase again, coming back to the
shift left. I think that makes a lot more
impact. So speaking about doing this
security program, building some kind of roadmap understanding,
what do we want out of? This security team.
And if we have established, this security team, what could be a
good indicator of success? What are the measurement of
success? How should you evaluate?
Is it just by number of findings?
Or is it just number of security breaches incidents?
Or is there any other measurement that you advise
people to look at for measuring the success?
Yeah, I think there's two main ones that I would focus on one
is for the downward trend on vulnerabilities.
Not upward again, we have no problem, finding vulnerabilities
we can Find them all day every day, but it's really, are we
moving the needle on reducing that backlog that to me is
better indicator of a security program where we're ducing that
backlog, not adding to it. And to be honest there's been
times where we've had scans done or tests done and there weren't
any vulnerabilities that were found and all of us that work in
the security space here like that I call BS on that.
That's why there's no way and you kind of second guess
yourself. I swear, it's like, wait, that
can't be right. You know, there's got to be
something. And after seeing several of
those I'm starting to come around to the idea is like,
well, hey maybe the program is working, you know, maybe we're
actually stopping these things from going out and that's a good
thing. But like I said, all of us in
the security space immediately when you see a scan, the comes
back with no results. You're like, wait a minute, that
can't be right. But yeah, I think it's always.
You can validate that know. This is right.
I think that's a good indication as well as that the program is
working, right? We're not finding things as
much. We're not adding to the backlog.
Reducing it. I think the other thing too is
something I'll steal from the operational spaces.
You know? Meantime to remediation how
quickly are we resolved in those vulnerabilities.
Do we have vulnerabilities that are sitting out there for weeks
months maybe even years? If that's the case, that's the
problem and there's a couple things with that especially ones
that are very long. Lasting vulnerabilities, past
several months or even a year or more.
If they ask question, is this even still a valid issue of
something that's been out there that long that there's something
not Right there, but I think looking at the amount of time
that it takes to actually remediate a vulnerability is
also critical indicator of how successful the program is.
Because again, we can find vulnerabilities all day but if
critical vulnerability is found and we're able to remediate that
within a few hours or a day or two or something like that, it's
very strong indicator that your program is humming along the
way. It should.
Yeah. Speaking about remediation, I
think the ultimate thing will be the zero day vulnerabilities,
right? Whenever it's found.
And how long does it take for The organization to actually
take an action. May be in your opinion, you are
in the security space a lot more.
How should people build this kind of zeroed a capability?
Yeah, I think that comes down to that mean time to remediation,
right? I'll go back to the sca example,
the software composition, we can develop software and you can
have zero vulnerabilities when that the software goes out into
production. The next day, some component
that we pulled in from a repository could be vulnerable.
Whether it's a zero day or whether Saint identified public
vulnerability. Either way, it's vulnerable,
right? And you did everything right
time will result in vulnerabilities being found.
And so, it really comes down to how your process is in place to
take those vulnerabilities that have been discovered in a
production environment and get a remediation out the door.
And in short period of time, that goes back to that mean,
time to remediation, where if we find an issue in production and
we're able to get a remediation push to production in a very
short period of time, that could be hours, that could be He's
could be week or so. Then great that means that your
programs is again doing very well, something that we didn't
really touch on and it's not because I was ignoring it, but
runtime protection, there are tools out there whether it's
laughs web application firewall or runtime application security
protection. Those also go a long way and
being able to provide some cover for a period of time until you
can get that remediation out the door.
So there's a lot of levers that we can kind of pull from a
security perspective to ensure that we are Are providing that
protection against especially things like zero days, where
something like runtime protection does come into play
because it allows you to do virtual patching, that allows
you to potentially stop any malicious activity.
Until you get code out the door, thanks for the plug for the
runtime, the Woof, and all these things.
So I think that sometimes can be very useful, especially if you
are being attacked as well DDOS. For example, when suddenly
somebody from the internet, just Target your system.
So having this kind of run time, protection definitely is very
Spoil. If you don't have it, please
Implement that as soon as possible.
So direct has been a great conversation.
Learning about security is very exciting as well.
Unfortunately, we reach the end of our conversation but I have
one last question that I normally ask for all my guests
which I call the tree technical leadership, wisdom.
So think of it just like an advice that you want to give to
the listeners here. Maybe if you can share us your
version of three. Technical leadership wisdom here
I think one is stay curious. One thing with technology is
that it's always changing, right?
And the prime example, everyone's on the A I trained
right now where it's everywhere. It's inescapable and everyone's
trying to figure out what to do with it and it's just a prime
example of how things change. And I think there's a lot of
people trying to figure out, is this a danger or is this going
to be helpful? I think there's pluses minuses.
There's two sides that it's just again.
It's an example of where technology is always changing.
One of the things with my application Security in general
or more specifically, is that we have to stay up to speed with
what developments doing. You know, the things that we
were doing five years ago, or vastly different than what Doing
today. And so you have to be able to
stay curious. Stay engaged and be able to know
where the new technology is heading.
I think the other thing is be a mentor if you can or be able to
help others again especially in this space with security Henry
mentioned earlier about how there's a lot of openings in
security and we're having trouble filling them and I think
we need help in this space. We definitely need people that
want to get into security and I think being able to to help
Mentor people and be able to bring them into this space is
going to help all of us. So find somebody that might be
interested in security and try to help them along the way.
I guess. The last point I would make is I
know, we were kind of sorted on the same thing with in terms of
hiring and Staffing but certifications aren't always the
answer. I know that I could probably sit
down and probably take the certification test and pass it
today without studying on many of these.
That doesn't mean that I've achieved anything, right?
I'm not saying certifications. Long or anything like that
because there's definitely value and certifications.
I know a lot of organizations look, specifically for
certifications to make a hiring decision.
But what I've often found is that I like studying for
certifications whether I take the exam or not because I had to
learn from that. I think especially in this
space, we see a lot of people that just want to get into
security and the first question is, which certification should I
take? And it's like well you don't
necessarily have to get a certification in order to get
into space. I mean you need to know
something, right? So So start dabbling start
getting involved when you're looking at application security,
specifically start understanding how software is developed.
Start understanding about cicp pipelines and integrating tools
and how code gets delivered and deployed and maintained.
If you're looking into getting into other aspects of security,
you know, start understanding those different corners and
really, really understand it, not just understand enough to
pass an exam, so that's my advice, right?
Thank you for including The certifications.
Yeah, I think now that you mention it, I'm very aware that
a lot of people in the security space ones to collect so-called
certifications right there. So many security organizations
and things like that and people tend to chase these
certifications or but it like you mentioned, right?
It's always about the practicality.
It's not just the knowledge only, you can accumulate all
this knowledge but the practicality I think, is the
most important. Like, how do you actually deal
with security, vulnerabilities, or even prevent it from the
development life cycle? So directly, people enjoy this
composition, they would want to learn from you.
Maybe the directs maturity model, right?
Is there a place where they can find you online here on, try to
stay pretty active on LinkedIn? Like I said, I'd stay pretty
busy but I try to get on LinkedIn and post and things
like that and I've been creating some content that I've been
releasing. Anybody that's been following me
on LinkedIn will see that. But yeah, the best way to get
ahold of me as on LinkedIn. I've seen some of your YouTube
videos. I think that's really cool and
fun. So yeah, maybe people should
check those out as well. So thank you again Derek for
this opportunity. I'll really Learn a lot from
security the conversation today and I hope people do as well.
So thank you for that. Thank you.
Thank you for listening to this episode and for staying, right
until the end if you highly enjoyed it.
I would appreciate if you share it with your friends and
colleagues who you think would also benefit from listening to
this episode. And if you are new to the
podcast, make sure to subscribe and leave me your valuable
review and feedback. It helps me a lot in order to
grow this podcast better. You can also find the full show
notes of this conversation on the episode page at technology,
not death website, including the full transcript and Arresting
courts and links to the resources mention from the
conversation. And lastly make sure to
subscribe to the show's mailing list on tackling Journal dot f
to get notified for any future episodes.
Stay tuned for the next package you know, episode.
And until then goodbye. Arresting courts and links to
the resources mention from the conversation.
And lastly make sure to subscribe to the show's mailing
list on tackling Journal dot f to get notified for any future
episodes. Stay tuned for the next package
you know, episode. And until then goodbye.