DevOps is not the end !

The purpose of this blog post series is to explain what I use to do in my work as DevOps to secure each part of application development and infrastructure.

Traditional security operates from the position that once a system has been designed, its security defects can then be determined by security staff and corrected by business operators before the system is released. Unfortunately, the belief that security must operate this way is flawed with the introduction of iteration and has since created inherent risks within the system because business decisions need to be balanced inline and addressed at the speed of business.

DevOps means a lot of different things to different people but basically, it’s concept, a culture, the reconciliation of operations and development engineers participating together in the entire service lifecycle, from design through the development process to production support.

By design, DevOps is applying agile and lean approaches to operations work and manage collaboration between development and operations staff throughout all stages of the development lifecycle when creating and operating a service. DevOps is also characterized by operations staff making use many of the same techniques as developers for their systems work. Those techniques can range from using source control to testing to participating in an Agile development process.

DevOps is a combination of some concepts that is know today as CALMS :

The idea is to develop a culture of automation to gain agility in the management of each part of the application lifecycle. But it’s not a end in itself.

DevOps is not the end of something, it’s just a transition to a fully automated and secured infrastructure. That’s why today the DevOps word is updated with some other acronym. DevSecOps is part of it.

DevSecOps is an evolution of the DevOps culture. They are tightly coupled.

The purpose and intent of DevSecOps is to build on the mindset that everyone is responsible for security with the goal of safely distributing security decisions
at speed and scale to those who hold the highest level of context without sacrificing the safety required.

This means that with the change impacted by the DevOps culture, traditional security is no longer an option.

The mindset established by DevSecOps lends itself to a cooperative system whereby business operators are supplied with tools and processes that help with security decision making along with security staff that enable use and tuning for these tools. In this way, the value that DevSecOps engineers supply to the system is an ability to continuously monitor, attack and determine defects before non-cooperative attackers might discover them. This allows for all, including security staff, within the business ecosystem to contribute to iterative value creation without the additional pain of attempting to acquire severely scarce security practitioners to be added to DevOps teams.

Like DevOps, DevSecOps is a combination of values that can be explain :

Leaning in over always saying “No”
Data & security science over fear, uncertainty and doubt
Open contribution & collaboration over security-only requirements
Consumable security services with APIs over mandated security controls & paperwork
Business driven security scores over rubber stamp security
Red & Blue team exploit testing over relying on scans & theoretical vulnerabilities
24x7 proactive security monitoring over reacting after being informed of an incident
Shared threat intelligence over keeping info to ourselves
Compliance operations over clipboards & checklists

Developing security as code provide insights directly to developers, and generally favor iteration over trying to always come up with the best answer before a deployment.
DevOps and DevSecOps values give you the ability to add agility in the security management. Each concept allow you to manage security by iteration to quickly patch a tool or a service independently of the ecosystem.

Some folks thinks that DevOps means that developers and operations are taking over security and doing it themselves. Part of that is true and part of it is not.

Developers and operation teams do not have to define their security policy, they have to work with the security team to create policies and take care of it as soon as possible in their projects.

DevSecOps should be seen as an evolution of the management of security infrastructure. The evolution of microservice, cloud, orchestration platforms ask to revise the old security practices to adjust this concept on the life cycle of current infrastructures.

Development, operations and security teams must work together to to define good practices to put in place.

This will necessarily go through the deployment of management tools (monitoring, logging, SIEM, etc.) but also by the understanding of tools by each collaborators and the involvement of each party in putting security concepts into practice.

In my next blog post, I’m gonna give more details on how DevSecOps can be implemented, his relation with development and operation teams and the benefits for each part.

Related posts:

A man sits down at a local bar, still wearing his suit and tie from work. He orders two beers from the bartender. Minutes later, another gentleman enters, wearing a dirty plaid shirt, plaster on his…

But I thought the main problem for everyone is what they desire because due to desire we feel sad and frustrated. someone’s desire about money, someone’s good home or gold or etc.., but the reality…

Recently there has been a lot of talk about incorporating mindfulness into our hectic, modern lives. Loosely rooted in the Buddhist practice of sati, mindfulness practitioners seek to improve their…