Multi-architecture collaborative vulnerability library construction method based on mimicry defense

Abstract

The invention relates to a multi-architecture collaborative vulnerability library construction method based on mimicry defense, and the method comprises the steps: introducing mimicry defense core function components: mimicry label, mimicry matching, mimicry distribution, mimicry decision, feedback control and executor scheduling under the condition that there is a difference in vulnerability environment. The mimicry component can call application containers under different architectures, multi-heterogeneous environment collaborative vulnerability reproduction is achieved, meanwhile, applications with similar functions are scheduled to conduct mimicry defense transformation on existing applications, and the vulnerability is effectively prevented from being utilized. The problems that an existing vulnerability library construction technology only aims at original environment collection of public vulnerabilities, the public vulnerabilities are reproduced under the condition that the operation environment is consistent, and if a public solution does not exist, the vulnerabilities of the application of the version cannot be repaired are solved, during reproduction, a mimicry matching component directly pulls a container corresponding to a label, and the vulnerabilities of the application of the version cannot be repaired. And a mimicry environment is automatically constructed to reproduce an original vulnerability environment or a mimicry vulnerability environment.

Description

Technical Field

[0001] This invention relates to a cyberspace security technology, and in particular to a method for constructing a multi-architecture collaborative vulnerability database based on mimicry defense. Background Technology

[0002] In the current context of deep digital integration into society, China's security situation is facing extremely severe challenges. For example, malicious cyberattacks such as server viruses, Trojan horses, and vulnerability exploits are emerging in an endless stream, launching wave after wave of attacks on network systems. In addition, other forms of cyberattacks are also rampant, running rampant in the cyber world.

[0003] To effectively safeguard national information security and ensure the robust operation of the economic system, protecting it from harm, the collection and protection against existing vulnerabilities is crucial and urgent. Vulnerability location and collection require professionals with sophisticated skills and keen insight to pinpoint every potential security threat within complex network architectures and massive amounts of code. After vulnerability collection, preventative measures must be studied. Therefore, the collection, storage, and resolution of vulnerabilities constitute a critical security protection process. However, current technologies are sufficient for vulnerability collection but insufficient for effective protection.

[0004] While existing vulnerability databases are extensively collected and stored in various vendors' databases, their coverage is quite limited. Furthermore, even when vulnerabilities are collected, solutions for reproducing the vulnerabilities are often lacking, and even when solutions are provided, direct replication is difficult, making it impossible to directly compare the existence of vulnerabilities with their absence. Mimicry-based defense, with its dynamic, heterogeneous, diverse, and randomized characteristics, can take defensive measures against unknown vulnerabilities, improving system security, increasing the difficulty for attackers, effectively preventing vulnerabilities for which solutions are not publicly available, and enabling multi-architecture device collaboration through the construction of a mimicry framework in multi-architecture scenarios. Summary of the Invention

[0005] To address the issue that existing vulnerability database construction techniques only collect data from the original environment of publicly disclosed vulnerabilities, reproduce publicly disclosed vulnerabilities under the same operating environment, and cannot fix vulnerabilities in the application version if there is no publicly available solution, a multi-architecture collaborative vulnerability database construction method based on mimicry defense is proposed.

[0006] To address the challenges posed by varying vulnerability environments, a core mimicry defense component is introduced: mimicry tagging, mimicry matching, mimicry distribution, mimicry adjudication, feedback control, and execution scheduling. This mimicry component can invoke application containers across different architectures, enabling collaborative vulnerability reproduction across multiple heterogeneous environments. Simultaneously, it schedules applications with similar functionalities to perform mimicry defense modifications on existing applications, effectively preventing vulnerability exploitation.

