Security vulnerability SCAP specification standard

In daily vulnerability research and management, it is usually found that different vulnerability platforms and different teams usually have different definitions of vulnerability numbers and severity.

For example, the following are 6 common elements of vulnerabilities:

Let’s take the Heartbleed vulnerability as an example:

These contents all describe Heartbleed. You can see that different platforms have different numbers and categories. The affected components, levels, and titles are all different. So for security researchers or vulnerability management, it is inevitable You need to identify whether it is the same vulnerability, and then you need to determine the vulnerability level and type yourself. Different people or teams often have contradictions such as the following:

This is due to different knowledge, understanding of vulnerabilities, and standards, which leads to these problems. So is there a unified standard to deal with this problem? Yes, SCAP!

SCAP

Today we mainly introduce SCAP1.0 version.

SCAP includes Protocol and Content. Protocol means that SCAP is composed of a series of existing public standards. These public standards are called SCAP Elements. Protocol specifies how these Elements work together. . Content refers to the data that is generated using Element description and applied to the actual inspection work according to the agreement of the Protocol.

Six elements of SCAP:

You may be relatively familiar with CVE and CVSS, so I will explain them one by one:

CVE

CVE is relatively easy to understand. In layman's terms, it is a unified collection and numbering of vulnerabilities. Of course, this is for common component vulnerabilities. This is why you often see security personnel writing on their resumes how many CVEs they have survived. number, that means that the common component vulnerability corresponding to the number was 0DAY discovered by him at that time, which is a symbol of his independent 0DAY discovery ability; of course, the CVE does not reflect the impact and severity of the vulnerability, so the CVE number alone I don’t see anything, but a very weak vulnerability can still be applied for a CVE number.

CVSS

CVSS is a scoring system. The basic expression method is the direct score of 5.0 as shown on the right, or something similar to

CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N/RL:O/CR:L

As for the expression of this vector, as for what AV, AC, etc. here mean, we can continue to read below to get a rough idea.

The CVSS score has three indicator groups. Generally, when we look at the severity of the vulnerability itself, we mainly look at the basic indicators. This indicator is calculated more from some points of the vulnerability itself, and the time indicator group is sometimes also considered. For example, as time changes, if there was no way to exploit the vulnerability in the first place, but later it appears, the exploitation of the vulnerability is completely different, and the hazard index should probably rise linearly. For example, in Eternal Blue, when the vulnerability broke out at the beginning, although it was accompanied by Exp, but only a few people know how to use it. However, with the emergence of various online exploit articles and MSF plug-ins, people all over the world are using this vulnerability to attack. Furthermore, environmental indicators mainly refer to the impact of the vulnerability on different environments. May vary.

As I mentioned just now, what are the AVs above? In fact, it is these indicator items. The details can be seen in the picture below. They are translated into Chinese in the PPT for the convenience of everyone’s understanding. The H and L here may represent high and low. For details, please see the official website description https: //www.first .org/cvss/specification-document .

Back to the score calculation, how to calculate the score? In fact, there is a formula. Let’s take the basic indicator group as an example.

Determine what situation each indicator of the vulnerability belongs to. For example, attack vectors include network, adjacent network, local, and physical. They refer to several ways to launch vulnerability attacks. The corresponding factor scores used for calculation are 0.85, 0.62, 0.55, 0.2. Generally speaking, vulnerabilities that can be attacked directly through the network are the most convenient to exploit, so they have the highest scores; the same is true for several other indicators.

Let’s take the vulnerability "phpMyAdmin Reflected XSS Vulnerability (CVE-2013-1937)" as an example:

Then apply the formula to calculate:

ISCBase = 1 - [(1−ImpactConf) × (1−ImpactInteg) × (1−ImpactAvail)] = 1 - [(1−0.22) × (1−0.22) × (1−0)] = 0.3916

ISC =
Scope Unchanged 6.42 × ISCBase
Scope Changed 7.52 × [ISCBase−0.029] − 3.25 × [ISCBase−0.02]15
=7.52 × [0.3916−0.029] − 3.25 × [0.3916−0.02]15 = 2.72675084384

