What is DevSecOps?

DevOps, symbolized by the infinite logo, includes activities that enable developers and administrators to collaborate consistently and iteratively on application development, testing, continuous integration, and monitoring. These modes of organization and tooling have profoundly changed the practices of production development teams. These developments are not without impact on security.

DevOps, the new headache for CISOs? Not at all! To get out of it, simply integrate security at the heart of DevOps, and set up a DevSecOps approach.

What objectives should be achieved in a DevSecOps approach?

The goal of a DevSecOps approach is ultimately to achieve as efficiently as possible a level of application security adapted to the risks. Different principles contribute to achieving this objective with minimal effort:

Iterative

According to agile principles, it is better to fail quickly to correct quickly. For example, an imperfect design is sometimes more efficient than a specification phase that is too long. It is therefore necessary to evaluate the benefit of the design in relation to the time it imposes on the project. This is also what leads to adopting an iterative approach to regularly reassess the direction of the project. In security, this could be achieved by planning several PDCA (Plan, Do, Check, Act) iterations. Thus, study, audit or governance phases can be intertwined throughout the project. For example: reassessment of threats in the deployment phase, recurring code scans from the beginning of development, several versions of the architecture file during the project or perform compliance checks on technical components from the test phases, etc.

Automated

Since we seek to increase the frequency of security checks to “iterate” in the project and without increasing the associated workload, we must equip the controls to make the project team autonomous.This necessarily involves project monitoring indicators or evidence of these controls. For example: participation in an architecture committee, scan report, compliant architecture principles, configuration templates, “Access Management” and “API Management” specifications… are all indicators of the project and are often measurable without systematically resorting to the security team.

It is also possible to allow certain levels of opening of the application service based on the results of these security checks. For example: opening internally only, delivery for testing, restricted to a pilot population or for a limited time and subject to the application of an action plan.

In summary, equipping and automating controls allows:

• To make teams autonomous and no longer slow them down
• Anticipate the actions of the teams
• Increase the frequency of checks for an equivalent or lower workload and thus avoid significant discrepancies between two security checks

Collaborative

For security controls to be applicable, it is also necessary to identify the different suppliers of the project and their level of responsibility. It will also be necessary to determine, for example, whether the architecture is partly on “on premise” or multi cloud. It is also necessary to establish with the operators of security and infrastructure equipment (Access Management, APIM Management, Continuous Integration Platform, etc .) the needs to anticipate their proper use.

Finally, an organization with responsibilities organized and documented at the different levels below allows to maintain the fluidity brought by DevOps:

• Product Liability
• Responsibility for the development architecture
• Responsibility for the development of a component
• Responsibility for operations
• Responsibility for quality and testing

Our advice to set up a DevSecOps approach

To initiate a DevSecOps approach, it is first of course necessary to understand current SecOps practices and try to answer some organizational questions:

• How to assess risks and monitor the application of measures in a constantly evolving project?
• What tools and indicators should be shared to make the project team autonomous?
• How to automate controls to allow the project team to anticipate its action plans?

Based on this risk analysis, processes and security tools already in place or identified, it is necessary to prioritize the indicators to be monitored, the tools that will be able to produce them and the people who will be responsible for monitoring these indicators. We can then set them up and iterate for the first time as they are and practice continuous improvement. To sustain the use of security tools and the indicators they produce, it is then necessary to define the responsibilities around these tools.