A cloud platform-based vulnerability alarm method and device

Abstract

The application provides a cloud platform-based vulnerability alarm method and device, comprising: obtaining a security vulnerability existing in a cloud platform and a physical machine with the security vulnerability; determining a service of the cloud platform supported by the physical machine; predicting a virtual asset loss caused by the security vulnerability to the service within a target period to obtain a loss value; generating vulnerability alarm information for prompting the security vulnerability existing in the cloud platform based on the loss value, wherein the vulnerability alarm information comprises the virtual asset loss caused by the security vulnerability to the service; and outputting the vulnerability alarm information corresponding to the security vulnerability. Through the application, the virtual asset loss caused by the security vulnerability to the service within the target period can be predicted, and the vulnerability alarm information comprising the virtual asset loss caused by the security vulnerability to the service can be generated and output.

Description

Technical Field

[0001] This application relates to Internet technology, and in particular to a vulnerability alerting method and device based on a cloud platform. Background Technology

[0002] A vulnerability, also known as a flaw, is a defect or deficiency in the specific implementation of hardware, software, and protocols, or in the system's security strategy, of a computer system. Unauthorized users can exploit these vulnerabilities to gain additional privileges on the computer system, allowing them to access or elevate their access without authorization, thereby damaging the system and compromising computer security. Vulnerabilities in cloud platforms are primarily assessed using two methods: one is based on open vulnerability assessment languages, which standardizes and normalizes the description of vulnerabilities; the other is vulnerability scoring research targeting the Software-as-a-Service (SaaS) layer of cloud service providers, which allows professionals to better understand the harm caused by vulnerabilities. However, these assessment methods only allow professionals to intuitively understand the impact of vulnerabilities, making it difficult for business departments or other non-professionals to intuitively understand the harm they pose. Summary of the Invention

[0003] This application provides a cloud-based vulnerability alerting method, device, electronic device, computer-readable storage medium, and computer program product, which can predict the virtual asset losses caused by security vulnerabilities to business operations during a target period, and generate and output vulnerability alert information including the virtual asset losses caused by security vulnerabilities to business operations.

[0004] The technical solution of this application embodiment is implemented as follows:

[0005] This application provides a vulnerability alerting method based on a cloud platform, including:

[0006] Identify the security vulnerabilities existing in the cloud platform and the hosts containing the security vulnerabilities;

[0007] Determine the services of the cloud platform supported by the host;

[0008] Predict the virtual asset losses that the security vulnerability will cause to the business during the target time period, and obtain the loss value;

[0009] Based on the loss value, a vulnerability alert is generated to indicate the existence of the security vulnerability in the cloud platform. The vulnerability alert includes the loss of virtual assets caused by the security vulnerability to the business.

[0010] Output the vulnerability alert information corresponding to the security vulnerability.

[0011] This application provides a vulnerability alerting device based on a cloud platform, comprising:

[0012] The acquisition module is used to acquire security vulnerabilities existing in the cloud platform and the physical machines containing the security vulnerabilities.

[0013] A determination module is used to determine the services of the cloud platform supported by the physical machine;

[0014] The prediction module is used to predict the virtual asset losses caused by the security vulnerability to the business within a target time period, and obtain the loss value;

[0015] The generation module is used to generate vulnerability alert information based on the loss value to indicate the existence of the security vulnerability in the cloud platform. The vulnerability alert information includes the virtual asset loss caused by the security vulnerability to the business.

[0016] The output module is used to output the vulnerability alert information corresponding to the security vulnerability.

[0017] In the above scheme, the acquisition module is further used to acquire vulnerability data that affects the security of the cloud platform, as well as the types of security vulnerabilities existing in the cloud platform; wherein, the vulnerability data includes at least one of the following: host device data, host network data, and service data of services deployed in the host; and analyzes the vulnerability data according to the types of security vulnerabilities existing in the cloud platform to determine the security vulnerabilities existing in the cloud platform.

[0018] In the above scheme, the device further includes a normalization module, which is used to determine the security impact category to which the security vulnerability belongs; obtain the risk level range corresponding to the security impact category; map the risk level of the security vulnerability to the risk level range to obtain the risk level value of the security vulnerability; the prediction module is also used to predict the virtual asset loss caused by the security vulnerability to the business within a target time period based on the risk level value of the security vulnerability, and obtain the loss value.

[0019] In the above scheme, the normalization module is further used to obtain the security vulnerability type corresponding to the security vulnerability; based on the security vulnerability type, map the risk level of the security vulnerability to a risk level range to obtain a mapping result; and based on the mapping result, obtain the risk level value of the security vulnerability.

[0020] In the above scheme, the prediction module is further configured to: obtain a first risk item associated with the security vulnerability and a second risk item associated with the host; wherein the first risk item includes at least one of the following: security vulnerability type, vulnerability exploitation method, vulnerability exposure port, and vulnerability attack method; and the second risk item includes at least one of the following: host defense mechanism and host vulnerability data; determine a first risk level value corresponding to the first risk item and a second risk level value corresponding to the second risk item; and based on the first risk level value and the second risk level value, predict the virtual asset loss caused by the security vulnerability to the business within a target time period, and obtain the loss value.

[0021] In the above solution, the security vulnerability includes a first vulnerability existing on the cloud platform side and a second vulnerability existing on the cloud platform user side. The prediction module is further used to predict the first loss caused to the business by the first vulnerability within a target time period; predict the second loss caused to the business by the second vulnerability within a target time period; and sum the first loss and the second loss to obtain the loss value corresponding to the virtual asset loss caused to the business by the security vulnerability within the target time period.

[0022] In the above scheme, the prediction module is further used to obtain the loss influencing factors associated with the second vulnerability, the loss influencing factors including at least one of the vulnerability exploitation method of the second vulnerability, user-side defense mechanism, and user-side business type; based on the loss influencing factors associated with the second vulnerability, determine the second loss caused by the second vulnerability to the business within the target time period.

[0023] In the above scheme, the prediction module is further used to: determine the total amount of virtual assets of the services supported by the host during the target time period; determine the ratio of the number of hosts with the security vulnerability to the total number of hosts supporting the services; and based on the total amount of virtual assets and the ratio, predict the virtual asset loss caused by the security vulnerability to the services during the target time period, and obtain the loss value.

[0024] In the above scheme, the device further includes a second acquisition module, which is used to acquire the time point at which the security vulnerability was discovered, and the repair time required for the host with the security vulnerability to repair the security vulnerability; and to determine the target time period based on the time point at which the security vulnerability was discovered and the repair time.

[0025] In the above scheme, the generation module is further used to obtain the information template of the vulnerability alarm information; and based on the loss value and the information template, generate vulnerability alarm information to indicate the existence of the security vulnerability in the cloud platform.

[0026] In the above scheme, the output module is further configured to: determine the management terminal corresponding to the host based on the obtained host with the security vulnerability; obtain the notification method corresponding to the vulnerability alarm information; and send the vulnerability alarm information to the management terminal using the notification method, so as to output the vulnerability alarm information through the management terminal.

[0027] This application provides an electronic device, including:

[0028] Memory, used to store executable instructions;

[0029] When the processor executes the executable instructions stored in the memory, it implements the cloud-based vulnerability alerting method provided in the embodiments of this application.

[0030] This application provides a computer-readable storage medium storing executable instructions, which, when executed by a processor, implement the cloud-based vulnerability alerting method provided in this application.

[0031] This application provides a computer program product or computer program that includes computer instructions stored in a computer-readable storage medium. A processor of an electronic device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the electronic device to perform the cloud-based vulnerability alerting method provided in this application.

[0032] The embodiments of this application have the following beneficial technical effects:

[0033] When assessing and alerting on vulnerabilities in cloud platforms, it can predict the virtual asset losses that security vulnerabilities will cause to the business during the target period, and generate and output vulnerability alert information that includes the virtual asset losses caused by security vulnerabilities. In this way, since the output vulnerability alert information includes the virtual asset losses caused by security vulnerabilities, users or relevant personnel can more intuitively understand the impact and severity of security vulnerabilities on the business, thereby prompting users to fix security vulnerabilities more efficiently. Attached Figure Description

[0034] Figure 1 This is an optional architecture diagram of the cloud platform-based vulnerability alerting system provided in this application embodiment;

[0035] Figure 2 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application;

[0036] Figure 3 This is a flowchart illustrating the cloud-based vulnerability alerting method provided in this application embodiment;

[0037] Figure 4 This is an optional flowchart illustrating a cloud-based vulnerability warning method provided in an embodiment of this application.

[0038] Figure 5 This is an optional flowchart illustrating the prediction of virtual asset losses caused to business operations by security vulnerabilities within a target time period, provided in an embodiment of this application.

[0039] Figure 6A This is an optional schematic diagram illustrating the predicted virtual asset losses to services caused by security vulnerabilities within a target time period, provided in an embodiment of this application.

[0040] Figure 6B This is an optional schematic diagram illustrating the predicted virtual asset losses to services caused by security vulnerabilities within a target time period, provided in an embodiment of this application.

[0041] Figure 7 This is an optional flowchart illustrating the prediction of virtual asset losses caused to business operations by security vulnerabilities within a target time period, provided in an embodiment of this application.

[0042] Figure 8A This is an optional schematic diagram illustrating the second loss to the business caused by the second vulnerability during the target time period, provided in an embodiment of this application.

[0043] Figure 8B This is an optional schematic diagram illustrating the second loss to the business caused by the second vulnerability during the target time period, provided in an embodiment of this application.

[0044] Figure 9A This is an optional schematic diagram illustrating the total vulnerability loss provided in an embodiment of this application;

[0045] Figure 9B This is an optional schematic diagram illustrating the total vulnerability loss provided in an embodiment of this application;

[0046] Figure 9C This is an optional schematic diagram illustrating the total vulnerability loss provided in an embodiment of this application;

[0047] Figure 10 This is an optional flowchart illustrating a cloud-based vulnerability alerting method provided in an embodiment of this application.

[0048] Figure 11 This is an optional schematic diagram illustrating the calculation process of cloud platform-side loss provided in an embodiment of this application;

[0049] Figure 12 This is an optional schematic diagram illustrating the calculation process of user-side loss on the cloud platform provided in this application embodiment. Detailed Implementation

[0050] To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings. The described embodiments should not be regarded as limitations on this application. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0051] In the following description, references are made to “some embodiments,” which describe a subset of all possible embodiments. However, it is understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0052] In the following description, the terms "first, second, third" are used merely to distinguish similar objects and do not represent a specific ordering of objects. It is understood that "first, second, third" may be interchanged in a specific order or sequence where permitted, so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein.

[0053] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0054] Before providing a further detailed description of the embodiments of this application, the nouns and terms involved in the embodiments of this application will be explained, and the nouns and terms involved in the embodiments of this application shall be interpreted as follows.

[0055] 1) Cloud platform vulnerabilities: Vulnerabilities existing in the cloud platform itself (such as vulnerabilities in the cloud platform infrastructure, vulnerabilities in the cloud platform's own business, including but not limited to web vulnerabilities, component vulnerabilities, logic vulnerabilities, etc.), as well as vulnerabilities on the user side of the cloud platform that can affect the cloud platform service provider or other tenants under the cloud platform (i.e., the vulnerability can affect the cloud platform's own business or other users under the cloud platform through any user).

[0056] 2) POC: Proof of Concept. In the security field, a POC is a description or an example of an attack that allows the reader to confirm that the vulnerability actually exists.

[0057] 3) Tenant (User): This refers to an individual who purchases products / services provided by a cloud service provider on the cloud platform. Products include, but are not limited to, specific products such as cloud virtual machines and cloud disks, while services include, but are not limited to, SMS sending and voice recognition. If a cloud platform service provider provides its cloud platform products / services to its subordinate units or subsidiaries, they are also considered tenants (users).

[0058] 4) Remote exploitation: This refers to a vulnerability type that can be exploited by remotely sending data packets as long as the network is open.

[0059] 5) Local exploitation: A vulnerability type that can only be exploited after a file is transferred to the machine and then run.

[0060] 6) Exposure surface: This refers to assets or services that the cloud platform or cloud tenant directly exposes to the outside world (remote direct access). Examples include open ports or interfaces. These exposure surfaces are often directly exploitable once vulnerabilities are discovered.

