Last updated: 2024-11-21 22:07:00.853112 File source: link on GitLab
Learn DevOps practices and how your organization works.
Maintain relationships with Developers, QA, and Operations teams.
Do not fail builds unless you are at maturity level 3 or 4.
Do not run any tool which takes more than 10 minutes in CI/CD pipelines.
Create separate jobs for each tool/scan.
Roll out tools/scans in phases(iteratively).
Do not buy tools that don’t provide APIs or CLIs.
Verify that tool vendors can do incremental/baseline scans.
Do not be afraid to create custom rules.
Try to do everything as code.
Write documentation wikis.
A maturity model, in general, is a tool or a series of stepping stones that demonstrate the effectiveness and measurement of a person's or an organization's competence for a certain discipline. A maturity model is typically organized into degrees of effectiveness, where one begins out with a clean slate and advances to a greater level of capability as they climb the ladder.
To put it another way, consider of a maturity model as courses or grades in a school where a student is promoted to the next class once they have completed a grade and have attained a minimal level of knowledge in the prescribed subjects. Although it might surprise you, maturity models are just like students in the classroom in a way that they can be tricked. There are several maturity models on the market today, but we will only discuss or refer to those that are pertinent to information security, or more precisely, the "DevSecOps Maturity Model." Before we dive directly into this maturity model, we first need to understand what DevSecOps is.
Agile frameworks, product teams, and DevOps practices are currently dominating the software development business, from startups to large multinational corporations. It has been seen that security considerations are frequently overlooked or at the very least not given enough attention during implementation. The build pipeline in the continuous integration environment frequently does not use or apply the normal safety standards of the production environment.
DevOps was never intended to be limited to development and operations alone. In the past, security was restricted to a specific team or department that worked on the project's final stages. Security at the very end of the development life-cycle will always lead to roadblocks and never function in a sector that is evolving so quickly.
Here, DevSecOps enters the picture. Its acronym stands for development, security, and operations. This approach emphasizes security as a shared responsibility among all parties and combines automation, platform architecture, and—most critically—culture.
The term DSOMM stands for “DevSecOps Maturity Model” which is an open framework developed by “Timo Pagel” under the OWASP umbrella. When there are a lot of security-related initiatives that need to be completed in development and operations but no means to prioritize them or keep track of their present maturity, DSOMM can help.
The DSOMM Maturity Level 1-4 offers opportunities to harden DevOps tactics and demonstrates how they can be given priority and similarly, DevOps strategies can enhance security at the same time. In other words, these levels can be compared to a baby that must first learn to crawl before standing, walking, and then running.
Here are these 4 implementation levels:
Level 1: Basic understanding of security practices.
Level 2: Adoption of basic security practices.
Level 3: High adoption of security practices.
Level 4: Advanced deployment of security practices at scale.
The following picture describes the whole maturity framework in the shape of a round pizza where you can decide to take out a slice and work through the maturity of each implementation phase.
The DSOMM further categorizes depth of activities that need to be carried out and evaluated in four different types which are:
Static Depth: How deep is the static code scan that you are performing within the CI pipeline.
Dynamic Depth: How deep is the dynamic scan that is being run within the CI pipeline.
Intensity: Frequency for the security scans running in CI pipeline.
Consolidation: Your remediation workflow for handling findings and process completeness.
At this point, we often start the DevSecOps process under the presumption that no previous security work has been done, and this is the default state. It is hard to carry out the activities without some business assistance, just like with any security framework. I like to think about it like this: During this phase, you must do the following because "Security" is not always necessarily a company's core business:
Take management on board in security decisions and discussions.
Determine the decision-makers in your organization.
Start with people who are aware about security in your organization.
Start preaching the security principles to all the technical people in your organization.
The assessment of this level is not really needed because it’s enough to have the commitment to embark on this journey.
At this level, things don’t really start to get exciting because it’s the beginning. This is where we deliberately run the tools without any tuning as it is. Why you might ask? Because of false positives!
Let’s look at what happens on all 4 axes at this level:
Static Depth
Run SAST scans without any custom rules.
Run SCA scans without any custom rules.
Run Secret scans without any custom rules.
Dynamic Depth
Run DAST scans with baseline settings.
Intensity
Not to be worried about at this level. But you can define the frequency to be once a month or twice.
Consolidation
Not to be worried about at this level.
**Note: Another important thing to keep in mind at this level is that you are not supposed to fail any builds or stop developers in their tracks. **
After spending a few quarters in level 1, you are now quite familiar with all the tooling that performs scans for you. Furthermore, you have also shared this expertise with other engineers and built up effective team communications to provide you prompt feedback. Now, it’s time to level up.
In level 2, we make informed decisions based on minor tweaks to the default rule sets or configuration. This is mostly to test waters.
Let’s look at what happens on all 4 axes at this level:
Static Depth
Run SAST scans with minor tweaks to rules.
Run SCA scans with minor tweaks to rules.
Run Secret scans with minor tweaks to rules.
Dynamic Depth
Run DAST scans with minor tweaks to baseline settings.
Intensity
You can now define the frequency of scans to be twice a month.
Consolidation
You can start adding the findings in a vulnerability register after analysis.
**Note: Another important thing to keep in mind at this level is that you are not supposed to fail any builds but you can consult the developers for any concrete findings. **
Now is the time where things start to get really interesting. At this level, you should be fully operational and can defend against most threats.
Let’s look at what happens on all 4 axes at this level:
Static Depth
Run SAST scans with major tweaks to the existing rules.
Run SCA scans with major tweaks to the existing rules.
Run Secret scans with major tweaks to the existing rules.
Start writing custom rules.
Dynamic Depth
Run DAST scans with authentication and major tweaks to the settings.
Intensity
You can now define the frequency of scans to be once a week.
Consolidation
You can start adding all the findings in a vulnerability register and start the remediation process.
Note: Another important thing to keep in mind at this level is that you are supposed to fail all builds and notify the relevant teams immediately.
We are finally at the last level which is considered to be the most mature level. Most organizations never reach this level because it is very hard to do so.
Let’s look at what happens on all 4 axes at this level:
Static Depth
Run SAST scans with custom rules tailored to your organization.
Run SCA scans with custom rules tailored to your organization.
Run Secret scans with custom rules tailored to your organization.
Dynamic Depth
Run DAST scans with custom profiles for each application.
Intensity
You can now define the frequency of scans to be once a day against any merges that day.
Consolidation
You have now automated the remediation process.
