Posts Tagged beta
From reviewer and user feedback, there’s a few noticeable changes in the model itself between the Beta and 1.0 releases. Here’s a recap of the major changes to the model.
- 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.
There’s been a huge amount of feedback and lots of refinement to SAMM since the Beta was release last August. I’m happy to report that we’re putting the finishing touches and reviews on the next release as I write. I’ll put together some separate posts that discuss the rationale behind the major changes, but in general, here are some new features in the next release:
- Better introduction – there’s a proper Executive Summary and a section describing the structure of the model before diving into the details
- A section on assessing an existing assurance program – this should help folks that need to map an existing software security program into SAMM (or anyone just performing an assessment of a software security program in general)
- Better guidance on building assurance programs – the Beta had some short text, but the next release includes a bigger section on and building a roadmap for a particular organization
- New layout and design – revamped the ordering of SAMM materials based on feedback from users and there’s a new topical table of contents (to better route people through the resource provided)
I’m looking forward to feedback on the 1.0 release once it’s out this week… stay tuned!
Thanks to sponsorship and feedback from Fortify, we’ve finished an initial release of the Software Assurance Maturity Model (SAMM) that is now available on the downloads page. Everyone is encouraged to review and provide feedback either directly to me or through discussion on the OWASP-CMM mailing list. The working goal is to have a solid 1.0 release in a few months after public review and feedback from organizations using the model and vendors in the software security space.