26 April, 2023
OWASP is the Open Worldwide Application Security Project and it is a non-profit foundation that works to improve the security of software. One of its most recognized contributions to the field of software security is the Software Assurance Maturity Model (SAMM), illustrated above. SAMM is a software assurance framework that covers the secure software development lifecycle, but also includes additional business functions, like Governance and Operations. These additional business functions are typically organization-wide aspects related to security, while the middle three are application specific. Each business function is divided into three security practices. In this blog post we will focus on the OWASP SAMM Policy and Compliance practice of the Governance business function, what it is and how you can evaluate and improve your security posture in this practice, using our management tool, SAMMY.
Moreover, we have also written several blogs about other practices in the SAMM framework like Stress Testing, Education and Guidance, Security Architecture, Threat Modeling and Secure Build. We will continue to write articles about the different practices so make sure to stay tuned for that.
What is the Policy & Compliance practice of the OWASP SAMM framework?
The purpose of the OWASP SAMM Policy and Compliance practice is to drive internal security standards that seamlessly allow your organization to meet external legal and regulatory requirements when developing software.
The table below illustrates the Policy and Compliance practice. As is the case with all practices in the SAMM framework, the practice is separated into two streams and three maturity levels.
Stream A is Policy & Standards and Stream B is Compliance Management. For each of these you can score one of four maturity levels, three being the highest and zero the lowest. Having a maturity level of zero means that you don’t follow this stream at all. Let us go over both streams and their maturity levels.
Stream A – Policy and Standards
This stream focuses on setting and implementing security policies and standards in your organizations. These standards and policies allow for an easier verification of the security of your applications by providing guidelines for security requirements. Below I discuss the different maturity levels of this stream.
Maturity Level 1
To improve software security in an organization, it’s important to establish policies and standards based on industry standards, appropriate for the industry. Proposed standards should be reviewed with product teams and feedback should be invited to ensure feasibility and cost-effectiveness. Policies should focus on high-level definitions and broader objectives of protecting computing environment integrity, data safety and privacy, and improving software development life-cycle maturity. Standards should incorporate policy requirements and provide technology-specific implementation guidance. Expert input from senior developers and architects should be used in creating and periodically updating standards in a format that enables maintenance and audits.
Maturity Level 2
This maturity level requires organizations to develop and organize application security requirements and test scripts related to each applicable policy and standard in libraries accessible to all application teams. Label and link documents to policies and standards for ongoing updates and maintenance, and version policies and standards with detailed change logs for easier integration into different products’ SDLC. Write requirements in a format consistent with existing requirements management processes, and create multiple versions for different development methodologies or technologies. Test scripts reinforce application security requirements, guide testing efforts, and ensure ongoing compliance as applications evolve.
Maturity Level 3
This maturity level requires to create a compliance measurement program for applications that motivates and reports on mandatory requirements consistently across all teams. Whenever possible, integrate compliance status into automated testing and report it with each version, including the version of policies and standards and appropriate code coverage factors. Encourage non-compliant teams to review available resources such as security requirements and test scripts and forward issues resulting from insufficient guidance to the responsible teams for future releases. Escalate issues that cannot meet policies and standards to teams that handle application security risks.
Stream B – Compliance Management
The second stream of the OWASP SAMM Policy and Compliance practice focuses on checking whether the established security standards and policies match 3rd-party compliance drivers and requirements. Moreover, this stream focuses on implementing these compliance requirements into your application requirements to achieve compliance more seamlessly in your SSDLC. 3rd-party compliance requirements consider requirements of regulations like the GDPR, which I covered in a previous blog post titled GDPR Compliance in Software Development. Below I discuss the different maturity levels of this stream.
Maturity Level 1
To ensure compliance with external legal and regulatory requirements when developing software, create a comprehensive list of compliance requirements that could trigger application scope. Review each obligation with experts and legal to ensure understanding, and indicate opportunities to lower compliance burdens by changing how data is handled. Consider publishing a compliance matrix to identify which compliance requirements are applicable at the organizational level, and map compliance requirements to existing policies and standards. Update policies and standards to include organization-wide compliance requirements, and create compliance-specific standards for individual requirements.
Maturity Level 2
To ensure regulatory compliance of applications, create a library of application requirements and test scripts that are available to all development teams. The library should address individual compliance requirements like PCI or GDPR, as well as global compliance requirements such as ISO. Periodically re-assess each application’s compliance requirements and review all functionality to identify opportunities to reduce scope and overall compliance costs. The requirements should include enough information for developers to understand the functional and non-functional requirements of the different compliance obligations, references to policies and standards, and explicit references to regulations. The test scripts should verify compliance and clarify compliance requirements for developers, making the compliance process transparent. Finally, the requirements should be formatted for importing into individual repositories.
Maturity Level 3
This maturity level requires organizations to create a compliance measurement and reporting program for applications. Leverage automation to promptly detect compliance issues in frequently updated apps and use application requirements and test scripts to assess compliance status. QA, Internal Audit, or Information Security teams perform manual testing when fully automated testing is not possible. Track remediation actions and periodic updates, and review compliance remediation activities to ensure effective progress. Develop standard reports and compliance scorecards to help teams and organizations manage compliance gaps. Review compliance gaps requiring significant expenses or development with subject-matter experts and compare costs against minimizing scope or eliminating compliance requirements. Long-term compliance gaps require formal compliance risk acceptance and management approval.
How can you use SAMMY to implement the OWASP SAMM Policy and Compliance practice into your SSDLC?
SAMMY is a tool that allows you to manage your organization’s security posture following the SAMM framework. It allows you to manage all practices in the model but in this section we will focus on how you can use it to evaluate and improve your maturity level for the Policy and Compliance practice. For this, we will go over how this process is done in the Policy and Standards stream. The process is the same for the Compliance Management and for any other stream in any other business function, the difference lies in the questions that are asked in the evaluation phase.
Usually, users in SAMMY are organized into teams and then roles are assigned to the different team members. The three roles that are assigned are: evaluator, validator and improver. Let me explain to you what each of these do as we explain the process.
Evaluation
Firstly, the evaluator will evaluate your security posture with regards to the Policy and Compliance practice. For these, they will answer three questions (for each stream), each of which has four possible answers, as illustrated above. Depending on what answer you choose you will score either 0, 0.25, 0.5 or 1. If you get a score of 1 in all questions then that means that you have the maximum maturity level for this stream with a total score of 3. As you can see, in the example above the score for this particular stream is 1.25 out of 3.
Next, the evaluator needs to present evidence to support their evaluation. This can come in the form of documentation uploaded to SAMMY or a written explanation provided in the text box above. This evidence will then be checked by the validator in the next step to validate the evaluation.
Validation
The validation step is to ensure that the evaluation has been done correctly. A validator is assigned which can then go over the evaluation and the evidence presented to support it. The validator can be an internal and external auditor that is checking the security posture of your company with regards to a particular practice. If the evidence is sufficient and the evaluation is correct then it is accepted by the validator. It is important to note that the validation step is optional under certain maturity levels. For example, if you evaluate that the maturity level of your organization is zero for a particular stream then you do not need to validate this. From here, we move to the third and final step, the improvement .
Improvement
Finally, the improvement step. This involves writing up an improvement plan along with a target date for which this plan has to be finished, as can be seen in the screenshot above.
This step is also optional, as SAMMY is built to be used following your organization’s risk profile. It may be that, following this risk profile, your organization does not seek to improve their maturity level in a particular stream. Thus, the improvement step is not necessary.
If the improvement plan is carried out, a new evaluation is done and the new maturity score is calculated, as can be seen in the screenshot below.
Conclusion
In conclusion, the Policy and Compliance practice of the OWASP SAMM model is a very important practice to consider when developing security standards and aiming to comply with 3rd-party regulations. In this blog post, we have gone over each of the maturity levels of both the Policy and Standards and Compliance Management streams. More importantly, we have shown you how to use SAMMY to evaluate and improve your maturity level for each stream.
If you would like to get started with SAMMY you can create an account for free here and if you want some guidance then feel free to reach out to us.
