Who is responsible for application security within your organization? While this is something I don’t hear asked very often, when I look around the implied answer is the security team. This isn’t just limited to application security either. Look at network security. Who, in your organization, is responsible for network security? From my experience, the answer is still the security group. But is that how it should be? Is there a better way?
Security has spent a lot of effort to take and accept all of this responsibility. How often have you heard that security is the gate keeper to any production releases? Security has to test your application first. Security has to approve any vulnerabilities that may get accepted. Security has to ….
I won’t argue that the security group has a lot of responsibility when it comes to application security. However, they shouldn’t have all of it, or even a majority of it. If we take a step back for a moment, lets think about how applications are created. Applications are created by application teams which consist of app owners, business analysts, developers, testers, project managers, and business units. Yet, when there is a security risk with the application it is typically the security group under fire. The security group typically doesn’t have any ability to write or fix the application, and they shouldn’t. There is a separation, but are you sure you know where it is?
I have done a few presentations recently where I focus on getting application teams involved in security. I think it is important for organizations to think about this topic because for too long we have tried to separate the duties at the wrong spot.
The first thing I like to point out is that the application development teams are smart, really smart. They are creating complex business functions that drive most organizations. We need to harness this knowledge rather than trying to augment it with other people. You might find this surprising, but most application security tools have GUIs that anyone on your app dev teams can use with little experience. Yet, most organizations I have been into have the security group running the security tools (such as Veracode, Checkmarx, WhiteHat, Contrast, etc). This is an extra layer that just decreases the efficiency of the process.
By getting the right resources involved with some of these tools and tasks, it not only gets security closer to the source, but it also frees up the security team for other activities. Moving security into the development process increases efficiency. Rather than waiting on a scan by the security team, the app team can run the scans and get the results more quickly. Even better, they can build it into their integration process and most likely automate much of the work. This changes the security team to be reserved for the more complex security issues. It also makes the security team more scalable when they do not have to just manage tools.
I know what you are thinking.. But the application team doesn’t understand security. I will give it to you, in may organizations this is very true. But why? Here we have identified what the problem really is. Currently, security tries to throw tools at the issue and manage those tools. But the real problem is that we are not focusing on maturing the application teams. We attempt to separate security from the development lifecycle. I did a podcast on discussing current application security training for development teams.
Everyone has a responsibility for application security, but we need to put a bigger focus on the application teams and getting them involved. We cannot continue to just hurl statements about getting these teams involved over the fence. We say to implement security into the SDLC, but rarely are we defining these items. We say to educate the developers, but typically just provide offensive security testing training, 1-2 days a year. We are not taking the time to identify how they work, how their processes flow, etc. to determine how to address the problem.
Take a look at your program and really understand it. What are you currently doing? Who is performing what roles? What resources do you have and are you using them effectively? What type of training are you providing and is it effective regarding your goals?
We will be discussing more of these topics in the future. To get started in your own organization, start with the questions above. Want to talk more about these topics? Contact us
James Jardine is the CEO and Principal Consultant at Jardine Software Inc. He has over 15 years of combined development and security experience. If you are interested in learning more about Jardine Software, you can reach him at james@jardinesoftware.com or @jardinesoftware on twitter.