[0061] 7) Attack Surface: This generally refers to the attack surface that can be exploited within the cloud platform. For example, the communication methods between cloud hosts and the cloud platform. If a vulnerability is discovered and successfully exploited, there is a possibility of directly controlling some functions of the cloud platform or controlling other cloud hosts.

[0062] 8) Cloud platform: A service platform that provides cloud-based services for developers to use when creating applications, including cloud computing and cloud storage.

[0063] 9) Cloud computing: A computing model that distributes computing tasks across a resource pool consisting of a large number of computers, enabling various application systems to obtain computing power, storage space, and information services as needed. The network providing these resources is called the cloud. From the user's perspective, cloud resources appear infinitely scalable, readily available, on-demand, and expandable, with payment based on usage.

[0064] 10) Cloud storage: A new concept that has been extended and developed from the concept of cloud computing. A distributed cloud storage system (hereinafter referred to as storage system) refers to a storage system that uses cluster applications, grid technology and distributed storage file system functions to bring together a large number of storage devices of various types in the network (storage devices are also called storage nodes) to work together through application software or application interfaces to provide data storage and business access functions to the outside world.

[0065] 11) Virtual assets: also known as virtual resources, are used to indicate the total inflow of equity formed in the ordinary course of business that leads to an increase in owners' equity and is unrelated to the owners' capital contributions.

[0066] The applicant found that the assessment results obtained when evaluating the danger of vulnerabilities are often only understandable to professionals (such as vulnerability severity scores), making it difficult for business departments or other personnel to intuitively understand the harm caused by the vulnerability. At the same time, the assessment process mainly considers the vulnerabilities of the cloud platform itself, while ignoring the vulnerabilities of the tenants themselves and the vulnerabilities that can affect the cloud platform from the tenant's side.

[0067] Based on this, embodiments of this application provide a vulnerability alerting method, apparatus, device, computer-readable storage medium, and computer program product based on a cloud platform. By combining relevant data such as business type, amount involved in the business, and business scope, the potential amount of loss can be calculated, thereby making the public more intuitively aware of the harm of the vulnerability. At the same time, it not only considers the vulnerability on the tenant side itself, but also the relationship between tenants and between tenants and the cloud platform, thus making a more comprehensive analysis.

[0068] See Figure 1 , Figure 1 This is an optional architecture diagram of the cloud platform-based vulnerability alerting system 100 provided in this application embodiment. To realize the application scenario of cloud platform-based vulnerability alerting (for example, the application scenario of cloud platform-based vulnerability alerting can be that a website is built based on a cloud server, and a vulnerability appears in the underlying machine of the server during the operation of the website, or a logical vulnerability appears in the business or management page of the website, so a vulnerability alerting system is used to alert the vulnerability), the terminal (terminal 400 is shown as an example) connects to the server 200 through the network 300. The network 300 can be a wide area network or a local area network, or a combination of both.

[0069] Terminal 400 is used by users to access client 401 and is displayed on display interface 401-1 (display interface 401-1 is shown as an example). Terminal 400 and server 200 are interconnected via wired or wireless network.

[0070] Server 200 is used to acquire security vulnerabilities existing in the cloud platform and the hosts with security vulnerabilities; determine the cloud platform services supported by the hosts; predict the virtual asset losses caused by the security vulnerabilities to the services within a target time period and obtain the loss value; based on the loss value, generate vulnerability alarm information to indicate the existence of security vulnerabilities in the cloud platform, the vulnerability alarm information including the virtual asset losses caused by the security vulnerabilities to the services; and output the vulnerability alarm information corresponding to the security vulnerabilities to the terminal 400 corresponding to the host with the security vulnerabilities.

[0071] Terminal 400 is also used to display the received vulnerability alert information on the display interface 401-1.

[0072] In some embodiments, server 200 may be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDNs), and big data and artificial intelligence platforms. Terminal 400 may be a smartphone, tablet, laptop, desktop computer, set-top box, or mobile device (e.g., mobile phone, portable music player, personal digital assistant, dedicated messaging device, in-vehicle terminal, in-vehicle infotainment system, in-vehicle data center, portable gaming device, smart speaker, and smartwatch), but is not limited thereto. Terminal devices and servers can be directly or indirectly connected via wired or wireless communication, which is not limited in this embodiment.

[0073] See Figure 2 , Figure 2 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. In practical applications, the electronic device can be... Figure 1 The server 200 or terminal 400 shown are described in the following document. Figure 2 , Figure 2 The illustrated electronic device includes at least one processor 410, a memory 450, at least one network interface 420, and a user interface 430. The various components in terminal 400 are coupled together via a bus system 440. It is understood that the bus system 440 is used to implement communication between these components. In addition to a data bus, the bus system 440 also includes a power bus, a control bus, and a status signal bus. However, for clarity, in… Figure 2 The general labeled all buses as Bus System 440.

[0074] The processor 410 can be an integrated circuit chip with signal processing capabilities, such as a general-purpose processor, a digital signal processor (DSP), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor, etc.

[0075] User interface 430 includes one or more output devices 431 that enable the presentation of media content, including one or more speakers and / or one or more visual displays. User interface 430 also includes one or more input devices 432, including user interface components that facilitate user input, such as a keyboard, mouse, microphone, touch screen display, camera, other input buttons and controls.

[0076] The memory 450 may be removable, non-removable, or a combination thereof. Exemplary hardware devices include solid-state storage, hard disk drives, optical disk drives, etc. The memory 450 may optionally include one or more storage devices physically located away from the processor 410.

[0077] The memory 450 may include volatile memory or non-volatile memory, or both. The non-volatile memory may be read-only memory (ROM), and the volatile memory may be random access memory (RAM). The memory 450 described in this application embodiment is intended to include any suitable type of memory.

[0078] In some embodiments, memory 450 is capable of storing data to support various operations, examples of which include programs, modules, and data structures or subsets or supersets thereof, as illustrated below.

[0079] Operating system 451 includes system programs for handling various basic system services and performing hardware-related tasks, such as the framework layer, core library layer, driver layer, etc., for implementing various basic business functions and handling hardware-based tasks;

[0080] The network communication module 452 is used to reach other computing devices via one or more (wired or wireless) network interfaces 420, exemplary network interfaces 420 including: Bluetooth, WiFi, and Universal Serial Bus (USB), etc.

[0081] Presentation module 453 is configured to enable the presentation of information (e.g., a user interface for operating peripheral devices and displaying content and information) via one or more output devices 431 (e.g., a display screen, a speaker, etc.) associated with user interface 430;

[0082] The input processing module 454 is used to detect and translate one or more user inputs or interactions from one or more input devices 432.

[0083] In some embodiments, the cloud-based vulnerability alerting device provided in this application can be implemented in software. Figure 2A cloud-based vulnerability alerting device 455 stored in memory 450 is shown. It can be software in the form of programs and plug-ins, including the following software modules: acquisition module 4551, determination module 4552, prediction module 4553, generation module 4554, and output module 4555. These modules are logical and can therefore be arbitrarily combined or further split according to the functions they implement.

[0084] In other embodiments, the cloud-based vulnerability alerting device provided in this application can be implemented in hardware. As an example, the cloud-based vulnerability alerting device provided in this application can be a processor in the form of a hardware decoding processor, which is programmed to execute the cloud-based vulnerability alerting method provided in this application. For example, the processor in the form of a hardware decoding processor can be one or more application-specific integrated circuits (ASICs), DSPs, programmable logic devices (PLDs), complex programmable logic devices (CPLDs), field-programmable gate arrays (FPGAs), or other electronic components.

[0085] In some embodiments, the terminal or server can implement the cloud-based vulnerability alerting method provided in this application by running a computer program. For example, the computer program can be a native program or software module in an operating system; it can be a native application (APP), i.e., a program that needs to be installed in the operating system to run, such as an instant messaging APP or a web browser APP; it can also be a mini-program, i.e., a program that only needs to be downloaded to a browser environment to run; or it can be a mini-program that can be embedded in any APP. In short, the above-mentioned computer program can be any form of application, module, or plugin.

[0086] Based on the above description of the cloud-based vulnerability alerting system and electronic device provided in the embodiments of this application, the cloud-based vulnerability alerting method provided in the embodiments of this application is described below. In actual implementation, the cloud-based vulnerability alerting method provided in the embodiments of this application can be implemented by a terminal or a server alone, or by a terminal and a server working together, so that... Figure 1 The following description uses the example of server 200 executing the cloud-based vulnerability alerting method provided in this application embodiment. See also... Figure 3 , Figure 3This is a flowchart illustrating the cloud-based vulnerability alerting method provided in this application embodiment, which will be combined with... Figure 3 The steps shown are explained.

[0087] Step 101: The server obtains the security vulnerabilities existing in the cloud platform, as well as the hosts with security vulnerabilities.

[0088] In practice, the process of obtaining security vulnerabilities in the cloud platform involves first obtaining vulnerability data that affects the security of the cloud platform, as well as the types of security vulnerabilities existing in the cloud platform. The vulnerability data includes at least one of the following: host device data, host network data, and service data of services deployed on the host. Then, based on the types of security vulnerabilities existing in the cloud platform, the vulnerability data is analyzed to determine the security vulnerabilities existing in the cloud platform.

[0089] In actual implementation, the host device data, host network data, and service data of the services deployed on the host can be the host device data, host network data, and service data of the services deployed on the host of the cloud platform itself, or it can be the host device data, host network data, and service data of the services deployed on the host of the cloud platform user side, or it can be the host device data, host network data, and service data of the services deployed on the host of the cloud platform itself, as well as the host device data, host network data, and service data of the services deployed on the host of the cloud platform user side.

[0090] In practice, the process of obtaining vulnerability data that affects the security of the cloud platform can involve reading at least one of the following data from the database or other interfaces: host device data, host network data, and service data of services deployed on the host. Then, based on the types of security vulnerabilities existing in the cloud platform, such as cross-site scripting vulnerabilities, SQL (Structured Query Language) injection vulnerabilities, weak password vulnerabilities, payment vulnerabilities, password recovery vulnerabilities, and unauthorized queries, the obtained vulnerability data is analyzed to determine the security vulnerabilities existing in the cloud platform.

[0091] As an example, when a cloud server is purchased from a cloud platform and an operating system is run on it, and the operating system is found to have vulnerabilities that could be exploited remotely, the obtained data represents the cloud platform's own host device data. Similarly, when a cloud server is purchased from a cloud platform and an online store is set up on it to provide services, data such as user access time, port, and user IP information recorded when users visit the store is obtained; this data represents the cloud platform's own host network data. Furthermore, when a cloud server is purchased from a cloud platform and an online store is set up on it to provide services, data such as user registration information (e.g., phone number, name) and shopping information are obtained; this data represents the service data of the services deployed on the cloud platform's own hosts. Then, based on the types of security vulnerabilities present in the cloud platform, the obtained data is analyzed to identify the security vulnerabilities within the cloud platform.

[0092] In practice, the process of identifying hosts with security vulnerabilities involves obtaining vulnerability data and then determining the hosts with security vulnerabilities based on the hosts corresponding to the vulnerability data.

[0093] In practice, after reading vulnerability data that affects cloud platform security from the database or other interfaces, the data can be summarized from the host / business system or other perspectives. For example, vulnerability information and network location information related to host A can be summarized together. This makes it easier to conduct further analysis or provide the data to users for reading and analysis.

[0094] In some embodiments, see Figure 4 , Figure 4 This is an optional flowchart illustrating a cloud-based vulnerability warning method provided in an embodiment of this application. Figure 3 After step 101, the following can also be executed:

[0095] Step 201: The server determines the security impact category to which the security vulnerability belongs.

[0096] In practice, security vulnerabilities are first categorized based on their type. Based on this categorization, the security impact category to which the vulnerability belongs is determined. For example, these categories include web vulnerabilities, binary vulnerabilities, logic vulnerabilities, and component vulnerabilities. After identifying the vulnerability, it is further categorized based on its type, such as cross-site scripting (XSS), SQL injection, weak password, payment vulnerabilities, password recovery vulnerabilities, and unauthorized access vulnerabilities, to determine its security impact category. For instance, if a vulnerability is a cross-site scripting vulnerability, SQL injection, or weak password, its security impact category is web vulnerability. Conversely, if a vulnerability is a payment vulnerability, password recovery vulnerability, or unauthorized access vulnerabilities, its security impact category is logic vulnerability.

