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

1. JASON
SUTTIE
CODING
DEVSECOPS

3. 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.

4. 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.

5. 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.

7. 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

8. 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:

9. 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 mind
OPERATIONS 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

10. SECURITY TEAM >
experiment / automate / test
new security approaches and
modules
SECURITY OPERATIONS >
continue detect / hunt /
contain threats
Writes 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 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.

11. 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