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"
m |
m |
||
| Line 8: | Line 8: | ||
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. | 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. | ||
| − | {| | + | {{SAMM-BadgeList|name=Threat_Assessment|abbr=TA}} |
| − | |||
| − | |||
| − | |||
| − | |} | ||
| Line 19: | Line 15: | ||
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. | 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. | ||
| − | {| | + | {{SAMM-BadgeList|name=Security_Requirements|abbr=SR}} |
| − | |||
| − | |||
| − | |||
| − | |} | ||
| Line 32: | Line 24: | ||
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. | 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. | ||
| − | {| | + | {{SAMM-BadgeList|name=Secure_Architecture|abbr=SA}} |
| − | |||
| − | |||
| − | |||
| − | |} | ||
Revision as of 03:06, 2 May 2009
|
For the latest project news and information, join the mailing list and visit the OpenSAMM website. |
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.
|
|
|
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.
|
|
|
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.
|
|
|