[0007] When publicly disclosed vulnerability information is containerized and stored in a vulnerability database, the mimicry tagging component is invoked to automatically analyze the middleware version, application version, and other relevant runtime environment information within the container, and then store it in a database table. Next, the mimicry matching component is invoked to match applications with similar functions from the container database table and add them with tags. During reproduction, the mimicry matching component directly pulls the container corresponding to the tag and automatically constructs a mimicry environment to reproduce the "original vulnerability environment" or the "mimicry vulnerability environment."

[0008] The technical solution of this invention is as follows: A multi-architecture collaborative vulnerability library construction based on mimicry defense includes: Step 1: Automatic collection of external raw vulnerabilities. In a network environment, the built-in capture module captures external vulnerabilities from the internally set vulnerability sources and attempts to add them to the database; or manually enter vulnerability information and manually upload the vulnerability information to the raw vulnerability collection module. Step 2: Store the original vulnerability information in the original vulnerability database; Step 3: The original vulnerability database calls the mimicry tagging component to containerize the vulnerabilities and then stores them in the vulnerability database. After analyzing the vulnerability's runtime environment information, it is stored in the database. The original vulnerability database calls the mimicry matching component to match and analyze similar applications in the container database, records the similar application information, and then stores it in the database. Step 4: After the data information is recorded, wait for the external environment to call it. The external environment will pass the reproduction information to the mimicry distribution component. Step 5: The mimicry distribution component distributes information to the execution scheduling module; Step 6: The execution body scheduling module identifies vulnerability information in the reproduced information and passes it to the vulnerability information matching module; it schedules and deploys a multi-architecture execution body environment based on the information returned by the vulnerability information matching module; it passes the information to be adjudicated to the mimic adjudication component; the container library component in the vulnerability information matching module calls the mimic tag component and the mimic matching component to pull container tag information from the vulnerability library and the database. Step 7: The mimicry adjudication component adjudicates the final information and transmits the reproduction information to the external access environment; Step 8: Feedback control records the adjudication information from the mimicry adjudication, and schedules the execution body to go online and offline based on the information.

[0009] Furthermore, steps 1-3 specifically include: The original vulnerability information is collected from outside the system or manually entered into the system. The vulnerability information and data are then formatted and stored in the original vulnerability database. The original vulnerability database calls the mimicry tag component, which uses the built-in mimicry environment containerization module to containerize the vulnerabilities. After the vulnerability containerization is completed, it is stored in the vulnerability database. At the same time, the built-in vulnerability information collection and analysis module of the mimicry tag collects vulnerability runtime environment information, analyzes and formats it, and then enters it into the database. After completing the original vulnerability analysis, the original vulnerability database calls the mimicry matching component. The application information matching module built into the mimicry matching component is responsible for breaking down the vulnerability information and matching it with similar application information. Then, the tagged data is stored in the database. After the vulnerability is stored in the original vulnerability database, it awaits the next call. During the call, all components of the mimicry framework are introduced. During the vulnerability reproduction process, mimicry modifications are performed to create different architecture runtime environments, pull different architecture containers, and achieve multi-architecture collaborative processing.

[0010] Furthermore, steps 4-8 specifically include: The external access environment module transmits information about the vulnerability database that needs to be reproduced to the mimicry distribution component. The mimicry distribution component breaks down the vulnerability reproduction information transmitted by the external access tool and distributes it to the execution body scheduling module. The execution body scheduling module allocates and schedules execution bodies according to different information, selects containers with the corresponding architecture to enter the execution body pool, and at the same time, the execution body scheduling module will send a container selection request to the container library. In the vulnerability information matching module, the container library is responsible for storing all externally collected vulnerability containers, middleware, open-source applications, applications that are not open-source but provide one-click deployment methods, runtime environment containers, and platform-built-in applications. When it receives container selection request information from the execution body scheduling module, it passes the information to the mimicry matching component and the mimicry tag component. The mimicry tag and mimicry matching component compare the information in the database and the vulnerability database. After the comparison is completed, the corresponding tag information is passed to the container library. The container library completes the container screening process and pushes the container to the execution body environment. The execution body screening is completed, and the multi-architecture collaborative execution body environment is deployed. The mimicry adjudication component receives data from the executors in the executor environment, and adjudicates the final information through logical arbitration and consistency voting tools. Executors with inconsistent information will return information to the executor scheduling module through feedback control. The executor scheduling module records the inconsistent situations and displays the state unaffected by the vulnerability and the state affected by the vulnerability according to the settings in the reproduction request, clearly showing the difference between the two. In a mimicry defense environment, a multi-architecture collaborative vulnerability database will label, analyze, containerize, store, schedule, and standardize the information of collected vulnerabilities. Vulnerability reproduction requires ensuring multi-architecture collaborative deployment, a complete reproduction process, and correct matching of vulnerability container tags. Therefore, mimicry components are introduced to completely transform the vulnerability reproduction process.

