introduction of bsimm

Posted by millikan at 2020-03-02

The person in charge of application security in a certain field will encounter the following dialogue at a certain time and a certain moment:

Scene 1:

CSO: how are you doing this year?

Wang: it's not bad. My brothers found many loopholes when working overtime. I have data.

CSO: what's the use of that?

Wang: ah

Scene two:

CSO: to change the topic, how is our software security on the whole?

Wang: steady progress. In recent years, the team has been established, and the company's software security situation is getting better and better.

CSO: what are the facts and standards?

Wang: ah

Scene three:

CSO: last time, I said that with the security construction, it has achieved certain results?

Wang: maybe it's on the first and second tier of China.

CSO: what are the shortcomings of the distance and what should we continue to increase investment in?

Wang: ah

This "ah???..." is a common situation at work. As security practitioners, we must know that there is no operation without measurement. We used to know that our ideas are Microsoft's SDL and Synopsys' touchpoints, both of which are guiding strategies. The former SDL

You must be familiar with this picture

The goal is: "minimize security vulnerabilities in the design, coding, and implementation phases, and identify and reduce such security issues as early as possible in the development life cycle. ". The premise of SDL is based on three core concepts: training and education, continuous process improvement and responsibility division. Continuous education and training of personnel within the software development team helps enterprises respond to changes in technology and threat situations. SDL tends to pay attention to understand the causes and effects of security vulnerabilities. In order to deal with the emerging new technologies and threats, it is necessary to periodically evaluate the effectiveness of SDL processes and make necessary changes. Application security is responsible for collecting three types of data: evaluating the training effect of the company for architects, testing, development and PM (the number of product defects before and after the training); in-process indicators are used to confirm the compliance of security process (the number of compliance applications of each department, the repair of historical vulnerabilities); post distribution data (missing data, coverage data) guide the team to cope with the change of the focus of future work 。 According to Microsoft's practice, it can improve the effect of security work by integrating security activities into software development process.

The latter touchpoints know a little less, but we are already doing it, which is suitable for the scenarios that are not involved and can not pay attention to the software design and the specific implementation of the system. It was first proposed by McGraw (the profile of the elder brother can see through the box and cross-border: a living method after the departure of a foreign bull). Software security is composed of three pillars: risk management, knowledge and touchpoints. All specific behaviors of software security are summarized into seven control measures, including abuse cases, security requirements, risk analysis Analysis), risk based security tests, code review, penetration testing and security operations; At the right time, seven control measures are involved in the software development life cycle, from requirements and use cases, architecture and design, test plans, codes, test and test results to feedback from the system after launching Field), so that every stage of development has a close relationship with software security.

Different from SDL, it can be used in multiple iteration stages

This way of thinking is lighter and can be customized for the development process. The main output indicators and data are in the external review, black-and-white box test, vulnerability management stage.

These two kinds of methodologies are applied in security construction, and they do not provide a group of descriptive indicators to help enterprises evaluate, understand and benchmark software security plans and practice results. CSO needs to understand and be told -- 1. Where to do well and where to do badly; 2. Where to lose the same horizontal line and where to distance from the high-level model; 3. How to invest resources.

Concept introduction

The bsimm introduced in this paper is a set of practice model evaluation tools. The official bsimm documents are divided into three parts, each of which has its own emphasis. The first part is to introduce the basic concepts of bsimm, the logic and methods of scientific research; the second part is a detailed explanation of a series of terms and minimum activities; the third part is the scorecard table and the spider chart of various vertical industries. Enterprises can reverse The theoretical framework is applied to multiple rounds of analysis. The organization's security plan is always dynamic.

It can cover all aspects of the software security plan, and visually evaluate the maturity of the software security plan through a series of index weights based on the quantifiable industry data. The advantage is that after evaluation, enterprises can find horizontal gaps in the industry for continuous improvement, vertical evaluation of the maturity of the safety plan after implementation for a period of time, to reallocate resources, or external publicity.

