May 18, 2015
The RSA security conferences often have central themes that capture the security zeitgeist for the given year. From attending this year’s RSA security conference, I would sum up this year’s theme as, “stop resisting, accept change, and embrace DevOps”.
According to Gene Kim, author of The Phoenix Project and one of the presenters at RSA, traditional security organizations are “being shoved out of the game” because their operating models are unable to keep up with the pace of changes introduced by DevOps. In my own experience, a key catalyst of those changes is the continued growth in cloud adoption.
Successful security organizations are those that can integrate the DevOps model into their overall security program. Ericka Chichowski, author of Rugged DevOps: 10 ways to start embedding security into DevOps patterns, quotes Rich Mogul, CEO at Securosis, as saying “I see DevOps doing nothing but improving security when done right. Not only is software going to be more secure, but if you learn from these techniques it can help you get your day-to-day security more efficient.”
Chichowski also declares that security teams must embrace automation. She notes that the bad guys are already using the “continuous delivery model…and cloud-style technologies” to gain unauthorized access to systems while security professionals are still using manual techniques to defend against constantly mutable attacks.
As an example, she cites James Wicket, developer for Gauntlt, recommending the use of automated security tools that generate low false positives early in the development cycle.
How can organizations best implement these insights? It is perhaps tempting to suggest that organizations should simply embed security professionals into the DevOps teams, but the folks at Intuit presented a cautionary tale against such an approach. Shannon Leitz’s and Scott Kennedy’s Enterprise Cloud Security via DevSecOps presentation informed us that a traditional security operations approach does not work because it largely depends on manual processes, which are unable to keep up with the continuous changes introduced by DevOps. Under such a scenario, Security quickly becomes a bottleneck to getting work done and thus becomes a group to be avoided at all costs. Instead, Leitz and Kennedy suggest that security specialists become more like DevOps by developing code to automate security activities. Specifically, they suggest identifying security policies that can be “converted to code.”
But how does one convert security policies into code? I believe that a good example is Major Hayden’s Ansible Role CIS, which can be used to audit or remediate hosts against the Center for Insecurity Security (CIS) security benchmarks. Security practitioners have been using the CIS benchmarks to help guide and harden operating systems, applications, and databases. In fact, Hayden’s idea has been so influential that the folks at CIS now offer a hardened HVM in the AWS marketplace.