Security Center provides the vulnerability management feature. The feature can detect security vulnerabilities in operating systems, web content management systems, and applications. The feature can also evaluate the risk levels of vulnerabilities and priorities to fix the vulnerabilities. You can use the feature to fix specific types of vulnerabilities with a few clicks and reduce the attack surface on your system. This topic describes the types of vulnerabilities that can be detected and fixed, the priorities to fix vulnerabilities, and the supported operating systems.
Time required to update the vulnerability list
Security Center updates the list of supported vulnerabilities within a specific period of time after operating system providers release security bulletins. The following list describes the period of time based on operating systems:
Linux: Security Center adds vulnerabilities to the list of supported vulnerabilities within 14 × 24 hours, and adds high-risk vulnerabilities within 48 hours to the list after Linux providers release security bulletins for vulnerabilities in Common Vulnerabilities and Exposures (CVE).
Windows: Security Center adds vulnerabilities to the list of supported vulnerabilities within 48 hours after Microsoft releases security bulletins for vulnerabilities in CVE.
You can view the list of supported vulnerabilities in the Security Center console. If a vulnerability is displayed in the list, the vulnerability can be detected by Security Center.
The update of the list of supported vulnerabilities may be delayed during public holidays. If you require vulnerability detection during public holidays, submit a ticket.
Billing
Usage notes
Advanced, Enterprise, and Ultimate: No purchase is required. To fix vulnerabilities on a protected server, log on to the Security Center console and send commands that are required for vulnerability fixing to the server or call the OperateVuls or ModifyOperateVul operation. You are provided an unlimited quota for the vulnerability fixing feature.
Basic, Value-added Plan, and Anti-virus: To use the vulnerability fixing feature, purchase the feature by using the pay-as-you-go billing method or purchase a quota for the feature by using the subscription billing method. Then, log on to the Security Center console and send commands that are required for vulnerability fixing to the required server or call the OperateVuls or ModifyOperateVul operation.
Rules for calculating the number of fixed vulnerabilities
If you successfully fix a vulnerability on a server in the Security Center console, all Common Vulnerabilities and Exposures (CVE) vulnerabilities on the server in the security bulletin for the vulnerability are fixed. A security bulletin may contain multiple CVE vulnerabilities in the same software.
If you have 5 servers each of which requires fixing for 10 vulnerabilities (security bulletins) and you successfully fix the vulnerabilities by sending commands to the servers in the Security Center console, the total number of fixed vulnerabilities is 50.
If a server requires a restart after vulnerabilities on the server are fixed, the fixes are considered successful only after you restart the server and the vulnerability status is Fixed.
Failed attempts to fix vulnerabilities are not counted.
Types of vulnerabilities that can be detected and fixed
The following table describes the types of vulnerabilities that can be detected and fixed in each edition of Security Center.
The following symbols are used in the table:
: The feature is supported.
: The feature is not supported.
Vulnerability type | Feature | Basic edition | Value-added Plan edition | Anti-virus edition | Advanced edition | Enterprise edition | Ultimate edition |
Linux software vulnerability | Manual vulnerability scan | ||||||
Periodic automatic vulnerability scan | (The default scan cycle is two days.) | (The default scan cycle is two days.) | (The default scan cycle is two days.) | (The default scan cycle is one day.) | (The default scan cycle is one day.) | (The default scan cycle is one day.) | |
Vulnerability fixing | You must purchase a quota for vulnerability fixing or purchase vulnerability fixing based on the pay-as-you-go billing method. | You must purchase a quota for vulnerability fixing or purchase vulnerability fixing based on the pay-as-you-go billing method. | |||||
Windows system vulnerability | Manual vulnerability scan | ||||||
Periodic automatic vulnerability scan | (The default scan cycle is two days.) | (The default scan cycle is two days.) | (The default scan cycle is two days.) | (The default scan cycle is one day.) | (The default scan cycle is one day.) | (The default scan cycle is one day.) | |
Vulnerability fixing | You must purchase a quota for vulnerability fixing. | You must purchase a quota for vulnerability fixing. | |||||
Web-CMS vulnerability | Manual vulnerability scan | ||||||
Periodic automatic vulnerability scan | (The default scan cycle is two days.) | (The default scan cycle is two days.) | (The default scan cycle is two days.) | (The default scan cycle is one day.) | (The default scan cycle is one day.) | (The default scan cycle is one day.) | |
Vulnerability fixing | |||||||
Application vulnerability | Manual vulnerability scan | ||||||
Periodic automatic vulnerability scan | (The default scan cycle is one week. You can specify a custom scan cycle.) | (The default scan cycle is one week. You can specify a custom scan cycle.) | |||||
Vulnerability fixing | |||||||
Urgent vulnerability | Manual vulnerability scan | ||||||
Periodic automatic vulnerability scan | (The default scan cycle is one week. You can specify a custom scan cycle.) | (The default scan cycle is one week. You can specify a custom scan cycle.) | (The default scan cycle is one week. You can specify a custom scan cycle.) | ||||
Vulnerability fixing |
Security Center can only detect urgent vulnerabilities and application vulnerabilities, but cannot fix these types of vulnerabilities. If you want to fix these types of vulnerabilities, you must log on to the server on which the vulnerabilities are detected and manually fix the vulnerabilities based on the fix suggestions provided on the details pages of the vulnerabilities.
Priorities to fix vulnerabilities
If multiple vulnerabilities are detected on your assets, you may be unable to identify the vulnerability that needs to be fixed at the earliest opportunity. To address this issue, Security Center provides the Alibaba Cloud vulnerability scoring system that evaluates vulnerabilities and prioritizes remediation for the vulnerabilities. This way, you can determine the priorities to fix vulnerabilities based on the score of urgency to fix a vulnerability.
Alibaba Cloud vulnerability scoring system
The Common Vulnerability Scoring System (CVSS) can evaluate the scopes and impacts of vulnerabilities. The CVSS can also evaluate the possibility of exploiting a vulnerability and inform you about the consequences of the vulnerability. Alibaba Cloud analyzes the severity levels of vulnerabilities that are detected in actual attack and defense scenarios, and then develops a vulnerability scoring system based on the principles of CVSS.
The Alibaba Cloud vulnerability scoring system determines the score of urgency to fix a vulnerability based on the severity level of the vulnerability in the actual cloud-based attack and defense scenarios, the exploitability of the vulnerability in the threat detection model, and the status of exploits that are disclosed on the Internet. The severity level can be low, medium, high, or critical, and the severity level is converted from the score that the CVSS gives to the vulnerability. The threat detection model is provided by Security Center. This way, the system helps enterprises remediate vulnerabilities that are at high risk of being exploited and ensures the effectiveness of vulnerability remediation.
The severity level of a vulnerability is determined based on the following factors:
Technology.
Exploitability, which can be a proof of concept (PoC), an exploit, a weaponized worm, or a weaponized virus.
Threat. This factor indicates whether the vulnerability can be exploited to obtain server permissions.
Number of IP addresses that are affected after the vulnerability is exploited. This factor indicates the likelihood that the vulnerability is exploited by attackers.
Formula for the score of urgency to fix a vulnerability
The score of urgency to fix a vulnerability dynamically changes. After a vulnerability is disclosed, the Alibaba Cloud vulnerability scoring system gives a score to the vulnerability based on the impacts that may be caused by the vulnerability. The score is called the Alibaba Cloud vulnerability score. When operating systems are updated, some vulnerabilities are fixed. Therefore, less operating systems are affected by the vulnerabilities, and the threat of the vulnerabilities is reduced. This lowers the score of urgency to fix this type of vulnerability. In addition, the score of urgency to fix a vulnerability is affected by the deployment environment and the importance of an asset.
Alibaba Cloud provides the following formula to calculate the score of urgency to fix a vulnerability:
Score of urgency to fix a vulnerability = Alibaba Cloud vulnerability score × Time score × Environment score × Asset importance score
The following table describes the elements in the formula.
Element | Description | Remarks |
Alibaba Cloud vulnerability score | The score is generated based on the Alibaba Cloud vulnerability scoring system. | The score is used to evaluate the severity level of a vulnerability. |
Time score | A dynamic time curve is used. The curve is generated based on factors such as the postponement in the deployment of vulnerability mitigation and the popularization of vulnerability exploit methods. Valid values: 0 to 1. | Within three days after a vulnerability is exposed, the possibility that the vulnerability is exploited significantly increases. During this period, the time score increases from 0 to a temporary peak value, which is less than 1. After this period, the time score significantly decreases. Vulnerabilities become easier to be exploited over time due to increased exploitability. The time score increases and approaches 1 within 100 days. |
Environment score | The score indicates the environmental condition of your server. Security Center calculates the environment score based on factors such as the conditions of exploiting a vulnerability and the status of your server. The environment score is an important element in the preceding formula. | The following list describes the factors that determine the environment score:
|
Asset importance score | If you have a large number of servers, the system calculates asset importance scores for different servers based on their importance in different scenarios. The asset importance score is an important element in the preceding formula. | The default value is 1. On the Host page, you can attach one of the following tags to your assets: Important, Normal, and Test. The asset importance score varies based on the following types of assets:
|
Priorities to fix vulnerabilities
You can fix vulnerabilities based on priorities, which are determined by the score of urgency to fix a vulnerability.
The following table describes the mappings between the score of urgency to fix a vulnerability and each priority.
Priority | Description | Score of urgency to fix a vulnerability | Suggestion |
High | This priority is assigned to a vulnerability that can be easily exploited by an unauthenticated remote attacker. The vulnerability can be exploited to compromise systems over arbitrary code execution without user interactions. In most cases, this type of vulnerability is exploited by worms or ransomware. | Greater than 13.5 | We recommend that you fix this type of vulnerability at the earliest opportunity. |
Medium | This priority is assigned to a vulnerability that may adversely affect the confidentiality, integrity, or availability of resources. In most cases, this type of vulnerability cannot be exploited. However, this type of vulnerability is given a high score by the CVSS when they are disclosed on the Internet or at an official website. We recommend that you attach importance to this type of vulnerability. | 7.1 to 13.5 | We recommend that you fix this type of vulnerability based on your business requirements. |
Low | This priority is assigned to a vulnerability that has the lowest possibility of being exploited or does not pose risks after it is exploited. In most cases, this type of vulnerability is a bug in the source code of a program or a vulnerability that affects compliance and service performance. | Less than 7 | We recommend that you ignore this type of vulnerability. |
If the environment score of a vulnerability cannot be calculated due to reasons such as network jitters, the priority to fix the vulnerability is Low.
Urgent and Web-CMS vulnerabilities are assigned the High priority, which is confirmed by Alibaba Cloud security engineers. We recommend that you fix urgent and Web-CMS vulnerabilities at the earliest opportunity.
Limits
Supported operating systems of vulnerability detection and vulnerability fixing
Supported operating system | Version |
Windows Server |
|
CentOS |
|
Redhat |
|
Ubuntu |
|
Alibaba Cloud Linux |
|
Anolis OS |
|
Debian |
Note Security Center can detect vulnerabilities but cannot fix vulnerabilities. |
SUSE |
|
Kylin | Kylin V10 |
Lifecycles of operating systems
If an operating system reaches its EOL, Security Center no longer detects or fixes Linux software vulnerabilities and Windows system vulnerabilities in the operating system. The following table describes the operating systems that are subject to this limit. Other features of Security Center are not affected.
Operating system version | Official EOL date | Impact on vulnerability-related features |
Windows Server 2003 | July 14, 2015 | Security Center detects only vulnerabilities that are exposed before July 14, 2015 and applies patches to fix the vulnerabilities. |
Windows Server 2008 | January 14, 2020 | Security Center detects only vulnerabilities that are exposed before January 14, 2020 and applies patches to fix the vulnerabilities. |
Windows Server 2008 R2 | January 14, 2020 | Security Center detects only vulnerabilities that are exposed before January 14, 2020 and applies patches to fix the vulnerabilities. |
Windows Server 2008 SP2 | January 14, 2020 | Security Center detects only vulnerabilities that are exposed before January 14, 2020 and applies patches to fix the vulnerabilities. |
Windows Server 2012 | October 10, 2023 | Security Center detects only vulnerabilities that are exposed before October 10, 2023 and applies patches to fix the vulnerabilities. |
Windows Server 2012 R2 | October 10, 2023 | Security Center detects only vulnerabilities that are exposed before October 10, 2023 and applies patches to fix the vulnerabilities. |
Ubuntu 12.04 LTS | April 28, 2017 | Security Center detects only vulnerabilities that are exposed before April 28, 2017 and applies patches to fix the vulnerabilities. |
Ubuntu 14.04 LTS | April 2019 | Security Center detects only vulnerabilities that are exposed before April 2019 and applies patches to fix the vulnerabilities. |
Ubuntu 16.04 LTS | April 2021 | Security Center detects only vulnerabilities that are exposed before April 2021 and applies patches to fix the vulnerabilities. |
Ubuntu 18.04 LTS | April 2023 | Security Center detects only vulnerabilities that are exposed before April 2023 and applies patches to fix the vulnerabilities. |
CentOS 5 | March 31, 2017 | Security Center detects only vulnerabilities that are exposed before March 31, 2017 and applies patches to fix the vulnerabilities. |
CentOS 6 | November 30, 2020 | Security Center detects only vulnerabilities that are exposed before November 30, 2020 and applies patches to fix the vulnerabilities. |
CentOS 8 | December 31, 2021 | Security Center detects only vulnerabilities that are exposed before December 31, 2021 and applies patches to fix the vulnerabilities. |
Redhat 5 | March 31, 2017 | Security Center detects only vulnerabilities that are exposed before March 31, 2017 and applies patches to fix the vulnerabilities. |
Redhat 6 | November 30, 2020 | Security Center detects only vulnerabilities that are exposed before November 30, 2020 and applies patches to fix the vulnerabilities. |
Vulnerability retention period
To maintain a clean and efficient vulnerability management system and prevent long-standing vulnerabilities from consuming resources, Security Center automatically deletes vulnerabilities whose status remains unchanged for a long period of time.
If a vulnerability is in a state other than the Invalid state and the status of the vulnerability remains unchanged for more than a year, Security Center automatically deletes the vulnerability. The states other than the Invalid state include Fixed, Fixing Failed, Ignored, Unfixed, Fixing, and Verifying.
After the status of a vulnerability changes to Invalid, if the vulnerability remains in the Invalid state and the duration reaches the threshold, Security Center automatically deletes the vulnerability. You can configure the Retain Invalid Vulnerabilities For: parameter in the Vulnerability Settings panel to specify the threshold. For more information, see View and handle vulnerabilities.