Skip to content ↓ | Skip to navigation ↓

OK, so “play it again OpenSAMM” is a twist on a misquote from Casablanca, but the song Sam sings in that movie does say, “fundamental things apply.” One fundamental in our world, which seems often overlooked, is that of software assurance. Enter OWASP and it’s Open Software Assurance Maturity Model (OpenSAMM). Before you roll your eyes and openly mutter “DAMM” (Damn! Another Maturity Model), you should keep reading.

Just about every compliance framework I’ve seen mentions, or at least alludes to, software assurance.  For example, PCI DSS Requirement 6 and ISO 27002 Section 12 both require assured software development practices.  Application security is, I believe, a very soft spot in our underbelly – I would claim softer than maintaining hardened configurations, though that, too, has proven a challenge (see @TheOtherMichael‘s recent post).

But, implementing a secure Software Development Lifecycle (SDLC) can be difficult, and many don’t even know where to start.  Enter OpenSAMM.  OpenSAMM defines a three-level maturity model covering four business functions, each being composed of three security functions:

  • Governance: Strategy and Metrics, Policy and Compliance, Education and Guidance
  • Construction: Threat Assessment, Security Requirements, Secure Architecture
  • Verification: Design Review, Code Review, Security Testing
  • Deployment: Vulnerability Management, Environment Hardening, Operational Enablement

The good folks working on the OpenSAMM project have made this document not only readable, but concise.  On page five there are three “I would like to…” statements:

  • Assess existing software assurance practices
  • Build a strategic roadmap for an organization
  • Implement or perform security activities

Follow the keyed bullets for what you would like to do, and they guide you through the document safely skimming over that which is not immediately relevant to your concern.

OpenSAMM recommends starting with a base assessment so that you understand where you are (you can’t get where you’re going without understanding where you are), and they do this with a very simple questionnaire requiring only yes/no answers.  Roles are outlined.  Assessment processes are detailed.  Maturity levels are clearly explained.  The authors have even provided rationalized, phased program templates for Independent Software Vendors, Online Service Providers, Financial Services Organizations, and Government Organizations.

I have three constructive criticisms.  The first two are about OpenSAMM specifically, and the second applies to maturity models and frameworks in general.  I believe OpenSAMM is an excellent framework, but I feel it could provide a clearer picture with respect to governance – I do not have a clear picture about which role(s) manage the overall OpenSAMM program.  Along those lines, I am not clear from where certain personnel commitments were derived.  For example, understanding Security Requirements at maturity level one lists the following personnel and time commitments:

  • Security Auditor (2 days/yr)
  • Business Owner (1 day/yr)
  • Managers (1 day/yr)
  • Architects (1 day/yr)
Other concerns across maturity levels provide the same level of guidance.  I would like to know much more about how they arrived at these estimates for time commitment, which segues into my final criticism.
OpenSAMM, along with other maturity models and frameworks, falls short with respect to providing example processes and procedures where the rubber meets the road.  Yes, every enterprise is different, but that doesn’t mean that examples shouldn’t be provided.  If example processes/procedures had been provided, I would have a much clearer picture about which role is doing what and how much time I can expect to need from each role.
The bottom line is that OpenSAMM is good and you should take some time to read the Executive Summary and skim through the document based on its guidance (see the three statements above).  It’s well-written, relevant, and – most important – actionable.  Why?  Because the maturity model is trim yet effective.  OpenSAMM is lightweight enough that just about any enterprise should be able to handle the additional workload.  It’s effective because it sticks to the fundamentals.