[0011] Furthermore, the external access environment module refers to external access tools that need to access the external interfaces exposed by the vulnerability database, including multi-architecture vulnerability database front-end interfaces and vulnerability database calling tools. These tools use the interfaces exposed by the multi-architecture collaborative vulnerability database for external calls.

[0012] The beneficial effects of this invention are as follows: Traditional vulnerability databases directly add raw vulnerabilities to the database after collection. While this completes the initial accumulation of vulnerability data, it has high requirements for the runtime environment and cannot be directly reproduced when needed. The containerization modification of the mimicry component solves this problem and ensures the availability of vulnerability reproduction in the environment.

[0013] The mimicry component performs mimicry deployment while ensuring the successful reproduction of the vulnerability environment, heterogeneously transforming the vulnerability environment and simulating vulnerability scenarios under multiple architectures; it then stores vulnerability-related information in the form of information tags, simultaneously simulating scenarios with and without vulnerabilities.

[0014] The vulnerability database, after being modified to mimic the behavior of other systems, can reproduce the entire vulnerability scenario after receiving only one reproduction information. In the demonstration phase after the reproduction is completed, multiple architectures simulate scenarios where the vulnerability is effective and scenarios where it is not, allowing for an intuitive analysis of the vulnerability situation. Attached Figure Description

[0015] Figure 1 This is a data flow diagram of the vulnerability tag entry into the database for this invention; Figure 2 This is a diagram illustrating the process of reproducing the vulnerability in the present invention. Detailed Implementation

[0016] The present invention will now be described in detail with reference to the accompanying drawings and specific embodiments. These embodiments are based on the technical solution of the present invention and provide detailed implementation methods and specific operating procedures. However, the scope of protection of the present invention is not limited to the following embodiments.

[0017] A multi-architecture collaborative vulnerability database construction method based on mimicry defense introduces the core concept of mimicry defense into the process of external vulnerability database collection and localization. Starting with the analysis and disassembly of vulnerability runtime environment information, it integrates mimicry components into the vulnerability localization process. Detailed design data flow diagrams are available in [link to data]. Figure 1 .

[0018] The original vulnerability information is collected from outside the system or manually entered into the system. The vulnerability information and data are then formatted and stored in the original vulnerability database.

[0019] The original vulnerability database calls the mimicry tag component, which uses the built-in functional module (mimicry environment containerization modification module) of the mimicry tag component to containerize the vulnerabilities. After the vulnerability containerization modification is completed, it is stored in the vulnerability database. At the same time, the built-in functional module (vulnerability information collection and analysis module) of the mimicry tag collects vulnerability runtime environment information, analyzes and formats it, and then enters it into the database.

[0020] After completing the original vulnerability analysis, the original vulnerability database calls the mimicry matching component. The built-in module (application information matching module) in the mimicry matching component is responsible for breaking down the vulnerability information and matching it with similar application information, and then storing the tagged data into the database.

[0021] After the vulnerability is stored in the original vulnerability database, it awaits the next call. During the call, all components of the mimicry framework are introduced. During the vulnerability reproduction process, mimicry modifications are performed to create different architecture runtime environments, pull different architecture containers, and achieve multi-architecture collaborative processing.

