When we think about DevOps (you are thinking about DevOps, aren’t you?) we usually think about speed. By combining what used to be separate application development and operations into one continuous cycle, companies like Facebook and Netflix can instantly tweak their Web-based offerings based on the latest usage feedback.
But in a “DevOps State of the Union” dinner hosted by a several cloud hosting and software companies the other night in Boston, security was a bigger topic than speed. One prong of the conversation was how DevOps could make it even harder to secure corporate data and applications. The second was how DevOps could instead be, in the words of Jerry Skurla, vice president of marketing of security management software vendor Firemon, the “last, best hope for security.”
Needed: Security Smarts
Either way, security makes for a relatively little-known area where you can prove your smarts as a provider of DevOps tools and services.
Let’s tackle the end-of-the-world scenario first.
Change, or so the conventional wisdom goes, is inherently bad for security. That’s because any time you tweak application code, update a driver or reconfigure a server or firewall you could create a security gap. A recent HP report, for example, claims that nearly 80 percent of application vulnerabilities are caused not by poorly written code, but improper file settings, outdated software versions and misconfiguration.
Many DevOps devotees boast of rolling out not one new code package per week or month, but hundreds every day. Consider that many of these updates might require links to new databases or legacy (read: outdated) corporate systems, or through the corporate network out to third-party data sources? It only makes sense that so much rapid, continuous change could create a security nightmare. And if you put every change through rigorous security checks, aren’t you slowing the rapid code releases that DevOps is all about?
The flip side of the coin is that real-time visibility into application performance will let developers find security vulnerabilities more quickly, while rapid code refreshes will let them fix those vulnerabilities more quickly. In this scenario a vulnerability found at 8 a.m. could be patched as part of a routine code refresh that contains other application tweaks before noon. In fact, says TK, DevOps could make it possible for smart companies to make strong security a competitive differentiator.
So will DevOps wind up being good or bad for security? Probably both, depending on how the industry tackles some pesky implementation details. For DevOps marketers, tackling these real-world questions provides great fodder for “thought leadership” blog posts, white papers, newsletters, and the like.
- How do you enforce security-related coding and configuration standards without slowing code releases? (Skurla says this can be done by adding “built-in checks/processes” to emerging DevOps tools.)
- How do you perform regression testing to ensure your latest release doesn’t open a security hole, again without slowing code updates?
- How do you provide for code rollback so you can quickly withdraw a release that caused a security problem?
- If you need an audit trail of who made what changes to which code and systems, how do you provide this in a DevOps environment without bogging everyone down in paperwork?
- What balance do you strike between spreading the authority to quickly make needed code changes, and the need to control administrative access to your most critical systems?
- How do you create a culture where your people speak up about a security problem in code they deployed, rather than staying quiet (and delaying a fix) in hopes someone else will catch the blame?
Where there are good, a new question like this, there’s opportunity to engage customers and set the terms of the marketing conversation. DevOps devotees, fire away!
Filed under: Uncategorized
Like this post? Subscribe to my RSS feed and get loads more!