This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org
Difference between revisions of "OWASP DHS SWA Day 2010 OpenSAMM"
| Line 14: | Line 14: | ||
;[[:Category:Software Assurance Maturity Model|Software Assurance Maturity Model (SAMM)]] | ;[[:Category:Software Assurance Maturity Model|Software Assurance Maturity Model (SAMM)]] | ||
| − | The Open SAMM project is committed to building a usable framework to help organizations formulate and implement a strategy for application security that's tailored to the specific business risks facing the organization. | + | The Open SAMM project is committed to building a usable framework to help organizations formulate and implement a strategy for application security that's tailored to the specific business risks facing the organization. Anyone can provide feedback on OSAMM at the[http://www.opensamm.org ] we site. SAMM has Creative Commons rights management. |
| − | + | OSAMM is used as a measuring stick against an organization’s security practices and functions. The OSAMM maturity model should be used as a scorecard for improving software assurance and provides prescriptive guidance for technical and non-technical users. | |
| − | + | OSAMM divides the SDLC into the governance, construction, verification, and deployment business functions, each consisting of 12 security practices. Each practice is a silo for improvement that can be performed independently or as part of a plan. The maturity of each practice is scored from 0 to 3. | |
The approach of SAMM is iterative and the goal is to have a phased approach to assess which areas need the most work and prioritize. The initial results are used to create a baseline roadmap from which the phased approach would be developed. The resulting scorecard provides a basis to perform a gap analysis. | The approach of SAMM is iterative and the goal is to have a phased approach to assess which areas need the most work and prioritize. The initial results are used to create a baseline roadmap from which the phased approach would be developed. The resulting scorecard provides a basis to perform a gap analysis. | ||
| − | A new | + | A new OSAMM version will include new functionality of analyzing feedback, case studies, and mapping of OSAMM to other regulations such as PCI, COBIT, CMMI, and FISMA. See [https://buildsecurityin.us-cert.gov/swa/proself_assm.html Software Assurance (SwA) Self-Assessment |
| + | ] where the SwA Processes and Practices Working Group has synthesized the contributions of leading government and industry experts (including OSAMM) into a set of high-level goals and supporting practices. | ||
[[Category:OWASP_Conference_Presentations]] | [[Category:OWASP_Conference_Presentations]] | ||
Revision as of 20:14, 5 October 2010
The presentation
This presentation is given as part of OWASP Software Assurance Day at the | 13th Annual Software Assurance Forum.
Download the presentation -- Note, some of the images have been removed to reduce file size for download.
The speaker
A speaker bio for Shakeel Tufail will be posted shortly.
Notes
The Open SAMM project is committed to building a usable framework to help organizations formulate and implement a strategy for application security that's tailored to the specific business risks facing the organization. Anyone can provide feedback on OSAMM at the[1] we site. SAMM has Creative Commons rights management.
OSAMM is used as a measuring stick against an organization’s security practices and functions. The OSAMM maturity model should be used as a scorecard for improving software assurance and provides prescriptive guidance for technical and non-technical users.
OSAMM divides the SDLC into the governance, construction, verification, and deployment business functions, each consisting of 12 security practices. Each practice is a silo for improvement that can be performed independently or as part of a plan. The maturity of each practice is scored from 0 to 3.
The approach of SAMM is iterative and the goal is to have a phased approach to assess which areas need the most work and prioritize. The initial results are used to create a baseline roadmap from which the phased approach would be developed. The resulting scorecard provides a basis to perform a gap analysis.
A new OSAMM version will include new functionality of analyzing feedback, case studies, and mapping of OSAMM to other regulations such as PCI, COBIT, CMMI, and FISMA. See [https://buildsecurityin.us-cert.gov/swa/proself_assm.html Software Assurance (SwA) Self-Assessment ] where the SwA Processes and Practices Working Group has synthesized the contributions of leading government and industry experts (including OSAMM) into a set of high-level goals and supporting practices.
