News Stay informed about the latest enterprise technology news and product updates.

DevOps and security: Coexistence depends on automated security tools

Does DevOps sacrifice security to speed software deployments? Experts say DevOps and security can coexist with help from automated security tools.

BOSTON -- Information security is often viewed by enterprise business and IT leaders as a cost center that slows down software deployments, whereas the growing DevOps movement is all about reducing the time needed to release new software code and products. Despite seeming to be antithetical to one another, experts say DevOps and security can coexist.

With that rate of change, you cannot have a month of lag time to find the server, harden the server and put security controls in front of the server.

Josh Corman,
CTO, Sonatype

DevOps devotees gathered last week at a DevOps event, hosted by server management vendor JumpCloud, to share how the approach is affecting their respective organizations, mostly for the better. DevOps is an approach meant to break down the metaphorical wall between an organization's development and systems operation teams, empowering the same person who writes the code to also deploy and maintain it. Participants in a panel discussion said that some companies now deploy code thousands of times a day, as opposed to once a month or less as in the past.

Panelist David Greenstein, co-founder and chief technology officer for Boston-based startup, recently acquired by Cisco, said that DevOps was the byproduct of a "cultural shift" in enterprise IT, driven by the growing need to introduce products and features faster than competitors. Organizations that don't find ways to deploy code more quickly will simply be uncompetitive, Greenstein said, and unless security professionals find a way to play a part in the process, they risk being left behind.

"The casualty of this shift is security," Greenstein said. "It's all about time, which is the most expensive resource. The only way security becomes successful is to build it into DevOps."

Cory von Wallenstein, chief technology officer for Manchester, N.H.-based Internet performance vendor Dynamic Network Services Inc. (Dyn), warned security professionals that they must adapt to faster deployments rather than giving in to their natural inclination to delay releases until everything is secure. In fact, von Wallenstein noted that Dyn spent nine months filling its director of security role because the company specifically wanted someone that "wouldn't slow us down."

Still, despite concern that security teams simply can't keep up with DevOps-style deployments, all members of the panel would ideally like to see security play a greater role in the process.

Pete Cheslock, director of the DevTools team at Dyn, said that the link between security and DevOps is clearer than some may believe. Security and operations teams have always shared some common values, including the desire for greater availability and stability, he noted, and with developers now taking on some of the core responsibilities previously held only be operations, they must now share those concerns.

"Security is hard, and as an operations person at my core, the last thing I ever want is to get hacked," Cheslock said. "The worst thing is to have something perfectly preventable happen to you."

Automation and education

With time obviously at a premium, several panelists said that security professionals should turn to automated security tools as a way to play a greater role in the DevOps process.

Jerry Skurla, vice president of marketing for security intelligence vendor FireMon, noted that he had seen a shift in his company's customer base over the last 12 to 18 months on this front. Whereas his customers wanted humans to follow up on potential problems signaled by automated security tools in the recent past, Skurla said companies are now much more willing let those tools identify an issue, such as common Web vulnerabilities, and then act to resolve it without any human intervention.

Josh Corman, chief technology officer for Fulton, Md.-based Sonatype Inc., said in an interview with SearchSecurity that automated tools can play a key role in growing the relationship between security and DevOps. That is why some of the thought leaders in this space have pushed companies on the cutting edge of DevOps to deploy automated security tools, with the hopes that those organizations will influence others adopting DevOps tactics. Netflix, for example, had great success with its Chaos Monkey tool in the Amazon Web Services environment, so security experts worked with the company to create the automated Security Monkey tool, which ends AWS instances that are deemed to have security weaknesses.

Before DevOps, Corman said that security was often the "last runner in the relay race." After developers handed off code to operations for deployment, only then would the security team come in, but Corman stressed that DevOps makes such scenarios practically impossible.

"When you start going that fast and you're deploying environments and multiple configurations a day – [that's] thousands of changes a day," Corman said. "They might be minor, but with that rate of change, you cannot have a month of lag time to find the server, harden the server and put security controls in front of the server."

Though such automated tools are improving, Greenstein cautioned that relying on automation alone won't cover up for other potential security flaws, pointing to his past experience in a small startup as a cautionary tale. The extent of the startup's security strategy was "having a firewall," according to Greenstein, but otherwise, the company simply hoped that developers knew how to properly implement encryption and other security controls.

"It doesn't matter how good your security tools are if the application developers don't know what they are doing," Greenstein said.

DevOps demands new focus on security best practices

Dyn's von Wallenstein said that the No. 1 priority for security teams should be to educate developers and engineers about security best practices.

Panelist Matt Barlow, director of DevOps automation service at Rackspace Hosting Inc., said the fact that developers now have to take ownership over the entire process, including deployment and maintenance, makes a huge difference in terms of their interest in security. Rackspace developers now reach out to get help with security, Barlow said, and conversely, he encouraged security pros to actively extend a helping hand and emphasize how they can help with the process.

Barlow noted that the very nature of DevOps means that security's best hope may be to have best practices built in before deployment.

"If you're letting your developers deploy code straight into product," Barlow said, "you're basically giving them root access."

Corman said the willingness of DevOps practitioners to reach out to security teams is indicative of the larger opportunity available to the security community. The relationships with DevOps teams must be delicately developed, though, according to Corman, because security is a "toxic term" and is often viewed by developers as a "cost sink" and inhibitor.

To build those key relationships, Corman suggested that security teams focus on the common ground shared with DevOps, especially in regard to the desire to reduce complexity in the environment.

"There's a longstanding truth in security that complexity is the enemy of security. The more complex something is, the more bugs and ways it is attackable. It turns out complexity is also the enemy of stability," Corman said. "The DevOps people might not have cared about privacy or data loss or whatnot, but they absolutely care about availability. So both parties, DevOps and security, have an interest in driving down complexity."

Dig Deeper on Secure software development

Join the conversation

1 comment

Send me notifications when other members comment.

Please create a username to comment.

I'm not sure its a matter of it sacrificing security, I think it likely has more to do with dev time tables, and rush to get product out the door.  THe article suggests not following best practices are part of it, but best practices are not going to prevent security defects.  Constant questioning, constant evaluation, being aware of new techniques of exploits, and vulnerabilities are necessary to stay up to date.