OWASP DevSecOps Security Model

Welcome back to death. Cicotte Fundamentals for Lesson 4.6 We're gonna just introduce the AWAS def SEC Ops maturity model have referenced a couple of times. It's going to a little bit more in depth. I think it's important concept of creating maturity plan for your def SEC ops and will all references and later modules as we go through for each one of the stages that we're working on objectives.

‍

This wouldn't discuss the need of why for maturity model to find a different levels, examined some of the test verification activities and interpret some of the build maturity activities of how you should be progressing so the model has 16 dimensions to it. I'm not gonna list all them out, but it's for each one of these stages of the build deployment process. Monitoring infrastructure hardening like that, you'll see the graphic has a circular function, with each one of these dimensions and the maturity levels going out and the color's highlight Teoh define defined maturity models or activities or tool specific to those those dimensions.

‍

So the idea is there's four level of level one is just a basic understanding of security practices. Then you have an understanding. Level three, you have a higher understanding and finally the highest level. You have an advanced understanding of security practices at scale, which means being able to deploy micro servers to the cloud any of those more advanced topics. So one of the first ones is testing verification, to mention just kind of give an example of what this maturity model looks like.

‍

So under this third dimension, there's a sub dimension for static depth of applications. So at level one you're testing the middleware components with known vulnerabilities. Whereas Level two you might start adding static analysis for her important server top server side components as well. So be not just testing the code, but actually the application server and looking for any vulnerabilities in that as well.

‍

So just a quick question before you go too far into this, do you understand this concept of the maturity levels in this maturity model for def SEC ops? The idea is to create maturity targets so specifically for a plan. That's the way I like to look at it to say, I'm at level one. I could see I'm you know I'm halfway through it. This is where I wanna be. And not everybody may want to go to the highest levels that you can set these targets if this is where I want to be.

‍

And here's two steps I need to go through to get to them. So again you want to evaluate your readiness to is do I have a budget in place? Can I procure these tools? So I have the expertise needed to improve the maturity again, I mentioned, I think it's useful to help create a goal. Are and also a plan on how to get to the higher levels. There's another dimension. Ah, against arts is the higher levels for static depth rob staycations.

‍

So as you move from the level to which was testing the server components and level three, you going to do analysis for important client side components, which again, we're doing a little bit more in depth now or not. We're not just looking at the server side testing Clyde side components with known vulnerabilities using multiple tools now, So you have these.

‍

There's gonna be some overlap, but each tool may not make may have certain strengths to it that and may be able to find different vulnerabilities that the other 1 may not have. Then you get to the highest level. You have the ability to exclude source code duplicates to static analysis across all the components. All of the library's and then do announce this was well on some of our on yourself Rick components and then do in stylistic analysis to she saw in the um in the In the Jenkins demo.

‍

We do the Czech style look for these errors that were calling him there. They may not be security related, but they have these issues with understanding how the code is written, especially when you're trying to fix later on or you have the new developers may come in. Can they understand the club? The code is it doesn't have some logic to it. And here's an example for the building deployment dimension.

‍

There's the sub dimensions specifically build, so in the most basic, you have a defined build process. Hopefully, that's in place. A Z get a little bit higher. You might be doing regular tests and then when you get to the third level, used to be digitally signing your artifacts and code so that it it's been part of protecting your supply came. But also as you move from the development side to the operations side is this code digitally signed?

‍

Though I know that anything happened in between or can I trust who created this code? And as you get the higher level what you're to be building and testing artifacts and running them in a virtual environment testing amount instead of having to deploy them to physical hardware, which is, as you see later on, we start building our Jenkins Dem a little bit further on will actually deploy into a virtual instance on and then finally deployed out to a doctor as well. So in this just in this module just started this lesson just introduced the quick concept of the maturity model from the OAS.

‍

And so we're gonna be using this quite a quite a bit or just kind of looking at how we can mature the process so that that was important to introduce it now and we're gonna this the end of the module also, and the next one just kind of recap, recap The concepts we learned