OWASP is one of the best sources of knowledge for all professionals who wish to work with software development, and to have a robust knowledge in best practices of secure development. At CONVISO, we have OWASP as our source of studies and knowledge.
Within OWASP projects, all very well structured and as an excellent knowledge, we use SAMM a lot, created as a maturity model for those who want to understand and improve their development process within what the market has been testing for decades as best practices.
SAMM is the basis for many things we do and recommend. Moreover, we understand that today it is one of the most mature and effective models we can find in the market. However, it is not the only one.
We have many other models, all very good and with a great track record, as is the case with BSIMM. In this article we will present and talk a little about how this model compares to the OWASP model. The intention is not to show superiority of one or the other, which can be used separately or understood as good sources of studies. What we want here is to show other possibilities, other points of view.
BSIMM
In our previous posts we have talked a lot about SAMM, so we want to suggest that you read our previous articles, this can help to better understand how SAMM can be used. In addition we have a number of articles being very well presented by Wagner Elias, another reading suggestion.
Let’s focus on BSIMM.
Well, BSIMM – Building Security In Maturity Model – is in its 10th interaction this year. It is with some changes, but keeping all its base and knowledge, who still not aware it is good to read about this model.
But what is BSIMM? If we take its own description we will have:
“is a study of existing software security initiatives. By quantifying the practices of many different organizations, we can describe the common ground shared by many as well as the variations that make each unique.
BSIMM is not a how-to guide, nor is it a one-size-fits-all prescription. Instead, it is a reflection of software security.”
Like other models, BSIMM tries to bring best practices to market, as well as the understanding of what can and can’t work. After all, these are practices evaluated and validated over time.
BSIMM is a framework formed by the experience of 122 companies that participate in the study and that are linked to different markets, precisely to achieve a more comprehensive view.
As a model, BSIMM is formed by 119 activities grouped into 4 major visions of a company. These are them: Governance, Intelligence, SSDL Touchpoints and Deployment, as can be seen in the image below.
So, as we can see, BSIMM is very similar to other process evaluation frameworks, always having a basis of practices related to stages or even areas of an organization.
This way, we can compare that organization with the OWASP SAMM. Reinforcing: here our intention is not to put an evaluation of effectiveness, to say which is better, we want to understand the similarities between them.
Even because the use of one or the other model will depend a lot on the organization that will implement the practices. Therefore, it must be part of its reality, the understanding and acceptance of the concepts passed by the model.
What do SAMM and BSIMM have in common
As we have already mentioned, in terms of structure the two models look very similar. However, there are differences. One of the main ones is that BSIMM is a descriptive model, while SAMM is a prescriptive model. Let’s explain.
Because it is a descriptive model, BSIMM is a framework that shows how participants are applying secure practices in their development processes. SAMM is a prescriptive model and its construction presents how an organisation can be more secure in its development process.
Of course there are still other differences and similarities between the two, but what we have to understand is that both are extremely useful models, and they should be very well understood before they are even used.
The BSIMM data formation model is formed by an evaluation and interview process, with more than 100 companies participating in the project. In this tenth year, a total of 122 companies participated.
The SAMM model goes through an internal evaluation process of the OWASP project teams, which based on the experiences and market assessments create and evaluate the effectiveness of the activities suggested in the model.
Illustration
As we can see in the image above, BSIMM bears a great resemblance to the structure of OWASP SAMM, which also has a concept of division based on large areas of organizational action. They keep some differences in that, because in this last version of SAMM, we went from 4 to 5 large areas.
This change brought about by the new version of SAMM was really a relevant improvement to the model, bringing to light processes that were in some way already in the previous versions but which are now separate and with their own related activities.
As we can see, there are great similarities between the structures, and we have even managed to relate to each other. This even enables us to use both models at the same time, since one is a descriptive model and the other a prescriptive one.
In general, we can use BSIMM to understand how companies are seeking to introduce security into their processes. SAMM can help us understand how we can improve or even increase the level of security in our products.
Below we will try to maintain a correlation between the two models, seeking to present the similarities within the two structures. This can help us to visualize how to use these two great models.
Let’s talk a little about these relationships but, to keep a reference point, let’s use SAMM as a support point and, from there, draw the similarities.
To make the article more practical and not so extensive, we will not focus on showing point by point each of the internal practices of each area, but we will deal with their similarities and differences in a macro way. But the reader is invited to look for the details in each model in a more personal way.
SAMM – Governance
Let’s first try to understand what each model brings as an objective to this area.
For SAMM, the main focus of the Governance area is to understand how the organization manages its general activities of producing secure applications. One look at multifunctional groups and business processes is that it is in the focus of these Governance related activities, and for SAMM, a development program without a defined plan is just a waste of time.
This view of SAMM on Governance is very similar to that of BSIMM.
In the BSIMM statement:
“Governance includes those practices that help organize, manage, and measure a software security initiative. Staff development is also a central governance practice”:
So, if we go back to the image above, we will be able to notice that the 3 areas of SAMM Governance are directly related to the 3 areas of BSIMM, even with a great similarity between its objectives.
Besides these direct relations between the areas of Governance of the two models, SAMM Governance, but specifically “Compliance & Policies” maintains a correlation with the practice of “Standards & Requirements” of BSIMM.
From SAMM, we have that “Compliance & Policies” practice focus on understanding what are the external as well as internal requirements and regulations that must be followed by the applications that will be built. Its counterpart of BSIMM focuses on understanding the explicit security requirements, in addition to creating standards that must be followed by the development teams when building their software.
SAMM – Design
Again we have the three practices in this area relating directly to other areas at BSIMM. Here there is no correlation between macro areas, but there is this relationship with practices in both models.
The practice of SAMM called “Threat Assessment”, which is focused on identifying and understanding the risks of the project, based on its functionality and the characteristics of the environment, now in execution time.
If we take this objective description as a basis, we will see that BSIMM’s “Attack Models” practice has a similar focus. Not different from another relationship with the “Architecture Analysis” practice, which also uses Threat Modeling methods to identify, and the subsequent creation of a remediation plan.
Continuing, we can see that the SAMM practice of “Security Requirements” is linked to the practice of “Standards & Requirements”, because both seek as objectives to establish security standards for the application to follow, thus creating a security context within its development.
As the last practice in this area of SAMM, “Security Architecture” has a connection with a similar practice at BSIMM called “Security Features & Design” that focuses on building some standards that will define the main security controls. This BSSIM practice is also directly related to another BSIMM practice, the “Standards and Requirements”. A double correlation for this practice.
SAMM – Implementation
In this area of SAMM, we have only two practices that relate to others in BSSIM, leaving out of this comparison the practice of “Secure Build”, so we will focus on the other two practices.
The Secure Deployment practice is focused on ensuring that the final product of the development is delivered secure and completely. This is to ensure that there were no unauthorized changes to the code during its passage through the development pipeline.
Now, if we look at the “Software Environment” practice at BISMM, we see that its focus is directly related to ensuring the security of the software, looking at all the components that allow it to run, use and deliver in a secure manner.
Another SAMM practice, “Defect Management”, aims to record, analyze and collect in the software errors and defects, thus allowing its analysis later. This practice is related to “Configuration Management & Vulnerability Management” of BSIMM. This practice is also related to the need to understand and seek to analyze the errors within the structure, performing the best possible corrections.
SAMM – Verification
When we look at SAMM’s “Architecture Assessment” practice, we think about how it is focused on ensuring that the architecture and infrastructure are meeting all security requirements appropriately.
The activities of this practice are related to both the SSDL Touchpoints and Deployment practices of the BSIMM model.
The Architecture Assessment activity can be mapped to the Architecture Analysis activity, and as we have seen in another correlation, this activity focuses on helping to identify threats through some methods. One of them can be the use of a threat modeling.
SAMM’s “Security Testing” activity can help complement BSIMM’s “Code Review” and “Security Testing” activities, having very similar objectives when we look at the whole set.
Of course, we’ll hardly have an exact correlation of goals and activities, but if we try to understand the goal of each of the model activities, we can understand these correlations.
The last activity of SAMM’s “Verification” practice is “Requirements-driven Testing” and in case you’re curious to read your goal, you’ll realize that it can very well be mapped to the “Deployment” practice, but precisely in your “Penetration Test” activity.
This mapping is done because your main goal is to search for software failures already operational, and performing intrusion tests is one, but not the only test to be performed.
SAMM – Operation
This SAMM practice has the least correlation with BSIMM practices.
Of SAMM, only the activity of “Environment Management” has relation with its pair in BSSIM, in this call of “Software Environment”. Both, in general, focus on looking at the structure that supports the application and seek to build the best possible secure basis for this application to act.
In this case, both have as focus the technology stack, and seek to keep this stack as secure as possible, keeping operating systems updated, technologies well configured and arranged in the best possible way. Everything to give the application a secure place for its operations.
In this practice of SAMM the other activities do not have a direct relationship at BSIMM, but this does not mean that the activities of both models that are not correlated are not important. They just have different focuses.
Learn all about our Consulting Services
Conclusion
With this article we try to show that there may be other possibilities that can be evaluated to use in your projects.
We try to show that if you haven’t gotten along with SAMM for some reason, there are other options. BSIMM is just one of them, there are still others – but that’s a theme for a future article.
We now want to understand how and with what you are evaluating your secure development process. Tell us through comments or our social media how your experience with maturity models is going.
See you in the next article.