[0097] Step 202: Obtain the risk level range corresponding to the safety impact category.

[0098] In practice, after determining the security impact category to which a security vulnerability belongs, the risk level range corresponding to that category is obtained. This risk level range is determined by ranking the severity of the security vulnerability type's threat to host security. Specifically, security vulnerability types are ranked from highest to lowest or lowest to highest severity. After ranking, the severity of the security vulnerability type's threat to host security is quantified, mapping the risk level of the security vulnerability type to a specific dimension. For example, when the security vulnerability types are component vulnerabilities, web vulnerabilities, and logic vulnerabilities, they are ranked from highest to lowest severity, resulting in component vulnerabilities, web vulnerabilities, and logic vulnerabilities. The risk level of each vulnerability type is then mapped to the following dimensions: component vulnerabilities ∈ [10, 7], web vulnerabilities ∈ (7, 4], and logic vulnerabilities ∈ (4, 0). Here, component vulnerabilities are a broad category with many subcategories such as operating systems, middleware, databases, web containers, and other components; therefore, a range is used to represent them.

[0099] It's important to note that the severity of security vulnerabilities is calculated based on their potential impact. For example, remote code execution vulnerabilities are often considered more severe than cross-site request vulnerabilities. In practice, if the classification of vulnerability types is unclear, one can refer to Common Vulnerabilities and Exposures (CVEs) or the description of the vulnerability in the China National Vulnerability Database (CNVD) for classification. Furthermore, the ranking of certain vulnerability types can be intentionally adjusted based on the characteristics of actual business operations. For instance, in cloud platforms that heavily utilize third-party components, component vulnerabilities could be ranked higher.

[0100] Step 203: Map the risk level of the security vulnerability to a risk level range to obtain the risk level value of the security vulnerability.

[0101] In practice, after obtaining the risk level range corresponding to the security impact category, the risk level of the security vulnerability is mapped to the risk level range based on the type of security vulnerability, thereby normalizing the risk level of the security vulnerability and obtaining the risk level value of the security vulnerability.

[0102] Following the example above, the risk level range of the obtained security vulnerabilities is component vulnerability ∈ [10, 7], web vulnerability ∈ (7, 4], and logic vulnerability ∈ (4, 0). Thus, when the security vulnerability is a component vulnerability, the risk level of the security vulnerability is mapped to the risk level range, that is, the risk level of the security vulnerability is determined to be ∈ [10, 7].

[0103] It should be noted that after determining the risk level range of a security vulnerability, since each security impact category includes various types of security vulnerabilities, the risk level value of the security vulnerability is determined from the risk level range based on its security type. This determination can be made using a list or by directly taking the midpoint of the range. For example, when determining the risk level value of a security vulnerability from the risk level range using a list, if the security vulnerability is a web vulnerability, since web vulnerabilities include various security vulnerability types such as cross-site scripting vulnerabilities, SQL injection vulnerabilities, and weak password vulnerabilities, different risk levels are presented in a list. The risk level value corresponding to the vulnerability type within the risk level range of the web vulnerability is listed. For example, if a web vulnerability ∈ (7, 4], the list shows a risk level value of 4 for cross-site scripting (XSS), 5 for SQL injection, and 6 for weak password vulnerabilities. Thus, the risk level value of a security vulnerability can be queried from the list. However, when the method of determining the risk level value of a security vulnerability from the risk level range is to directly take the midpoint of the range, continuing with the above example, if a web vulnerability ∈ (7, 4], then the risk level values ​​for XSS, SQL injection, and weak password vulnerabilities are all 5.5. This application does not limit the method of determining the risk level value of a security vulnerability from the corresponding risk level range.

[0104] Step 204: Based on the risk level of the security vulnerability, predict the virtual asset loss that the security vulnerability will cause to the business during the target time period, and obtain the loss value.

[0105] In practice, after determining the risk level of a security vulnerability, a first risk item associated with the vulnerability and a second risk item associated with the host are also obtained. Here, the first risk item includes at least the type of security vulnerability, the method of exploitation, the port exposed by the vulnerability, and the method of attack, while the second risk item includes at least the host's defense mechanism and host vulnerability data. After obtaining the first and second risk items, it is necessary to determine the first risk level value corresponding to the first risk item and the second risk level value corresponding to the second risk item. Then, based on the first and second risk level values, the virtual asset loss caused by the security vulnerability to the business during the target period is predicted, and the loss value is obtained.

[0106] The process of obtaining the first risk item associated with the security vulnerability and the second risk item associated with the host will be explained next.

[0107] The process of obtaining the first risk item associated with a security vulnerability specifically involves obtaining the vulnerability type, vulnerability exploitation method, vulnerability exposure port, and vulnerability attack method.

[0108] In practice, the process of obtaining the vulnerability type in the first risk item is the same as the process of determining the security impact category to which the security vulnerability belongs in step 201.

[0109] In practice, the process of obtaining the exploit methods for the first risk item involves determining the vulnerability type and then identifying the supported exploit methods. These exploit methods are categorized as remote or non-remote. It's important to note that non-remote exploitation involves directly exploiting the vulnerability on the host device, which is generally more difficult. Remote exploitation is typically divided into three types: direct exploitation, complex exploitation, and condition-specific exploitation. Direct exploitation is the simplest method, often requiring only one or two data packets to succeed. Complex exploitation increases in difficulty, often requiring multiple data packets. Condition-specific exploitation requires certain prerequisites, such as login or specific version / enabled features. Here, after identifying the different exploitation methods supported by the security vulnerability, it is determined whether the security vulnerability has already been exploited. If the security vulnerability has been exploited, the current exploitation method is obtained as the exploitation method of the security vulnerability; if the security vulnerability has not been exploited, the method with the lowest exploitation difficulty among the exploitation methods supported by the security vulnerability is determined, thereby determining the exploitation method of the security vulnerability.

[0110] In practice, the vulnerability exposure port here also refers to the exposure surface. The process of obtaining the vulnerability exposure port in the first risk item involves identifying the security vulnerabilities in the cloud platform and the hosts with these vulnerabilities, then determining whether the port or interface corresponding to the vulnerability is open. Here, the open port or interface corresponding to the security vulnerability is considered the vulnerability exposure port. It should be noted that this does not consider situations where external access is blocked due to firewalls or Access Control List (ACL) policies; the vulnerability exposure port is determined solely from the perspective of whether it is open.

[0111] In practice, the vulnerability attack methods here also have a wide spread. The process of obtaining vulnerability attack methods is as follows: after identifying the security vulnerabilities in the cloud platform and the hosts with security vulnerabilities, the communication methods between the hosts and the cloud platform or between the hosts are first obtained. This includes communication methods between interfaces, communication methods between ports, etc. Then, it is determined whether the obtained communication methods have vulnerabilities, that is, whether there is a possibility of directly controlling some functions of the cloud platform or controlling other cloud hosts. The communication methods with security vulnerabilities are the vulnerability attack methods.

[0112] The process of obtaining the second risk item associated with the host involves obtaining the host's defense mechanism and host vulnerability data respectively.

[0113] In practice, the host defense mechanism refers to the host's own defense. The process of obtaining the host defense mechanism involves checking whether the vulnerable host has security software installed or whether there are security detection devices such as traffic detection and firewalls deployed in front of the host, as well as checking whether relevant logging is enabled on the corresponding host, such as login logs and command audit logs.

[0114] In practical implementation, host vulnerability data refers to the security of directly affected hosts, that is, the overall security of hosts with security vulnerabilities. The process of obtaining host vulnerability data specifically involves acquiring data such as whether the host has been infected with viruses / Trojans within a preset time period, whether the host has been successfully intruded upon within a preset time period, and whether the host currently has other security vulnerabilities. It should be noted that the preset time period is a period set by the user according to their own needs, which can be one month, six months, or one year; this application embodiment does not impose such limitations.

[0115] In practice, after obtaining the first risk item and the second risk item, it is necessary to determine the first risk level value corresponding to the first risk item and the second risk level value corresponding to the second risk item. The process of determining the first risk level value corresponding to the first risk item and the second risk level value corresponding to the second risk item will be explained below.

[0116] First, the process of determining the first risk level value corresponding to the first risk item will be explained.

[0117] In practice, after obtaining the security vulnerability type, exploitation method, vulnerability exposure port, and vulnerability attack method in the first risk item, the security vulnerability type, exploitation method, vulnerability exposure port, and vulnerability attack method are normalized. That is, the security vulnerability type, exploitation method, vulnerability exposure port, and vulnerability attack method are normalized to the same dimension. Then, the normalization results are summed to obtain the first risk level value corresponding to the first risk item.

[0118] For the process of normalizing security vulnerability types, please refer to the content described in step 203 above.

[0119] The process of normalizing vulnerability exploitation methods involves first obtaining the risk level range corresponding to each exploitation method. Different exploitation methods have different risk level ranges, such as direct exploitation ∈ [3, 2], complex exploitation ∈ (2, 1], conditional exploitation ∈ (1, 0), and non-remote exploitation ∈ (1, 0). After obtaining the exploitation methods for the security vulnerabilities, the risk level range to which each exploitation method belongs is determined. Then, the normalized result of the exploitation method is determined from the corresponding risk level range. This determination can be done using a list or by directly taking the midpoint of the range. For example, when the normalized result of the exploitation method is determined from the risk level range using a list, the process is as follows: When the exploit method is complex exploitation, since the security impact categories of security vulnerabilities are different (such as component vulnerabilities, logic vulnerabilities, etc.), the normalized results corresponding to different security impact categories in the risk level range corresponding to complex exploitation are presented in a list. For example, for complex exploitation ∈ (2, 1], the list shows that the normalized result corresponding to logic vulnerabilities is 1, and the normalized result corresponding to component vulnerabilities is 1.5. Thus, the risk level value of security vulnerabilities can be queried through the list. When the normalized result of the exploit method is determined from the risk level range by directly taking the median value of the range, following the example above, for complex exploitation ∈ (2, 1], the normalized result for logic vulnerabilities, component vulnerabilities, etc. is 1.5. Here, the method for determining the normalized result of the exploit method from the corresponding risk level range is not limited in this embodiment.

[0120] The process of normalizing exposed ports for vulnerabilities involves identifying the open ports or interfaces corresponding to the security vulnerability, counting the number of these open ports or interfaces, and using the final count as the normalization result. For example, if there is one open port corresponding to a security vulnerability on the host, the normalization result is 1; if there are five open ports corresponding to a security vulnerability on the host, the normalization result is five.

[0121] The process of normalizing vulnerability attack methods involves, after identifying the communication methods containing security vulnerabilities (i.e., the attack methods), counting the number of such methods and using the final statistical result as the normalization result. For example, if there is one vulnerable communication method, the normalization result is 1; if there are five vulnerable communication methods, the normalization result is 5. It should be noted that if the vulnerable communication method is a proprietary protocol, the normalization result can be 0.5; if it is a proprietary and encrypted protocol, the normalization result can be 0.

[0122] Next, the process of determining the second risk level value corresponding to the second risk item will be explained.

[0123] In actual implementation, after obtaining the host defense mechanism and host vulnerability data in the second risk item, the host defense mechanism and host vulnerability data are normalized respectively, and then the normalized results are summed to obtain the second risk level value corresponding to the second risk item.

[0124] The process of normalizing the host defense mechanism involves two steps: detecting whether the vulnerable host has security software installed or whether there are security detection devices such as traffic detectors and firewalls deployed in front of it, and detecting whether relevant logging, such as login logs and command audit logs, is enabled on the corresponding host. Therefore, the normalization process is based on these two detection results. Specifically, if the detection results indicate that the host has neither security software nor security devices such as traffic detectors and firewalls in front of it, and no important logs are recorded, the host defense mechanism is normalized to the first value. If the detection results indicate that the host has security software and no security devices such as traffic detectors and firewalls in front of it, but no important logs are recorded, or if the detection results indicate that the host has neither security software nor security devices such as traffic detectors and firewalls in front of it, but important logs are recorded, the host defense mechanism is normalized to the second value. If the detection results indicate that the host has both security software and security devices such as traffic detectors and firewalls in front of it, and important logs are recorded, the host defense mechanism is normalized to the third value. Here, the first value is less than the second value, the second value is less than the third value, and the first value is negative, while the second and third values ​​are positive.