Exploitability
= 8.22 × AttackVector × AttackComplexity × PrivilegeRequired × UserInteraction
= 8.22 × 0.85 × 0.77 × 0.85 × 0.62 = 2.8352547300000004

If (ISC <= 0) 0 else,
Scope Unchanged Round up (Minimum [(Impact + Exploitability), 10])
Scope Changed Round up (Minimum [1.08 × (Impact + Exploitability), 10])
= Round up (Minimum [1.08 × (2.72675084384 + 2.8352547300000004), 10])
= Round up (Minimum [6.006966019747201, 10])
= 6.1

The final base score for this vulnerability was 6.1.

Do you think this calculation is troublesome? In fact, it doesn’t need to be so complicated. The official website provides an online calculator. Just select it and it will be automatically calculated:

This is CVSS.

CPE

CPE is a common platform enumeration. When describing a vulnerability, it is often necessary to describe which components and versions the vulnerability affects, then CPE can be used.

CPE has three formats, namely WFN, URI, and FS. The corresponding format is

CPE:2.3:类型:厂商:产品:版本:更新版本:发行版本:界面语言:软件发行版本:目标软件:目标硬件:其他

The previous 2.3 refers to the version of CPE used, because CPE also has multiple versions. In version 2.2, the fields sw_edition, target_sw, target_hw, and other do not exist. For the specific representation method, you can refer to the left side of the above figure. Sample.

Of course, in addition to describing the components and corresponding versions affected by the vulnerability, CPE can also be used to directly match whether a vulnerability exists. To detect the component version for a certain environment, use CPE to describe it, and then compare it with the vulnerability. By matching the affected CPE version, you can directly describe whether the environment is affected by this vulnerability. In this scenario, CPE uses the corresponding matching method. For details, please refer to the figure above. If it needs to be implemented in the code, it is also very simple. Generally, There are ready-made modules. For example, Python has a ready-made third-party package also called CPE, which contains related matching and formatting methods and can be easily used.

CCE

Let’s talk about CCE. In fact, CCE is easy to understand. It can be understood as the CVE number for the baseline configuration. CVE is for common component vulnerabilities, while CCE is for the baseline configuration.

For example, as shown in the picture:

CCE-27868-9
Definition: The maximum password age setting for Apache's service account should be configured appropriately. Parameter: number of days. Technical Mechanisms: defined by Local or Group Policy

CCE-27868-9 describes the requirements for the maximum expiration time of the Apache service account, and requires the use of an appropriate value.

OVAL

Let’s continue talking about OVAL, which is a description language used to define technical details such as inspection items and vulnerabilities. It seems difficult to understand this. In layman's terms, you can understand that it tells you how to detect the existence of a certain vulnerability step by step in a corresponding environment. It also has a library that can be retrieved through such a number. It is 上图oval:org.mitre.oval:def:24241XML Format; let’s take Heart Bleeding as an example:

This is part of it, which describes that under Ubuntu 12.04, if there is a dpkg package such as libssl 1.0.0 in the system, and the version is smaller than that, it 0:1.0.1-4ubuntu5.12means that there is a Heartbleed vulnerability.

OVAL uses a unified standard to describe the detection details of a certain vulnerability, and OVAL can also be contributed by the community. In this way, security personnel and security tools can actually detect related vulnerabilities based on OVAL.

XCCDF

The last thing we need to talk about is XCCDF.

XCCDF looks somewhat similar to OVAL, but XCCDF is designed to support information exchange, document generation, organizational and contextual adjustment, automatic consistency testing and compliance scoring, and can support interaction with a variety of basic configuration checking technologies. The recommended and default inspection technology is MITER's OVAL. In actual SCAP applications, XCCDF and OVAL often appear in pairs. It can be understood that OVAL can be used as a subset of XCCDF.

In addition to OVAL, you can actually see CPE in the XCCDF document. It is also an XML format file.

Looking back at the six elements, I borrowed a picture from the Internet to represent them. In fact, the relationship and function between them is roughly as follows:

SCAP tools

