Archive for category Changes
Last week we had our first OpenSAMM Summit in Dublin on 27-28 March.
Full agenda for the User and Project Day are available here:
We had about 30 people gathering on the User day, with presentations (now available online (linked in the agenda page), a short OpenSAMM training (slides also available) and 2 great round tables to discuss OpenSAMM experiences.
On Friday evening most attendees came together in the centre of Dublin for the social event in the Cocktail / Winter Garden at Fade Street Social. Great food and lots of Guinness!
The Project day on Saturday was packed with constructive discussions and decisions on the content and release of v1.1 of OpenSAMM and the evolution of the tooling & guidance to support is. More details on the OpenSAMM Benchmark initiative – which was announce during the User day – were presented and debated together with a timeline for the release of the first data set (expect this by September 2015).
The User day meeting notes – together with the list of actions – are available here:
The final release of OpenSAMM v1.1 will be done in the coming weeks. The core model will be split of the full document. Some nomenclature changes were decided to better cover the underlying OpenSAMM security activities. The how-to, templates, toolbox and quick-start guide will be released separately and will have their own versioning. The existing mappings from other frameworks will also be updated and now includes a mapping on PCI DSS v3.
Overall feedback scores from the survey on the summit were great. Overall score was 93.3 % ! Detailed scores and lessons learned have been captured here:
I want to thank all participants, my project co-leaders and the supporting sponsors for making this summit a big success!
I will finish with the following quote: “The SAMM summit provided an opportunity to breathe new life into a framework that I use to facilitate my day-to-day work and support my customers.” Bruce C Jenkins, Fortify Security Lead, Hewlett-Packard Company
Stay tuned for the release of OpenSAMM v1.1 and hope to see you at one of our next OpenSAMM summits!
OpenSAMM Project Team
For the impatient, click here to download the mapping spreadsheet. For those still reading… Firstly, many thanks to the OWASP community for hosting the fantastic OWASP Summit 2011 in Lisbon, Portugal a few weeks back. This was a fantastic forum for us to hold OpenSAMM working sessions to discuss experiences and potential improvements to the model. Over the course of the week, we were able to build up a list of additions/changes we’d like to make in the next release, but I’ll cover those in more detail under separate cover.
The main thing I want to share now is an activity-level mapping of the ~110 BSIMM2 activities to the corresponding 72 activities in SAMM. Obviously, this means that in some cases, more than one BSIMM activity may be mapped to a single SAMM activity. That being said, the overlap spots seem to make sense when we (the ~10 people that worked on it) looked at them in detail. Don’t take our word for it, though, please do review and send any feedback (mailing list or just comment below). And before you ask, yes, you probably will have to go read the respective BSIMM and SAMM activity descriptions in order to see the linkage for some of them (given the occasionally imprecise nature of written language, it’s not always obvious from the activity names alone).
It’s worth noting that we did leave two BSIMM activities unmapped. They are SM 3.2 “run external marketing program” and T 3.3 “host external software security events”. Based on the experience of the working group participants, these activities did not appear to directly improve an organization’s software assurance posture, rather, they appeared to be evidence that the organization was using its (presumably mature) software assurance posture to bolster its public perception or generate additional value in the business. Again, this is totally up for debate if anyone has an argument the other way, so please do share your thoughts.
Last, but certainly not least, I’d like to thank all the people at the Summit for the detailed and thoughtful conversations about using SAMM and about what we can do to make it even better. Specifically, those that contributed and helped review this mapping (in no particular order):
- Colin Watson
- Seba Deleersnyder
- Steven van der Baan
- Bart De Win
- Justin Clarke
- Dan Cornell
- Sherif Koussa
- Brian Chess
Description: Several users and many organizations have requested the SAMM content in an editable format. This facilitates content editing and is a core requirement for translation of SAMM into other languages. The solution must also allow for easy integration of edits back into the layout/publish workflow.
Owner(s): Pravir Chandra
Estimated completion: 2009-05-11
- 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.
Since release of the 1.0, I’ve received a huge amount of email from volunteers and supporters. It quickly became evident that we’d need to adopt a lightweight process for managing future community contributions. Today, we’ve put the straw-man process up. Like everything, its mechanics are up for discussion, so just hit the mailing list if you’ve got strong feelings.
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.
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.