On November 16, 2021, the U.S. Cybersecurity and Infrastructure Security Agency (CISA)
published the Cybersecurity Incident and Vulnerability Response Handbook as required by Executive Order EO 14028.
The vulnerability response process stipulated in the manual includes four steps: identification, assessment, repair, and report notification
. method to determine whether there is a vulnerability in the environment and the importance of the underlying software or hardware". Why does CISA focus on naming SSVC, and what are its characteristics in vulnerability assessment? This article will introduce and analyze it.
## 1. The basic concept of SSVC
### 1. Inadequacies of CVSS
The Common Vulnerability Scoring System (CVSS) is currently the most widely used vulnerability severity assessment standard, and the CVSS score of a vulnerability is usually published together with the CVE number by the US National Vulnerability Database (NVD). But CVSS has some shortcomings:
(1) CVSS only regards technical severity as a basic principle, and takes time and environment as optional factors. All three should be the main factors for evaluating vulnerabilities;
(2) At present, there is a lack of relevant methods to guide decision-making through CVSS scores , and due to the uncertainty of measurement and the design of indicators, the conversion from numerical to qualitative is relatively complicated;
(3) The parameters of the CVSS scoring algorithm are not transparent , and the relevant working group has not proved the use of the formula, so a high CVSS score does not mean that the vulnerability will be commonly exploited or has a public exploit method;
(4) The basic score of CVSS is static and does not change over time;
(5) Studies have shown that analysts do not consistently interpret the elements of the CVSS V3 score.
### 2. SSVC goals and summary
For organizations and analysts, given limited resources, which vulnerabilities should be dealt with and which vulnerabilities can be ignored at present is a problem that needs to be solved, but based on CVSS, it may not be able to be effectively realized.
With these in mind, the Software Engineering Institute of Carnegie Mellon University made clear the goal at the beginning of designing the new vulnerability assessment system SSVC: the
output is a qualitative decision, not a quantitative calculation, and the input is also qualitative; Stakeholder groups make diverse recommendations; process argumentation is transparent; results are interpretable.
Overall, SSVC is a prioritization system for operations in vulnerability management. It is a modular decision-making system based on a decision tree model, avoiding a one-size-fits-all solution. SSVC is a conceptual tool for vulnerability management. What content should be included, how to clearly record and communicate decisions, etc. are described; SSVC is aimed at all kinds of vulnerability management stakeholders (and also the main participating members of the supply chain), focusing on their handling decisions in the case of vulnerabilities.
So far, SSVC has released three versions, namely V1.0 in November 2019, V1.1 in December 2020, and V2.0 in April 2021.
## 2. SSVC specific content
### 1. Vulnerability management stakeholders defined by SSVC
Stakeholders can be categorized as Providers, Deployers, or Coordinators depending on the tasks the team performs in the supply chain.
(1) The provider
is the provider of the vulnerability repair solution, which can generally be regarded as the software producer. Providers usually receive vulnerability reports for one or more versions of their products, and they need to decompose the report information into a set of products or versions affected by the vulnerability, that is, correlate the vulnerability with the affected products, and finally provide Affected products offer fixes or mitigations.
(2) The deployer
is the deployer of the vulnerability repair solution, which can generally be regarded as the information system user. Deployers typically get fixes or mitigations for their deployments from providers, which they must decide whether to deploy to a particular instance. The core of the deployer’s vulnerability management process is data collation, including the maintenance of the product version deployment instance list, the correspondence between vulnerabilities and repair or mitigation solutions, and the correspondence between repair or mitigation solutions and product versions, etc.
(3) Coordinator Coordinator is
a newly added role in SSVC V2.0, which refers to the individual or organization that promotes the collaborative response process in Vulnerability Coordinated Disclosure (CVD), including the Computer Security Incident Response Team (CSIRT), the national Responsible CSIRTs (such as US-
CERT), Product Security Incident Response Teams (PSIRTs), security research organizations, bug bounties and commercial brokers, etc. Different coordinators vary widely and may use SSVC differently. The work of the coordinator is often related to an independent vulnerability report, and may also reorganize the report according to the requirements of the workflow, such as merging, splitting, expanding, reducing, etc.
### 2. Vulnerability priority decision results of various stakeholders
SSVC defines the specific processing decisions that three types of stakeholders should make according to the priority of vulnerabilities, that is, the priority decision results for processing vulnerabilities. (1) The decision result of provider vulnerability priority
Table 1. Decision results of provider vulnerability priority
(2) The decision result of the deployer's vulnerability priority
Table 2 Decision results of the deployer's vulnerability priority
(3) Coordinator vulnerability priority decision results SSVC takes CERT/CC as an example, including two types: The goal of decision-making results about coordination is that CERT/CC analysts can obtain the information when receiving vulnerability reports, and the decision-making results There are 3 types:
Table 3 Results of decisions on coordination
· Decision results about release CERT/CC often have to decide when or whether to release information about vulnerabilities at a certain point in time, and there are two decision results of "release" and "not release".
### 3. Possible decision points of various stakeholders
The decision point is the judgment basis for each stakeholder to make a vulnerability priority decision result, and each decision point has several decision values.
There are 7 decision points for providers and deployers defined in SSVC V2.0, 7 decision points for coordinators (taking CERT/CC as an example) for coordination, and 3 decision points for release . (1) Provider and Deployer Decision Point · Exploitation is the evidence of actively exploiting a vulnerability, which is applicable to both the provider and the deployer. Its decision values include:
Table 4 Availability decision value
· Technical Impact refers to the technical impact of exploiting a vulnerability, which is applicable to providers and deployers. Its decision values include:
Table 5 Decision value influenced by technology
· Utility (Utility) is based on the assumption that the attacker can exploit the vulnerability, and compares its efforts to estimate the attacker's income. It is applicable to the provider and the deployer. Its decision value includes:
Table 6 utility decision value
· Safety Impact
is the safety hazard to the affected system, such as physical health, economic, social, emotional and mental health. The idea is that stakeholders should be aware of the immediate consumers down the supply chain and the common usage of their own software, and should consider the security implications for system operators and users of the software they supply. Its decision values include:
Table 7 Security impact decision value
- The Public Safety Impact provider must have a coarse-grained view of the generalized safety impacts described above. Its decision values include:
Table 8 Public safety impact decision value
- Situated Safety Impact (Situated Safety Impact) Deployers
may have a more fine-grained view of the generalized safety impact and use it in conjunction with business impact to simplify implementation for deployers. · Mission Impact
refers to the impact on the organization's business basic function (MEF), which is mainly applicable to the deployer. Its decision values include:
Table 9 Business impact decision value
· Human Impact Scenario A combination of security impact and business impact, applicable to deployers. Its decision values include:
Table 10 Scenario security impact decision value
· System Exposure (System Exposure) refers to the accessible attack surface of the affected system or service, which is mainly applicable to the deployer. Its decision values include:
Table 11 System exposure decision value
(2) Coordinator CERT/CC decision points CERT/CC decision points on coordination include the previous "utility" and "public safety impact", as well as 5 new decision points:
TABLE 12 Decision points on coordination
· CERT/CC's decision points on releases include the previous "Availability" and two new decision points: -Public Value Added
asks how valuable a release from the coordinator is to the wider community, its The decision value is based on the state of the existing public information about the vulnerability:
Table 13 Decision values for added common values
- Supplier Involvement describes the status of the supplier's work on vulnerabilities. Its decision values include:
Table 14 Decision Values for Provider Inputs
### 4. Vulnerability priority decision tree for each stakeholder
Given a set of useful decision points and corresponding decision outcomes for specific stakeholders, they can be combined into a comprehensive decision set regarding priorities for action to be taken. This decision set and the corresponding derivation process can be expressed in various forms such as logic. SSVC uses a decision tree to represent such information (in the following figures, the rectangle represents the decision point and the triangle represents the decision result). (1)
Proposed provider decision tree This provider decision tree considers 4 decision points of "Availability", "Utility", "Technical Impact" and "Public Safety Impact", which are combined into 36 decision paths, in which the decision The results were 13 items of "immediately", 8 items of "planned", 13 items of "irregularly", and 2 items of "postponed".
Figure 1. Proposed Provider Decision Tree
(2) The proposed decision tree for the deployer
The decision tree for the deployer considers the four decision points of "exploitability", "system exposure", "utility" and "task impact", which are combined into 108 decision paths, where the decision result There are 5 "immediate" items, 69 "planned" items, 23 "irregular" items, and 11 "postponed" items.
Figure 2
Decision tree for the proposed deployer 
(3) Decision tree for the proposed coordinator on coordination
The decision tree contains all CERT/CC decision points on coordination, combined into 52 decision paths, where the decision result is "coordination" 17 items, 15 items of "tracking", 20 items of "rejection".
Figure 3
The proposed coordinator’s decision tree on coordination 
(4) The proposed coordinator’s decision tree on release
This decision tree contains all decision points of CERT/CC on release, combined into 27 decision paths, where the decision result is “release 13 items of ", 14 items of "not released".
Figure 4. Decision tree for the proposed coordinator on publishing
## 3. Future work and summary
The Institute of Software Engineering at Carnegie Mellon University will continue to improve SSVC in the following aspects: (1)
collect requirements through research sociology methods, use long-term, structured interviews, etc. to obtain the value that practitioners and decision makers want to obtain from vulnerability evaluation, etc. (2)
In addition to considering CSIRT, the coordinator will also pay attention to the needs of PSIRT; (3)
SSVC currently does not consider the risk of change due to the implementation of mitigation or repair measures, and the next step will provide assessment of risk of change or approach to vulnerability risk-related costs; (4)
conduct more in-depth decision tree testing, more testing with different analysts is required before the decision tree is reliable; (5) consider internationalization and localization issues for SSVC.
The author believes that, as a vulnerability assessment method, SSVC is mainly characterized by three "orientations": oriented to the supply chain, oriented to decision-making results, and oriented to practical experience.
Facing the supply chain, the roles of stakeholders can be determined according to the tasks they perform in the supply chain, and it is also clearly pointed out in decision points such as "security impact" that stakeholders should consider their security responsibilities to downstream users in the supply chain;
Oriented to decision-making results, SSVC pays attention to the decision-making results of each stakeholder's vulnerability handling priority, and combines more qualitative judgments rather than quantitative calculations, and considers more factors;
Facing practical experience,
the decision points and decision values in the SSVC system will be added, deleted, and adjusted according to the results of experimental tests, rather than just relying on theoretical definitions, and methods such as systematic structured interviews will be introduced later to obtain empirical data.
User's security responsibility;
Oriented to decision-making results, SSVC pays attention to the decision-making results of each stakeholder's vulnerability handling priority, and combines more qualitative judgments rather than quantitative calculations, and considers more factors;
Facing practical experience,
the decision points and decision values in the SSVC system will be added, deleted, and adjusted according to the results of experimental tests, rather than just relying on theoretical definitions, and methods such as systematic structured interviews will be introduced later to obtain empirical data.
Network security engineer enterprise-level learning route
At this time, of course you need a systematic learning route
If the picture is too large and compressed by the platform, you can download it at the end of the article (free of charge), and you can also learn and communicate together.
Some of my collection of self-study primers on cyber security
Some good video tutorials I got for free:
The above information [click the card below] can be received, free to share