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.