[0125] As an example, if the detection result indicates that the host has neither security software nor security devices such as traffic detection or firewalls in front of it, and no relevant important logs are recorded, then the host defense mechanism is normalized to -1; if the detection result indicates that the host has security software and no security devices such as traffic detection or firewalls in front of it, but no relevant important logs are recorded, or if the detection result indicates that the host has neither security software nor security devices such as traffic detection or firewalls in front of it, but relevant important logs are recorded, then the host defense mechanism is normalized to 1; if the detection result indicates that the host has both security software and security devices such as traffic detection or firewalls in front of it, and relevant important logs are recorded, then the host defense mechanism is normalized to 2.

[0126] It should be noted that if the security detection equipment already clearly possesses the capability to detect the security vulnerability, then the first, second, and third values ​​can be considered for upward adjustment. Continuing with the example above, when the detection results indicate that the host has both security software and no upstream security devices such as traffic monitoring or firewalls, and also records relevant important logs, then the host defense mechanism is normalized to 2. In this case, if the security detection equipment already clearly possesses the capability to detect the security vulnerability, then the normalized result of the host defense mechanism is increased to 3.

[0127] The process of normalizing host vulnerability data involves three steps: determining whether the host has been infected with a virus / Trojan within a preset time period, whether the host has been successfully compromised within a preset time period, and whether the host currently has other security vulnerabilities. Therefore, the normalization process also follows these three steps: first, determining whether the host has been infected with a virus / Trojan within a preset time period; second, determining whether the host has been successfully compromised within a preset time period; and third, determining whether the host currently has other security vulnerabilities. These three results are normalized to obtain three normalized results, which are then superimposed to obtain the final normalized host vulnerability data. Specifically, when the host has been infected with a virus / Trojan within a preset time period, the host vulnerability data is normalized to a fourth value; when the host has been infected with a virus / Trojan within a preset time period, the host vulnerability data is normalized to 0. When the host has been successfully intruded into within a preset time period, the host vulnerability data is normalized to a fifth value; when the host has not been successfully intruded into within a preset time period, the host vulnerability data is normalized to 0. When the host currently has other security vulnerabilities, the number of existing security vulnerabilities is counted, and this count is used as the normalized result of the host vulnerability data (e.g., 1 security vulnerability is normalized to 1, 5 security vulnerabilities are normalized to 5); when the host currently has no other security vulnerabilities, the host vulnerability data is normalized to 0. Then, the normalized result of the host vulnerability data is obtained by summing the three normalized results.

[0128] It should be noted that when counting existing security vulnerabilities, because low-risk vulnerabilities pose a lower risk, only vulnerabilities of medium, high, high, and critical risk are counted (vulnerability levels are generally categorized as low, medium, high, and critical). This reduces the number of vulnerabilities that need to be counted and improves the efficiency of counting security vulnerabilities. Also, the fourth and fifth values ​​here are positive.

[0129] In practice, after determining the first risk level value corresponding to the first risk item and the second risk level value corresponding to the second risk item, the loss of virtual assets caused by the security vulnerability to the business within the target time period is predicted based on the first and second risk level values, and the loss value is obtained. Here, the process of predicting the loss of virtual assets caused by the security vulnerability to the business within the target time period based on the first and second risk level values ​​and obtaining the loss value will be explained in step 103.

[0130] Step 102: Determine the services of the cloud platform supported by the host.

[0131] In practice, the process begins by acquiring all services within the cloud platform. Then, based on identified hosts with security vulnerabilities, the services supported by those vulnerable hosts are selected from the acquired services. For example, the services in the cloud platform may include at least websites and e-commerce platforms built on the cloud platform.

[0132] Step 103: Predict the virtual asset losses that the security vulnerability will cause to the business during the target time period and obtain the loss value.

[0133] In actual implementation, see Figure 5 , Figure 5 This is an optional flowchart illustrating the prediction of virtual asset losses caused by security vulnerabilities to business operations within a target time period, based on an embodiment of this application. Figure 3 Step 103 can also be performed in the following way:

[0134] Step 1031: Determine the total amount of virtual assets supported by the host during the target time period.

[0135] In practical implementation, before determining the total amount of virtual assets supported by the host within the target time period, it is first necessary to obtain the target time period. There are two ways to obtain the target time period. In some embodiments, the target time period can be obtained by obtaining the time point when the security vulnerability was discovered and the time required for the host with the security vulnerability to fix it. Then, based on the time point when the security vulnerability was discovered and the time required to fix it, the target time period is determined. For example, it refers to the time from when an official organization publicly discloses the security vulnerability online or through other channels to when the host with the vulnerability fixes it. In other embodiments, the target time period can be obtained by obtaining the time point when the security vulnerability occurs and the time point when the security vulnerability is discovered, i.e., the time point when the security vulnerability is reported. Then, based on the time point when the security vulnerability occurs and the time point when the security vulnerability is discovered, the target time period is determined. For example, since the security vulnerability reporting cycle is set differently for the host, it will not be reported immediately when a security vulnerability occurs. Therefore, based on the pre-set security vulnerability reporting cycle, the time when the security vulnerability is reported is determined, and then combined with the time when the security vulnerability occurs, the target time period can be determined.

[0136] It should be noted that, regarding the method of determining the target time period based on the time from the emergence of the security vulnerability to the expected time of its fix, if there is no official patch (i.e., the official organization has announced the fix time), the time during which security devices are capable of intercepting attacks against the corresponding vulnerability is calculated. In other words, the target time period is determined based on the time of the vulnerability's emergence and the time during which security devices are capable of intercepting attacks against the corresponding vulnerability.

[0137] In practice, after obtaining the target time period, the total amount of virtual assets of the services supported by the host with the security vulnerability within the target time period is determined. It should be noted that since a certain service is not based on a single host but on multiple hosts, after identifying the host with the security vulnerability, the services supported by that host are identified, and then the total amount of virtual assets of the services supported by the host with the security vulnerability within the target time period is determined, which is the total amount of virtual assets of the corresponding service within the target time period.

[0138] Step 1032: Determine the ratio of the number of hosts with security vulnerabilities to the total number of hosts supporting the service.

[0139] In practice, before determining the ratio of the number of hosts with security vulnerabilities to the total number of hosts supporting the service, it is first necessary to obtain the number of hosts with security vulnerabilities and the total number of hosts supporting the service. After obtaining the number of hosts with security vulnerabilities and the total number of hosts supporting the service, the ratio of the number of hosts with security vulnerabilities to the total number of hosts supporting the service is determined by dividing the number of hosts with security vulnerabilities by the total number of hosts supporting the service.

[0140] Step 1033: Based on the total amount and ratio of virtual assets, predict the virtual asset losses caused by security vulnerabilities to the business during the target period and obtain the loss value.

[0141] In actual implementation, before predicting the virtual asset loss caused by the security vulnerability to the business during the target period based on the total amount of virtual assets and the ratio, it is first necessary to determine the business virtual asset assessment of the business supported by the host with the security vulnerability based on the total amount of virtual assets and the ratio. Specifically, the total amount of virtual assets and the ratio are first multiplied to obtain the amount of virtual assets of the host with the security vulnerability during the target period. Based on the ratio of the amount of virtual assets of the host with the security vulnerability during the target period to the target period, the business virtual asset assessment of the business supported by the host with the security vulnerability is determined.

[0142] As an example, the total virtual assets here are 1 million, the total number of hosts supporting the corresponding business is 10, and the number of hosts with security vulnerabilities is 2. The ratio here is 0.2. The amount of virtual assets of the hosts with security vulnerabilities in the target period is 100 * 0.2, which is 200,000. Assuming the target period is 4 days, the business virtual assets of the business supported by the hosts with security vulnerabilities are estimated to be 20 / 4, which is 50,000 / day.

[0143] It should be noted that after determining the target time period, it will be converted into a time period in days or years to facilitate subsequent calculations.

[0144] In practice, after assessing the virtual assets of the services supported by the host with the security vulnerability, the potential loss of virtual assets due to the vulnerability during the target time period can be predicted, thus obtaining the loss value. There are two ways to predict the potential loss of virtual assets due to the vulnerability during the target time period: one is to consider only the loss caused by the vulnerability, and the other is to consider both the loss caused by the vulnerability and the loss caused by the host's own security performance.

[0145] Next, we will explain two methods for predicting the virtual asset losses caused by security vulnerabilities to the business within a target time period and obtaining the loss value.

[0146] In some embodiments, when only considering the virtual asset loss caused by security vulnerabilities to the business, the process of predicting the virtual asset loss caused by security vulnerabilities to the business within a target time period and obtaining the loss value specifically involves obtaining the first risk level value corresponding to the first risk item, and multiplying the first risk level value with the business virtual asset assessment of the business supported by the host with the security vulnerability. Specifically, since the first risk level value is the sum of the normalized results obtained by normalizing the security vulnerability type, vulnerability exploitation method, vulnerability exposure port, and vulnerability attack method in the first risk item, multiplying the first risk level value with the business virtual asset assessment of the business supported by the host with the security vulnerability is equivalent to multiplying the normalized results obtained by normalizing the security vulnerability type, vulnerability exploitation method, vulnerability exposure port, and vulnerability attack method in the first risk item with the business virtual asset assessment of the business supported by the host with the security vulnerability. See [link to documentation]. Figure 6A , Figure 6A This is an optional schematic diagram provided by the embodiments of this application for predicting the virtual asset loss caused to the business by a security vulnerability within a target time period. After performing the product processing, the result of the product processing is the predicted virtual asset loss caused to the business by the security vulnerability within the target time period, i.e., the loss value.

[0147] It should be noted that in the process of predicting the virtual asset losses caused by security vulnerabilities to the business during the target period, multiple weights of the normalized values ​​corresponding to the security vulnerability type, vulnerability exploitation method, vulnerability exposure port, and vulnerability attack method can also be obtained. These weights are set by the user in advance according to their own needs. After obtaining the corresponding weights, the corresponding virtual asset losses are calculated based on the weights to obtain the virtual asset losses caused by security vulnerabilities to the business during the target period.

[0148] In some embodiments, when considering both the virtual asset loss caused by security vulnerabilities to the business and the virtual asset loss caused by the host's own security performance, the process of predicting the virtual asset loss caused by security vulnerabilities to the business within a target time period and obtaining the loss value specifically involves: obtaining the first risk level value corresponding to the first risk item and the second risk level value corresponding to the second risk item; multiplying the difference between the first risk level value and the second risk level value by the business virtual asset assessment of the business supported by the host with the security vulnerability; or, multiplying the first risk level value and the second risk level value by the business virtual asset assessment of the host with the security vulnerability, respectively, and then taking the difference of the results to obtain the virtual asset loss caused by security vulnerabilities to the business within the target time period. Here, since the first risk level value is a measure of the type of security vulnerability in the first risk item, The first risk level is the sum of the normalized results obtained by normalizing the vulnerability exploitation method, vulnerability exposure port, and vulnerability attack method. The second risk level is the sum of the normalized results obtained by normalizing the host defense mechanism and host vulnerability data in the second risk item. Therefore, whether the difference between the first and second risk level values ​​is multiplied by the business virtual asset assessment of the host with the security vulnerability, or whether the first and second risk level values ​​are first multiplied by the business virtual asset assessment of the host with the security vulnerability and then the difference is taken, it can be regarded as multiplying the difference between the normalized results obtained by normalizing the vulnerability type, vulnerability exploitation method, vulnerability exposure port, and vulnerability attack method in the first risk item and the normalized results obtained by normalizing the host defense mechanism and host vulnerability data in the second risk item, and the business virtual asset assessment of the business supported by the host with the security vulnerability. See [link to relevant documentation]. Figure 6B , Figure 6B This is an optional schematic diagram provided by the embodiments of this application for predicting the virtual asset loss caused to the business by a security vulnerability within a target time period. After performing the product processing, the result of the product processing is the predicted virtual asset loss caused to the business by the security vulnerability within the target time period, i.e., the loss value.

