JASON SUTTIE

CODING DEVSECOPS

CODING DEVSECOPS

Typically, IT policies cover many aspects of technology – including security. These policies are written in elaborate

documents and then are stored somewhere

cryptic.

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.

CODING DEVSECOPS

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.

CODING DEVSECOPS

This process and related events span over months, meaning this whole cycle

may take multiple months.

We need to close the window, and change the

time framework from months, to days to hours and ideally, real-time to match the timeframes of

potential hackers.

And I’m going to tell you how we at RMB tested

out DevSecOps.

We’ve framed the problem, now how do we bring DevSecOps into this :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 changes into the following: • Engineering• Operations• Data Science• Compliance

ENGINEERING & OPERATIONS

Engineering refers to how you build with

security in mind and bring security into your engineering pipeline. A

typical engineering pipeline shown here:

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.

DEVELOPMENT TEAM > bring into the way you think

/ engineering pipeline (policies & practices) Writes the code with

security in mindOPERATIONS TEAM >

bring into the way you think / engineering pipeline (policies & practices) Writes Puppet code to

manage infrastructure state to application layer as well

as comply against OpenSCAP policies

SECURITY TEAM > experiment / automate / test

new security approaches and modules

SECURITY OPERATIONS > continue detect / hunt /

contain threatsWrites OpenSCAP policies that describe the IT policy

Some examples of the parallels:>> Static Code Analysis: SonarQube for Developers

and PuppetLint for Operations

>> Automated unit test: Beaker for Operations and

xUnit for DevelopmentWith 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.

The data collected from DevSecOps can be

used to augment already well

established security data.

Measurement gives you compliance

measurement feedback against your policies

More at www.jason_suttie.net