Welcome def SEC Ops Fundamentals. This is Lesson 1.3. We're talking about integrating security into the Dev Ops.
So for the objectives for this module, this'll Essen wanna look at the list of some of the major steps of Dev ops identified some of the points where we do some secure review describes in the benefits of finding the these vulnerabilities early and why it? It's a lot more helpful,
and we'll look at the coms framework, which is for Dev Ops. But we couldn't see how we can integrate with security and then to discuss some of the challenges with agile development.
So here's the
It's a little expanded what we've seen before. The Infinity
cycle for Dev Ops is from the D. O d enterprise Deb Sick cops reference design.
So you can see then a little bit more around Dev showing as a cyclical process before a bill sorry development build test and then keep going until it's ready for release. And then there's the crossover and same thing and deploy operate monitor where they have this continuous cycle. Were there
continuously evaluating, too,
to see if there's any new requirements and indeed be put into place,
but we have here they have a little additional context of what? Weaken dio these security touch points so we knew. Threat modelling, secure coding.
Security has codes static analysis like we've seen before, dynamic analysis.
And then, if you're looking to do a full production security test, you could do a full pen test and then you digitally sign it. Once it's ready before it gets released,
verify that its securely transferred that you have a secure configuration
in place for any security credentials and then do your validation scan
and again do these security patching the audits and before you get to monitoring and analysis. So you see that there's even more steps we're not gonna go into as in depth. But you can see that it's it's
they're reference design. They really went through a lot of the steps that should be integrated into the develop cycle.
So what is the cost of? This? Came from a NIST reference. From a while back, I haven't seen
The idea of this graphic is to show that the cost a relative to say if you're doing in the design phase before anything has been coded. You're just thought it's pretty easy. It's pretty cheap to fix something versus when you code it. You made any find a vulnerability. May need to go back and change the design a little bit, but it's still a little bit cheaper
versus when you get to the integration and testing and then any
any problems that are found need to go holy back to design coding integration. All these steps need to go be performed again,
especially when you get to production
that any any idea I vulnerabilities If you wait to find them in production, you're gonna have to go through this whole cycle again.
What we need
keep in context as well is remember, this is from IBM security costs for a data breach that says the average cost was like $4 million. So any of these other, less small prices that would cost that we saw homes get advertised.
Zero. When you think within this larger scale of okay, what happens if I wait till something gets the production and I don't find it in time?
There's one question just to kind of think about as we've talked about death SEC ops so far and some of the components. But how would your organization need to change in order to implement a death set? Cops.
So the questions you kind of have to ask yourself, Really? Answer. This is how would would management support it mentioned before you really need executive by? And would they be willing to possibly add a little bit length at complexity to the current development cycle?
Do you have the tools in place? Anything automated tools
to her, or do you need to go purchase them? Do you have the people in place to do it? There's a lot of questions you have to ask yourself, and it's kind of keep reflecting on this maturity cycle is
you set up a goal of what you want to get to and just come up with these logical steps of how you want to keep contar continuously maturing your process.
This idea is just, Ah, talk about is the columns framework. This is really for Dev ops, but we can kind of look at it from the perspective of
that Def SEC ops. So there's obviously this acronym for culture, which is we mentioned before being part of the solution automation. We really need to have tools yet lean. Having this handoff, complexity, air and off complexity have minimizing the amount of complexity it takes in between each one of these gates
and then having these metrics the measure and then sharing between the team the integration among the Dev and Security that security operations and being part of this whole team whole cycle
case, I don't want to go through the whole calm each one of the acronyms, that going too far in depth. You can take a look at it, but I just want to kind of look at one portion of it. The automation just kind of get it, giving idea of some of the ideas, the concepts you do look at. So
So the idea of a supply chain hygiene we could automate this with there. That is a tool called our Sona Typo Tower called Nexus Life Cycle, which is a chrome plug in
they said runs and then, as it knows where you're looking at where the developer is, and so as they might browse a page with some third party library, the Blufgan can actually look at that and say and notify the users like, Hey, you're looking at this version
of this third of this library and it has a vulnerability. Should take a look at. Make sure you look getting a new version,
which would helps so that you don't download this library, put it and develop all the code around it. And then, by the end, right when it's too late, you didn't find his vulnerability. Have to go back and get the new version of it. Look, for if there's any vulnerability or sorry, any incompatibilities with the code is already written, so it's
really trying to move the security as far left as we can.
So Sonar Cube has a some coding standards that that can they get that bacon bed so it will take a look at the code and say, you might be not being adhering to the standards, and it's gonna cause these problems later on. So it's
the more less structure. Do you have your code? It may work, but then, as a secondary developer comes in,
they may look at it, might not be cleared them, and it may not start introducing security vulnerabilities because the logic may not be be correct
products like Get Lab that has vulnerability and code scanning built into it so that you can are so you don't have to come out and find
the secondary tool to try to add into they integrate really well into the process. And
Jenkins has it as well on a whole set of third party libraries is why we picked it for this,
of course. And then there's other tools, like Run deck, which is this interesting idea of
people that need to request a task that may need admin privileges instead of having to create a ticket handed off to multiple tiers. And you find to get this administrator who has the valuable time, they have to go work on this task, you can actually give units of work with the Ministry of Privilege to individuals so they can run it and taken.
They can actually accomplish this task without needing the full set of privileges.
So the next portion we have mentioned it before, but the way it's that the security needs really needs to change as well if they're gonna integrate into a dev ops
cycle is they need to have come up with the agile security method. So they need to look at small release the small releases that that air coming through with agile
and their frequent. So you need to be able to perform these security checks at the at the same rate as they dio.
Um, so you might have the idea of a baseline scan where you have a point where you do what you do a full scan
and then you only look at the Delta's each as each one of these,
uh agile deployments comes out and and you would just scan on the delta of that sear, limiting the amount of time you have to pour many type of security reviews.
And then you may at AZM or more in depth
releases come out. You may need to do a little additional work, but this would be part of integrating with the team and then looking at the stories that are coming out and saying, OK, this is a big change. This is this is gonna have a big effect on a security controls we have in place. Someone do need to do a little bit more in depth.
We need to minimize the chain. The scans based on these changes, a Zai mentioned looking, integrating It's really about integrating with the development team and understanding, going to the meetings, reviewing the documentations that's coming out and taking a look at the code.
It is a kind of good, good graphic. You'll have to look at depth, but you couldn't review. This is again another one from the D. O. D Enterprise def SEC Ops Reference Design, where they identify the pillars of def sec ops. If you want to kind of look through these each of these four pillars and kind of identify
the components that that you're gonna need within your organization, so mention this several time you need a cultural shifting by in
process, you need a really collaborative design across the teams. The technologies is talking about the tools
on moving towards infrastructures. Code security is a code allowed these more,
um, advanced topics.
And I'm from the government governance perspective. You want to have the right policy easy when you want to have the right sort of creation certification in place. That really takes advantage of this new way of securing the code.
This model we had looked at assessing the readiness to integrate security into the Dev ops
and then the next we're just gonna recap the module concept since we've reached the end of the content.