Testing your software for vulnerabilities is important. There’s no doubt about it, but if there’s something I’ve learned over the years when it comes to application security, is that you can’t test yourself secure. The reason is that development teams are writing new code all the time and if your main approach to securing the code is testing, it quickly becomes a never-ending cycle of testing –> fixing –> repeating. This is a lot like treating the symptoms of malady.
What you really want is a cure for the malady.
Most industry experts agree that the cure for insecure applications is to implement a secure Software Development Lifecycle (SDLC).Having a secure SDLC essentially means that you’ve incorporated discrete security activities into your organization’s development processes. It’s proactive versus reactive. Let us not be confused, testing (whether it’s static, dynamic, or manual) is extremely valuable, but it is just one aspect of more than 100 activities that could be done.
The greatest value that an organization can derive from implementing a secure SDLC is in the more polished products that emerge without having to break the builds. The most well-known case of an organization implementing a secure SDLC was the software giant Microsoft. In the late 1990’s and early 2000’s, Microsoft was beleaguered by security vulnerabilities in its products. They were being hammered by viruses and worms like Nimda and Code Red. It was so bad that respected research firm Gartner recommended that everyone immediately stop using Microsoft’s IIS web server. In January 2002, Bill Gates sent his now-famous Trustworthy Computing memo to Microsoft employees. From that starting point, the company proceeded to implement what they call the Security Development Lifecycle, or SDL. As time went on, this dramatically reduced the number and severity of vulnerabilities in their products.
It’s important to recognize that implementing a secure SDLC is not something that happens overnight. It is a process, most effective when rolled out in phases, and it may even take several years. In fact, as an integral process within the development lifecycle it probably won’t ever be “done”. As such, a secure SDLC initiative goes hand-in-hand with a software security maturity model.
Recently, my company hosted Joel Scambray, co-author of the popular “Hacking Exposed” books, to talk about software security. The focus of Joel’s talk was the Building Security In Maturity Model, or BSIMM. The BSIMM is an annual survey of leading companies and the objective is to observe, classify, and quantify the activities happening within real secure SDLC initiatives.
The most recent BSIMM includes 112 activities. Examples are:
- Create evangelism role and perform internal marketing
- Impose policy on software vendors
- Provide awareness training
- Include security resources in on-boarding
- Create security standards
- Use a risk questionnaire to rank applications
- Use automated static analysis along with manual code review
- Include security tests in QA automation
- Use external penetration testers to find problems
- Require security sign-off for compliance risk
- Operate a bug bounty program (this is a new activity added in the most recent BSIMM)
The BSIMM provides a framework and can serve as a guide during the implementation of a software security initiative. All of the various activities are classified under 4 domains and 12 practices as follows:
Using this framework you can rate your company’s software security maturity to get an idea where you stand. You can also compare yourself to the best – the top 10 most mature organizations – using the spider chart shown below.
Each spoke on the chart represents one of the 12 practice areas. Level 3.0 at the outside edge is more mature than level 0.0 at the center. I believe that using a chart like this is a great way to track the progress of your secure SDLC initiative. As you become more mature, the line you plot will expand closer to the outside edge.
So, if you want to cure the malady of insecure applications at your organization, I recommend taking a look at the BSIMM, which you can download for free at http://www.bsimm.com.
Dave Ferguson is an experienced Application Security professional currently working at a large enterprise in the U.S. With a 12-year career as a software developer under his belt, he transitioned to a role in Application Security. He served as a Principal Consultant with a leading information security company and as well as a Solutions Architect with an application security vendor. Dave holds CISSP and CSSLP certifications, is an OWASP member and contributor since 2006, and authored the OWASP Forgot Password Cheat Sheet.
For more AppSec posts from Dave, check out his blog!
Note: While Dave writes about the Building Security in Maturity Model there are several other standards available to model your secure Software Development Lifecycle on. OWASP maintains one such project with the Software Assurance Maturity Model, or SAMM, Software Innovation touts an Application Security Maturity Model, and, as Dave mentions, Microsoft’s Secure Development Lifecycle continues to be maintained and updated.