The Open Worldwide Application Security Project Software Assurance Maturity Model is a model that provides a measurable way for any organization to analyze and improve their software development lifecycle.
SAMM is technology and process agnostic, meaning this framework could apply to any organization regardless of the technology or processes used within its infrastructure. This is vital because there is no single recipe that works for all organizations.
SAMM depicts a clear actionable pathway for improving maturity levels over time through defined iterations and progressive improvements in secure pratices while defining/measuring your security-related activities.
SAMM v2 (the most updated version at the time of this writing) has 15 security practices grouped into 5 business functions. Each security practice contains a set of activities, structured into 3 maturity levels. The activities at a lower maturity level are easier to execute and require less effort than the ones on a higher maturity level:
Those 5 business functions can mean any category of activities involved with software development. Under each business function lies 3 security practices (we will be using only 1 security practice in our example) which are areas of security-related activities that build assurance for the related business function. Security practices have activites, grouped into logical flows and divided into two streams which cover different aspects of a practice and have their own objectives. Those activities are linked into 3 different maturity levels as shown in the above diagram. Each level has more sophisticated objectives with specific activies and more strict success metrics.
Let's dive into a real world example of how we would get started. The first section of the SAMM model is the "Strategy & Metrics" section which we will use in this example. Our business function will be "PRODUCT SECURITY" and our security practice under product security is "API SECURITY". Under API Security you'll find Stream A (Create & Promote) and Stream B (Measure & Improve) which will be the maturity level activities you will continuously work on within the Strategy & Metrics section of the SAMM. Depicted below you will see the outline of how we have mapped it out.
Stream A Maturity L1 Activity:
Goal: Gain a common understanding of the org's security posture.
Understand what threats exist or may exist in the future and how tolerant executive leadership is of these risks. This is a key component of determining software security assurance priorities. To ascertain these threats, we must interview stakeholders to document drivers specific to industries where the org. operates. Information gathering here includes worst-case scenarios that could impact your org. as well as opportunities where an optimized SDLC could provide a positive outcome and/or create additional opportunities. This information provides a baseline for the org. to develop and promote its appsec program. Items in the program are prioritized to address threats and opportunities most important to the org. which are then split into several risk factors and drivers linked to the org's priorities and used to help build a risk profile of each custom-developed app by documenting how they can impact the org. if they're compromised.
By the end of this activity you should be able to understand the risk appetite of the org. as well as its applications.
Use this check list to confirm:
You captured the risk appetite of your org's executive leadership.
The org's leadership vet and approve the set of risks.
You identify the main business and technical threats to your assets and data.
You document risks and store them in an accessible location.
Stream A Maturity L2 Activity:
Goal: Available and agreed upon roadmap of your AppSec program.
Based on the magnitude of assets, threats, and risk tolerance, develop a security strategic plan and budget to address business priorities around appsec. The plan covers 1-3 years and includes milestones consistent with the org's business drivers and risks. It will provide tactical and strategic initiates and follows a roadmap that makes its alignment with business priorities and needs visible.
Stream A Maturity L3 Activity:
Goal: Continuous AppSec program alignment with the org's business goals
Review AppSec plan periodically for ongoing applicability and support of the org's evolving needs and future growth. Repeat steps from the first two maturity levels of this Security Practice at least annually. The main goal is for the plan to always support the CURRENT and FUTURE needs of the org. which ensures the program is aligned with the business. We also closely monitor the success of the implementation of each milestone within the roadmap. You evaluate the success of each milestone based on completeness, efficiency of implementation, budget considerations, and any cultural impacts or changes resulting from the initiative. Review missed or unsatisfactory milestones and evaluate possible changes to the overall program. Develop dashboards and measurements for management and teams responsible for development to monitor roadmap implementation. These dashes should be detailed enough to identify individual projects and initiates to provide a clear understanding of whether the program is successful and aligned with org. needs.
Stream B Maturity L1 Activity:
Goal: Acquire basic insights into your AppSec program's effectiveness and efficiency.
Define and document metrics to evaluate the effectiveness and efficiency of the AppSec program. Similar to how Splunk has dashboards, you will also create dashboards reflecting the dynamic nature of EFFORT, RESULTS, and ENVIRONMENT metrics. Effort board will measure the effort spent on security (example: training hours, time spent in code review, etc.). Results board will measure the results of security efforts such as outstanding patches with security defects or number of security incidents involving application vulnerabilities. Environment board will measure the environment where security efforts take place such as number of apps or lines of code as a measure of difficulty or complexity. While identifying metrics always stick to the metrics that meet several criteria:
Consistently measured
Inexpensive to gather
Expressed as a cardinal number or a percentage
Expressed as a unit of measure
Stream B Maturity L2 Activity:
Goal: Transparency on your AppSec program's performance
Once the org. has defined its application security metrics, collect enough information to establish realistic goals. Confirm you can gather data consistently and efficiently over a short period of time. Now you should have enough information to commit to goals and objectives expressed through Key Performance Indicators (KPIs). KPIs are comprised of the most meaningful and effective metrics. You'll have to spend some time tuning the KPIs to reduce changes of unfavorable numbers resulting from temporary or misleading individual measurements. At this point you can view KPIs as definitive indicators of the success of the whole program and consider them actionable. Distribute KPIs to teams contributing to the success of the program as well as org's leadership. Include brief explanation of the information sources for each KPI and the meaning of the high/low numbers. Include short and long-term goals and ranges for unacceptable measurements requiring immediate intervention. Share action plans with AppSec and dev teams to ensure full transparency in understanding of the org's objectives and goals.
Stream B Maturity L3 Activity:
Goal: Continuous improvement of your program according to results.
Define guidelines for influencing the AppSec program based on the KPIs and other app security metrics. These guidelines combine the maturity of the application development process and procedures with different metrics to make the program more efficient.
Focus on maturity of the development lifecycle makes the relative cost per defect lower by applying security proactively.
Monitoring the balance between effort, result, and environment metrics improves the program's efficiency and justifies additionoal automation and other methods for improving the overall application security baselines.
Individual Security Practices could provide indicators of success or failure of individual application security initiatives.
Effort metrics helps ensure applicaiton security work is directed at more relevant and important technologies/tasks.
If you have any questions feel free to message me on LinkedIn.
Hope this has been helpful. Thanks for reading.