In my last post I touched on five reasons for organizations to take a programmatic approach to dealing with application security. Having a program allows the organization to address the full scope of the problem with better information for decision making, and a roadmap for managing organizational change. The natural follow-on question is: how does one get a program started? So here are five tips for getting your application security program started.
1. Look for quick win projects that align with your strategy. The thing about strategy is that it gets implemented one step at time. That first step, your first project has to be successful and has to demonstrate that the programmatic approach was integral to that success. It could be starting a security attestation program to ensure that software purchased from small ISVs is compliant with a basic security policy – e.g. no SQL injection flaws allowed. It could be a PCI compliance project for a particular number of applications. It could be an online developer training project – where developers take some classes. The key here is that regardless of what you choose your first project, it should be scoped so that it can succeed quickly.
2. Determine how you will find your applications. We’ve seen several programs get off to a slow start because the security team assumed there was a readily available and accurate list of applications and application owners. More often than not, the federated nature of most large organizations results in inaccurate application inventories. Loose enterprise-wide inventory cataloging is typical when individual business units have the autonomy to build, buy, or outsource new applications. Tracking application ownership is also challenging because business units are charged with new objectives or merged with other groups or acquisitions. It is common to see application ownership and responsibility shift without clear hand-offs or tracking. Spending some time early to develop pragmatic approaches to discovering and understanding the application inventory will go a long way to ensuring the success of your first project and position you to continue to advance your strategy.
3. Design broadly applicable policies. Well defined policies can be consistently applied to a wide variety of applications, regardless of the source of those applications. As an enterprise organization adds new applications to its portfolio, policies can be manually or automatically assigned a security assessment policy commensurate with its expected usage. Using the same suite of policies across the application portfolio ensures consistent standards of security acceptance and a solid basis on which to assess the risk to the organization.
4. Remember that the remediation effort requires resources as well. The goal of an application security program is to manage risk by fixing application vulnerabilities according to their severity and potential business impact. Part of your security assurance program should include security expertise to assist developers understand the results of the tests, explain why code patterns are secure or not, and discuss how to remediate the found flaws. It’s the reason why we packaged remediation assistance into every one of our support packages. The packages give customers access to security folks who are used to working with developers every day. For applications that are not under active internal development, there will be no development team to complete the remediation. Many of our clients outsource the remediation efforts, we have several partners that do that.
5. Integrate, integrate, integrate. Take every opportunity to embed security assessment and learning into the basic fabric of your software development processes. Remediating software quality issues during developmental phases is more cost-effective than post-production remediation. In our experience, that fact is also true for software security remediation. However, take the time to design an integration approach that matches the team’s development methodologies. While some development methodologies can leverage a traditional stage-gate based security testing, Agile or LEAN development probably need a different approach. For example, Veracode APIs and plugins enabled a global insurance company integrate 26 different development teams, each with different SDLC methodology requirements. Integrating security should not require the teams to change how they interacted with their code or how they identified and fixed defects.
So those are five tips for getting a program started. We’d love to hear any other tips and tricks from others that have started application security programs.