>> Hey, good news.
We're here today with Victoria Almazova to talk
about formal DevSecOps. Join us.
[MUSIC]
>> Welcome to the Azure Enablement Show,
where we'll be discussing the challenges you
and our other text-heavy customers have encountered.
Together we're going to be talking with
experts to find out how they think about these problems,
recommend the tools, and best practices, and
tips they have years of experience that you can use.
Today we're really lucky because we have a chance to talk to
Victoria Almazova who is a senior security architect.
In order to have this conversation,
I think it's best that I go over to customer mode.
Let me switch now. Hey, Victoria,
thanks for taking time to talk to me.
I could really use your help.
I was talking with my boss, and they are
really interested in doing something called DevSecOps,
which I've never heard of, and I don't really want to
look like I don't know what I'm talking about.
Could you just help me understand what DevSecOps is?
>> Yeah. I'm glad that you have asked.
Let me ask you some questions.
How you do the development today?
I believe you're doing the DevOps, right?
>> Yeah. We've been DevOps shop for a reasonable amount of time.
>> How about the security part?
When you do the security,
do you have any separate team,
and you check your application for
the security vulnerabilities at the end of
your development before going to the release?
>> Yeah, so we have, I think,
a pretty good security team. They're really good.
What we usually do is what everybody else does.
We develop the code, and we get the thing ready,
and then when everything's ready,
we turn to the security team to help us prove that it's secure.
They come in and do whatever
they do penetration tests or whatever.
I think this is the standard thing.
At the end of the process,
we make sure everything is secure.
>> Got you. Usually the penetration tests and the security checks,
they do take the time, correct.
It takes maybe two weeks or something like that.
>> Yeah, it can take a while
because sometimes they get backed up for sure.
>> Yes, and this where's the DevSecOps comes in.
When we speak about the DevSecOps,
it's all about getting the security practices in
your DevOps environment and in your DevOps practices.
That means that you are moving
the security from the end of the state when you already have
developed your solution, and now you're waiting for
your security team all the way to the beginning.
Where do you start to plan
your application development, then you plan it,
and when you develop it, build it,
and push it in every single step,
you are adding some
small bits and pieces of the security checks.
>> That sounds a lot of work in the middle.
Why is it important to do this?
>> Good point. Like you mentioned,
for example, when you have done your development, now,
it's time for the security team and,
usually, it takes, like we discussed,
two weeks or even a bit more.
That's one thing that doesn't go well for the continuous delivery.
As well, think, how do you prioritize boost
findings, because you are quite short in
timing for the releasing of your application.
Usually you put the security findings in your backlog,
they may stay there forever
because obviously the prioritization is to bring
the new functionality and every single sprint.
This is a reason why adding the small steps or
the small security checks in
every development step makes it more worth.
At some point, it sounds that you spend
more time on integrating the security,
but you fix the security findings
before they even arrive to your production. Does that make sense?
>> Yeah. That makes total sense to me.
That's pretty convincing.
Can you give me a sense of what's involved with this?
>> Of course. Let me show you the slide.
When we do the development,
we have different phases.
We do the planning,
then we develop the code.
We push it to the source code repository,
where it gets compiled, and then it gets to the test environment,
then to the production,
and then it goes into the operation mode.
On every single step what you can do,
you can add some security practices,
tools, and the processes.
Like for example, when you plan your user stories,
you, as well may run different modeling,
which will allow you to detect
potential security threats which you can cover later.
with the security user stories and develop them in
the same way as you do with
the functionality to protect your application.
Once you have developed your code,
you commit it to them
source code repository, where you can run
the static code analysis, and as well, check
your dependency management because we know a lot of
today's development is happening
with the help of the third-party libraries.
We need to be sure that these ones
are secure as well as your own code.
Once we have checked our code, and we go to the test environment,
which is another place where you can
add some additional security controls,
like checking your infrastructure if you write it is as a code.
In that way, you can add
the security checks against your infrastructure.
Then as well, you can do the security scanning and in
this time you're going to do the dynamic security scanning.
After, when all the testing has been
done, and you have assured the quality and the security,
you go into the production, where you add on the top
some other check,s like the configuration checks.
For example, your test environment may be different slightly
from the production, and you may miss some misconfigurations.
Of course, in operations in the same way you do in the DevOps,
it's quite crucial to focus on the monitoring
and looking for the potential security threats from there,
and as well, the blameless postmortems,
these practices coming forms the DevOps and
they should be also emphasized in the security.
Does it make sense for you, David?
>> Yeah, I totally get it.
I guess the thing that I'm struck about is,
it looks there's a lot there to do, and it
looks there's definitely lots of things I could choose.
Can you give me some senses like where to start
and how I would prioritize what I start on?
>> Yeah, it may sound so very overwhelming,
but what I would suggest to you is to look on your theme set up.
What is the knowledge of the security in your team?
>> Well, I would say that
our developers do have a sense of security,
but they don't know nearly as much as the security people do.
Some, I'd say but not a ton.
>> Yes. In this particular case,
if you can get your security team to work aside
with you to help all of these things to get implemented,
then I would start from the things that are quite close
to the developers, which is the CICD pipeline,
where you do the continuous integration
and the continuous delivery.
This is where we could implement the things,
like the dependency management scanning.
These will give the same seamless experience from
the developer site because you worked
with the pipelines and you know how to build them.
That transition would be quite helpful.
I would start with the CICD pipeline.
>> I like that idea a lot.
I think I could really just use
a little bit of help understanding what it
means in the implementation and how we do this.
I'm wondering if you would be willing to talk to me
another time and we can go over the tools aspects of this.
>> Of course. I will be happy.
>> Great, well let's do that.
With that, let's, let me switch back to
host mode. Back to being a host.
With that, I want to thank Victoria
for helping me out as a customer.
I want to thank you for watching
this episode of the Azure Enablement show.
Don't forget to like comment,
share, and subscribe, and join us again
to watch more of the Azure Enablement Show.
[MUSIC]