This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit

Difference between revisions of "SAMM - Security Requirements - 3"

Jump to: navigation, search
Line 56: Line 56:
===Additional Resources===
===Additional Resources===
Line 62: Line 62:

Latest revision as of 00:44, 20 April 2015

250px-OpenSAMM_logo.png For the latest project news and information,
join the mailing list and visit the OpenSAMM website.

SR1.png SR2.png SR3.png


Security Requirements - 3

Objective: Mandate security requirements process for all software projects and third-party dependencies


  • Formally set baseline for security expectations from external code
  • Centralized information on security effort undertaken by each project team
  • Ability to align resources to projects based on application risk and desired security requirements

Add’l Success Metrics

  • >80% of projects passing security requirements audit in past 6 months
  • >80% of vendor agreements analyzed for contractual security requirements in past 12 months

Add’l Costs

  • Increased cost from outsourced development from additional security requirements
  • Ongoing project overhead from release gates for security requirements

Add’l Personnel

  • Security Auditor (2 days/yr)
  • Managers (2 days/yr)
  • Business Owners (1 day/yr)

Related Levels

  • Threat Assessment - 3
  • Policy & Compliance - 2


A. Build security requirements into supplier agreements

Beyond the kinds of security requirements already identified by previous analysis, additional security benefits can be derived from third-party agreements. Typically, requirements and perhaps high-level design will be developed internally while detailed design and implementation is often left up to suppliers.

Based on the specific division of labor for each externally developed component, identify specific security activities and technical assessment criteria to add to the vendor contracts. Commonly, this is a set of activities from the Design Review, Code Review, and Security Testing Practices.

Modifications of agreement language should be handled on a case-by-case basis with each supplier since adding additional requirements will generally mean an increase in cost. The cost of each potential security activity should be balanced against the benefit of the activity as per the usage of the component or system being considered.

B. Expand audit program for security requirements

Incorporate checks for completeness of security requirements into routine project audits. Since this can be difficult to gauge without project-specific knowledge, the audit should focus on checking project artifacts such as requirements or design documentation for evidence that the proper types of analysis were conducted.

Particularly, each functional requirement should be annotated with security requirements based on business drivers as well as expected abuse scenarios. The overall project requirements should contain a list of requirements generated from best-practices in guidelines and standards. Additionally, there should be a clear list of unfulfilled security requirements and an estimated timeline for their provision in future releases.

This audit should be performed during every development iteration, ideally toward the end of the requirements process, but it must be performed before a release can be made.

Additional Resources