Industry Standard Secure Development Methodologies and Maturity Models
The activities we’ve discussed in this chapter are a good foundation for building your own secure development methodology. However, when you’re ready to move to the next level, it would be worth your while to take a closer look at some of the industry standard secure development programs. These programs include (but are not limited to) Microsoft’s Security Development Lifecycle (SDL), OWASP’s Comprehensive Lightweight Application Security Process (CLASP), the Software Assurance Maturity Model (SAMM), and the Building Security In Maturity Model (BSIMM).
The Microsoft Security Development Lifecycle (SDL)
The year 2001 was difficult for Microsoft security. In July of that year, the Code Red worm hit the Internet, attacking and defacing millions of web sites through a vulnerability in the Microsoft Internet Information Server (IIS) web server. This attack was followed only two weeks later by the Code Red II worm, and then the Nimda worm after that. At this point, John Pescatore, Vice President and Research Fellow for the Gartner technology analyst firm, recommended that companies migrate off the IIS web server and onto its competitor Apache immediately. Pescatore compared running IIS to owning a finicky car, saying “If you got hit by Nimda, you’ve proven you can’t keep up with the security problems of IIS. It’s like a car: don’t buy a Fiat unless you’re prepared to get it fixed a lot.”
Clearly, something had to be done inside Microsoft to turn the ship around, and in January 2002 Microsoft CEO Bill Gates sent a memo to every employee instructing them to emphasize security in their products, and to choose security when faced with the decision between adding new features or resolving security problems. The “Trustworthy Computing Memo,” as it became known, eventually led to the creation of the Microsoft Security Development Lifecycle (SDL) process that is now mandatory for all Microsoft product and services teams.
The SDL specifies tasks for development teams to perform over the course of their product development lifecycle. You can see a graphic of these tasks in Figure 9-6. We’ve already covered many of the basic SDL tasks in this chapter, such as threat modeling, use of static and dynamic (black-box) analysis tools, and creation of a security incident response plan. The SDL additionally specifies some more advanced-level tasks such as attack surface reduction (removing or disabling rarely used functionality, running under low-privileged accounts, and so on) and fuzz testing (throwing thousands or millions of random malformed requests at an application to try to make it crash in unexpected and potentially exploitable ways).
Figure 9-6 The phases and activities of the Microsoft Security Development Lifecycle
The SDL is based on a waterfall-style development methodology in which there are distinct development lifecycle phases. There is a well-defined requirements-gathering phase, followed by a design phase. Once the design is complete, the developers start coding. Once the code is complete, the testers begin testing, and so forth. While this made sense for Microsoft back when the SDL was first being developed—after all, this is the way that big Microsoft products like Windows and Office were built—it’s less applicable now for web application development for both them and everyone else. As we mentioned earlier in the chapter, many web development shops follow a more Agile development methodology like Scrum. Scrum release cycles come in “sprints” that lack strictly defined phases.
To address the difficulty of completing SDL tasks in such an environment (and to address the difficulty of completing so much security work in the space of a one-week-long Agile release cycle), Microsoft developed an adaptation of the original SDL process called SDL-Agile. SDL-Agile prescribes all of the same activities that the classic SDL does, but it reorganizes the activities based on the frequency they should be performed. For example, static analysis is both relatively quick and easy to perform, and is very useful in finding potential vulnerabilities, so it should be performed during the course of every sprint. However, fuzz testing takes much longer to perform, and finds fewer vulnerabilities (at least for average web applications), so it only needs to be performed once every six months.
If you’re interested in learning more about either the SDL or the SDL-Agile development process, you can read about them on the SDL home page at www.microsoft.com/sdl.
OWASP Comprehensive Lightweight Application Security Process (CLASP)
Another widely used secure development process is the OWASP Comprehensive Lightweight Application Security Process, or CLASP. CLASP was originally developed as a commercial methodology by the source code analysis company Secure Software, but was donated to OWASP in 2006 and made freely available. Like SDL, CLASP specifies development lifecycle activities for teams to perform in order to make more secure, resilient software; however, where SDL categorizes these activities by lifecycle phase (and SDL-Agile categorizes them by frequency), CLASP categorizes them by role. Each contributor to a CLASP project fits into one or more of these seven roles:
Project Manager
Requirements Specifier
Architect
Designer
Implementer
Test Analyst
Security Auditor
Each of these roles has different responsibilities and actions to perform over the course of the project. For instance, the project manager is responsible for promoting awareness of security issues both inside and outside the product team. When other teams within the organization (such as Sales) put pressure on the product team to hurry their ship date or to cram in new features, it’s the project manager who stands up for security to ensure that essential security activities don’t fall by the wayside. On the other hand, the responsibilities of an architect are entirely different. The architect’s role is to model security into the system, to determine where trust boundaries exist between components, to specify how and where security technologies such as firewalls integrate into the system, and to identify the different user roles that the system will support.
In a nice touch, the CLASP documentation includes two sample roadmaps to help teams get started with the process: one roadmap for new, “green-field” projects, and a separate roadmap for established, legacy projects. The green-field roadmap presents a more comprehensive and thorough approach to security engineering processes, whereas the legacy roadmap includes just the CLASP activities with the highest return on investment so as to minimize the impact on established projects.
You can read more about the CLASP project on its home page on the OWASP site at www.owasp.org/index.php/Category:OWASP_CLASP_Project. If you’re on the fence as to whether to go with SDL or CLASP, an independent research paper written by S. K. Pandey, K. Mustafa, and S. Rehman (http://www.srehman.110mb.com/web_documents/clasp_sdl-revisted.pdf) for the Second International Conference on Information Processing in 2008 compared the two processes in detail. They came to the overall conclusion that SDL is more rigorous but also more heavyweight, and that it would be a better fit for large organizations, whereas CLASP is more appropriate for smaller organizations with “less strict security demands” due to its more lightweight nature.
The Software Assurance Maturity Model (SAMM)
Pravir Chandra, the project lead for the OWASP CLASP project (and currently Director of Strategic Services for HP Fortify), has also developed a security maturity model named the Software Assurance Maturity Model, or SAMM. (You may be more familiar with this project under the name OpenSAMM, which is yet another OWASP project dedicated to maintaining and updating the SAMM model.) SAMM starts by defining four business functions, collections of processes and activities that all software development shops perform. The four functions are:
Governance, or the management of software development
Construction, or the design and coding of software
Verification, or the testing of software
Deployment, or the shipping and support of software
Within each critical business function, SAMM defines three distinct security practices that are key to improving software security assurance for that function. These practices vary between business functions; for example, the governance function is concerned with setting policy and ensuring regulatory compliance, where the deployment function is concerned with hardening the environment that the application is deployed into. You can see a complete list of the 12 security practices in Table 9-4.
Table 9-4 The Business Functions and Security Practices of the Software Assurance Maturity Model
Finally, for each security practice, SAMM defines four maturity levels, starting at level zero (unfulfilled) and moving towards level three (mastery). Each maturity level is defined by an objective and a set of activities to accomplish this objective. For example, the objective to attain the level one maturity stage of the design review practice is for the organization to “support ad-hoc reviews of software design to ensure baseline mitigations for known risks.” In order to accomplish this, the team must identify the potential attack surface of their application and check their application’s design against a set of predefined security requirements.
If you’d like to read more about SAMM or to take a self-assessment quiz to gauge your organization’s maturity levels for each of the SAMM practices, visit the OpenSAMM web site at www.opensamm.org.
The Building Security In Maturity Model (BSIMM)
In March 2009, a group of security experts from Cigital and Fortify released the Building Security In Maturity Model, or BSIMM for short. BSIMM is somewhat similar to SAMM in that it’s a maturity model with four high-level domains (governance, intelligence, secure software development lifecycle [SSDL] touchpoints, and deployment) with three defined practices for each domain. Table 9-5 lists the specific BSIMM domains and practices.
Table 9-5 The Domains and Practices of the Building Security in Maturity Model
Note
Both BSIMM and SAMM are rooted in the same research; Pravir Chandra has referred to the projects as forks.
Again, like SAMM, BSIMM defines maturity levels for each practice and sets of activities to take you from one level to the next. However, there is one very important difference between the two models. The activities defined by BSIMM don’t come directly from the BSIMM authors’ experience in creating secure software; instead, the authors interviewed security executives at 30 organizations with world-class software security initiatives and created the BSIMM activities from the commonalities that those organizations reported. So the security testing activity to ensure that quality assurance engineers include edge case tests in their test plans comes from the fact that most of the 30 organizations interviewed also perform this activity. As a result, BSIMM is not meant to be prescriptive; it is only meant to be descriptive. Instead of thinking of it like a cookbook full of recipes, the BSIMM documentation states, you should think of it like a trail guide full of waypoints.
If you’re interested in learning more about BSIMM or in having your organization potentially included in the results of future BSIMM studies, visit the BSIMM web site at bsimm.com.
Conclusions on Secure Development Methodologies and Maturity Models
While the secure development methodologies are considerably larger in scope than the steps we’ve laid out here, they do also offer correspondingly more assurance that the resulting application will be secure from attack. And there’s no rule that says you have to take any of these processes as gospel and follow them to the letter; feel free to pick and choose those activities you think will best suit your team and its capabilities. But do always try to at least accomplish the core set of process steps we’ve covered in this chapter.
Baking security in
The cost benefits of finding security issues as early as possible
The dangers of a penetrate-and-patch approach to application security
The holistic approach to application security
Security training
Threat modeling activities and tools
Secure coding libraries
Manual and automated security code review
Security testing and black-box application scanners
Incident response planning
Industry standard secure development methodologies and maturity models
The Microsoft Security Development Lifecycle (SDL)
The OWASP Comprehensive Lightweight Application Security Process (CLASP)
The Software Assurance Maturity Model (SAMM)