Does devops change security practices?

Security is still the elephant in the agile room - or should I say the fly in the ointment.

Agile people and business people like to think about functionality that will be delivered quickly; but the sad reality is that if something is delivered that is not secure, it can kill you, in terms of your business reputation. The problem is, how does security fit into agile?

I address this at length in Value-Driven IT and in High-Assurance Design. But now with devops, the concepts need some refreshing. Does devops change things, with respect to security?

On the level of fundamentals, no. The only effective approach to application security is to have developers that understand and appreciate application security, because security affects the design - at least, it should. That often means embedding a security expert in a team to mentor the team, with the strong expectation that some of the people on the team will strive to become experts as well, at which point the embedded security expert can leave. That approach is far more effective than a control-based approach that tries to externalize security by defining rules from a distance.

A very naive approach is to rely on scanning. Scanning is now thought to only detect 5-10% of actual vulnerabilities. (See http://www.cs.umd.edu/~pugh/MistakesThatMatter.pdf and http://samate.nist.gov/docs/SA_tool_effect_QoP.pdf.) Scanning is important - critical even - but it is not sufficient. There is no substitute for developers who are knowledgeable and current on application security.
Since it is hard to teach security and to get people to learn application security, this implies smaller teams of very experienced developers - developers who either know application level security or who want to learn about it. And it implies having enough security experts who can be embedded at least part time to work directly with teams on an ongoing basis. Of course, this needs to be done based on a risk model - one need not make everything as secure as possible.

These things have not changed. But what has changed is that virtualization makes it possible to do security testing earlier.  If one can provision entire test environments (VMs, software-defined network, virtual storage, other resources - including production-like test data) from images on demand via a cloud using OpenStack, AWS, etc., then one can perform security testing at will and do it at regular intervals throughout a development cycle rather than waiting until the end. I am talking about exploratory types of testing of course - things that are manual, like penetration testing. One should also embed automated scanning within the continuous integration test suite.

One of the core agile values, implicit in many of the principles of the Agile Manifesto, is that we really need to elevate people rather than trying to make things better only through better processes: ultimately, you can't improve things unless people increase what they know. This applies to security as well.