There’s been considerable discussion recently about how to make certain good security practices remain integrated within DevOps-driven environments. To get the scoop from a security pro who is experienced working on delivering security programs in development environments, I turned to Andrew Storms for some insight. Storms has been leading IT, security and compliance teams for the past 20 years and his multidisciplinary background includes product management, quality assurance, and software engineering.
Storms is also a CISSP, a member of Infragard, and a graduate of the FBI Citizens’ Academy. Currently, Storms is vice president of security services at New Context. Previously, he was the senior director of DevOps for CloudPassage and the director of security operations for nCircle (acquired by Tripwire). At nCircle, he was responsible for the definition and enforcement of the security programs, delivering EAL3 certification and SOC2 audits, and managed the company’s PCI ASV program.
Storms recently gave a talk at the RSA Conference, How Security Can Be the Next Force Multiplier in DevOps, where he shared his thoughts on how security teams should integrate themselves as business enablers within fast-paced DevOps enterprises.
DevOps.com: What’s your take on DevOps being a force multiplier and enhancing security?
Storms: Much of it [the concern around DevOps] really is rooted in fear. People see that the organization has brought together the developer and the operations team and they fear that everything will become the Wild West. However, we’ve shown over and over through the years that bringing these teams together actually has huge positive impact.
Unfortunately, too many people in security view it differently. They think that they’ve lost control of a situation that they barely had control over to begin with.
DevOps.com: What are the best approaches for integrating security with DevOps?
Storms: There are two approaches to this. One of the best ways to bring DevOps and security together is to utilize the tools and the processes that DevOps really excels at and apply them to security – things like automation, orchestration, and instrumentation. Let’s use those tools to build these closed-loop security systems where everything’s automated and everything’s predictable. That’s a way we actually can fulfill the security requirements in an automated fashion with fewer resources.
Another is to treat security more as an enabler. Security has fallen into the pitfall that, instead of being an enabler to the organization, it is all about ‘No.’ There’s pushback on new initiatives for fear of falling out of regulatory compliance, or being breached. Instead, the organization needs to take a different approach. It should view security as a business enabler, just like IT and operations.
In this way, it can secure new initiatives and actually enable people to focus on their core competencies and allow the company to take educated risks. At the end of the day, that helps to provide more of what the business needs to do, whether that is increase revenue or decrease time to market, or whatever it may be that the company needs.
DevOps.com: Done right, people say that security needs to be integrated throughout all of the processes, but that’s seldom reality. What do you say to security teams about this?
Storms: That’s the approach that I take here with the integration of DevOps and security. Really, if we think about it, the integration of Dev and Ops together in DevOps has actually opened the door for security to come in and do something very similar – to come in and work more collaboratively and integrate itself more closely with the rest of IT.
What security professionals need to recognize here, but often don’t, is that DevOps is an opening. Take it. That is to say: Don’t fear DevOps; embrace it. Address the fear, and then learn about DevOps, and see where you can integrate security people, processes, and technology.
DevOps.com: When integrating the people, processes, and technologies that help forward security interests in DevOps, I imagine it takes time and effort to go back and review a lot of those controls, to make sure that they’re up to speed with the way people actually work today.
Storms: I think that’s one aspect. I think the other aspect is, if we look at the manifest of Agile, which is the ability to take and see change and adapt, all of those controls, to some degree, still make sense. They just need to be adapted to the modern way that code is developed.
One of the great examples I like to share is a health care company I worked with. It is deep into continuous deployment but has all kinds of compliance requirements. So, it can’t just centrally deploy code at any time it wants without all the compliance check-offs that have to happen.
It has to run application security and compliance checks. So, it automated them, to the point where the auditors are happy. When their code gets pulled in to master, it runs it through many types of integration and security tests.
DevOps.com: What happens if there is an issue; how is it resolved?
Storms: The company has put in automated checks. Think of it as kind of a speed bump; for example, when an event happens, there’s a message that is sent to the chat room [See: ChatOps, Communicating at the Speed of DevOps], and there’s a Hubot that watches the messages. The Hubot has logic that says, right before they’re ready to go, you need to stop and alert the chat room that this event needs to happen, and it needs N number of people to approve it.
For example, it may require that there be a product manager, there must be a security manager, there must be an ops manager, and so on. And they’ve got logic in there that says if the right number of people in the chat room all respond with a keyword – let’s just call it “yes” – then let’s actually capture all of that, enter a log message to go ahead and approve the release, and push it out automatically.
If an issue is found in the tests or in the approval processes, then it has to be resolved, and is then moved forward along the pipeline.
With this continuous pipeline, the company actually has all of the steps, all the compliance requirements, and the audit log. Thus, it still can maintain compliance requirements, and security. That’s what DevOps and security should be all about.