A Deep Dive Into Secure Software Development Based On OWASP SAMM

The Methodology Of Choice

There are many good secure software development standards out there, and I do not want to reinvent the wheel. Our reference model for this series will be OWASP SAMM v2. The current version has been released early 2020 and constitutes a significant improvement concerning agile development methods and DevOps. In addition, OWASP SAMM v2 comes with a built in methodology to asses the maturity level of the individual secure software development practices, which is a nice bonus on top.

I won’t go into all the details of OWASP SAMM here. It is an open standard that’s well documented. You can check out the OWASP SAMM website for further information.

Benchmarking your Secure Software Development Process

OWASP SAMM already provides a maturity assessment methodology, that allows the rating of each security practice on a scale from 0 to 3. But that’s just one part of the story. You will face the question, whether your security activities are appropriate for the protection requirements of your applications or not. OWASP SAMM cannot answer this question at the moment. Yes, your Defect Management activities may have a maturity level of 1.47, but what does that mean regarding a specific application which you are responsible for?

I always tell my clients that they should not aim for a certain number. It is only human to do so and comparing your current score to the score you got last time is appealing. But it misses the goal of what we are actually trying to accomplish. I am happy for you, if you reach the benchmark you have aimed for. But secure software development is not about numbers, it is about results! And that’s what I am really after.

I decided to create a simple system for this series, that allows us to talk about our goals without an artificially calculated metric. All we need for this are two things – a method to estimate the quality of our security activities and easy to understand protection profiles for our applications. I will introduce them below.

Quality Levels for your Security Activities

After seeing many different development teams in action, you realize that security is driven by more than just a bunch of activities. It is also driven by the mindset of the people, especially the stakeholders and other key players in the team. Therefore, I decided to describe the quality level of the security activities we are going to discuss not only in terms of what the development team does but also with which mindset those activities are approached. This will become clearer in the next article, when you put this methodology to good use.

To make the quality levels more intuitive, we will name them accordingly and document our general association with each level:

Wood

We don’t really care about this security activity and if we consider it occasionally, it is rather by accident.

Bronze

We have thought about the activity and do implement it on an ad-hoc basis. We are following common guidelines but do not fine-tune any of them.

Silver

We are aware of the importance of the activity and have established a foundation for its implementation that’s adjusted for our needs.

Gold

This security activity is well established and it feels wrong not to follow the established security process. The activity has a high maturity level and is considered a normal part of our development process.

Diamond

It is not accepted to develop an application without implementing this security activity. The maturity level of this activity has peaked. Insufficient implementation would result in failed quality gates and therefore going live with a non-compliant version of the software would be prevented. Everyone in the team is aware of its importance and acts accordingly.

Those quality levels allow us to describe what a specific security activity on a certain level would look like. For example, in the next article of this series, we will see how a company acts that treats Security Requirements with wood quality compared to a company treating Security Requirements with diamond quality, and everything in between.

Protection Profiles

Defining the quality levels was the first step, now we need to talk about the individual protection profiles of certain applications. Knowing those protection profiles allows us to decide, which quality level we need for our security activities.

Minimal Protection Profile

An application or system finds itself in this category, if it doesn’t have to fulfill any substantial security requirements. You don’t mind it being knocked offline for a few days and even if someone manipulates its content, you couldn’t care less. The software is not used in any environments, where it can be utilized as an entry point to more critical systems or applications. Common examples are private home pages or the fan page of your local sports team. In a business context, you usually don’t find any of those applications.

Low Protection Profile

This category represents applications with low protection requirements. Your software has a certain relevance, but the potential damage that can be done won’t cause any long lasting financial loss or harm to your brand. Especially when it comes to data handled by such an application, no confidential data is processed or stored. You will usually find business applications on this level, that are not considered critical for operation.

Medium Protection Profile

This category builds the bridge between the applications not really considered relevant for security and those that can have a massive impact. You worry about those applications and are willing to spend a certain amount of resources and manpower into their protection, but a system compromise still feels manageable. An internal knowledge base comes to mind. If it is offline, employees will be less efficient. If the content gets manipulated, people will make ill advised decisions. If confidential data gets accessed unauthorized, valuable information will fall into the wrong hands. Depending on the actual impact of those scenarios, it can be argued that the protection profile should be considered lower or higher instead, but this category is a solid middle ground for those important applications, that you don’t feel comfortable rating high.

High Protection Profile

Once an application reaches this category, things become interesting. Such an application might not have the potential to bring a company to its knees in case of failure, but an attacker could still deal significant damage by compromising such a system. A broad range of application types come to mind for this category. This could be a VPN server protecting your network against unauthorized access, a news portal with a broad audience or a system acting as potential entry-point for an attacker into critical areas of your network. If a system compromise would really hurt you, but the company will likely survive the impact, you have probably identified an application with a high protection profile.

Very High Protection Profile

This category is reserved for the most critical applications that are considered business critical. A successful attack against such an application often has an immediate but also long lasting impact like a significant financial loss, violation of law or a very detrimental effect on the value of the brand. In the worst case, a significant breach could be the end of the company using the software. Usually, such applications are core systems of critical infrastructure, are involved in high-value financial transactions, handle large amounts of PII, provide the main service of a company or have to capacity to harm the safety of people.

Which profile is best?

Of course it is no coincidence that we have the same amount of quality levels as we have different protection profiles. Those two definitions are aligned. If you have an application with just a minimal protection profile, guess what? Wood quality might actually be enough for you. Of course you can invest more in such applications, but from a security perspective, you are fine doing the minimum. When we are talking about applications with a very high protection profile, there is only one way to go. Diamond quality is crucial to address the needs of such critical applications.

Summary

To keep track of the big picture, I have created an overview that summarizes the essential properties of each quality level. This overview will also serve as a reference for all future articles in this series in order to model the respective security activities. You are welcome to start assessing selected areas of your secure software development process based on this generic overview. However, it only becomes really tangible once you are using the specific versions that will be released in the months to come.

Where to go from here?

Now that we have established a simple but effective methodology to talk about the security activities necessary for secure software development, we can finally do our first deep dive. The first article in this series is called Security Requirements Engineering – The Backbone of your SSDLC. We analyse the importance of security requirements engineering and discuss why security requirements are the backbone of all security practices implemented in a modern software development process. Using the methodology described above, you can compare your own quality level regarding security requirements and find out where you stand right now.

That’s what has been planned so far. Where we go from there is up to you, dear reader. I love to write about my favorite topics, but in the end I want you to get the most out of these articles. If you can apply what you have learned in my articles in your own projects, my mission is accomplished. My offer is still standing! If you have any specific questions, which you want to see addressed in the next articles, let me know on Twitter.

Click here to get to the complete SSDLC Deep Dive blog series.