How do you define and build a product security program?
First, the answer depends on whether you are "only" shipping software artifacts to your customer or operating something as a service. For the former, you need a secure development lifecycle. For the latter you will additionally need to secure the infrastructure that runs your software and safeguard your customer’s data.
The goal of this post is to provide you with two things that will help you build your own security program: (1) ideas for defining an overall security roadmap / strategy and (2) ideas for security controls that will define the details of your roadmap.
Instead of providing my own roadmap, templates or controls, I will provide you with references to comprehensive 3rd party documents that are available in the public domain. Most of this material are (de-facto) industry standards that represent best practices collaboratively written by many people over the years. There is no need to reinvent the wheel when you can reuse existing, high quality material.
Keep in mind that a security roadmap always depends on your organization’s structure and current security maturity level, the type of your product/service and the type of customers you are serving. That implies that you will always have to customize a security roadmap to fit your own needs.
For completeness, this post is not about corporate security aspects, like device management or asset inventory. If your are looking for information on this topic, you best start with the CIS Critical Security Controls[1].
High Level Goals
What is the goal of a product security program? From a high-level perspective, it is the same as for any security program: identify risks and address them. Risks are usually centered around the loss of confidentiality, integrity or availability (the CIA triad).
There are four strategies for dealing with risk: avoid, reduce, transfer or accept risk. When a risk is relatively high you will want to completely mitigate (=avoid) it or at least reduce the impact in case an issue is exploited. Risk transfer is important for shared responsibility models where security ownership has to be jointly addressed by a service provider and the customer using the service.
You might also have to comply with certain compliance programs. Well known examples are ISO 27001, PCI DSS, SOC 2 Type 2 or the EO 14028.
These are the high-level goals that should drive any security program. I am skeptical about compliance programs providing a lot of security value. But these compliance certifications are often required for business reasons and especially large customers might ask for them. You can however use the compliance requirements as the means to get buy-in for for your own security initiatives though.
Security Domains & Maturity Levels
Moving on from the high level goal, what security controls exist and what should you implement in order to fulfill your high-level security objectives? And in what order? Should you start with threat modeling at an early stage or introduce it later on? Or should you first focus on vulnerability management?
There are many different security activities that you might want to or have to introduce. It is a good idea to first structure them into high-level domains. Luckily this work has already been done by other people.
The NIST Cybersecurity Framework groups everything into six functions: Govern, Identify, Protect, Detect, Respond and Recover [2].
The OWASP Software Assurance Maturity Model (SAMM) is structured around five business functions: Governance, Design, Implementation, Verification and Operations. It covers security aspects for both building and operating software.
Orthogonal to the different security domains is the concept of maturity levels that the OWASP SAMM model introduces. Level 1 represents an initial implementation and level 3 an improved and optimized implementation. An example for incident response:
-
Level 1: roles and responsibilities are identified
-
Level 2: formal incident response process has been established and roles have been assigned to staff
-
Level 3: dedicated incident response team has been established
I firmly believe that the concept of maturity levels is absolutely vital. You can not go from 0 to 100 in one step. You will first have to establish a baseline and then iteratively improve over time.
Implementation
So how should you start?
In the first step, adopt the NIST CSF and/or OWASP SAMM domain models. Read through them and get an understanding of what happens in each domain. Granted, those models are relatively high-level. But they will provide you with the overall structure of your security program. You can also start with a more fine-grained domain model, derived from these existing models.
Then determine your current security posture, e.g. using the OWASP SAMM self-assessment. The goal of this is to (1) identify and document what security controls you already have in place and (2) identify gaps.
You can then start defining your goals. For each domain you will select specific security controls to be implemented. The subsequent sub-sections will provide you with reference material that contain a large number of security controls. Because there are so many, it is important to follow the maturity level approach instead of trying to introduce everything at once.
SDLC & Supply Chain Security
This is a huge one. This covers everything related to security in software design, securing your source code, the build process, distribution of software artifacts, security for your 3rd party dependencies and the infrastructure used for all of this, such as version control systems, etc.
I suggest to first start with NIST SP 800-218. It focuses on producing and shipping secure software and is structured around the domains of Prepare the Organization (e.g. security trainings), Protect Software, Produce Well-Secured Software and Respond to Vulnerabilities. While most of the requirements in this document are mandatory for compliance with EO 14028, they are also extremely useful outside of this context.
The CIS Benchmark on Software Supply Chain Security is a similar and useful document that provides a lot of specific security controls.
Finally, the Supply-chain Levels for Software Artifacts (SLSA) are an interesting read as well. It is structured into three security levels, which are basically maturity levels.
Web Application Security
OWASP Application Security Verification Standard (ASVS) provides the best material for web application technical security controls and a list of requirements for secure development. They define three security levels, with each level providing a higher level of security.
I also want to mention the OWASP Cheat Sheet Series: while this series is more of an encyclopedia of web application security controls then a structured roadmap, it is nevertheless very useful.
Cloud Security
When you are deploying and running software in the cloud you will also have to secure your cloud infrastructure and services.
The Cloud Security Maturity Model (CSMM) provides some basic guidance, structured into 3 domains and 12 categories.
Marco Lancini’s On Establishing a Cloud Security Program provides specific suggestions for protecting a cloud native, service provider agnostic, container-based environment. It also follows a maturity level based approach. The CloudSecDocs are somewhat of a companion page collecting and sharing technical notes and knowledge related to Cloud Security.
There are also cloud provider specific guides available. For example for AWS, you can follow Scott Piper’s AWS Security Maturity Roadmap or the AWS Security Maturity Model.
Kubernetes
Kubernetes is so widely used, especially in cloud environments, that it has to be mentioned.
The official Security Checklist is very comprehensive and provides a significant amount of material for securing both Kubernetes itself and the applications you deploy inside Kubernetes.
A little bit of additional guidance is also available for Role-based Access Control related aspects.
DevSecOps
I am also mentioning this, because shift-left has been a concept, even buzz word, for some time.
The OWASP DevSecOps Guideline provides basic information on introducing security tooling into CI/CD pipelines.
The DevSecOps playbook is more comprehensive and provides explicit guidance and specific security controls that can be implemented across five domains.
Threat Detection
One could argue whether this is still relevant for product security, or not. I think it makes sense to include this.
The Detection and Response Pipeline git repo is a good starting point for building a data / detection / correlation pipeline that can be used for threat detection.
Measuring Progress: Metrics
Assuming you have established a security program and it has been active for some time, the next question will be: how do you measure progress or even success of your program?
The most objective answer to this question is: collect and evaluate metrics. Some examples:
-
Number of security incidents with more details information, e.g. remediation time
-
Number of open critical/high vulnerabilities
-
Number of findings by vulnerability class (hard coded secrets, XSS, etc.)
-
Tool accuracy based in true positives, false positives, and false negatives
-
Issues fixed, risk/severity reduced, or risk accepted
You can start with first security metrics using Twilio’s Security Metrics that Count or the Create your Value Operating System repository.
The templates from SecTemplates.com also include metrics for vulnerability management.
Example
To make the content presented so far more practical, let’s look at some examples.
Requirement PW.1.1 from NIST SP 800-218 refers to risk modelling, e.g. threat modeling, when designing software. This activity maps perfectly into the Threat Assessment part of the OWASP SAMM model. On the first maturity level, this can be a brainstorming activity with a basic checklist of threats. For higher maturity levels you can start standardizing this activity to achieve consistent results across your entire organization, or automate parts of it. Another requirement from the NIST document that can be mapped to the same SAMM domain are code reviews or tool based code analysis (PW.7.2).
The requirements from the Supply-chain Levels for Software Artifacts (SLSA) specification can be mapped into the Secure Build part of OWASP SAMM. The SLSA levels provide more details then the OWASP model, so you might want to start implementing the requirements from SLSA level 1 first and then gradually move towards level 3.
The requirements provided in the OWASP Application Security Verification Standard (ASVS) can be used for the Security Requirements part of OWASP SAMM, where maturity levels 2+3 mandate that security requirements must be defined and used by engineering teams.
Putting these examples together, the resulting list of activities, grouped by SAMM category, is as follows:
-
Threat Assessment:
-
Level 1: code reviews
-
Level 2: threat modeling
-
-
Secure Build: SLSA requirements from each level
-
Security Requirements: ASVS requirements from each level
The activities in each of these categories will be distributed over time, starting with level 1 and slowly moving to higher levels.
This was a small and incomplete example, but the basic workflow is always the same: pick requirements from the source documents and think about their appropriate maturity level, from the perspective of your organization. This ordered list of requirements is then your security roadmap.
You can map those requirements back to your overall security roadmap, using domains like those from OWASP SAMM.
Summary
To wrap up, to build your own security program you:
-
Define a security roadmap that is structured into security domains. Start from already existing domain models like OWASP SAMM.
-
Iteratively select security controls to be implemented for each domain. Prioritize the controls based on a maturity level rating.
The list of reference documents provided in the Implementation section of this post is relatively short, considering that it covers such a large variety of topics. But don’t underestimate it: implementing everything provided in those documents will keep you busy for a long time. And at the end you will have a very good security posture that can be further extended with whatever you need.