We recently hosted a webinar, with special guest Chris Condo of Forrester Research, to help security professionals better understand the challenges developers face in the lightning-fast paced DevOps world – and to explain how they can fully embed themselves into the DevOps process. We received a number of thoughtful questions during the Q&A portion of the webinar. Following are some highlights from this interactive discussion.
Q: Throughout the webinar, we discussed the importance of security taking on a services role. This service responsibility concept is very important as we think about how different groups and multi-disciplinary teams can interact with one another. How you do see service responsibility breaking out for application-level security concerns?
Chris: What the “you write it, you own it” mentality really means is that it’s security’s job to empower the development team by helping them to fully understand what the threats are and educate them – not just on the architecture – but also on how they will host each particular application. They need to understand how it’s going to be secured, how to deploy the code to that machine, etc.
At one time, you might have had a person on the operations team who pushed code out to a server based on a list of written instructions (here’s how to configure the server, here’s how to load the software package, etc.) and expected things to work magically. But of course, this never works. What’s transformed from that era is that the development team has taken on a true ownership role, because security and infrastructure folks realize that they [the development team] are the ones who truly know the application best.
What I see working best is when development kicks off a project by engaging the security team, saying, “Hey, I’m going to develop this product, it needs to be delivered in six months and I need to get your insights on what we should be doing along each step of the way.”
Q: What should those initial conversations between DevOps and security teams look like?
Chris: There are a host of questions about what goes into product development that developers don’t necessary know to ask initially. Thereforer, it’s important that security is involved to walk through those questions from the start. For example, the first thing that should be addressed is what kind of data will be stored. Who’s going to use it and, in which geographies? How many people are going to use the product? What kind of technologies are used to build the application? Are contractors involved? Is the product going to being developed in other countries, outside of the United States, for example? Who’s the customer?
Then, as development gets closer to delivery, it’s important to address questions such as, how is the application going to be hosted? What’s that going to take? How many servers are needed? Then, close collaboration with security is necessary to address network security and infrastructure security requirements. Sit down together and have a discussion about how the application is evolving and what needs to happen. Lean on the security team as you would a consultant or advisory team – look to them for best practices and proven advice.
Q: How does automation play into this collaborative approach?
Chris: Automation makes parts of the code development process more opaque. It means that somebody could insert code that shouldn’t be there. It also allows teams to do things undercover that at one time (when the coding process was manual) would have been very transparent, such as an automated deployment to a test environment.
That’s why it’s so important that the DevOps team (or whoever owns building that DevOps chain) consults with the security team upfront, letting them know what they are doing, showing them which tools require which types of of privileges to run and confirming what needs to happen when a particular CI tool requires admin access, for example. You need to be proactive and start thinking about how to isolate those tools if they can’t be replaced with any other tool, or how to build other types of methodologies, so that the methodology used to build the software is also secure.
Q: Where do you see security budgets, efforts and mandates coming from? Is it coming from within the line of business? Is it more central? And how do you see that playing out in terms of how companies address security problems?
Chris: What often happens within these distributive models is that everyone adopts the attitude of, “Well, I own my own DevOps tool chain, so I’ll do what I want.” The reason why they feel like they can do that is because they don’t own the responsibility for security or the execution of security principles. They simply leave it to security to be the heavy-handed person who comes in at the end and says, “Oh, hold on a minute, let’s put on the brakes and go through all these checklists.” That’s when you end up in a stand off. Instead, the CIO or CTO should say, “Listen development team, if a security feature goes out the door and you break some sort of policy, it’s on you. You need to be the holders of the security execution.” The security team is going to tell you what you need to do, but it’s your job to get it done.”
Successful teams often establish a center of excellence. They pull experts from various teams – similar to the Spotify Guild strategy – to meet with some frequency and discuss best practices to collaboratively find solutions that can provide both speed and security.
Q: Any closing thoughts?
Chris: An essential first step is getting executive buy-in to the fact that security and development is a joint process and conveying the value of incorporating security upfront and throughout entire development process. The sooner security’s voice is heard, the less expensive the project is actually going to be.
Editors Note: These responses have been edited for clarity and brevity. You can tune in to the webinar recording to watch the full presentation or check out additional highlights in this blog post.
