24 January, 2022
Cybersecurity is currently a “hype”. It was a “hype” in the year 2001 and every year after that. The number of cybersecurity professionals, experts, mentors, <replace by a fancy title> is currently exploding as everyone is trying to hop on the “hype train”. BUT – cybersecurity is not really a new technology, methodology, philosophy, approach. It’s a quality property of the software system. There is an actual definition for it and CIA can help us all with that. CIA – as in short for Confidentiality, Integrity and Availability. Thus cybersecurity is making sure your software system guarantees confidentiality, integrity and availability. Simple, isn’t it? Here is a better definition for cybersecurity we all know. Security is a pervasive problem we have no idea how to deal with in a systematic way. Well, actually we (the real security experts) do. However it’s not simple, cheap nor painless. It’s called a security assurance programme.
In this blog, I will tell the readers more about what a security assurance programme is. I will focus on two most promising frameworks, namely BSIMM and SAMM and provide a comparison of both.
Disclaimer: While I am SAMM Core Team member I have never been involved in a BSIMM assessment. My analysis is based on the online resources and conversations with BSIMM practitioners. Hence, this article might contain factual inconsistencies about BSIMM and I welcome any feedback (especially from Synopsys).
Traditional approach to software security
Security is a very hard quality for organizations to deal with. First of all, security is intangible. You can’t really see nor perceive whether a software system is secure. Secondly, you can’t really measure security either. It is impossible to check how secure a software product is and objectively compare it to an alternative offering. Finally, security only seems to incur costs without a clear upside. Sure, you could use security as a sales argument. Everybody does! However your customers cannot compare your product’s security to that of your competitors. Hence many organizations keep security investments to a bare minimum, which brings us to today’s realities.
Data breaches create jobs
Unfortunately bad guys sometimes hack into corporate networks and then start bragging around. That isn’t the worst thing to happen actually. Remember Petya ransomware which completely smashed FedEx for weeks and made them go back to the previous century? Major data breaches are weekly news nowadays (Uber and Optus for the past 2 weeks). So in the past 5 years organizations have started taking security more “seriously” simply because the lack of it can have a massive impact on the bottom line.
Note that regulatory pressures, such as the GDPR are also a factor organizations have to take into account when dealing with security. However we have all lawyered up. Even the least security aware firms out there can easily claim GDPR conformity.
Update: Since the initial publication of this blog both the US and the EU have actually introduced regulations targeting to improve the security posture of organizations. For the interested readers we refer to our blog on How to implement NIST SSDF with SAMM and SAMMY.
Best practices in software security
So far the “best practices” in software security are typically limited to the following three activities:
- Security incident and event management (so basically advanced low-level monitoring and control)
- Regular patching
- Periodic penetration testing
While all of that is necessary, it is far from sufficient. By practicing these activities you mainly focus on finding bugs, not flaws. The latter are 1000 times more expensive to fix once the system is in production. Moreover, there are no guarantees that you have identified all bugs. Your bug-fix might also introduce a new vulnerability.
Security Tooling in the DevSecOps Pipeline
DevSecOps is a buzzword that typically refers to automation in building and deploying software systems. Adding security tooling in the build / deploy pipelines of your software systems is obviously a great idea. However there are at least 2 essential challenges in the industry with using security automation tools. First of all, the number of false positives identified by the tools can be mind-bending. Secondly, the tools typically rank the findings using a Common Vulnerability Scoring System (CVSS) score. CVSS score measures impact and not risk. As an organization you are only interested in the latter. All that eventually results in a non-trivial challenge on how to select the appropriate security tooling for your DevSecOps pipeline.
The more security-aware firms are using the “shift left” philosophy. Shifting left is a recent buzzword that promotes dealing with security properties during the early design phase of a software system. Threat modeling is a methodology enabling “security by design” and it is one of the most fundamental security activities to have in your security assurance programme. However threat modeling is still not enough and far from mainstream. Furthermore I am more than convinced that most organizations are unaware what threat modeling is.
The problem of a systematic approach to security has been solved quite some time ago. Microsoft has introduced the first security assurance programme in 2004. Named Microsoft Security Development Lifecycle (MSDL), it was Microsoft’s response to reduce software maintenance costs and increase reliability of software concerning software security related bugs. Since then a number of security assurance initiatives have been launched, such as OpenSAMM, BSIMM, SAMM, SSE CMM, SafeCode, NIST SSDF, etc. Unfortunately, up till now, they never really got any grip in the community. The main reasons are that they are not simple and challenging to introduce to large organizations. Small organizations have a lower risk exposure and the management typically isn’t really aware of the problem until it’s too late.
Here is the really great news though. More regulatory pressure is on its way to mandate the use of a security assurance programme for organizations. Memorandum M-22-18 mandates all US Federal agency suppliers to conform to NIST SSDF. European regulation is in the making. Furthermore, leading security-minded organizations are starting to set the bar higher for the rest.
OpenSAMM and Its Descendants
The remainder of this blog focuses on two maturity models that originate from the same source, i.e., OpenSAMM. OpenSAMM was created by Pravir Chandra and sponsored by Fortify. Fortify has then donated OpenSAMM to the OWASP community. Both BSIMM and SAMM originate from OpenSAMM. Both models still contain some similarities, but follow different approaches to application security.
Building Security In Maturity Model (BSIMM)
BSIMM is a maturity model that helps organizations plan, implement and measure their software security assurance programme. BSIMM consists of 4 domains split in 12 practices and containing a total of 125 security activities. So think of pen testing, patching, monitoring tools and threat modeling as some of these 125 activities you could (but not always should) do in your security assurance programme. Here is a structural overview of the BSIMM13 domains and practices.
BSIMM is not only the framework, but is also a measuring stick in the industry. BSIMM comes with an objective assessment of the different activities in 130 organizations from 8 industry verticals (financial services, independent software vendors, technology, healthcare, cloud, Internet of Things, insurance, and retail).
Software Assurance Maturity Model (SAMM)
SAMM is a maturity model that provides an effective and measurable way for all types of organizations to analyze and improve their software security posture. SAMM consists of 5 business functions split over 15 security practices and containing a total of 90 security activities. Here is a structural overview of SAMM functions and practices.
SAMM is planned to include the upcoming Benchmarking project that will also allow one to compare your own security posture with the rest of the industry.
BSIMM and SAMM: a Quick Overview
The goal of the model is to observe and report. BSIMM doesn’t say what you should be doing, rather what other firms out there are doing.
SAMM provides prescriptive advice on how to implement particular activities.
The scoring is binary, hence you get a yes or no.
The scoring per activity is on a scale from 0 to 1 so you will get partial credit.
BSIMM is proprietary to Synopsys. For an assessment you should reach out to them for cost and logistics.
SAMM is an open source OWASP flagship project. Hence, you can easily do a self-assessment of SAMM.
Levels refer to how frequent a certain activity is and are not necessarily related to maturity.
SAMM defines three maturity levels. Each level has a successively more sophisticated objective with specific activities, and more strict success metrics.
You can measure your own posture against someone else in the industry
|No comparison possible
At the moment SAMM does not support any comparisons in terms of scores, however Benchmarking project is in the making.
Updates are qualitative and provide valuable insights on what’s going on in the industry.
|2-3 year updates
SAMM model gets updated every 2-3 years.
The tooling for BSIMM is provided by Synopsis, however it is not publicly available.
Various tools support SAMM including an open source tool SAMMWise, a free tool SAMMY and Excel/Google Doc spreadsheets.
BSIMM provides a clear picture which security activities are most commonly implemented throughout the industry.
SAMM recommends picking your improvement roadmap based on your risk profile and driven by metrics.
Which model is better: SAMM or BSIMM?
I have to disappoint some readers at this point and say that I don’t have a black-and-white conclusion that states that one of the models is better. In this section I discuss the main advantages and disadvantages of both models from the perspective of an organization. My own subjective preference is with SAMM for obvious reasons.
One of the main strengths of BSIMM lies in its adoption and faster feedback loops to Synopsys. Synopsys updates BSIMM yearly based on a systematically collected set of qualitative and quantitative measurements from the participating organizations. This information is also shared with the participating organizations. Hence, an organization using BSIMM can more easily create a roadmap for improvements based on the industry standard set by BSIMM.
SAMM currently lacks this capability. We do expect the Benchmarking project to provide some improvements in the near future. However one of the most commonly asked questions by the SAMM users is where should they start? While the answer might be obvious (i.e., start from risk) for an organization which is just booting up their AppSec programme it might be really hard to figure that out. Risk is everywhere and risk prioritization is not as straightforward as it might seem. Data from the industry can clearly help with that.
On the other hand the fact that BSIMM observes certain activities in the participating organizations does not necessarily mean that copying those to your organization will have the best returns on investment. Moreover the list of participating organizations typically consists of very large enterprises (median number of developers 800). Thus it is unclear if BSIMM is a good fit for SMEs. From experience I know that SAMM is suitable for any size of organization.
Free and Open Source
BSIMM is proprietary and only Synopsys can do a real assessment. In fact, some details regarding the assessment are not disclosed (e.g., quality criteria to achieve an activity). A small organization is unlikely to be able to afford BSIMM. SAMM is open source. SAMM welcomes community collaboration and contributions that has lead to a more robust and widely adopted framework. We have a Slack channel where you are welcome to ask any questions you might have. The Core Team regularly organizes SAMM trainings that allow anyone interested to get a deep dive into the framework.
Even from a larger organization perspective SAMM is a great fit. BSIMM seems more of an all-in choice. SAMM allows you to experiment with a small scope and see what works for the organization. We know that for a fact as we have recently onboarded Zebra Technologies in the SAMMY tool.
SAMM flattens the learning curve by leveraging maturity levels. Each security practice is defined in terms of successively more sophisticated (and more rigorous) objectives. BSIMM claims to be a maturity level, however the levels are largely related to how pervasive a certain activity is.
One of the greatest advantages of SAMM lies in its prescriptive guidance. SAMM provides advice on how to implement each activity. Many security initiatives fail due to the poor details. Note BSIMM might include prescriptive guidance as well, however it is not freely available.
SAMM allows you to score a security practice that is only partially implemented. As a result your improvement roadmap can be more granular as you will get partial credit for certain activities. BSIMM scoring seems to be binary. (Once again the details of the scoring are not published in the model.)
Finally, SAMM comes with a number of supporting tools including the open source SAMMWise, Codific’s free SAMMY tool and Google / Microsoft Spreadsheets published by SAMM. These tools can help you with an assessment, setting the improvement targets and demonstrating measurable improvements. We are not aware of any similar BSIMM tools available to the public.
I believe in a holistic approach to security where organizations practice security throughout the entire software development lifecycle. Unfortunately for the industry (and fortunately for Codific) security is a really tough nut to crack. It is not a new technology we could learn and forget. It is not a product nor device we could buy and forget. Security is a quality that requires a systematic approach. Security assurance programmes provide the necessary and sufficient solution to the problem.
Introducing a security programme is extremely challenging. First of all, an organization’s behaviour changes slowly over time. Hence changes need to be smaller and iterative to really take hold and make a difference. Secondly, there is no single recipe that works for all organizations. Thirdly, guidance related to security activities must be prescriptive. Too often, security initiatives fail due to poor details, lack of communication, or invalid assumptions. Coincidentally (or not really), these are the core principles behind SAMM that is simple, well-defined, and measurable.
What do we build with SAMM and SAMMY?
Codific is a team of security software engineers that leverage privacy by design principles to build secure cloud solutions. We build applications in different verticals such as HR-tech, Ed-Tech and Med-Tech. Secure collaboration and secure sharing are at the core of our solutions.
Videolab is used by top universities, academies and hospitals to put the care in healthcare. Communication skills, empathy and other soft skills are trained by sharing patient interview recordings for feedback.
SARA is used by top HR-Consultants to deliver team assessments, psychometric tests, 360 degree feedback, cultural analysis and other analytical HR tools.
SAMMY Is a Software Assurance Maturity Model management tool. It enables companies to formulate and implement a security assurance program tuned to the risks they are facing. That way other companies can help us build a simple and safe digital future. Obviously our AppSec program and SAMMY itself is built on top of it.
We believe in collaboration and open innovation, we would love to hear about your projects an see how we can contribute in developing secure software and privacy by design architecture. Contact us.