[0022] During the vulnerability environment reproduction process, a secondary matching process is performed using a mimicry tag and mimicry matching component. When the reproduction request is executed in the external environment, the execution body scheduling component connects to the container library to select a container. After selection, the mimicry adjudication process begins, ultimately completing the multi-architecture reproduction. For a detailed reproduction process, see [link to documentation]. Figure 2 .

[0023] The external access environment module refers to external access tools that need to access the external interfaces exposed by the vulnerability database, such as multi-architecture vulnerability database front-end interfaces and vulnerability database calling tools. These tools usually use the interfaces exposed by the multi-architecture collaborative vulnerability database to make calls, and the information of the vulnerability database that needs to be reproduced is passed to the mimicry distribution component by such tools.

[0024] The mimicry distribution component breaks down the vulnerability reproduction information transmitted by the external access tool and distributes it to the execution body scheduling module. The execution body scheduling module allocates and schedules execution bodies according to different information, selects containers with the corresponding architecture to enter the execution body pool, and at the same time, the execution body scheduling module will send a container selection request to the container library.

[0025] In the vulnerability information matching module, the container library is responsible for storing all externally collected vulnerability containers, as well as common middleware, open-source applications, applications that are not open-source but provide one-click deployment methods, runtime environment containers, and platform-built-in applications. When it receives a container selection request from the execution body scheduling module, it passes the information to the mimicry matching component and the mimicry tag component. The mimicry tag and mimicry matching components compare the information in the database and the vulnerability database. After the comparison is completed, the corresponding tag information is passed to the container library. The container library completes the container screening process and pushes the container to the execution body environment. Once the execution body screening is complete, the multi-architecture collaborative execution body environment deployment is finished.

[0026] The mimicry adjudication component receives data from executors in the executor environment and adjudicates the final information through logical arbitration and consistency voting tools. Executors with inconsistent information will have their information returned to the executor scheduling module by feedback control. The executor scheduling module records the inconsistent situations and, based on the settings in the reproduction request, displays the state unaffected by the vulnerability and the state affected by the vulnerability, clearly showing the difference between the two.

[0027] In a mimicry defense environment, a multi-architecture collaborative vulnerability database will label, analyze, containerize, store, schedule, and standardize information on the collected vulnerabilities. Vulnerability reproduction requires ensuring multi-architecture collaborative deployment, a complete reproduction process, and correct matching of vulnerability container tags. Therefore, mimicry components are introduced to completely transform the vulnerability reproduction process.

[0028] The above-described embodiments are merely one implementation of the present invention, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of the invention. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of the present invention, and these all fall within the protection scope of the present invention. Therefore, the protection scope of this invention should be determined by the appended claims.

Claims

1. A multi-architecture collaborative vulnerability database construction method based on mimicry defense, characterized in that, include: Step 1: Automatic collection of external raw vulnerabilities. In a network environment, the built-in capture module captures external vulnerabilities from the internally set vulnerability sources and attempts to add them to the database; or manually enter vulnerability information and manually upload the vulnerability information to the raw vulnerability collection module. Step 2: Store the original vulnerability information in the original vulnerability database; Step 3: The original vulnerability database calls the mimicry tagging component to containerize the vulnerabilities and then stores them in the vulnerability database. After analyzing the vulnerability's runtime environment information, it is stored in the database. The original vulnerability database calls the mimicry matching component to match and analyze similar applications in the container database, records the similar application information, and then stores it in the database. Step 4: After the data information is recorded, wait for the external environment to call it. The external environment will pass the reproduction information to the mimicry distribution component. Step 5: The mimicry distribution component distributes information to the execution scheduling module; Step 6: The execution body scheduling module identifies vulnerability information in the reproduced information and passes it to the vulnerability information matching module; it schedules and deploys a multi-architecture execution body environment based on the information returned by the vulnerability information matching module; it passes the information to be adjudicated to the mimic adjudication component; the container library component in the vulnerability information matching module calls the mimic tag component and the mimic matching component to pull container tag information from the vulnerability library and the database. Step 7: The mimicry adjudication component adjudicates the final information and transmits the reproduction information to the external access environment; Step 8: Feedback control records the adjudication information from the mimicry adjudication, and schedules the execution body to go online and offline based on the information.

