It would be hard to be involved in technology in any way and not see the dramatic upward trend in DevOps adoption. In their January 2019 publication “Five Key Trends To Benchmark DevOps Progress,” Forrester research found that 56 percent of firms were ‘implementing, implemented or expanding’ DevOps. Further, 51 percent of adopters have embraced DevOps for either all new or all applications. Clearly, DevOps adoption is here and growing. As with any significant technology development, however, security is an important and oftentimes secondary consideration for many organizations. Some even view it as an obstacle to adoption for a period of time. We’ve seen this pattern before with virtualization, and we’re still seeing it with cloud. Where are we with security and DevOps, then? Tripwire recently conducted a survey in order to better understand the current status of security and DevOps. The results showed that a vast majority of respondents (94 percent) are concerned about container security, with the highest percentages lacking knowledge (54 percent), visibility (52 percent) and the ability to assess containers prior to deployment (43 percent). And the concern isn’t unfounded. Sixty percent of respondents have had container security incidents in the last year. So while adoption continues to grow, security is a big issue for DevOps, especially for containers. The resounding solution being promoted in the market is to ‘shift left.’ That is to say, move the application of security controls from the Ops side of the DevOps lifecycle to the Dev side. After all, identifying and addressing security findings prior to deployment is always better than in production. There’s nothing wrong with this statement. It’s accurate. But there are lies to be uncovered in this mantra of ‘shift left.’
Lie #1: Ops security isn’t really important if you shift left
It’s implied in the language used in the market that a shift left means you don’t have to spend as much time on the right side of the equation. Traditional operational security controls aren’t really that important anymore. After all, if you just deploy secure containers or images, then why do you need to monitor them for change, vulnerabilities or mis-configurations. Surprisingly, this isn’t a new argument, and the idea that deploying secure systems is good practice isn’t new, either. It rarely happens these days, but there was a time when it wasn’t uncommon for an organization to claim they didn’t need to scan for vulnerabilities because they deployed secure builds to start with. The reality of production systems is that they change, and if the systems themselves don’t change, then the threat environment does. Production security controls are still a vital part of any DevOps environment.
Lie #2: New security controls are required for DevOps
It’s a common misconception that new technology brings fundamentally new threats and therefore requires new controls. New technology may require new tools, but the core security controls necessary don’t change nearly as quickly. If you start with the perspective of what security controls you need for DevOps, you’ll find that they’re not really new: configuration and vulnerability management, change detection, log management, etc. If you start with the technology, you’ll end up with tools and capabilities you might not really need or that you can’t effectively operationalize. This isn’t to say that your existing security tools can be repurposed for the Dev side of DevOps but more that starting with the required controls will produce better outcomes. While it’s fun to use dramatic language in a blog post or presentation to keep the audience engaged, it doesn’t take away from the reality that uncovering these ‘lies’ is important for information security. The tendency to see DevOps as an opportunity to ‘move on’ and ‘shift left’ bring a risk that we start ignoring the lessons learned from decades of information security. DevOps doesn’t require that we shift left but that we expand left, addressing security throughout the DevOps lifecycle. Pre-production and production require security controls. Ignoring either side of the equation leaves unacceptable risk and opportunity for attackers. Understanding what controls are required throughout the lifecycle allows the conversation about which tools can be used to provide those controls to occur productively. On March 12th, 2019, Tim Erlin will be presenting this material at the Cloud and Cybersecurity Expo in London.
