One of the areas I research is application security – not only how to develop applications that are more secure, but also how applications should be architected to consume security services. The former is increasingly important as the bad guys move “up the stack” to target applications and information. Secure application development is a priority for nearly every organization I talk with. Whether they are developing their own applications in-house or outsourcing development to a third party, the concern is the same: how can I produce applications that are more secure?
My colleague, Joseph Feiman, and I research application security testing tools, methodologies and best practices. For example, we recently published our magic quadrant rating of static application security testing (SAST) tool vendors. The interest in these tools is remarkable. The market for SAST tools has doubled every year for the past several years. However, we’ve talked with a number of clients that purchased a tool which later becomes expensive “shelfware” or where the project was halted after delivering mixed results. What went wrong? Too much emphasis on a product and not enough on process. Since the lack of a SAST tool wasn’t the root of their problem, purchasing a tool couldn’t be the complete answer. A tool alone cannot solve what fundamentally is a development process problem.
This week, Fortify and Cigital released the results of their study (The “Building Security In Maturity Model”) of nine organizations which have implemented a secure application development process. The resulting study contains a multitude of common activities and best practices observed in these organizations. While a few of the activities are not practical for every organization (for example AM3.1 “Have a science team that develops new attack methods”), the value in the study is that it collected and documented which activities have worked in the real world. Rather than try and implement every activity listed, you pick and choose which practices make sense for your organization.
Out of the one hundred or so activities the study documents, the use of automated tools are a small fraction. I believe this makes my point exactly. Automated security testing tools? Great. But they represent only a small fraction of what we need to do to produce secure applications. To be successful, we absolutely cannot ignore the associated process and mindset changes necessary.