2. The construction of a multi-architecture collaborative vulnerability database based on mimicry defense as described in claim 1, characterized in that, Steps 1-3 specifically include: The original vulnerability information is collected from outside the system or manually entered into the system. The vulnerability information and data are then formatted and stored in the original vulnerability database. The original vulnerability database calls the mimicry tag component, which uses the built-in mimicry environment containerization module to containerize the vulnerabilities. After the vulnerability containerization is completed, it is stored in the vulnerability database. At the same time, the built-in vulnerability information collection and analysis module of the mimicry tag collects vulnerability runtime environment information, analyzes and formats it, and then enters it into the database. After completing the original vulnerability analysis, the original vulnerability database calls the mimicry matching component. The application information matching module built into the mimicry matching component is responsible for breaking down the vulnerability information and matching it with similar application information. Then, the tagged data is stored in the database. After the vulnerability is stored in the original vulnerability database, it awaits the next call. During the call, all components of the mimicry framework are introduced. During the vulnerability reproduction process, mimicry modifications are performed to create different architecture runtime environments, pull different architecture containers, and achieve multi-architecture collaborative processing.

3. The construction of a multi-architecture collaborative vulnerability database based on mimicry defense as described in claim 1, characterized in that, Steps 4-8 specifically include: The external access environment module transmits information about the vulnerability database that needs to be reproduced to the mimicry distribution component. The mimicry distribution component breaks down the vulnerability reproduction information transmitted by the external access tool and distributes it to the execution body scheduling module. The execution body scheduling module allocates and schedules execution bodies according to different information, selects containers with the corresponding architecture to enter the execution body pool, and at the same time, the execution body scheduling module will send a container selection request to the container library. In the vulnerability information matching module, the container library is responsible for storing all externally collected vulnerability containers, middleware, open-source applications, applications that are not open-source but provide one-click deployment methods, runtime environment containers, and platform-built-in applications. When it receives container selection request information from the execution body scheduling module, it passes the information to the mimicry matching component and the mimicry tag component. The mimicry tag and mimicry matching component compare the information in the database and the vulnerability database. After the comparison is completed, the corresponding tag information is passed to the container library. The container library completes the container screening process and pushes the container to the execution body environment. The execution body screening is completed, and the multi-architecture collaborative execution body environment is deployed. The mimicry adjudication component receives data from the executors in the executor environment, and adjudicates the final information through logical arbitration and consistency voting tools. Executors with inconsistent information will return information to the executor scheduling module through feedback control. The executor scheduling module records the inconsistent situations and displays the state unaffected by the vulnerability and the state affected by the vulnerability according to the settings in the reproduction request, clearly showing the difference between the two. In a mimicry defense environment, a multi-architecture collaborative vulnerability database will label, analyze, containerize, store, schedule, and standardize the information of collected vulnerabilities. Vulnerability reproduction requires ensuring multi-architecture collaborative deployment, a complete reproduction process, and correct matching of vulnerability container tags. Therefore, mimicry components are introduced to completely transform the vulnerability reproduction process.

4. The construction of a multi-architecture collaborative vulnerability database based on mimicry defense as described in claim 3, characterized in that, The external access environment module refers to external access tools that need to access the external interfaces exposed by the vulnerability database, including multi-architecture vulnerability database front-end interfaces and vulnerability database calling tools. These tools use the interfaces exposed by the multi-architecture collaborative vulnerability database for external calls.

Images