The rapid adoption of DevOps practices in the enterprise has forced a lot of CISOs to rethink their security play books.
Gone are the days of testing for security once software engineers are done developing a piece of software. With rapid iterations and continuous delivery of software there is no "done" anymore. Additionally, the fast-paced DevOps model gives engineers the power to provision their own development environments, code, run testing and push code all from a single seat. This blurring of IT roles raises separation of duty anxieties to the Nth degree for the uninitiated CISO.
These issues aren't insurmountable. They just require security leaders to get creative--and to flip their mentalities about security objectives and how they're achieved.
"Your participation in a DevOps team means you need to fit into DevOps, not the other way around," says Adrian Lane, analyst and CTO at Securosis. " If you’re going to work in a DevOps environment, you’re going to need to understand what it is, and how it works."
And one of the fastest ways to accomplish that is to start thinking of how security policies and practices impact the developer. To get you started, here are some things that developers wish CISOs understood about DevOps.
Software engineers don't have some secret aversion to security. It's just that for so long now the tools CISOs give them to test for and remediate vulnerabilities stick out like a square peg in the round hole of the developer's workflow.
"Security tools don’t easily integrate with classic development tools and processes, often flood development task queues with unintelligible findings, and lack development-centric filters to help developers prioritize," writes Lane. "Worse, security platforms and the security professionals who recommended them have been difficult to work with – often failing to offer API-layer integration support."
In the super-automated world of DevOps, that kind of mismatch simply won't fly anymore. Release cycles are too rapid and line-of-business leaders are too dependent on this agility to weight DevOps teams down with unwieldy testing tools and processes. CISOs will need to do the hard work of streamlining testing so that it fits seamlessly within the DevOps tool chain and workflow.
Speaking of speed, software engineers wish that their CISOs didn't fear it so. The truth is that the speed of deployment through DevOps can actually be a huge benefit to security teams once they buy into it. When developers are making smaller changes faster, it makes it much easier to quickly remediate security issues when they come up.
"The rate at which issues can be detected, responded to, and remediated will be 30 times greater or more," explains Ed Bellis, former CISO of Orbitz and current CTO of Kenna Security. "When my organization is deploying tens or even hundreds of times per day, I can react and fix issues faster and have much smaller windows of exposure."
One of the misconceptions CISOs have about DevOps teams is that devs operating in these environments are modern IT cowboys, hell bent on destroying perfectly good mechanisms for separation of duties. The truth is, developers are just trying to get their jobs done as efficiently as possible. And they're doing so with a set of automated tools that promotes accountability through constant measurement and automatic enforcement of policies and approvals rather than the old manual processes.
Rather than fixating on old methods, CISOs should instead examine (with an open mind) how the DevOps tool chain automates a lot of the process for things like provisioning and pushing code. What they'll find is that these tools often actually offer a better audit trail and more opportunities for enforcing separation of duties than what they depended on before.
"It is my belief that our industry needs to get better at having our systems embody the processes rather than just writing the processes down," says James Wickett, senior engineer at Signal Sciences Corp and creator of Gauntlt, an open-source security testing tool . "The benefits are huge: outliers are easier to detect, more people adhere to the process and generally people are happier. We need to make it easy to go faster and safer."
Like it or not, DevOps engineers scoff at your lofty security road maps. The whole DevOps ethos is centered around incremental improvements and the flexibility to adjust quickly to changing business conditions. Intricate, multi-year road maps promote neither. According to Forrester analyst Amy DeMartine, security leaders need to dump the complicated road map and instead focus on a broad vision that includes a few measurable objectives to work toward through incremental improvement.
Doing so makes the same shift that the rest of the IT team made when shifting away from waterfall development's big-bang mentality.
One of the biggest goals of DevOps is to minimize the amount of rework done by developers, because it takes a lot fewer resources to get a project done right the first time around than to go back and fix things after the fact.
"In order to maximize flow and minimize rework, everyone must focus on creating 'quality at the source,'" says Gene Kim, author of The Phoenix Project.
A lot of today's vulnerability management problems eventually come down to the fact that application security issues have primarily been left to be fixed after all the development work has been done. DevOps provides a great opportunity for CISOs to insert requirements into development cycles before a single line of code is written. The better security teams can embed these requirements at story and in the design or architecture, the more friends they'll make amongst developers.