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)