You know the illustration The March of Progress?  The name itself might not ring a bell for everyone, but more than likely you’ve seen it: it’s the illustration showing human evolution from the earliest primate ancestors on the far left, throughout various phases of evolutionary development, to modern humans ultimately taking their place on the far right.

That illustration – aside from being iconic in and of itself – is also almost a perfect metaphor for the way software development paradigms have evolved over the years.

The “well-seasoned” among us may remember the transition from waterfall to cyclical processes (such as RUP or MDF) in the early nineties, while those with fewer grey hairs probably remember the more recent transition from highly-formalized cyclical processes to leaner and more faster moving Agile-derived methodologies.

Now, it’s evolving again – sprints are becoming even faster through the employment of DevOps.

If you’re not familiar with the term (for example if you’re not a software developer or if your organization doesn’t employ it), DevOps is a unification of software development and operational support for the purposes of accelerating the development.

It does this by reducing the “friction” that can occur between when an application is developed and when it’s fielded into production.  The less delay between these two milestones, the faster functionality (not to mention fixes) can be pushed into the hands of waiting customers.

How is this possible?  First, increased speed is achieved through multiple smaller code pushes.  Meaning, instead of one big push, there might be many, many smaller-scale pushes.

In some situations and for some organizations, there could be anywhere upwards of 10-15 pushes every day.  Flickr has a process, for example, built to target up to 10 pushes per day.  Of course, the point isn’t to remove entirely all the “stuff in the middle” like QA, build, operational configuration, etc.

Instead, the various aspects of code publication are automated to allow this rapid pace to function seamlessly without (or with minimal) human intervention.

Pros and Cons

As you might imagine, from a security point of view there can be some concern about this.  Why?  Because consider the impact accelerated release cycles have on existing security processes without modification to them.

For example, consider a policy requiring security review at each development stage or release gate – for example, if policy requires a security review when code is pushed to QA, or a scan (or penetration test) before it goes into production.  What happens when those stages become more fluid and development stages iterate faster and faster?

Moreover, existing application testing methodologies are often challenged.  Consider web application scanning or pentesting when the application might be literally changing underneath the test.

A few weeks after the test, there could be dozens of new issues while the ones the testing team found have changed or gone away. This makes interpreting the results more challenging and complex to say the least. The point is, there’s a few different reasons why security practitioners have historically been challenged by DevOps.

But there’s also a flipside.  There are those who suggest that DevOps offers a more holistic view of the application and therefore, by extension, a more holistic and integrated view of security.  Meaning, rather than trying to figure out how to secure an application after the fact, DevOps allows that functionality to be built in.

In addition to (potentially) better integrating security into the application, there are also security benefits of appropriately controlled, automated configuration management and testing like that which is key in making DevOps practicable.

Just like functional testing can become more automated, so also can security testing — and just like system configuration modifications can be automagically made to support new development needs, so too can those tools address security needs like preventative steps against new and emerging attacks.

Actions

The point is, for organizations that embrace — and are ready for it — DevOps can be a boon.  For those that don’t – and aren’t — the complete opposite is true.  The difference between the two outcomes is the extent that you can get your application security program ready for the change.

The first step in getting ready is to remove the “security silo.”  Your application security program will have major challenges in a DevOps world if there aren’t strong relationships with the key players on both the development and the operations side.

Generally speaking, technical security teams probably already work closely with operations — so a relationship there may not need to be cultivated.  But for development, where a relationship with security exists at all in many shops, it tends to be adversarial.  If the organization does adopt DevOps processes, these relationships will become more important.

Moreover, the ability of the security team to automate their processes and tools into the new paradigm will likely involve development support from somewhere – it’s a good idea to get these folks on your side now so that when the time comes they know who you are, trust you, and are willing to invest in you.

Second, knowing what’s coming down the pike, now might be a good time to get a handle on current application security processes, how they work, and where the potential exists to leverage automation to support those processes.

Automating portions of the application security workflow – particularly those that lend themselves well to automation (for example, automated scanning) has an immediate benefit to you today, but can also help pave the way to a post DevOps world where automated security validation will be non-optional.

If you have an expensive-to-operate manual validation process, now could be a good time to consider automating some of that work.

Lastly, embrace the change when and if it happens.  In other words, don’t try to say no to DevOps “just because” it’s something new.  Frankly speaking, security is unlikely to win a fight about whether or not to adopt DevOps in the first place – no matter how well argued their position is.

Instead, the more likely scenario when security teams resist is that these other organizations will stop including security in the discussion and do what they’re going to without involving security. This makes the eventual integration of security into the resulting processes harder and more expensive to effect.  As with most things, you want to be involved as early as possible and stay involved throughout the whole process.

There are, of course, numerous other things besides these that you can do to get ready. However, these few are useful as a starting point and are likely a good idea no matter what stage of adopting DevOps (or considering adopting) the organization is.

Ed Moyle is Director of Emerging Business and Technology for ISACA.  Prior to joining ISACA, Ed was a founding partner of the analyst firm Security Curve.  In his more than 15 years in information security, Ed has held numerous practitioner and analyst positions including senior manager with CTG’s global security practice, vice president and information security officer for Merrill Lynch Investment Managers, and senior security analyst with Trintech.  Ed is co-author of Cryptographic Libraries for Developers and a frequent contributor to the Information Security industry as author, public speaker, and analyst.