Last week’s story, Caution: DevOps Ahead, caused a small stir on Twitter and sparked a response, DevOps: Security’s Last Best Hope, from DevOps.com’s Alan Shimel.
Coincidently, I recently had a conversation with Bill Burns, former director of IT security and networking at Netflix. Burns is currently an executive-in-residence at ScaleVP, where he provides strategic advice in the security market. He has experience managing security in hybrid cloud/IT environments and traditional IT environments. We thought now would be a perfect time to share his thoughts on how security can potentially be improved in organizations that embrace DevOps.
Here’s our talk:
DevOps.com: What impact do you think DevOps has on its security teams? How should traditional security practitioners look at that movement?
Bill Burns: DevOps could improve security if it’s done well, and more importantly I think if the business really buys into DevOps. What I noticed, especially at my prior company, was that as product teams were moving to DevOps, everybody was coming to the table with bite-sized building requirements. They weren’t ginormous, “Okay, we’ll do this in the next six months,” but instead: “What do we accomplish in the next two weeks? The next sprint cycle?”
It forced you to think of the problems early on and know that you would attack them in bite-sized chunks. The security team had to not just throw requirements over the wall, but had to participate in the design phase and in the negotiations.
With DevOps, you don’t have this ginormous build cycle where many things can go wrong and tests are often done at the very end. In that sense, if it’s done well, incorporating security into DevOps is sort of holy grail for a really robust software development lifecycle with security.
Everyone says they want to put security upfront within the design requirements and in the architecture. Because you don’t have the upfront cost of a large architecture phase, and you are iterating, it’s an opportunity for the security team to do that and to participate in tighter feedback loops both with developers and with operations.
DevOps.com: Well, it sounds like security teams could very well fall on their faces if they tried to be too rigid with DevOps.
Bill Burns: Yes. It’s the same as if an operations team came in and said, “Well that DevOps stuff is great, but this is the way we do operations.” They would become irrelevant pretty quickly.
It’s also an opportunity for the security team to become more consultative and advisory in nature. With DevOps, security can say, “These are the most important things to focus on now.” Maybe those things are the session handling or the encryption. For those critical things, it’s best to start on them right away. Whereas the things that are important, but not critical, can be handled later on and over time.
And security should be agile enough to pivot with the developer team to handle what it needs to do and make the incremental security improvements as the product changes.
DevOps.com: What are some of the barriers security teams face when trying to be a part of the conversation in a DevOps environment?
Bill Burns: What I’ve seen to be effective is, first of all, to approach the product team or the development team as an adviser. Also, speak honestly and say that you may not have all the answers right away, but that you’ll be a part of the process and learn as the project matures. Start with some of the best practices that you know should be a part of development early, and list things that you will want to be added later.
If you can prioritize the most important security issues along with the rest of the product team, they’re going to go through the process and will have a better understanding – and security is improved.
I also think it really helps if the security team members are not solely infrastructure-focused. That they’re not just trying to figure out how to get their intrusion detection system to participate, or how to get your security product to snap into the system. I think DevOps is forcing the security teams to become more like developers. I’ve noticed that a security team becomes more of an application security team and less about buying products and bolting them on.
Ultimately, the security team is not the risk owner. It’s the adviser. And I believe this is true for many organizations even though many don’t realize it. The security team, in my view, should say: Here’s our analysis. Here’s our impact. Here are our threat models.
And in that process, security can say that it thinks something is really important and a big risk. But, ultimately, the decision whether to accept the risk is on the product owner or business owner – not on the security team.
