DevOps is changing the way IT works.  Through a collaboration of development and IT teams, organizations can achieve tremendous scale at increased speed to deploy and maintain critical applications and infrastructure.  The key technologies of virtualization and configuration automation have made this possible.  Without these technologies, development may not slow down, but deployment would slow to a crawl and the benefits of DevOps would be minimal.

It is interesting to note that in almost no definition of DevOps is the security process discussed as a key element.  In some cases you will hear mention of improved security through consistent configuration management enabled through automation, but security teams are not at the DevOps table.  Why is that?  I would suggest that for most people security is considered a barrier to IT.  Not surprisingly, DevOps, a practice focused on streamlining IT, security has been left out of the conversation so as to not prevent achieving the goal.

But if you accept that security needs to remain a part of the story, then it must be just as manageable as the infrastructure or it will never have a seat at the DevOps table.  Take a look at Puppet or Chef; they automate the configuration of the systems necessary to run the applications.  Through automation scripts, systems are deployed, configured, updated, and managed.  Development boxes are configured consistently with production boxes limiting impacts related to deploying an application into production.  So why can’t security fit into this picture?

One reason, is a lack of standardization.  Every security vendor wants to be unique.  They promote their solution as so incredibly unique from their competitors that there is no way to standardize.  So, creating scripts to manage security would require not only a unique script for each vendor, but a unique solution.  In comparison, the command to edit a route in Linux may be slightly different than in Windows, but the parameters are the same.  When you are managing security rules on a firewall as an example, you can’t even get agreement on that.  Zones are required for some firewalls, not used in others.  Applications define access in Palo Alto, but don’t exist in Cisco.  Even firewalls that share the idea of Applications use non-standard dictionaries of Applications.  So, creating a script becomes a non-standard solution.  Worse yet, the script that worked today won’t necessarily work tomorrow when the vendor changes their solution.

To make it all unmanageable, is the fact that they are so proud of their uniqueness that they have obscured even how they do it.  If you take all the firewall vendors on the market, not one of them publishes an API on how to fully manage their firewall policies.  Palo Alto exposes some capabilities for object management in a cool SDN sort of way.  Check Point has a very powerful, but proprietary API that allows full management, but they do not recommend it be used in that way.  Cisco is straight up command line with some newly available API’s and should be commended for making it at least obvious how to do it, if not easy.

The result: security is not a big part of the DevOps picture today.  And if the vendors don’t do something, they will be replaced by solutions willing to operate in this new DevOps world.  Open source firewalls or integrated firewalls in the virtual stack for example are ready to take their place.

The solution for security vendors: publish API’s to fully manage their systems.  They must accept that their UI is no longer what differentiates them from their competitors, it is the security engine and enterprise manageability.  Make it possible for others to manage their solution through open API’s with their full support.  All the security vendors will not come together and agree on a single API, but each should at least publish a usable API for their own product.  Vendors like FireMon or open source contributors to solutions like Puppet and Chef will solve the rest.

Security vendors better wake up or they will get left behind.