Masaki Kubo at JPCERT undertook the great effort to translate the SAMM 1.0 document into Japanese. It’s available here. I’d like to thank him and JPCERT very much for the effort and the motivation to drive this to completion. Fantastic work!

It’s been a little while since I’ve posted anything to the site, but don’t mistake that for lack of activity! There’s actually a backlog of contributed resources that I’ve been meaning to post here but haven’t had the time to get it done yet. They’re all available via the mailing list with a little digging, but in the next week or two, we’ll try to get them all up here.

As an example, independent testing was a key part of the requirement set – for class C products (C1 and C2) vendors were explicitly required to provide independent testing by “at least two individuals with bachelor degrees in Computer Science or the equivalent. Team members shall be able to follow test plans prepared by the system developer and suggest additions, shall be familiar with the ‘flaw hypothesis’ or equivalent security testing methodology, and shall have assembly level programming experience. Before testing begins, the team members shall have functional knowledge of, and shall have completed the system developer’s internals course for, the system being evaluated.” [TCSEC section 10.1.1] Further, “The team shall have ‘hands-on’ involvement in an independent run of the tests used by the system developer. The team shall independently design and implement at least five system-specific tests in an attempt to circumvent the security mechanisms of the system. The elapsed time devoted to testing shall be at least one month and need not exceed three months. There shall be no fewer than twenty hands-on hours spent carrying out system developer-defined tests and test team-defined tests.” [TCSEC section 10.1.2] The requirements increase as the level of assurance goes up; class A systems require testing by “at least one individual with a bachelor’s degree in Computer Science or the equivalent and at least two individuals with masters’ degrees in Computer Science or equivalent” [TCSEC section 10.3.1] and the effort invested “shall be at least three months and need not exceed six months. There shall be no fewer than fifty hands-on hours per team member spent carrying out system developer-defined tests and test team-defined tests.”

In the past 25 years since the TCSEC, there have been dozens of efforts to define maturity models to emphasize security. Most (probably all!) of them are based on wishful thinking: if only we’d invest more in various processes, we’d get more secure systems. Unfortunately, with very minor exceptions, the recommendations for how to build more secure software are based on “gut feel” and not any metrics.

In early 2008, I was working for a medium sized software vendor. To try to convince my management that they should invest in software security, I contacted friends and friends-of-friends in a dozen software companies, and asked them what techniques and processes their organizations use to improve the security of their products, and what motivated their organizations to make investments in security. The results of that survey showed that there’s tremendous variation from one organization to another, and that some of the lowest-tech solutions like developer training are believed to be most effective. I say “believed to be” because even now, no one has metrics to measure effectiveness. I didn’t call my results a maturity model, but that’s what I found – organizations with radically different maturity models, frequently driven by a single individual who “sees the light”. [A brief summary of the survey was published as “What Measures do Vendors Use for Software Assurance?” at the Making the Business Case for Software Assurance Workshop, Carnegie Mellon University Software Engineering Institute, September 2008. A more complete version is in preparation.]

So how do security maturity models like OpenSAMM and BSIMM fit into this picture? Both have done a great job cataloging, updating, and organizing many of the “rules of thumb” that have been used over the past few decades for investing in software assurance. By defining a common language to describe the techniques we use, these models will enable us to compare one organization to another, and will help organizations understand areas where they may be more or less advanced than their peers. However, they still won’t tell us which techniques are the most cost effective methods to gain assurance.

Which begs the question – which is the better model? My answer is simple: it doesn’t really matter. Both are good structures for comparing an organization to a benchmark. Neither has metrics to show which techniques are cost effective and which are just things that we hope will have a positive impact. We’re not yet at the point of VHS vs. Betamax or BlueRay vs. HD DVD, and we may never get there. Since these are process standards, not technical standards, moving in the direction of either BSIMM or OpenSAMM will help an organization advance – and waiting for the dust to settle just means it will take longer to catch up with other organizations.

Or in short: don’t let the perfect be the enemy of the good. For software assurance, it’s time to get moving now.

About the Author

Jeremy Epstein is Senior Computer Scientist at SRI International where he’s involved in various types of computer security research. Over 20+ years in the security business, Jeremy has done research in multilevel systems and voting equipment, led security product development teams, has been involved in far too many government certifications, and tried his hand at consulting. He’s published dozens of articles in industry magazines and research conferences. Jeremy earned a B.S. from New Mexico Tech and a M.S. from Purdue University.

Over the weekend, we managed to get large parts of the SAMM content imported into the OWASP wiki so that folks can browse the model online. This will also support community contributions for additional material that maps under the SAMM activities. It’ll also help for folks making mappings to existing regulatory standards.

The official SAMM releases going forward will still be made in PDF form for mass distribution.  The wiki version will syndicate some of the content for easy online referencing, but the PDF version is still the authoritative source of SAMM information.

Check it out on the OWASP wiki.

Owner(s): Pravir Chandra

Estimated completion: 2009-05-11

Updates:

• 2009-04-22 – Looked into using XML-based content. This can allow SAMM content to be separated from the graphic layout, thereby cleaning up the workflow a bit. More over, it will also simply translations into other languages as well. Perhaps the biggest win is that applications and tools could also programmatically include SAMM content. So far, this seems the best option.

The process is based around the concept of a SAMM Enhancement Proposal (SEP). Each should represent a logical change or addition to the SAMM material. And, each SEP is numbered so that we can sanely discuss and debate the pros/cons of the proposed change.

Overall, the master plan is to have volunteers send ideas to the mailing list first, and then after initial discussion, we’ll create a SEP for tracking and posterity. The website has been updated to reflect this process under the Roadmap tab.

• Disciplines became Business Functions – The term ‘disciple’ used for the four high-level categories didn’t accurately capture their intent. After several discussions, it made more sense to rephrase them as the core business functions of software development and draw the security-related practices down from those.
• Strategic Planning became Strategy & Metrics – These changes were made to place more emphasis on the measurement of the overall software security assurance program. Even though example metrics were given for each maturity level, feedback indicated this wasn’t explicit enough
• Standards & Compliance became Policy & Compliance – Feedback showed the term ’standard’ wasn’t as popularly used as the term ‘policy’ for referring to the normative requirements an organization places on software development. Standards are still included here, but as an extension of policies.
• Threat Modeling became Threat Assessment – Feedback indicated this section was too specific to usage of attack trees, so the language was loosened to allow other methodologies for the threat modeling activities. Also, the name was changed to avoid collision with existing notions of the term ‘threat modeling’ (e.g. Microsoft’s methodology). Further, abuse-case modeling activities were moved from Security Requirements into this practice since many felt it was more suited here.
• Defensive Design became Secure Architecture – The term ‘defensive design’ didn’t resonate with reviewers at all, so the activities were re-evaluated and recast as organization-wide augmentations to the design process that emphasize centralized application architectures. Activities related to creating access control matrices were moved into Security Requirements since feedback showed this was more of a specifying activity rather than an architecture-related one. A new activity was added here to require promotion of centralized infrastructure and services since most reviewers felt that activity was missing from the Beta.
• Architecture Review became Design Review – This change was made to ensure the terms ‘architecture’ and ‘design’ were being used more consistently. This practice discussed reviewing detailed design, so ‘design review’ seemed a more agreeable title.
• Infrastructure Hardening became Environment Hardening – Since the term ‘infrastructure’ can easily be interpreted to include network devices and other appliances, the title and associated activities were changed to indicate specific focus on bolstering the security posture of the software’s environment.