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 "SAMM - Construction"

From OWASP
Jump to: navigation, search
m
m
Line 1: Line 1:
 +
[[Category:OWASP Software Assurance Maturity Model Project]]
 +
 
http://www.opensamm.org/badges/small/C.png
 
http://www.opensamm.org/badges/small/C.png
  

Revision as of 22:56, 1 May 2009


C.png

Threat Assessment

The Threat Assessment (TA) Practice is centered on identification and understanding the project-level risks based on the functionality of the software being developed and characteristics of the runtime environment. From details about threats and likely attacks against each project, the organization as a whole operates more effectively through better decisions about prioritization of initiatives for security. Additionally, decisions for risk acceptance are more informed, therefore better aligned to the business.

By starting with simple threat models and building to more detailed methods of threat analysis and weighting, an organization improves over time. Ultimately, a sophisticated organization would maintain this information in a way that is tightly coupled to the compensating factors and pass-through risks from external entities. This provides greater breadth of understanding for potential downstream impacts from security issues while keeping a close watch on the organization’s current performance against known threats.

TA1.png TA2.png TA3.png


Security Requirements

The Security Requirements (SR) Practice is focused on proactively specifying the expected behavior of software with respect to security. Through addition of analysis activities at the project level, security requirements are initially gathered based on the high-level business purpose of the software. As an organization advances, more advanced techniques are used such as access control specifications to discover new security requirements that may not have been initially obvious to development.

In a sophisticated form, provision of this Practice also entails pushing the security requirements of the organization into its relationships with suppliers and then auditing projects to ensure all are adhering to expectations with regard to specification of security requirements.

SR1.png SR2.png SR3.png


Secure Architecture

The Secure Architecture (SA) Practice is focused on proactive steps for an organization to design and build secure software by default. By enhancing the software design process with reusable services and components, the overall security risk from software development can be dramatically reduced.

Beginning from simple recommendations about software frameworks and explicit consideration of secure design principles, an organization evolves toward consistently using design patterns for security functionality. Also, activities encourage project teams to increased utilization of centralized security services and infrastructure.

As an organization evolves over time, sophisticated provision of this Practice entails organizations building reference platforms to cover the generic types of software they build. These serve as frameworks upon which developers can build custom software with less risk of vulnerabilities.

SA1.png SA2.png SA3.png