OWASP SAMM 2.0 Verification
Verification
Introduction
Architecture Assessment
| A: Architecture Validation | B: Architecture Compliance | |
|---|---|---|
| Maturity 1 - Review the architecture to ensure baseline mitigations are in place for known risks. | Identify application and infrastructure architecture components | Ad-hoc review of the architecture against compliance requirements |
| Maturity 2 - Review the complete provision of security mechanisms in the architecture | Validate the architecture security mechanisms | Analyze the architecture against known security requirements and best practices |
| Maturity 3 - Review the architecture effectiveness and feedback results to improve the security architecture | Review of the architecture components effectiveness | Feedback the architecture review results into the enterprise architecture, organisation design principles & patterns, security solutions and reference architectures |
Requirements Driven Testing
| A: Control Verification | B: Misuse/Abuse Testing | |
|---|---|---|
| Maturity 1 - Opportunistically find basic vulnerabilities and other security issues. | Test for standard security controls | Perform security fuzzing testing |
| Maturity 2 - Perform implementation review to discover application-specific risks against the security requirements. | Derive test cases from known security requirements | Create and test abuse cases and business logic flaw test |
| Maturity 3 - Maintain the application security level after bug fixes, changes or during maintenance | Perform regression testing (with security unit tests) | Denial of service and security stress testing |
Security Testing
| A: Scalable Baseline | B: Deep Understanding | |
|---|---|---|
| Maturity 1 - Perform security testing (both manual and tool based) to discover security defects. | Utilize automated security testing tools | Perform manual security testing of high-risk components |
| Maturity 2 - Make security testing during development more complete and efficient through automation complemented with regular manual security penetration tests | Employ application-specific security testing automation | Conduct manual penetration testing |
| Maturity 3 - Embed security testing as part of the development and deployment processes. | Integrate automated security testing into the build and deploy process | Integrate security testing into development process |
During several presentations on the subject of SAMM and application security, in general, I used to ask the audience members to vote on the different Business Functions in terms of impact on the security of software. In virtually all sessions Governance got the lowest scores, which should surprise no one. Frankly, if you work for an organization responsible for developing only a handful of custom applications, I would agree with that notion. However, as the number of developed applications increases and organizations get larger, Governance becomes indispensable.
One important factor to keep in mind is that for Application Security, the emphasis on Governance goes beyond maximizing the number of security checks and focuses just as much on optimizing security. This is done by emphasizing controls that impact the entire organization over the seemingly endless hunt for software defects. The three security practices under Governance should help illustrate new ways of thinking about Application Security Governance, and will hopefully help change some of the well-earned reputations of Governance as bureaucratic and out of step with development and security.
Strategy & Metrics
This practice is intended to form the foundation for all application security activities. The days when security could be sold and measured using words like “breach” or “security incident” are long gone, and understandable companies are requiring more from their security teams. Most importantly, organizations expect security to be strategic and proactive, and they want security to be measured. In this regards, SAMM’s guidance follows the following maturity guidance:
- Maturity 1 - Identify objectives and means of measuring the effectiveness of the security program.
- Maturity 2 - Establish a unified strategic roadmap for software security within the organization.
- Maturity 3 - Align security efforts with relevant organizational indicators and asset values.
To achieve this, the Security Practice identifies two important activities that must work together:
Create and Promote Organizations should start by identifying an organization’s drivers and most significant risks, and then determining how Application Security can best support them. Priorities should go beyond external considerations such as regulatory compliance and revenue, and also focus on priorities that may be uniquely related to the software development, such as standardization, the supportability of applications, uptime, and maximizing effectiveness of development teams. In most cases, a well designed Application Security strategy will be able to align with all objectives and find a significant amount of overlap with software development. Finally, even the best Application Security strategy can be made ineffective if nobody knows about it. Promoting the overall strategy organization-wide is a critical step in ensuring its effectiveness.
Measure and Improve When it comes to most organizations, they generally start metrics programs with measuring results, such as defect counts or backlog statistics. However, this would always provide an incomplete picture that focuses too much on security and not enough of the business of writing software. Other important considerations described by SAMM include measures of effort and environment, which provide measures of how much time is dedicated to security as well as measures of the landscape in which Application Security is implemented. Once combined with measurements of results metrics will begin to tell a more complete story and enable organizations to recognize and promote efficiency as well as security. Eventually, metrics and KPIs can be used to help influence future Application Security initiatives and help substantiate future investments in tools and developer resources.
Policy & Compliance
This practice is exactly what it sounds like and focuses on internal Policies and Standards, as well as external compliance requirements. While this general expectation has been a part of virtually every security and maturity framework, in SAMM 2 it has taken an important step forward in terms of making these requirements more aligned with the Agile methodology as well as current DevOps tools. Additionally, maturity roadmap now goes beyond simply having policies and focuses more on how these policies are promoted in the organization:
- Maturity 1 - Identify and document governance and compliance drivers relevant to the organization.
- Maturity 2 - Establish an application-specific security and compliance baseline.
- Maturity 3 - Measure adherence to policies, standards, and 3rd-party requirements.
The two activity streams are Policy and Standards and Compliance Management, and for this summary can be described together. One of the most important changes in this practice is the suggestion that Security Policies and Compliance Requirements should be published as Run Books or Test Scripts instead of the traditional long-form text. These documents should be formatted and designed in a way that would make it easy for developers and QA to understand and design appropriate application requirements and fully automated tests. The ultimate goal is to make an understanding of policies and compliance requirements easier, as well as potentially automate the process of verifying compliance by leveraging QA.
Education & Guidance
Dollar for dollar, the biggest improvement in Information Security can be made through additional and more effective training. While most organizations recognize the value of training, SAMM guidance will help move the basic concepts like membership to a growing number of CBT “all-you-can-eat” too much more formal programs including mandatory training requirements for different roles as well as platform certifications before giving full access to the production environment. Another important aspect of this practice is Organizational culture, which is intended to result in additional training opportunities as well as create an overall culture of security among developers. Together, these provide the following set of maturity level objectives:
- Maturity 1 - Offer staff access to resources around the topics of secure development and deployment.
- Maturity 2 - Educate all personnel in the software life-cycle with technology and role-specific guidance on secure development.
- Maturity 3 - Develop in-house training programs facilitated by developers across different teams
Training and Awareness This activity focuses on ways organizations can evolve their application security training programs, not to be confused with general security awareness that would apply to all employees. This activity is best reviewed for maturity expectations based on the overall size of the organization and the number of different applications being developed. Larger organizations will be best served by setting their targets at higher maturity.
Organization and Culture While most organizations began implementing programs such as “Security Champion”, the majority of them lack formal structure. This activity describes how large organizations can evolve these programs into tighter partnerships with organizations software architects and aligning their priorities. At highest maturity levels, these programs should evolve into Centers of Excellence where different teams that ordinarily would not have much contact could share knowledge and experience, which will inevitably result in fewer defects and more security applications.
Summary
Hopefully, this summary helped peak interest in Governance and supported the goal of showing how it can be aligned with software development. The next blog will describe the most significant changes and objectives of the Design Business Function.