[0149] It should be noted that in the process of predicting the virtual asset losses caused by security vulnerabilities to the business during the target period, multiple weights can be obtained, including the type of security vulnerability, the method of exploitation, the port exposed by the vulnerability, the attack method of the vulnerability, the host defense mechanism, and the normalized value corresponding to the host vulnerability data. These weights are set by the user in advance according to their own needs. After obtaining the corresponding weights, the corresponding virtual asset losses are calculated based on the weights to obtain the virtual asset losses caused by security vulnerabilities to the business during the target period.

[0150] In some embodiments, the security vulnerabilities obtained in step 101 include a first vulnerability existing on the cloud platform side and a second vulnerability existing on the cloud platform user side. It should be noted that when the obtained security vulnerabilities include both the first vulnerability on the cloud platform side and the second vulnerability on the cloud platform user side, the obtained vulnerability data affecting cloud platform security includes cloud platform host device data, cloud platform host network data, service data of services deployed on the cloud platform host, and cloud platform user-side host device data, cloud platform user-side host network data, and service data of services deployed on the cloud platform user-side host. See [link to relevant documentation]. Figure 7 , Figure 7 This is an optional flowchart illustrating the prediction of virtual asset losses caused by security vulnerabilities to business operations within a target time period, based on an embodiment of this application. Figure 3 Step 103 can also be performed in the following way:

[0151] Step 301: Predict the first loss that the first vulnerability will cause to the business within the target time period.

[0152] In actual implementation, the process of predicting the first loss to the business caused by the first vulnerability within the target time period is the process in steps 1031 to 1033 of predicting the virtual asset loss to the business caused by the security vulnerability within the target time period based on the first risk level value and the second risk level value, and obtaining the loss value.

[0153] Step 302: Predict the second loss that the second vulnerability will cause to the business during the target time period.

[0154] In actual implementation, predicting the second loss caused to the business by the second vulnerability within the target time period specifically involves first obtaining the loss influencing factors associated with the second vulnerability. These factors include at least one of the following: the vulnerability exploitation method, the user-side defense mechanism, and the user-side business type. After obtaining the loss influencing factors associated with the second vulnerability, the second loss caused to the business by the second vulnerability within the target time period is determined based on these factors.

[0155] Next, the process of obtaining the loss-influencing factors associated with the second vulnerability, namely the vulnerability exploitation method, user-side defense mechanism, and user-side business type, will be explained.

[0156] In practice, the process of obtaining the exploitation method of the second vulnerability is the same as the process of obtaining the exploitation method of the first risk item in step 101.

[0157] In practice, the user-side defense mechanism refers to the user's own defense. The process of obtaining the user-side defense mechanism involves detecting whether the user has purchased security products / services provided by the cloud platform and whether the user has built their own defense system.

[0158] It's important to note that cloud platforms typically recommend their security products / services to users who purchase them. These products / services generally offer better security because they are regularly monitored and maintained by dedicated personnel. However, for user-built defense systems, users with even a basic level of security awareness may use open-source or self-developed tools to check for security issues with their purchased services or products. But due to a lack of timely follow-up and limitations of the tools themselves, the security effectiveness can be less than ideal.

[0159] In practice, obtaining the user-side service type means determining which service type the user is using the host or service for. There are two main types of service types: single service type and mixed service type. A single service type means all purchased services or hosts are used for the same service. A mixed service type typically involves a user purchasing multiple hosts or services and then allocating them to different departments based on actual needs to meet normal business requirements. In this case, the service type corresponding to the host with the second vulnerability is selected.

[0160] In actual implementation, after obtaining the exploitation method, user-side defense mechanism, and user-side business type of the second vulnerability, the process of determining the second loss caused to the business by the second vulnerability within the target time period based on the obtained exploitation method, user-side defense mechanism, and user-side business type of the second vulnerability is as follows: the obtained exploitation method, user-side defense mechanism, and user-side business type of the second vulnerability are normalized respectively to obtain multiple normalization results, and then the second loss caused to the business by the second vulnerability within the target time period is determined based on the multiple normalization results.

[0161] Next, we will explain the process of normalizing the exploitation method, user-side defense mechanism, and user-side business type of the second vulnerability.

[0162] In actual implementation, the process of normalizing the exploitation method of the second vulnerability obtained is specifically the same as the process of normalizing the exploitation method of the first risk item in step 101.

[0163] In practice, the normalization process for the acquired user-side defense mechanism is as follows: After detecting whether the user has purchased security products / services provided by the cloud platform and whether the user has built their own defense system, the user-side defense mechanism is normalized to 0 if the user has purchased security products / services provided by the cloud platform, built their own defense system, and implemented security defenses based on the defense system (such as timely patching of vulnerabilities and regular security inspections). If the user has purchased security products / services provided by the cloud platform, built their own defense system, but has not implemented security defenses based on the defense system (such as not timely patching of vulnerabilities and not regular security inspections), the user-side defense mechanism is normalized to the sixth value. If the user has not purchased security products / services provided by the cloud platform but has built their own defense system, the user-side defense mechanism is normalized to the seventh value. If the user has not purchased security products / services provided by the cloud platform and has not built their own defense system, the user-side defense mechanism is normalized to the eighth value. Here, the sixth, seventh, and eighth values ​​are all positive, and the sixth value is less than the seventh value, and the seventh value is less than the eighth value.

[0164] As an example, when a user purchases security products / services provided by a cloud platform and builds their own defense system, but fails to implement security measures based on that system (e.g., fails to patch vulnerabilities in a timely manner or conduct regular security inspections), the user-side defense mechanism is normalized to level 1. When a user does not purchase security products / services provided by a cloud platform and builds their own defense system, the user-side defense mechanism is normalized to level 2. When a user does not purchase security products / services provided by a cloud platform and does not build their own defense system, the user-side defense mechanism is normalized to level 3.

[0165] In practice, the process of normalizing the acquired user-side business types is necessary because different types of businesses have different levels of security sensitivity. For example, banking and financial businesses clearly place greater emphasis on security. Therefore, after determining the user-side business types, the user-side business types are normalized according to the different levels of security emphasis of each business type. Specifically, after establishing the user-side business types, there are two processes for normalizing the acquired user-side business types based on the differences in business types.

[0166] In some embodiments, when the user-side service type is a single service type, the user-side service type is normalized according to the degree of importance attached to security by the user-side service type. Specifically, a pre-set security requirement ranking of service types is obtained, and the service types are normalized based on the security requirement ranking. The normalized value obtained is the normalized value of the user-side service type. Here, the level of security requirement of the service type is directly proportional to the normalized value of the user-side service type, that is, the higher the security requirement of the service type, the higher its corresponding normalized value.

[0167] As an example, if the security requirements of the obtained business types are ranked from highest to lowest as finance, enterprise, school, and hospital, then if the determined user-side business type is finance, the normalized value of the user-side business type is 4; if the determined user-side business type is enterprise, the normalized value of the user-side business type is 3; if the determined user-side business type is school, the normalized value of the user-side business type is 2; and if the determined user-side business type is hospital, the normalized value of the user-side business type is 1.

[0168] In other embodiments, when the user-side service type is a mixed service type, the user-side service type is normalized according to the degree of importance attached to security by the user-side service type. Specifically, a pre-set security requirement ranking of service types is obtained, and the user-side service type is normalized based on the security requirement ranking. The normalized value obtained by normalizing the service type is the normalized value of the user-side service type. Here, the level of security requirement of the service type is directly proportional to the normalized value of the user-side service type, that is, the higher the security requirement of the service type, the higher its corresponding normalized value.

[0169] It should be noted that when the host with the second vulnerability supports only one type of service, the service type is normalized, and the normalized value is the normalized value of the user-side service type. When the host with the second vulnerability supports multiple types of service, each type of service is normalized to obtain the corresponding normalized value. Then, the multiple normalized values ​​are summed to obtain the normalized value of the user-side service type.

[0170] Following the example above, the security requirements of the obtained business types are ranked from highest to lowest as follows: finance, enterprise, school, and hospital. The normalized value for the finance business type is 4, the normalized value for the enterprise business type is 3, the normalized value for the school business type is 2, and the normalized value for the hospital business type is 1. When the host with the second vulnerability only supports one business type, namely financial business, the normalized value of the user-side business type is 4. When the host with the second vulnerability supports multiple business types, namely financial business and hospital business, the normalized value of the user-side business type is the sum of 4 and 1, which is 5.

[0171] It should be noted that the pre-set business type security requirement ranking is based on the ranking result of the security requirements of all businesses supported by the cloud platform's hosts.

[0172] In actual implementation, after obtaining multiple normalization results, the process of determining the second loss caused to the business by the second vulnerability within the target time period based on the multiple normalization results is as follows: obtain the user-side business scale and user-side business virtual asset assessment, and determine the second loss caused to the business by the second vulnerability within the target time period based on the multiple normalization results, user-side business scale and user-side business virtual asset assessment.

[0173] Next, we will explain the process of obtaining the scale of user-side business and evaluating the virtual assets of user-side business.

[0174] In practice, the user-side business scale refers to the daily access volume or call volume of the corresponding business. For example, if a website is deployed on a cloud host with the second vulnerability, and that website receives 5000 visits per day, then the user-side business scale is 5000. If multiple businesses exist, the sum of the daily access volume or call volume of each business constitutes the user-side business scale. Continuing the example above, if two websites are deployed on the cloud host with the second vulnerability, and each website receives 5000 visits per day, then the user-side business scale is 10000.

[0175] It should be noted that after obtaining the user-side business scale, it can be converted into "thousands / day", "ten thousand / day", or "hundred thousand / day". Continuing with the example above, converting the user-side business scale to "ten thousand / day" means that 10,000 is equivalent to 5,000 / day after conversion.

[0176] It should be noted that the scale of user-side business can also be measured in months, years, etc. When the scale of user-side business can also be measured in months, the scale of user-side business refers to the monthly access volume or call volume of the corresponding business.

[0177] In practice, the process of acquiring virtual assets for user-side business involves two stages: one when the corresponding business generates revenue, and another when the corresponding business does not generate revenue. These two stages will be explained separately below.

[0178] In some embodiments, when the corresponding business generates revenue, the process of obtaining the evaluation of the virtual assets of the user-side business refers to the process of evaluating the virtual assets of the business supported by the host with the security vulnerability determined in steps 1031 to 1033.

[0179] In some embodiments, when the corresponding business does not generate revenue, the process of obtaining the assessment of virtual assets of the user-side business is specifically as follows: obtaining the total cost incurred by the user in purchasing the host with the second vulnerability, and then obtaining the second target period, which is the time range affected by the second vulnerability; after obtaining the total cost and the second target period, determining the virtual asset loss in the second target period based on the total cost and the second target period, and then determining the assessment of virtual assets of the user-side business based on the virtual asset loss in the second target period.

[0180] It should be noted that the process of obtaining the second target time period here refers to the process of obtaining the target time period in step 1031. Based on the virtual asset loss in the second target time period, the process of determining the virtual asset assessment of the user-side business involves converting the virtual asset loss in the second target time period into a value corresponding to the business scale, thereby obtaining the virtual asset assessment of the user-side business. For example, if the business scale is measured in days, the purchase cost of the host (i.e., the total cost) is 120,000 yuan / year, and the second target time period is one month, then the virtual asset loss in the second target time period is 10,000 yuan. Then, 10,000 yuan is converted into a unit of days, i.e., 3,333 yuan / day. Thus, the virtual asset assessment of the user-side business is 3,333 yuan / day.

[0181] It should be noted that when a host with a second vulnerability supports multiple services, some of which generate revenue and others generate revenue, the process is as follows: when a corresponding service generates revenue, the user-side service virtual asset assessment process is obtained to acquire the first user-side service virtual asset assessment for the service that generates revenue; simultaneously, when a corresponding service does not generate revenue, the user-side service virtual asset assessment process is obtained to acquire the second user-side service virtual asset assessment for the service that does not generate revenue. The sum of the first and second user-side service virtual asset assessments is used as the user-side service virtual asset assessment.

