When devising an application security plan, how do you get developers and testers to assume responsibility for security when many don't see it as part of their jobs?
The first thing you need to do is come up with an application security plan to determine whether or not security testing is actually part of the development team's job. Everyone involved in the creation of software is responsible for helping create secure software, but organizations implement software security programs in many different ways. Security testing may or may not fall to the development and quality assurance teams.
Development teams have limited resources and important deadlines. If you ask them to add another set of tasks to an already long list, you are not going to be successful.
Application security plans vary widely. Some organizations provide developers and quality assurance teams with security testing tools, while others rely on an application security team or a third-party organization to handle security testing. Decisions about roles and responsibilities in a security testing program should be made based on a variety of factors, including budgets, regulatory requirements and the organization's culture.
If developers and quality assurance teams are asked to assume responsibility for security testing, you need to look at the incentives and penalties that are put in place to make this happen. Development teams have limited resources and important deadlines. And if you ask them to add another set of tasks to an already long list, you are not going to be successful. The only real way to get development team to take on security testing is to make it an actual, documented part of their job responsibilities as well as part of the organization's development process. To make this happen, you have to have management support as well as a plan to successfully roll out the testing program.
But how do you get management support for your application security plan? I have seen many security teams expend a lot of effort trying to justify software security programs with mixed success. The sad truth is that the most effective justifications for software security initiatives are the result of external factors. Some common ones I have seen include:
- Security breach of an application. Nothing seems to inspire action better than having to apologize to customers and shareholders after a security incident. Incidents certainly have a way of spurring action and freeing up budget; the challenge in organizations like these is to avoid knee-jerk responses and, ultimately, to sustain the security program over time once the immediate sting of the incident has passed.
- Regulatory or compliance requirements. When the Payment Card Industry Data Security Standard (PCI DSS) was updated to include application security controls, a lot of organizations initiated developer training programs and began using security scanning tools and Web application firewall (WAF) deployments. A challenge for organizations adopting software security initiatives as a result of compliance requirements is to use that mandate to increase security, rather than just doing enough to pass an audit.
- Requirements from customers. Boosting the security of the software your organization is building is hard, but improving the security of the software you purchase can be as easy as adding a sentence or two into a purchasing contract. Not surprisingly, when customers start to ask hard questions about security -- and these security concerns hold up actual sales -- organizations suddenly get more interested in software security.
In summary, the first step in your application security plan is to determine who in your organization is responsible for security testing. There are advantages to having both developers and quality assurance teams involved, but this approach is not right for every organization. And if you do make developers and testers responsible, make sure you get management support for including application security testing in the development process. Simply asking developers and testers to do this job because it is the right thing is not sufficient.
This was first published in January 2013