One of the other new items is a full XML version of the SAMM 1.0 framework document. It includes all the content from the whole SAMM document, so now it should be a lot simpler to build tools and automation around the model itself (not to mention making translations into other languages a lot simpler).

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.

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.