[0182] In actual implementation, see Figure 8A , Figure 8AThis is an optional schematic diagram provided in the embodiments of this application for obtaining the second loss caused to the business by the second vulnerability within the target time period. After obtaining the user-side business scale and the user-side business virtual asset assessment, the process of determining the second loss caused to the business by the second vulnerability within the target time period based on multiple normalization processing results, the user-side business scale, and the user-side business virtual asset assessment is as follows: subtract the normalization value of the exploitation method of the second vulnerability from the normalization value of the user-side defense mechanism, add the normalization value of the user-side business type, and then multiply it with the user-side business scale and the user-side business virtual asset assessment respectively to obtain the second loss caused to the business by the second vulnerability within the target time period.

[0183] In some embodiments, while obtaining the exploitation method, user-side defense mechanism, and user-side business type of the second vulnerability, the importance of the customer on the user side can also be obtained. Then, the customer importance is normalized to obtain a normalized value, i.e., the normalized value of the customer importance. After obtaining the normalized value of the customer importance, see [link to relevant documentation]. Figure 8B , Figure 8B This is an optional schematic diagram provided by the embodiments of this application for obtaining the second loss caused to the business by the second vulnerability within the target time period. The normalized value of the exploitation method of the second vulnerability is subtracted from the normalized value of the user-side defense mechanism, and then the normalized value of the user-side business type and the normalized value of the customer importance are added. Then, the product is performed with the user-side business scale and the user-side business virtual asset assessment respectively to obtain the second loss caused to the business by the second vulnerability within the target time period.

[0184] It should be noted that in obtaining the second loss caused to the business by the second vulnerability within the target time period, multiple weights can also be obtained, including the exploitation method of the second vulnerability, the user-side defense mechanism, the user-side business type, the user-side business scale, the user-side business virtual asset assessment, and the normalized value of the customer's importance. These weights are set by the user in advance according to their own needs. After obtaining the corresponding weights, the corresponding virtual asset loss is calculated based on the weights to obtain the second loss caused to the business by the second vulnerability within the target time period.

[0185] It's important to clarify that "customer" refers not to the cloud tenant, but rather to the customers of the cloud tenant's business. Here, cloud tenants use cloud servers and services in two ways: one is exclusively for internal use, and the other is to provide them to customers after development. If it's only for internal use, the impact of customer importance can be disregarded; however, if it's for customer use, it's necessary to obtain the customer importance from the user's perspective and then normalize the customer importance based on this information.

[0186] In practice, the process of normalizing customer importance based on the acquired customer importance level is as follows: First, the customer importance level is obtained, and the customer importance level is determined. Then, based on the customer importance level, a normalized value corresponding to the customer importance level is determined. Here, the customer importance level is high, medium, and low. The normalized value corresponding to high is greater than that corresponding to medium, and the normalized value corresponding to medium is greater than that corresponding to low. All normalized values ​​corresponding to customer importance are positive. For example, the normalized value corresponding to a high customer importance level is 3, the normalized value corresponding to a medium customer importance level is 2, and the normalized value corresponding to a low customer importance level is 1. When the customer importance level is determined to be medium, the normalized value of the customer importance level is 2.

[0187] Step 303: Sum the first loss and the second loss to obtain the loss value corresponding to the loss of virtual assets caused to the business by the security vulnerability during the target time period.

[0188] In some embodiments, after obtaining the first loss and the second loss, the first loss and the second loss can be directly summed to predict the virtual asset loss caused by the security vulnerability to the business within the target time period and obtain the loss value.

[0189] In other embodiments, after obtaining the first loss and the second loss, the weights of the first loss and the second loss can be preset according to their own needs, and then the first loss and the second loss can be weighted and summed to predict the virtual asset loss caused by the security vulnerability to the business during the target period and obtain the loss value.

[0190] It should be noted that when calculating the total vulnerability loss caused by a security vulnerability, there are three calculation methods depending on the location of the vulnerability. See here for details. Figure 9A , Figure 9B as well as Figure 9C , Figure 9A , Figure 9B as well as Figure 9C These are optional schematic diagrams illustrating the total vulnerability loss provided in the embodiments of this application, based on... Figure 9A Some security vulnerabilities exist both on the cloud platform side and on the cloud platform user side. Therefore, it is necessary to calculate the losses on the cloud platform side and the cloud platform user side separately to determine the total vulnerability loss; based on Figure 9B Some security vulnerabilities exist only on the cloud platform side, not on the cloud platform user side, therefore only the cloud platform side needs to be calculated; while based on Figure 9CSome security vulnerabilities exist only on the cloud platform user side, and not on the cloud platform user side. Therefore, only the cloud platform user side needs to be calculated. For example, if a vulnerability exists on a certain component, and the cloud platform uses a certain component for development, but no one uses the component on the cloud platform user side, then only the cloud platform side needs to be calculated.

[0191] Step 104: Based on the loss value, generate vulnerability alert information to indicate the existence of security vulnerabilities in the cloud platform.

[0192] Among them, vulnerability alerts include the loss of virtual assets caused to business operations due to security vulnerabilities.

[0193] In practice, the first step is to obtain a vulnerability alert information template. Then, based on the loss value and the information template, a vulnerability alert is generated to indicate the existence of the security vulnerability in the cloud platform. It should be noted that the alert template must include at least the following information: the security vulnerability name, whether it will affect the cloud platform / cloud platform tenant, the host / system / business affected by the security vulnerability, the access volume / usage of the corresponding host / system / business, the vulnerability exploitation method, and the potential loss amount. Users can also modify the template to display the information. The generated vulnerability alert not only includes the virtual asset loss caused to the business by the security vulnerability, but also includes the specific details in the actual calculations, such as the security vulnerability type, vulnerability exploitation method, vulnerability exposure port, vulnerability attack method, host defense mechanism, host vulnerability data, the exploitation method of the second vulnerability, user-side defense mechanism, user-side business type, and customer importance, as detailed in steps 101 to 103.

[0194] Step 105: Output the vulnerability alert information corresponding to the security vulnerability.

[0195] In practice, the process begins by identifying the hosts with the security vulnerabilities and determining the corresponding management terminal. Then, the notification method for the vulnerability alert information is determined, and this method is used to send the vulnerability alert information to the management terminal, allowing the management terminal to output the vulnerability alert information. It should be noted that the notification method can be email, pop-up window, SMS, or other forms.

[0196] By applying the above embodiments of this application, when assessing and alerting vulnerabilities in a cloud platform, it is possible to predict the virtual asset losses that security vulnerabilities will cause to the business during a target period, and generate and output vulnerability alert information that includes the virtual asset losses caused by security vulnerabilities to the business. In this way, since the output vulnerability alert information includes the virtual asset losses caused by security vulnerabilities to the business, users or relevant responsible persons can more intuitively understand the impact and severity of security vulnerabilities on the business, thereby promoting users to repair security vulnerabilities more efficiently.

[0197] The following will describe an exemplary application of the embodiments of this application in a real-world application scenario.

[0198] Existing technical solutions primarily assess vulnerabilities through various methods, but the results are often only easily understood by professionals (e.g., vulnerability severity scoring), making it difficult for business departments or other personnel to intuitively grasp the harm caused by the vulnerability. Furthermore, existing technical solutions mainly consider vulnerabilities in the cloud platform itself, neglecting tenant-related vulnerabilities and vulnerabilities that can affect the cloud platform from the tenant's perspective. Therefore, this application provides a cloud platform-based vulnerability alert method. By combining relevant data such as business type, the amount involved in the business, and the scope of the business, it calculates the potential loss amount, thus making the harm of the vulnerability more intuitive for the public. In addition, it considers not only tenant-side vulnerabilities but also the relationships between tenants and the cloud platform, resulting in a more comprehensive analysis.

[0199] See Figure 10 , Figure 10 This is an optional flowchart illustrating a cloud-based vulnerability alerting method provided in an embodiment of this application. Figure 10 The embodiments described above in this application first read data, then program the read data, calculate the loss on the cloud platform side, then calculate the loss on the cloud platform user side, and finally combine the two loss results obtained from the statistical calculation to obtain the final loss result. Finally, alarm information is generated based on the final calculation result and then output. Thus, when analyzing the impact of vulnerabilities on the cloud platform, the embodiments described above in this application consider both the cloud platform itself and the cloud platform users, fully analyzing the potential losses from different perspectives such as network characteristics and business characteristics. This multi-dimensional examination of the harm caused by vulnerabilities to the cloud platform side greatly increases readability and, by incorporating business / operational data, makes the analysis results closer to the actual situation.

[0200] The data reading process in the above embodiments of this application specifically involves reading the data required for the following steps from a database or other interface, including: cloud platform-side host vulnerability data, cloud platform-side host network data, and cloud platform-side host deployment service data. If the customer obtains cloud platform user-side data (customer authorization or customer purchase of services provided by the cloud platform), then customer-side cloud host vulnerability data and cloud host network data are obtained.

[0201] The process of organizing the read data in the above embodiments of this application specifically involves summarizing the read data from the host / business system or other perspectives (such as vulnerability data) onto a single entity to facilitate further analysis or provide it to users for reading and analysis. For example, vulnerability information and network location information related to host A can be summarized together.

[0202] For the process of calculating the cloud platform-side loss in the above embodiments of this application, please refer to [link to relevant documentation]. Figure 11 , Figure 11 This is an optional schematic diagram illustrating the cloud platform-side loss calculation process provided in this application embodiment. Specifically, based on the read vulnerability data, the vulnerability type, remote exploitation difficulty, exposure surface, self-defense, diffusion surface, security of directly affected hosts, and corresponding business virtual asset assessment of the cloud platform are obtained. Then, the obtained data is used to... Figure 11 The formulas in the table are used to calculate the losses of the cloud platform. It should be noted that all data obtained here (i.e., the items to be calculated) must be normalized to the same dimension, such as [0, 10]. Next, the process of normalizing the vulnerability types, remote exploitation difficulty, exposure surface, self-defense, diffusion surface, security of directly affected hosts, and corresponding business virtual assets obtained from the cloud platform will be explained.

[0203] Vulnerability types refer to the classification of a vulnerability, ordered from most severe to least severe. Common vulnerability types include Web vulnerabilities, binary vulnerabilities, logic vulnerabilities, and component vulnerabilities. Vulnerability severity is calculated based on the potential impact of the vulnerability; for example, remote code execution vulnerabilities are often more severe than cross-site request vulnerabilities. In practice, if the classification of vulnerability types is unclear, the description of the vulnerability in CVE or CNVD can be used for classification. Furthermore, the ranking of certain vulnerability types can be intentionally increased or decreased based on the characteristics of the actual business. For example, if a platform heavily uses third-party components, the ranking of component vulnerabilities can be increased. The normalization process for vulnerability types involves mapping them to a specific dimension after sorting. For example, if the vulnerability types are sorted as "component vulnerabilities, Web vulnerabilities, logic vulnerabilities," they can be mapped to the following dimensions: "component vulnerabilities -> [10, 7], Web vulnerabilities -> (7, 4], logic vulnerabilities -> (4, 0)". (Component vulnerabilities are a broad category with many subcategories, hence the use of intervals.)

[0204] Remote exploitation difficulty refers to the difficulty of exploiting a vulnerability remotely. Generally, remote exploitation methods are divided into three types: direct exploitation (the simplest method, often requiring only one or two data packets to succeed), complex exploitation (increasingly difficult, often requiring multiple data packets to succeed), and conditional exploitation (requiring certain prerequisites, such as login or specific version / feature activation). The normalization process for remote exploitation difficulty involves mapping the exploitation method to specific units, such as "direct exploitation -> [3, 2], complex exploitation -> (2, 1], conditional exploitation -> (1, 0)".

[0205] The exposure surface refers to whether the port or interface corresponding to the vulnerability is open. The normalization process for the exposure surface does not consider situations where external access is blocked due to firewalls or ACL policies; it only calculates based on whether the interface is open. If multiple exposure surfaces exist on a machine, the total number of exposure surfaces is calculated. For example, if only one port corresponding to a vulnerability is open on the host, it is mapped to 1. If five ports are open, they are mapped to 5.