Having said this, are there any relevant tools that can help us use SCAP? For example, how to detect and output inspection results based on XCCDF? The more famous ones include OpenSCAP:

This is probably a brief introduction to SCAP. For more information, you can refer to the official website documents and some application cases.

In fact, the main function of SCAP is to unify standards. In this case, these standards can be directly applied to conduct related vulnerability research, learning, use, detection, etc. without security researchers or security tools. Generally speaking, there will be no differences due to different understandings. Problems such as different descriptions and definitions arise. Generally, well-made security products, even if they have their own set of standards, are generally compatible with some SCAPs, among which CVE is the most widely used. Of course, if you have different understandings of the standards during the use of SCAP, it may still lead to some differences. For example, in the process of calculating CVSS, although there are official explanations and explanations for the determination of different indicators of vulnerabilities, it is also possible that different people may Different understandings of vulnerabilities lead to different set results, and the final calculated values will also be different. This is inevitable, but SCAP is trying to provide a unified standard as much as possible.

Note: Newly added in SCAP version 1.2

CCSS Common Configuration Scoring System, similar to CVSS, except that CVSS is for vulnerabilities and is associated with CVE; CCSS is for configuration and is associated with CCE OCIL Open Checklist Interactive Language, similar to XCDDF

Vulnerability naming

Regarding the issue of vulnerability naming, we have previously designed a set of naming specifications, which are not part of the SCAP specification. The overall purpose is to roughly understand what kind of vulnerability it is through naming the vulnerability. You can also refer to the following:

grammar

The vulnerability naming in the vulnerability library mainly includes the name of the component that generates the vulnerability (that is, the component affected by the vulnerability): the version affected by the vulnerability, the location where the vulnerability occurs, the vulnerability type, and optional vectors. The naming rules are as follows:

漏洞影响组件名称+漏洞影响版本+漏洞产生位置+(向量)+漏洞类型

Vulnerability-affected component name: The vulnerability-affected component name mainly refers to the name of the specific component that generates the vulnerability. Components include various web applications, a certain plug-in, a certain system, a certain general module, etc., which can all be called components.
Vulnerability affected version: The vulnerability affected version refers to the version number corresponding to the component affected by the vulnerability. The version number here can be a single version (such as V1.0) or a range (such as >V1.0&<2.0), or The setting is the minimum value (such as >V1.0) or the maximum value (such as \<V2.0).
Vulnerability location: The vulnerability location refers to the specific problem that causes the vulnerability. The file location where the problem is located (such as /admin/admin.php) or the specific general function name or class name (such as _LoadBMP function) or both combination of persons.
Vector: Vector refers to vector, which is optional and refers to the input point of the vulnerability (for example, the vector of a SQL injection vulnerability is the parameter id)
Vulnerability type: Vulnerability type refers to the general vulnerability type, that is, the name of the vulnerability classification under the general classification corresponding to the vulnerability.

in principle

You can initially understand the basic information of the vulnerability through the vulnerability name.
Avoid duplication of vulnerability names as much as possible
Avoid long and meaningless vulnerability names

Example

ThinkSAAS 2.0.1 thinksaas.php local file contains vulnerability
ImLib BMP Image _LoadBMP function denial of service vulnerability
UFIDA U8 system/Server/CmxGetLoginType.php file appid parameter SQL injection vulnerability

Vulnerability Rating

Regarding the vulnerability rating issue, many people are accustomed to using the term "high, medium, low" or 1-10 to describe the vulnerability level. I have also designed a set based on Microsoft's DREAD risk model, which is also not part of SCAP. You can also refer to the following: Total vulnerabilities The risk level is divided into 10 levels, 1-4 being low risk, 5-7 being medium risk, and 8-10 being high risk.

Calculation formula

危险=发生的概率×潜在损失

Scoring item definition

Potential loss: How much would be lost if the flaw is exploited?
Reproducibility: How difficult is it to reproduce the attack?
Exploitability: How difficult is it to launch an attack?
Affected users: In rough percentage, how many users are affected?
Discoverability: Is the defect easy to find?