DevOps

On the tools side, embedding
security into DevOps for a truly Rugged
DevOps experience requires that
security teams find ways to
test early and often by
automating as much
testing as they can.
As Wickett explains,
current security
testing cycles are
really geared toward
waterfall approaches,
even as the rest of the
IT industry has drifted into
Agile and DevOps. And so things
like risk assessments and analysis,
plus PCI compliance checks tend to be
Test Early
and Often
completely out of sync with DevOps
cycles.
“We need better security testing
earlier on in the development
process and inside the build
pipeline,” Wickett says.
“Right after you commit
code, you should have
unit tests that run,
functional tests that run,
integration tests that
run and, at that point, you
should also have a suite of
security tests that run. Right
now, those tests usually are run on
an annual basis or as the product is just
about to ship.”
Automation is absolutely the lynchpin
to the whole strategy.
“At the speed people want to move,
reliance on manual testing just doesn’t
cut it,” explained Damon Edwards, host of
the DevOps Café podcast and long-time
DevOps evangelist, last year in a talk
at OWASP AppSecUSA. “The external
inspection by a third party who is going to
manually test something is not
going to be enough to catch
all of our problems.”
This does not
necessarily mean that
penetration tests go
away altogether, but they
may shift in importance
as automated tests
become the tip of the spear
and manual tests become a
backstop. At minimum, security
teams may want to start thinking of ways
to automatically integrate manual testing
results back into the pipeline.
“Even if you don’t do anything else,
whenever you shell out your $50,000
or whatever for your PCI compliance
Automate,
Automate,
Automate
testing, tell the penetration testers that
at the end, you won’t read a PDF,” Wickett
says. “Tell them the only output you will
accept is integration tests written in
Cucumber, Gauntlt, Behave or whatever
you want your stack to be, even if it’s just
Python scripts that test different parts
of my application to verify whatever it is
that needs verifying. Tell them you want
code delivered at the end of the
engagement.”
All of this is, of course,
easier said than done. As
Mogull explains, security
teams will need to vet their
tools for DevOps speeds
and processes, weeding out
some, retuning others and
bringing in new tools that are
purpose built for the new bar set
by the continuous delivery model.
“If you’re getting a lot of false
positives using a static analysis tool
and that’s impeding dev velocity, that’s
a problem,” Mogull says. “Some tools
aren’t well suited for working in this
environment.”