[0206] For self-defense, this refers to whether the vulnerable host has security software installed or whether there are security detection devices such as traffic inspectors and firewalls deployed in front of it. It also involves checking whether relevant logging is enabled on the host, such as login logs and command audit logs. Regarding the normalization process of self-defense, if the host has neither security software nor security devices such as traffic inspectors or firewalls in front of it, and no important logs are recorded on the host, then the mapping dimension is set to "-1". If either security software or other security detection devices are present, then the mapping dimension is set to "1"; if both are present, then the mapping dimension is set to "2"; furthermore, if the security detection devices clearly have the capability to detect the vulnerability, then the dimension value can be further increased to "3".

[0207] The diffusion surface refers to the exploitable attack surface within the cloud platform. This exploitable attack surface must consider all currently used communication methods with the platform or other cloud hosts (services), including communication methods between interfaces and ports. The normalization process for the diffusion surface involves mapping an attackable method to 1 if one exists; if multiple methods exist, the scale of all communication methods is summed. Note that if the communication method with the platform or other cloud hosts uses a proprietary protocol, the scale can be mapped to 0.5; if the protocol is proprietary and encrypted, the scale can be mapped to 0.

[0208] Regarding the security of directly affected hosts, this item refers to the overall security of hosts with the vulnerability, including: whether the host has been infected with a virus / Trojan in the past three months; whether the host has been successfully compromised in the past three months; and whether the host currently has other security vulnerabilities. The normalization process for this item is to set the corresponding unit to "1" if the answer to the first two items is yes, and to "0" if otherwise. The third item counts the number of existing security vulnerabilities, only requiring those at medium-high risk or above (vulnerability levels are generally categorized as low, medium, high, and critical). Similarly, the unit is set to "1" for each medium-high risk or above vulnerability, and the final count is the total number.

[0209] For business virtual asset assessment, this refers to the amount of virtual assets corresponding to the vulnerable hosts within the business during the period from when the vulnerability is disclosed to when it is patched. Specifically: the time frame refers to the time from when a research institution or authoritative organization publicly discloses the vulnerability online (or through other channels) to when the vulnerable hosts patch the vulnerability. If there is no official patch yet, the time it takes for security devices to intercept attacks exploiting the corresponding vulnerability is calculated. This is then converted to a time unit in days. The virtual asset quantity here is calculated as the proportion of the vulnerable hosts within the overall business. For example, if the virtual assets of the corresponding business within this time frame are 1 million, and the number of hosts (servers) supporting this business is 10, with 2 hosts vulnerable, then the virtual asset quantity should be 1 million * 0.2 = 200,000. Normalizing the business virtual asset assessment involves converting the time frame and virtual asset quantity into "amount / day". For example, assuming the above time frame is 4 days and the corresponding virtual asset quantity is 200,000, then the converted value is "50,000 / day".

[0210] The process of calculating the loss on the cloud platform user side in the above embodiments of this application is described in [reference needed]. Figure 12 , Figure 12 This is an optional schematic diagram illustrating the calculation process of cloud platform user-side losses provided in this application embodiment. Specifically, based on the read vulnerability data, the remote exploitation difficulty, self-defense, business type, customer importance, business scale, and corresponding business virtual asset assessment of the cloud platform user side are obtained. Then, the obtained data is used to... Figure 12 The formulas in the table are used to calculate the cloud platform's losses. It should be noted that all data obtained here (i.e., the items to be calculated) must be normalized to the same dimension, such as [0, 10]. Next, the process of normalizing the cloud platform's remote exploitation difficulty, its own defenses, business type, customer importance, business scale, and corresponding virtual assets assessment on the user side will be explained.

[0211] The process of determining the difficulty of remote exploitation is the same as obtaining the difficulty of remote exploitation from the cloud platform and normalizing it.

[0212] Regarding self-defense, this differs from the concept of cloud platform-side defense. Self-defense here mainly falls into two categories: one is purchasing security products / services provided by the cloud platform. Cloud platforms typically recommend these to users who purchase cloud products / services. Because these products / services have dedicated personnel for timely follow-up, they offer better security. The other is building a self-built defense system. Users with some security awareness usually use open-source or self-developed tools to investigate security issues with purchased services or products. However, due to a lack of timely follow-up and limitations of the tools themselves, the security effect is often less than ideal. The normalization process for cloud platform user-side self-defense is mapped from the following four perspectives: purchasing cloud platform security products / services, timely patching vulnerabilities, and conducting regular security inspections. This can be mapped to "0"; purchasing cloud platform security products / services but not addressing them promptly. This can be mapped to "1"; using open-source or self-built security systems. This can be mapped to "2"; neither purchasing cloud platform-side security products / services nor using open-source or self-built systems. This can be mapped to "3".

[0213] Regarding the business type, this item is used to determine which business type the user is using the host or service for. Different types of businesses have varying levels of security sensitivity; for example, banking and financial businesses place significantly higher emphasis on security. There are two main forms of business type: Single business type, where all purchased services / hosts are used for the same business; and Mixed business type, where users typically purchase multiple hosts or services and distribute them to different departments as needed to meet normal business requirements. In this case, the business type corresponding to the vulnerable host is selected. For the business type normalization process, after determining the form of the business type, the security requirements are sorted from highest to lowest, and a corresponding dimensional value is mapped from this sorting. For example, if the business type is determined to be the financial industry, and the security requirements are sorted as "finance > general enterprise > school, hospital," then the financial industry is ranked first, and therefore the corresponding dimensional value is "3".

[0214] Regarding customer importance, this item is optional. Here, "customer" refers not to the cloud tenant, but to the cloud tenant's customers. Cloud tenants use cloud servers and services in two ways: one is for internal use only, and the other is to develop services on top of them and then provide them to customers. If it's for internal use only, this item can be omitted. However, if it's for customer use and customer importance needs to be calculated, then it needs to be mapped according to the importance of the corresponding customer using the scale of "high -> 3, medium -> 2, low -> 1".

[0215] Regarding business scale, this refers to the daily number of visits or calls to the business. The normalization process for business scale involves calculating the daily number of visits or calls to obtain a specific value, and then unifying it to the unit "ten thousand / day". For example, if a website is deployed on a cloud server and the website has 5,000 visits per day, then after conversion, it would be "5,000 / day". Similarly, only the business involving the machines with vulnerabilities is calculated.

[0216] For the assessment of virtual assets related to business operations, there are two types: one is the assessment when the corresponding business generates revenue, and the other is the assessment when the corresponding business does not generate revenue. The normalization process for this assessment is the same as that for the cloud platform-side assessment, calculating the proportion of vulnerable hosts within the overall business. For the assessment when the corresponding business does not generate revenue, the cost of purchasing the machine is used, then discounted over the affected time period and converted to days. For example, if the purchase cost of the host is 120,000 yuan / year, and the vulnerability's impact lasts for one month, then the corresponding virtual asset is 10,000 yuan. This is then converted to days, resulting in 3,333 yuan / day.

[0217] The specific process of result statistics in the above embodiments of this application is as follows: after obtaining the vulnerability losses on the cloud platform side and the cloud platform user side, see here. Figure 9A , Figure 9B as well as Figure 9C ,based on Figure 9A Some security vulnerabilities exist both on the cloud platform side and on the cloud platform user side. Therefore, it is necessary to calculate the losses on the cloud platform side and the cloud platform user side separately to determine the total vulnerability loss; based on Figure 9B Some security vulnerabilities exist only on the cloud platform side, not on the cloud platform user side, therefore only the cloud platform side needs to be calculated; while based on Figure 9CSome security vulnerabilities exist only on the cloud platform user side, and not on the cloud platform user side. Therefore, only the cloud platform user side needs to be calculated. For example, if a vulnerability exists on a certain component, and the cloud platform uses a certain component for development, but no one uses the component on the cloud platform user side, then only the cloud platform side needs to be calculated.

[0218] The process of outputting warnings in the above embodiments of this application specifically involves saving the calculation results obtained from the result statistics to the database and generating corresponding alarm information for use on the corresponding display page. The alarm information template includes the following information: vulnerability name, whether it will affect the cloud platform / cloud platform tenant, the host / system / service affected by the vulnerability, the access volume / usage of the corresponding host / system / service, the vulnerability exploitation method, and the possible amount of loss (users can modify the template display information).

[0219] In this way, not only are the losses on the platform side taken into account, but also the situation of cloud tenants. Furthermore, it is possible to assess the losses caused by vulnerabilities from the perspective of the entire cloud ecosystem. At the same time, it is linked to actual business and uses specific monetary amounts to express the results of vulnerability losses in a more easily understandable way, which allows people to more intuitively understand the potential harm caused by the vulnerability.

[0220] The following description continues to illustrate the exemplary structure of the cloud-based vulnerability alerting device 455 provided in this application embodiment as a software module. In some embodiments, such as... Figure 2 As shown, the software modules stored in the cloud-based vulnerability alerting device 455 in the memory 440 may include:

[0221] The acquisition module 4551 is used to acquire security vulnerabilities existing in the cloud platform and hosts with the security vulnerabilities.

[0222] The determination module 4552 is used to determine the services of the cloud platform supported by the host.

[0223] Prediction module 4553 is used to predict the virtual asset loss caused by the security vulnerability to the business within a target time period, and obtain the loss value;

[0224] The generation module 4554 is used to generate vulnerability alarm information based on the loss value to indicate the existence of the security vulnerability in the cloud platform. The vulnerability alarm information includes the loss of virtual assets caused by the security vulnerability to the business.

[0225] The output module 4555 is used to output the vulnerability alarm information corresponding to the security vulnerability.

[0226] In some embodiments, the acquisition module 4551 is further configured to acquire vulnerability data affecting the security of the cloud platform and the types of security vulnerabilities existing in the cloud platform; wherein the vulnerability data includes at least one of the following: host device data, host network data, and service data of services deployed on the host; and analyze the vulnerability data according to the types of security vulnerabilities existing in the cloud platform to determine the security vulnerabilities existing in the cloud platform.

[0227] In some embodiments, the apparatus further includes a normalization module, which is configured to: determine the security impact category to which the security vulnerability belongs; obtain the risk level range corresponding to the security impact category; map the risk level of the security vulnerability to the risk level range to obtain the risk level value of the security vulnerability; the prediction module 4553 is further configured to: predict the virtual asset loss caused by the security vulnerability to the business within a target time period based on the risk level value of the security vulnerability, and obtain the loss value.

[0228] In some embodiments, the normalization module is further configured to: obtain the security vulnerability type corresponding to the security vulnerability; map the risk level of the security vulnerability to a risk level range based on the security vulnerability type to obtain a mapping result; and obtain the risk level value of the security vulnerability based on the mapping result.

[0229] In some embodiments, the prediction module 4553 is further configured to: obtain a first risk item associated with the security vulnerability and a second risk item associated with the host; wherein the first risk item includes at least one of the following: security vulnerability type, vulnerability exploitation method, vulnerability exposure port, and vulnerability attack method; and the second risk item includes at least one of the following: host defense mechanism and host vulnerability data; determine a first risk level value corresponding to the first risk item and a second risk level value corresponding to the second risk item; and based on the first risk level value and the second risk level value, predict the virtual asset loss caused by the security vulnerability to the business within a target time period, and obtain the loss value.

[0230] In some embodiments, the security vulnerability includes a first vulnerability existing on the cloud platform side and a second vulnerability existing on the cloud platform user side. The prediction module is further configured to: predict a first loss caused to the business by the first vulnerability within a target time period; predict a second loss caused to the business by the second vulnerability within a target time period; and sum the first loss and the second loss to obtain the loss value corresponding to the virtual asset loss caused to the business by the security vulnerability within the target time period.

[0231] In some embodiments, the prediction module 4553 is further configured to obtain loss influencing factors associated with the second vulnerability, the loss influencing factors including at least one of the vulnerability exploitation method of the second vulnerability, user-side defense mechanism, and user-side service type; and based on the loss influencing factors associated with the second vulnerability, determine the second loss caused by the second vulnerability to the service within the target time period.