In terms of sample data sources, bsimm9 has 116 activity indicators jointly established by 120 enterprises with a certain degree of security maturity around the world (including NVIDIA, Lenovo, Huawei, adobe, Alibaba, Cisco, etc.), with different weights. All of them are collectively referred to as 4 fields and 12 practice modules, which are refined to each level from level 1 to 3. 1 is the basic requirement. 3 is challenging. Whether the security plan of enterprise self-assessment software reaches the corresponding level to form a scorecard, through which the maturity of the enterprise can be seen directly, so as to achieve the effect of evaluation and benchmarking.

As shown in the figure below: bsimm12 practice areas.


We will find that many stages require the participation of suppliers. The version applicable to suppliers is called vbsimm. Modern enterprises use a large number of third-party software, including customized outsourcing systems, SaaS services deployed on the public cloud, and third-party components. Enterprises should evaluate the security risk capability of suppliers, not just the security of specific software at a certain moment. Requirements in the supplier self-test stage:

There is documented evidence of implementing the software security development life cycle (SSDL).

Evidence of the use of the activities described in the SSDL (such as the results of an architectural risk analysis or code review).

Interview with the software security team leader to show his high understanding of software security.

Running a software security team

The process record used to repair safety defects.

Third party review.

Compared with bsimm, it focuses on boldface

Finally confirm the signature according to the form below.

Differences with opensamm

All of them are used to measure the maturity of software security. Opensamm (Software Assurance maturity model) is a normative general framework, which is evaluated by experienced experts to tell reasonable enterprises what to do; bsimm (software security construction maturity model) is a descriptive practice accumulation, which tells enterprises a set of data to explain what is actually happening in other companies in the world. The former is based on deductive reasoning, while the latter is based on inductive reasoning.

How to operate

The author adapts the version compatible with bsimm9 to GitHub, (although it is free to join the bsimm community, it is recommended that you finally use the systematic evaluation method, and the professional business organization Synopsys will implement the evaluation process and improve the software plan. Open source projects can only be used for science popularization and self-evaluation). According to readme, docker will be used for transportation Fill in the survey form after each line, and the tool will automatically generate a chart to show the cobweb chart of the enterprise in 12 major aspects, and intuitively understand the shortcomings and leading points through scores and proportions.

When docker is running, start to access the bsimm main interface:

Create a new team, click the table menu, compare bsimm's interpretation of each level according to each key, self evaluate yes or no, and complete the survey all the way.

Complete the table survey, select redar after save, and the spider green chart is the actual evaluation result of the enterprise. By comparing the level 1-3 yellow chart below, you can see the length of the enterprise in 12 dimensions.

Click observed or observed (detailed) to see the overall situation. Enterprises can assume that the whole is the main body to build a project. Companies with software products as the main body can divide a single product line into independent projects to evaluate the maturity of software security plans between different products.


Take the example data Team-A above. It can be seen that the panorama shows that it has reached a high level in the field of security testing (foreigners write a lot of unit tests, because the demand is not so urgent, looking back at the domestic...), it is weak in strategy and goal, and even fails to reach the level of level 1, so it is necessary to carry out publicity and education, create and publish corresponding software plans. Other aspects will no longer be interpreted one by one (the assessment results are always implicitly known, but this is through scientific statistical methods, rather than experience as "Mongolian doctor").

Of course, the evaluation results are not all the same, and the deficiencies need to be treated rationally. For traditional financial enterprises, they may lead in governance compliance policy, new technology driven enterprises may lead in attack model, security test and penetration test, and cloud computing companies will dominate in software environment evaluation. Remember our goal - observe and evaluate the maturity of software security plan, with relatively accurate results, rational data support to improve the accuracy of resource investment in the next stage, find pain points for continuous improvement, and "catch up and leap" to reach the industry leading level.


Case study: