Welcome to Riskbloggers.com

Feb 22 2006

The following post is an excerpt from a new whitepaper I have released about developing secure software. You can access the full whitepaper at the Secure Software Forum website.

Application Security Assurance Program (ASAP) â€“ Extending Secure Software Development to all Enterprises

At the Secure Software Forum (SSF) held during the February 2005 RSA Conference, SPI Dynamics coined the term Application Security Assurance Program (ASAP), to describe the need to integrate security throughout the software development lifecycle and throughout the production lifespan of the application. By SPI Dynamicsâ€™ definition, the program must be holistic, providing end-to-end lifecycle coverage while spanning People, Process and Technology.

Another way of putting it might be to say that all organizations should implement their own Trustworthy Computing Initiative tailored to their own needs. An ASAP must be comprehensive, however it is premature to provide granular recommendations as to the very best development methodologies and other specific guidance at this point. However, based upon our first year of SSF activity, we are providing some more industry feedback in the form of a maturity model.

The ASAP Maturity Model

Through the data gathering at the SSF executive events augmented by additional research, we have arrived at an ASAP Maturity Model, which we are presenting as a recommended benchmarking model and migration path for organizations seeking to build secure software. The ASAP Maturity Model is a three level cumulative approach. By this we mean that an organization that has mastered the top level also continues to include all previous levels in their program. Of course we have seen organizations that approached secure development initiatives in a different order (or even attempted all at once), however the many data points from SSF executive events showed this model to clearly be the most common roadmap.

Level One â€“ Silos

In the first level of the ASAP Maturity Model, concern for secure software development resides primarily within the information security department. As part of overall information assurance and using risk management practices, the IS department takes the initiative to test web applications for development defects that create security vulnerabilities.
While this security testing can be done in many ways, typically it relies upon some utilization of web application testing tools to provide a hackerâ€™s eye view of web applications. In level one, the IS department typically has limited success in extending the initiative to outside departments.
The developer teams, while certainly conscientious about the generic issues of security for several years, are not implementing any specific programs related to security and often see it as antithetical to time to market drivers.

Level Two â€“ Cross-Functional

In the second level, true progress is made in achieving cooperation across departments. The security and developer teams may collaborate on security awareness programs for developers. The typical developer awareness course that makes a strong initial impact is along the lines of â€œWeb Application Hackingâ€, where developers see their own applications or similar software hacked by an educator with penetration testing and assessment skills.
This demonstration is augmented by a discussion of top development mistakes leading to security vulnerabilities, such as a failure to perform input validation. In level two organizations, the quality assurance department and developers may both have some of their own security tools for testing software and auditing code. While they can vary widely, in general organizations are making the most substantial progress in two of the three fundamental pillars of secure software development: Technology and People.
Level two organizations are relatively unsophisticated when it comes to processes specifically geared towards secure software development. Generally, these organizations are utilizing project management methodologies to drive the program, with loosely documented software development lifecycles.

Level Three â€“ Executive Buy-in

In the third level, the organization continues to innovate and improve their ASAP. From a technology perspective, the organization implements a framework to manage and integrate all the point solutions and pockets of innovation through out the enterprise. Management technology enables collaboration and provides greater decision support capabilities.
Examples of this on the developer side include solutions such as Microsoft Studio Team Systems, which provides workflow and collaboration capabilities, creating opportunities to reinforce corporate policies and creating greater accountability on the part of developers.
A cross-functional example is SPI Dynamics AMP, which manages multiple instances of their web application testing solution, WebInspect, as well as QA testing and developer tools.
From a people perspective, education has evolved from basic awareness to a full-blown curriculum, addressing the varied security needs of developers and working outward to other targets. Developers will get training on a variety of topics spanning languages, databases, design theory, threat modeling and other important issues. Related education is offered to non-developers to help them understand their role in the company-wide effort to build more secure software. Quality assurance groups, traditionally tasked with testing the performance, usability and functionality of software, will often participate in educational programs geared both towards developers and security practitioners, owing to their unique position in the development lifecycle.
Notably, organizations that are at level three have relatively sophisticated processes in place in support of secure software development. These enterprises tend to have security integrated at various points within their software development lifecycle (SDL), similar to the block diagram depicting Microsoftâ€™s processes. A level three organization uses policy enforcement mechanisms to assure that process is followed.
In level three, not only is there mastery of each of the foundational pillars (People, Process and Technology), but there is also integration of the pillars to create additional organizational value and higher quality software. For example: the use of tools helps educate developers regarding best practices and reinforce good behavior, management tools also help automate the processes and enable better decision making and educated users learn to follow processes more accurately and effectively.
Perhaps the most important part of level three and the reason that it is successful is the notion of executive buy-in. It is only possibly to drive this level of change within an organization with top down initiatives, while levels one and two are grass roots efforts.