"We have tripled the size of the data set to thirty firms, including Adobe, Aon, Bank of America, Capital One, The Depository Trust & Clearing Corporation (DTCC), EMC, Google, Intel, Intuit, Microsoft, Nokia, QUALCOMM, Sallie Mae, Standard Life, SWIFT, Symantec, Telecom Italia, Thomson Reuters, VMware, and Wells Fargo." -- Gary McGraw, co-author of BSIMM2
Evolving Rapidly, BSIMM2 Offers Key Elements of Successful Software Security Initiatives Shared by 30 Major Corporations
By Richard Power
The Building Security In Maturity Model (BSIMM) project is a worthy resource for those serious about software security in their organizations.
In March 2009, I covered the release of the initial BSIMM study here on CyBlog. Now, I am happy to report that BSIMM2 has been released.
As friend and colleague Gary McGraw, CTO of Cigital, one of the project's creators, explains, it is "a measuring stick for software security," and with its number of participants tripled since last year, it is evolving fast.
What is the BSIMM?
BSIMM2 is the end product of the collective work of 635 people working in the software security groups for those thirty organizations.
It is calibrated for use by "anyone charged with creating and executing a software security initiative" (typically, a senior executive) who led an internal Software Security Group (SSG)"charged with directly executing or facilitating the activities described in the BSIMM."
The BSIMM itself is organized around a Software Security Framework (SSF) consists of four domains, with its own goals and practices. Within this overarching framework, the BSIMM documents 109 activities. (See the table above.)
Using the SSF, McGraw and his co-authors, Brian Chess, Chief Scientist and co-founder of Fortify Software and Sammy Migues, Director of Knowledge Management and Principal at Cigital, conducted a series of in-depth fact-finding interviews with executives in charge of the thirty software security initiatives.
The BSIMM approach, "based entirely on the data gathered and processed from the interviews is a practical one," and it reflects a sophisticated understanding of real-world challenges faced by those tasked with software security in operational environments.
"We think the descriptive nature of the BSIMM study is an important characteristic of
the work," the authors remark. "We describe not what you should do for software security, but what successful software security initiatives are actually doing. BSIMM2 can be used to measure your own software security initiative and compare it to others ... One could build a maturity model for software security theoretically (by pondering what organizations should do) or one could build a maturity model by understanding what a set of distinct organizations have already done successfully. The latter approach is both scientific and grounded in the real world, and it is the one we followed.
How to Use the BSIMM
"The best way to use the BSIMM is to identify goals and objectives of your own and look to the BSIMM to determine which activities make sense. Choosing among and between practices is not recommended. In particular, we don’t believe a successful initiative will be able to omit all activity for any of the twelve practices. Put another way, the
data show that high maturity initiatives are well rounded and carry out activities in all twelve practices. In any case, browsing through objectives and noting which appeal to your culture is a much cleaner way to proceed. Once you know what your objectives are, you can determine which activities to adopt. Please note that in our view it is better to put some of the level one activities in each practice into place than to accelerate to level three in any one practice while ignoring other practices. This view is informed by the data we have gathered."
A spider chart from the new study, included in this post, should give you a sense of how to use the BSIMM. This particular spider chart shows data from the twelve financial services firms and the seven independent software vendors that participated in BSIMM2. The chart has twelve spokes, one for each of the twelve practices.
"These charts are created by noting the highest level of activity in a practice for a given firm, and then averaging those scores for a group of firms, resulting in twelve numbers (one for each practice)."
"One obvious comparison would be to chart your own maturity high water mark against these averages to see how your program stacks up."
The Devil is in the Details
To give you a better idea of the granularity of the one hundred and nine activities within the twelve practices and the four domains, I have randomly selected one activity from one practice within each of the domains.
Governance: Strategy and Metrics
SMI.4 Identify gate locations, gather necessary artifacts. The software security process will eventually involve release gates at one or more points in the software development lifecycle (SDLC) or SDLCs. The first two steps toward establishing these release gates is to identify gate locations that are compatible with existing development practices and to begin gathering the input necessary for making a go/no go decision. Importantly at this stage, the gates are not enforced. For example, the SSG can collect security testing results for each project prior to release, but stop short of passing judgment on what constitutes sufficient testing or acceptable test results.
Intelligence: Security Features and Design (SFD)
SFD 2.2 Create SSG capability to solve difficult design problems. When the SSG is involved early in the new product process, it contributes to new architecture and solves difficult design problems. The negative impact security has on other constraints (time to market, price, etc.) is minimized. If an architect from the SSG is involved in the design of a new protocol, he or she could analyze the security implications of existing protocols and identify elements that should be duplicated or avoided.
SSDL TOUCHPOINTS: Code Review (CR)
CR2.3 Make code review mandatory for all projects. Code review is a mandatory release gate for all projects. Lack of code review or unacceptable results will stop the release train. While all projects must undergo code review, the review process might be different for different kinds of projects. The review for low-risk projects might rely more heavily on automation, and the review for high-risk projects might have no upper bound on the amount of time spent by reviewers.
DEPLOYMENT: Configuration Management and Vulnerability Management (CMVM)
CMVM 2.1 Have emergency codebase response. The organization can make quick code changes when an application is under attack. A rapid-response team works in conjunction with the application owners and the SSG to study the code and the attack, find a resolution, and push a patch into production.
To download the study, FOR FREE, from the BSIMM2 site.
Related Posts
From Biometrics to BSIMM , & "50 Hurricanes Hitting At Once!" -- A Report on the Sixth Annual Partners Conference
CyLab Business Risks Forum: Gary McGraw on Online Games, Electronic Voting and Software Security
Fortify & Cigital Release BSIMM -- Integrating Best Practices from Nine Software Security Initiatives