Summarizing Open Software Assurance Maturity Model OpenSAMM Requirements
Earlier, Information Security was all about protecting your network from malicious activities. But today, with the evolution of technologies and extended usage of devices and applications, information security has become a Business concern for any organization. We now have to re-work on our development processes, methodologies to improve the maturity of Application Security and adopt related Practices.
Many organizations have come up with their own frameworks to help this initiative keeping their business requirements in view, however, these frameworks lack flexibility and might be too complex for some organizations to adopt. The industry needs a model which is simple, defined and measurable. One such model is The Open Software Assurance Maturity Model (OpenSAMM), which is viable and can define building blocks for an assurance program.
The OpenSAMM (Open Software Assurance Maturity Model) developed by OWASP in 2009 is an open (free & vendor-neutral) framework assisting organizations in understanding, formulating and implementing software security strategy, which can be customized completely based on the risk faced by the organization.
Analyse existing Software Security Maturity state of an organization according to the practices and assurance programs
Build a balanced Software Security Assurance program in systematic and well-defined iterations
Demonstrate improvements in the security assurance program and software security maturity
Define measurable security activities across an organization.
Principles Of SAMM
SAMM was developed based on the following principles:
The behavior of organizational changes over the period, hence the software security program should be stated in small iterations and should deliver assurance gains during progressively working towards long-term goals.
The single solution does not suit for all organizations; hence, the program should be flexible enough to customize based on the risk tolerance level.
Guidance for the security activities should be simple, measurable and well-defined.
Understanding The Model
The open SAMM model is designed based on the four business functions of the software development along with security practices associated with each function. The objectives of the model are categorized into three maturity levels under each of the security practices. So, totally the model includes four business functions, 12 security practices, and 36 objectives.
image source: SAMM
The 12 security practices are categorized into three maturity levels, which include required objectives for successive activities. General representation of the maturity levels is:
Recently, the Open SAMM version 1.5 has worked further on the scoring model to represent the additional assurance in presence beyond the maturity level it belongs to. To ensure organization could gain proper credit for their effort in software security, the Open SAMM version 1.5 offered the granular scoring with decimal points that represent different levels of maturity. This scoring change supports to complete the assessment without any confusion in case the answer is something between the yes and no.
The Open SAMM version 1.5 includes more granularity in scoring the security practice evaluation. The different levels of coverage are shown below:
Here is an example of assessment worksheet:
Image source: SAMM
Here, we are going to explore the four business functions of the software development and the security practices for each along with their maturity level to aware how they can be improved over time.
Governance is all about the way organization manages software development activities. It provides relations between effective business processes and development groups, by providing an effective measurable process and engagement rules.
1.1 Strategy & Metrics (SM)
This practice involves building strategy to collect metrics defining organization’s security posture. It assists in establishing a framework within the organization for a software security assurance program.
1.2 Policy & Compliance (PC)
This practice primarily focuses on external legal and regulatory requirements and driving internal security standards to ensure required business purpose and compliances are met.
1.3 Education & Guidance (EG)
This practice is all about ensuring educating and guiding workforce involved in software lifecycle with required knowledge and resources to design develop and deploy secure software. This practice assists teams in proactively identify and mitigate related security risk in their domain.
Construction concerns the processes and activities related to business goals and development projects. Overall, it defines the process of building an application, which includes activities related to product management, requirement gathering, high-level architecture specification, detailed design and implementation analysis.
2.1 Threat Assessment (TA)
This practice involves identification of project level functional threats and risk to software. Processes like threat modeling assist in such analysis.
2.2 Security Requirements (SR)
This practice is all about building proactive practices, providing expected software security behavior. As a part of project initiation, security requirements along with functional expectations are collected for the high-level business purpose.
2.3 Secure Architecture (SA)
This can also be taken as a pro-active security practice to ensure security is ensured by default in software design itself.
As the name suggests, it is related to verification and testing of the software. It focuses on processes and activities related to how organization review and to analyse (test) produced entities throughout Software development.
3.1 Design Review (DR)
This practice is focussed on assessment of software design and architecture for security concerns. It involves detailed data-level design inspections and enforcement of baseline expectations at the design level.
3.2 Implementation Review (IR)
This practice focuses on software source code inspection for security vulnerabilities. It involves the integration of code review practices in the development process and setting measurable expectations for same.
3.3 Security Testing (ST)
This practice focuses on software inspection in the runtime environment for security concerns. It also involves adding security functional aspects in an automated environment. Security testing results should play a major role in project release acceptance criteria.
Deployment business requirement talks about processes and activities related to software release procedures. This also includes how products are shipped to end users, deployment of same and expected operations in the runtime environment.
4.1 Issue Management (IM)
Issue Management practices define the required processes for handling security issues and operational incidents. It talks about methods of collecting information from reports and analysing the root cause of the concern.
4.2 Environment Hardening (EH)
This practice assists in hardening of security posture in the surrounding environment of deployed software. It ensures the competency of the environment which host the software.
4.3 Operational Enablement (OE)
This Security practice primarily focuses on communicating secure deployment and other critical information to end-users. Providing details on security configuration, features and best practices are part of the same.
Building Assurance Program
The main purpose of using SAMM is to build a software assurance model for an organization. This process begins with the security assessment using existing model in the organization. After the assessment, Open SAMM proposes several roadmaps templates to choose from. Organizations can further customize their roadmap based on these templates, which explains which section of Security practice needs improvement and try to achieve the required level.
The OpenSAMM Model is quick and easy to deploy and will help organizations to improve their software security state by building assurance program, according to organization structure and understanding. It allows them to do self-assessment with some guidance, to gain valuable insights on their software assurance matters and help demonstrate concrete improvements to their security assurance program. Their plan also includes mapping them with existing standards like ISO, PCI and more.
Hack2Secure can assist organizations in the analysis and adoption of OpenSAMM model for Secure SDLC process implementation. Our training, certification, and services can assist organizations across the OpenSAMM model requirements.