Coding DevSecOps

Typically, IT policies cover many aspects of the technology landscape – including security. These policies are written in elaborate documents and then are stored somewhere cryptic. Finding these policies is very often a challenge.

The Enterprise Problem

Typically, IT policies cover many aspects of the technology landscape – including security. These policies are written in elaborate documents and then are stored somewhere cryptic. Finding these policies is very often a challenge.

Then we hire experts to come in and manually run penetration tests against the environment which gives us measurement feedback on both compliance and vulnerabilities.

We then take these manually generated penetration test reports and ask people in our organizations to take the results and remediate according to the test findings.

While all this is happening we make policy changes to current policies, we also bring in new software into the environment to satisfy new business requirements. At the same time new threats appear.

Each part of the process can span months, meaning this whole cycle may take multiple months.

We need to close the window, and change the time reference from months, to days to hours and ideally, real-time to match the timeframes of potential hackers. This is DevSecOps and I’m going to tell you how to do it.

The Road to DevSecOps

We’ve framed the enterprise problem, now how do we apply DevSecOps to it? Well the answer is to delve a little more into DevSecOps.

DevSecOps = DevOps + Security ( Sec )

In the world of DevSecOps as you may predict we have three teams working together. Development, the Security team and Operations.

The “Sec” of DevSecOps introduces process changes to the following elements of an organization:

  • Engineering
  • Operations
  • Data Science
  • Compliance

This may seem a little daunting, let’s unpack these changes.

Engineering & Operations

Engineering refers to how you build with security in mind and bring security into your engineering pipeline. A typical engineering pipeline shown below:

As we practically observe code eating the world the engineering pipeline for the development, security & operations build team looks very similar. Coding best practices apply to all. Everyone needs to change the way that they think. We are no longer working in silos but rather working together in a well co-ordinated and harmonious manner.

Development team

  • Writes the system code with security in mind
  • There are changes to the engineering pipeline (policies & practices), most notably static code analysis using SonarQube that looks for security vulnerabilities

Operations team

  • Writes Puppet code to manage infrastructure state to application layer as well as comply against OpenSCAP policies
  • Static code analysis by means of PuppetLint

Security team

  • Experiments, automates and tests new security approaches and creates Puppet modules

Security operations

  • Continues to detect, hunt and then contain threats
  • Writes OpenSCAP policies that aligns to IT policy

Some examples of the parallels:

>> Static Code Analysis: Talk about SonarQube for Developers and PuppetLint for Operations

>> Automated unit test: Talk about Beaker for Operations and xUnit for Development

With this convergence there is no reason not to predict that the security team will soon follow similar practices when the toolsets reach the right levels of maturity.

 Data Science & Compliance

Once you start collecting data you can apply reverse looking analytics and forward looking data science approaches. The data collected from DevSecOps can be used to augment already well

established security data. In particular Puppet by its nature enforces a specific state, if this state changes without sanction these events can be used as ‘trip wires’ to detect potential intruders.

Measurement gives you compliance measurement feedback against your policies. This occurs at the cadence that you configure Puppet which defaults to 30 minutes.

To Conclude

In the new world – instead of having IT policies as documents, we codify them. Sec writes the policies and then Dev & Ops work together to write the remediation code.

Measurement moves from a manual state to an automated state. We write the policy code in OpenSCAP, remediate the policy breaches with Puppet code we have written. Threats, environment change and policy change occur as we expect.

The difference in the DevSecOps world is that we update and the policy & remediation code in minutes, we then rollout to the organization in hours.

That’s the true power of DevSecOps!

DevSecOps talks to how the principles of DevOps can be applied to the broader security context.

The path to building a culture of security in an organization needs to follow a similar path to that of DevOps: set the right expectations of outcome then empower and measure.

In this world of security challenges, can you afford not to do DevSecOps?

The Future

Look out for my next post on how to apply DevSecOps in a containerized environment!

by Jason Suttie