[0232] In some embodiments, the prediction module 4553 is further configured to: determine the total amount of virtual assets of the services supported by the host during the target time period; determine the ratio of the number of hosts with the security vulnerability to the total number of hosts supporting the services; and, based on the total amount of virtual assets and the ratio, predict the virtual asset loss caused by the security vulnerability to the services during the target time period, and obtain a loss value.

[0233] In some embodiments, the apparatus further includes a second acquisition module, which is configured to acquire the time point at which the security vulnerability was discovered, and the repair time required for a host with the security vulnerability to repair the security vulnerability; and determine the target time period based on the time point at which the security vulnerability was discovered and the repair time.

[0234] In some embodiments, the generation module 4554 is further configured to: obtain an information template for the vulnerability alert information; and generate vulnerability alert information to indicate the existence of the security vulnerability in the cloud platform based on the loss value and the information template.

[0235] In some embodiments, the output module 4555 is further configured to: determine the management terminal corresponding to the host based on the acquired host with the security vulnerability; obtain the notification method corresponding to the vulnerability alarm information; and send the vulnerability alarm information to the management terminal using the notification method, so as to output the vulnerability alarm information through the management terminal.

[0236] This application provides a computer program product or computer program that includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the cloud platform vulnerability alerting method described above in this application.

[0237] This application provides a computer-readable storage medium storing executable instructions. When these executable instructions are executed by a processor, they cause the processor to execute the cloud-based vulnerability alerting method provided in this application. For example... Figure 3 The method for vulnerability alerting based on a cloud platform is shown.

[0238] In some embodiments, the computer-readable storage medium may be a memory such as FRAM, ROM, PROM, EPROM, EEPROM, flash memory, magnetic surface memory, optical disk, or CD-ROM; or it may be a variety of devices including one or any combination of the above-mentioned memories.

[0239] In some embodiments, executable instructions may take the form of a program, software, software module, script, or code, written in any form of programming language (including compiled or interpreted languages, or declarative or procedural languages), and may be deployed in any form, including as a standalone program or as a module, component, subroutine, or other unit suitable for use in a computing environment.

[0240] As an example, executable instructions may, but do not necessarily, correspond to files in a file system. They may be stored as part of a file that holds other programs or data, for example, in one or more scripts in a Hyper Text Markup Language (HTML) document, in a single file dedicated to the program in question, or in multiple collaborating files (e.g., a file that stores one or more modules, subroutines, or code sections).

[0241] As an example, executable instructions can be deployed to execute on a single computing device, or on multiple computing devices located in one location, or on multiple computing devices distributed across multiple locations and interconnected via a communication network.

[0242] In summary, the embodiments of this application have the following beneficial effects:

[0243] (1) Previous methods of expressing the harm of vulnerabilities have been through scoring, but these are difficult for the average person to understand or to express the potential harm of the vulnerability in a more realistic way. However, the embodiments of this application express the vulnerability loss results in a more easy-to-understand way by linking them to specific monetary amounts, which allows people to understand the potential harm of the vulnerability more intuitively.

[0244] (2) Current vulnerabilities are often assessed based solely on factors such as the ease of exploitation and the versions involved. They lack consideration of actual security measures, resulting in some discrepancies with reality. In contrast, this application's embodiment links alerts to actual business operations and incorporates real-world scenarios, facilitating the implementation of appropriate security measures.

[0245] (3) This solution considers not only the losses on the cloud platform side, but also the situation of cloud tenants. Therefore, it is more able to assess the losses caused by the vulnerability from the perspective of the entire cloud ecosystem.

[0246] (4) By providing vulnerability alerts, including information on the loss of virtual assets caused by security vulnerabilities to the business, users or relevant personnel can more intuitively understand the severity of security vulnerabilities, thereby encouraging users to repair security vulnerabilities more efficiently.

[0247] (5) Weighting is achieved by adding coefficients before relevant calculation items during the calculation process. The specific weighting values ​​can be changed according to the actual situation, thus making the calculation more flexible.

[0248] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, and improvements made within the spirit and scope of this application are included within the scope of protection of this application.

Claims

1. A vulnerability alerting method based on a cloud platform, characterized in that, The method includes: The security vulnerabilities existing in the cloud platform and the hosts with the security vulnerabilities are identified. The security vulnerabilities include a first vulnerability existing on the cloud platform side and a second vulnerability existing on the cloud platform user side. Determine the services of the cloud platform supported by the host; Obtain a first risk item associated with the security vulnerability, and a second risk item associated with the host; Determine the first risk level value corresponding to the first risk item and the second risk level value corresponding to the second risk item; Determine the target time period and the total amount of virtual assets supported by the host during the target time period; Determine the ratio of the number of hosts with the security vulnerability to the total number of hosts supporting the service; Based on the difference between the first risk level value and the second risk level value, the total amount of virtual assets, the ratio, and the target time period, the first loss caused to the business by the first vulnerability during the target time period is predicted; Predict the second loss that the second vulnerability will cause to the business during the target time period; The first loss and the second loss are summed to obtain the loss value corresponding to the virtual asset loss caused by the security vulnerability to the business during the target time period; Based on the loss value, a vulnerability alert is generated to indicate the existence of the security vulnerability in the cloud platform. The vulnerability alert includes the loss of virtual assets caused by the security vulnerability to the business. Output the vulnerability alert information corresponding to the security vulnerability.

2. The method as described in claim 1, characterized in that, The process of identifying security vulnerabilities in the cloud platform includes: Obtain vulnerability data that affects the security of the cloud platform, as well as the types of security vulnerabilities existing in the cloud platform; The vulnerability data includes at least one of the following: host device data, host network data, and service data of services deployed on the host; Based on the types of security vulnerabilities existing in the cloud platform, the vulnerability data is analyzed to identify the security vulnerabilities present in the cloud platform.

3. The method as described in claim 1, characterized in that, After identifying the security vulnerabilities existing in the cloud platform, the process also includes: Determine the security impact category to which the security vulnerability belongs; Obtain the risk level range corresponding to the aforementioned safety impact category; The risk level of the security vulnerability is mapped to the risk level range to obtain the risk level value of the security vulnerability.

4. The method according to claim 3, characterized in that, The step of mapping the risk level of the security vulnerability to the risk level range to obtain the risk level value of the security vulnerability includes: Obtain the security vulnerability type corresponding to the security vulnerability; Based on the security vulnerability type, the risk level of the security vulnerability is mapped to a risk level range to obtain the mapping result; Based on the mapping results, the risk level value of the security vulnerability is obtained.

5. The method as described in claim 1, characterized in that, The first risk item includes at least one of the following: security vulnerability type, vulnerability exploitation method, vulnerability exposure port, and vulnerability attack method; the second risk item includes at least one of the following: host defense mechanism and host vulnerability data.

6. The method as described in claim 1, characterized in that, The prediction of the second loss to the business caused by the second vulnerability during the target time period includes: Obtain the loss influencing factors associated with the second vulnerability, wherein the loss influencing factors include at least one of the following: the vulnerability exploitation method of the second vulnerability, the user-side defense mechanism, and the user-side business type; Based on the loss impact factors associated with the second vulnerability, determine the second loss caused to the business by the second vulnerability during the target time period.

7. The method as described in claim 1, characterized in that, The determination of the target time period includes: Obtain the time point at which the security vulnerability was discovered, and the time required for the host with the security vulnerability to fix it. The target time period is determined based on the time when the security vulnerability was discovered and the time required to fix it.

8. The method as described in claim 1, characterized in that, The step of generating vulnerability alert information based on the loss value to indicate the existence of the security vulnerability in the cloud platform includes: Information template for obtaining the vulnerability alert information; Based on the loss value and the information template, a vulnerability alert is generated to indicate the existence of the security vulnerability in the cloud platform.

9. The method as described in claim 8, characterized in that, The output of the vulnerability alert information corresponding to the security vulnerability includes: Based on the host with the security vulnerability obtained, determine the management terminal corresponding to the host; Obtain the notification method corresponding to the vulnerability alert information; The vulnerability alert information is sent to the management terminal using the aforementioned notification method, so that the vulnerability alert information can be output through the management terminal.

10. A vulnerability alerting device based on a cloud platform, characterized in that, The device includes: The acquisition module is used to acquire security vulnerabilities existing in the cloud platform and hosts with the security vulnerabilities, wherein the security vulnerabilities include a first vulnerability existing on the cloud platform side and a second vulnerability existing on the cloud platform user side. The determination module is used to determine the services of the cloud platform supported by the host. The prediction module is used to acquire a first risk item associated with the security vulnerability and a second risk item associated with the host; determine a first risk level value corresponding to the first risk item and a second risk level value corresponding to the second risk item; determine a target time period and determine the total amount of virtual assets supported by the host during the target time period; determine the ratio of the number of hosts with the security vulnerability to the total number of hosts supporting the service; based on the difference between the first risk level value and the second risk level value, the total amount of virtual assets, the ratio, and the target time period, predict a first loss caused by the first vulnerability to the service during the target time period; predict a second loss caused by the second vulnerability to the service during the target time period; and sum the first loss and the second loss to obtain the loss value corresponding to the virtual asset loss caused by the security vulnerability to the service during the target time period. The generation module is used to generate vulnerability alert information based on the loss value to indicate the existence of the security vulnerability in the cloud platform. The vulnerability alert information includes the loss of virtual assets caused by the security vulnerability to the business. The output module is used to output the vulnerability alert information corresponding to the security vulnerability.

11. The apparatus as claimed in claim 10, characterized in that, The acquisition module is also used for: Obtain vulnerability data affecting the security of the cloud platform, as well as the types of security vulnerabilities existing in the cloud platform; wherein, the vulnerability data includes at least one of the following: host device data, host network data, and service data of services deployed on the host; analyze the vulnerability data according to the types of security vulnerabilities existing in the cloud platform to determine the security vulnerabilities existing in the cloud platform.

12. The apparatus as claimed in claim 10, characterized in that, The device further includes a normalization module, the normalization module being used for: Determine the security impact category to which the security vulnerability belongs; obtain the risk level range corresponding to the security impact category; The risk level of the security vulnerability is mapped to the risk level range to obtain the risk level value of the security vulnerability.

13. The apparatus as claimed in claim 12, characterized in that, The normalization module is also used for: Obtain the security vulnerability type corresponding to the security vulnerability; based on the security vulnerability type, map the risk level of the security vulnerability to a risk level range to obtain the mapping result; Based on the mapping results, the risk level value of the security vulnerability is obtained.

14. The apparatus as claimed in claim 10, characterized in that, The prediction module is also used for: Determine the total amount of virtual assets supported by the host during the target time period; determine the ratio of the number of hosts with the security vulnerability to the total number of hosts supporting the service; Based on the total amount of virtual assets and the ratio, the virtual asset loss caused by the security vulnerability to the business during the target time period is predicted, and the loss value is obtained.

15. The apparatus as claimed in claim 10, characterized in that, The device further includes a second acquisition module, the second acquisition module being configured to: Obtain the time point at which the security vulnerability was discovered, and the time required for the host with the security vulnerability to fix it. The target time period is determined based on the time when the security vulnerability was discovered and the time required to fix it.

16. The apparatus as claimed in claim 10, characterized in that, The generation module is further configured to: Obtain the information template of the vulnerability alert information; based on the loss value and the information template, generate vulnerability alert information to indicate the existence of the security vulnerability in the cloud platform.

17. The apparatus as claimed in claim 10, characterized in that, The output module is also used for: Based on the host with the security vulnerability, determine the management terminal corresponding to the host; obtain the notification method corresponding to the vulnerability alarm information; use the notification method to send the vulnerability alarm information to the management terminal, so as to output the vulnerability alarm information through the management terminal.

18. An electronic device, characterized in that, include: Memory, used to store executable instructions; The processor, when executing executable instructions stored in the memory, implements the cloud-based vulnerability alerting method according to any one of claims 1 to 9.

19. A computer-readable storage medium, characterized in that, It stores executable instructions for causing the processor to execute, thereby implementing the cloud-based vulnerability alerting method according to any one of claims 1 to 9.

20. A computer program product comprising a computer program or instructions, characterized in that, When the computer program or instructions are executed by the processor, they implement the cloud-based vulnerability alerting method according to any one of claims 1 to 9.

Images