A cloud service honeypot generation method and system for active defense

Abstract

The present invention provides a cloud service honeypot generation method and system for active defense, which relates to the field of network security technology, including: generating a cloud asset map based on initial honeypots and honeypot deception scenarios obtained by simulating real asset devices; obtaining an updated cloud asset map when an authenticated user drags and changes a cloud function, exporting a configuration file based on the updated cloud asset map, and extracting template samples from a preset honeypot policy template library based on the configuration file; arranging the template samples to obtain multiple honeypot deployment templates that conform to the corresponding cloud environment and attack path; generating multiple IaC source code files based on an IaC template, and calling a preset Terraform based on the IaC source code files to generate multiple honeypots. The present invention adopts a completely real cloud service infrastructure as a honeypot, utilizes the design concept of input parameters, output parameters, and intermediate checkpoints in the honeypot, and cooperates with the monitoring and alarm of the cloud service itself to adjust the honeypot in real time, thereby improving the security of the network system.

Description

Technical Field

[0001] The present invention relates to the field of network security technology, and in particular to a cloud service honeypot generation method and system for active defense. Background Art

[0002] Network deception defense is a proactive security strategy that confuses attackers by placing false information within the network, thereby protecting real assets. This technology aims to guide attackers to interact with fake resources, thereby capturing and analyzing their behavior and providing defenders with critical threat intelligence. However, with the emergence of worms, botnets, and advanced persistent threats, attack methods are becoming increasingly sophisticated, and traditional passive defense mechanisms are gradually becoming inadequate. These mechanisms rely on attackers' new techniques to update defense rules, leaving defenses in a perpetually passive state and vulnerable to bypass, thus reducing the security of network systems. Therefore, a solution is urgently needed to address this issue. Summary of the Invention

[0003] The purpose of the present invention is to provide a cloud service honeypot generation method and system for active defense, so as to improve the problem of low security of the network system caused by the low defense capability of the defender when facing more complex attack methods of the attacker.

[0004] In a first aspect, the present invention provides a method for generating cloud service honeypots for active defense, which adopts the following technical solutions:

[0005] generating a cloud asset map based on initial sweet spots and sweet spot deception scenarios obtained through simulation of real asset devices, wherein the cloud asset map has multiple cloud facilities, including but not limited to sweet spots, storage buckets, and cloud functions;

[0006] When the authenticated user drags and modifies the cloud function, an updated cloud asset graph is obtained, a configuration file is exported based on the updated cloud asset graph, and a template sample is extracted from a preset honeyspot strategy template library based on the configuration file;

[0007] The template samples are orchestrated to obtain multiple honeypot deployment templates that conform to corresponding cloud environments and attack paths, where the honeypot deployment templates are IaC templates available for Terraform;

[0008] A plurality of IaC source code files are generated based on the IaC template, and a preset Terraform is called based on the IaC source code files to generate a plurality of honey spots.

[0009] The beneficial effects of the cloud service honeypot generation method for active defense provided by the present invention are: first, using real cloud facilities as honeypots, by using real cloud facilities as honeypots, all cloud facilities are included in the scope of deception defense, thereby improving the comprehensiveness and flexibility of protection; second, using infrastructure as code (IaC) to build honeypots, and using Terraform to build honeypots, making the deployment of honeypots more flexible; third, establishing a dynamic feedback mechanism for honeypots, using the input and output parameter design mechanism of honeypots to associate the honeypots with each other, and dynamically adjusting the generation and destruction of honeypots according to alarm feedback processing, thereby reducing resource consumption while maintaining a high level of deception; fourth, supporting a multi-cloud service migration mechanism through the module and template mechanism, and being able to use the same code to quickly build on different cloud service provision platforms.

[0010] Optionally, the honey spot includes a pre-triggering condition and a consequence prediction strategy. Each pre-triggering condition corresponds to a unique honey spot transformation strategy. When an attacker triggers the pre-triggering condition, the corresponding honey spot service is transformed.

[0011] Optionally, when the attacker attacks the honey spot along the attack path, when the number of alarm triggering is less than or equal to the trigger threshold, the template sample is eliminated, and the updated template sample is reselected from the preset honey spot strategy template library, and the updated honey spot is obtained based on the updated template sample.

[0012] Optionally, the cloud asset graph corresponds to the currently running honeypot. During the entire honeypot operation, the assets in the cloud asset graph can be modified at any time. These modifications will be applied to the cloud facility through Terraform's IaC source code changes.

[0013] In a second aspect, the present invention further provides a cloud service honeypot generation system for active defense, comprising:

[0014] A cloud asset graph module is used to store and manage multiple cloud facilities and generate corresponding configuration files based on cloud facilities dragged and modified by authenticated users, where each cloud facility corresponds to a cloud service asset, and multiple cloud service assets are combined into a cloud asset graph;

[0015] The honeypot and policy module is used to store multiple honeypot policy templates based on a relational database. Multiple different cloud facilities have a honeypot policy template with the same policy.

[0016] A control terminal module, configured to automatically extract template samples that conform to the corresponding cloud environment and attack path from the honeyspot and policy module according to the configuration file, and generate IaC source code based on the template samples and the configuration file;

[0017] A code calling module, configured to call Terraform based on the IaC source code to update the types and quantities of cloud facilities and obtain an updated cloud asset map;

[0018] An orchestration component module, configured to extract a sample from the honeyspot strategy template and orchestrate the sample to obtain a template sample for a specified cloud facility;

[0019] The alarm feedback module is used to process events generated by cloud facilities in the cloud asset map to generate corresponding alarm events, and push the alarm events to the control terminal module.

[0020] Optionally, the alarm feedback module specifically includes:

[0021] The decoy module is used to combine storage buckets and cloud functions to generate decoy resources;

[0022] A real-time log module is configured to guide an attacker to attack cloud facilities within the cloud asset graph based on the bait resource to generate multiple attack logs, combine the multiple attack logs to obtain log report events, and send the log report events to a storage bucket for storage;

[0023] An audit module, configured to trigger a corresponding alarm mechanism according to a preset alarm condition, and send the log report events stored in the storage bucket to the event bus component based on the alarm mechanism;

[0024] The event bus module is used to orchestrate the log report event to obtain an alarm event, and send the alarm time to the control terminal to perform a Terraform call to update the cloud facilities in the cloud asset map.

[0025] For the beneficial effects of the second aspect, reference may be made to the description of the first aspect. BRIEF DESCRIPTION OF THE DRAWINGS

[0026] Figure 1 This is a flow chart of a cloud service honeypot generation method for active defense provided by the present invention;

[0027] Figure 2 This is a flowchart of the cloud asset map, control terminal, orchestration component, and policy library module provided by the present invention;

[0028] Figure 3 This is a module diagram of the alarm feedback component provided by the present invention. DETAILED DESCRIPTION

[0029] In order to make the purpose, technical solutions and advantages of the embodiments of the present invention clearer, the technical solutions in the embodiments of the present invention will be clearly and completely described below. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of the present invention. Unless otherwise defined, the technical terms or scientific terms used herein should be the common meanings understood by people with ordinary skills in the field to which the invention belongs. The words "including" and similar words used in this article mean that the elements or objects appearing before the word cover the elements or objects listed after the word and their equivalents, without excluding other elements or objects.

[0030] First, the present invention explains a series of nouns:

[0031] Infrastructure as code (IaC) refers to the ability to configure computing infrastructure using code instead of manual processes and settings. IaC defines the desired state of the infrastructure without including all the steps required to achieve that state. It describes the system architecture and its workings, controlling virtualized resources by treating configuration files as source code. As long as the infrastructure resources are available, the same IaC source code can be used to deploy the same environment to different systems in different locations.

[0032] Terraform is an open-source Infrastructure as Code (IaC) tool that allows developers to describe and provision data center infrastructure using a high-level configuration language. This allows developers to manage and orchestrate services and resources across cloud environments, virtualization platforms, or physical hardware.

[0033] In some embodiments, see Figure 1 , indicating a cloud service honeypot generation method for active defense provided by the present invention, comprising the following steps:

[0034] S1. Generate a cloud asset map based on initial sweet spots and sweet spot deception scenarios obtained through simulation of real asset devices, wherein the cloud asset map has multiple cloud facilities, including but not limited to sweet spots, storage buckets, and cloud functions;

[0035] S2. When the authenticated user drags and modifies the cloud function, an updated cloud asset graph is obtained, a configuration file is exported based on the updated cloud asset graph, and a template sample is extracted from a preset honeyspot strategy template library based on the configuration file;

[0036] S3. Arrange the template samples to obtain multiple honeypot deployment templates that meet the corresponding cloud environment and attack path, where the honeypot deployment templates are IaC templates available for Terraform;

[0037] S4. Generate multiple IaC source code files based on the IaC template, and call a preset Terraform based on the IaC source code files to generate multiple honey spots.

[0038] In some embodiments, see Figure 2 When an authenticated user drags and changes a cloud function from the cloud asset graph, the cloud asset graph exports a configuration file and sends it to the control terminal. The control terminal extracts the honey spots and policy templates corresponding to the configuration file from the honey spot and policy template library based on the configuration file, inputs them into the orchestration component for orchestration processing, and sends them to the control terminal. The control terminal outputs the IaC code.

[0039] In some embodiments, when executing step S1, the honey spot includes a pre-trigger condition and a consequence prediction strategy. Each pre-trigger condition corresponds to a unique honey spot transformation strategy. When the attacker triggers the pre-trigger condition, the corresponding honey spot service is transformed.

[0040] Furthermore, when executing step S1, the cloud asset map corresponds to the currently running honeypot. During the entire operation of the honeypot, the assets in the cloud asset map can be modified at any time. These modifications will be applied to the cloud facility through Terraform's IaC source code changes.

[0041] In some embodiments, when executing step S3, when the attacker attacks the honey spot along the attack path, when the number of alarm triggering is less than or equal to the trigger threshold, the template sample is eliminated, and the updated template sample is reselected from the preset honey spot strategy template library, and the updated honey spot is obtained based on the updated template sample.

[0042] In other embodiments, the present invention further provides a cloud service honeypot generation system for active defense, comprising:

[0043] The cloud asset graph module M1 is used to store and manage multiple cloud facilities and generate corresponding configuration files based on the cloud facilities dragged and modified by the authenticated user. Each cloud facility corresponds to a cloud service asset, and multiple cloud service assets are combined into a cloud asset graph.

[0044] Specifically, the cloud asset map is a graphical representation of the cloud service assets that can be listed based on the cloud service provider credentials provided by the user. Users can manage cloud service assets within a graphical interface. This section serves the deployment of sweet spots. Users can select a series of sweet spots and corresponding deception scenarios from the sweet spot and policy template library for existing assets and drag them into the cloud asset map. Users can also drag only one or several sweet spots and set their input and output parameters and intermediate checkpoints as required to form their own deception scheme. When users set sweet spots or policies to the asset map, these contents are synchronized with the orchestration component. The orchestration component generates the correct IaC source code according to the specified templates in the sweet spot and policy template library.

[0045] The honey spot and policy module M2 is used to store multiple honey spot policy templates based on a relational database. Multiple different cloud facilities have a honey spot policy template with the same policy.

[0046] Specifically, the honeypoint and policy template library primarily stores honeypoint and policy templates written by professional security personnel. In reality, multiple cloud service providers each have their own templates for the same policy. The template library is implemented using a relational database and exposes an API for orchestration components and control terminals to access. When a honeypoint service is created or modified, the orchestration component searches the template library for the corresponding available template and combines multiple partial templates to form the IaC source code.

[0047] A control terminal module M3 is configured to automatically extract template samples that match the corresponding cloud environment and attack path from the honeyspot and policy module M2 according to the configuration file, and generate IaC source code based on the template samples and the configuration file;

[0048] Specifically, the control terminal module M3 is primarily responsible for receiving alarm feedback and constructing and scheduling cloud environment hotspots. When a user modifies the asset map or a trigger condition is met requiring a hotspot change, the IaC source code processed by the orchestration component is passed to the control terminal. The control terminal then calls Terraform based on the new IaC source code to update the cloud environment's infrastructure. When an alarm arrives through the control terminal's API, the control terminal determines the attacker's behavior based on the IaC template and traverses along predefined checkpoints. If the attacker's path follows the designed pattern, the control terminal records the attacker's actions.

[0049] Furthermore, when a deception scenario proves ineffective and the attacker is unable to trigger an alert along the designed path, the control terminal module M3 adjusts the number of honeypots with fewer triggers. It then selects a better strategy and honeypot template from the honeypot and policy module M2, and redeploys some or all of the honeypots to create a new, more practical, and "sweeter" deception scenario. In particular, honeypots deemed no longer necessary based on policy are removed from the current cloud environment within a certain period of time after the last interaction, saving costs.

[0050] A code calling module M4 is used to call Terraform according to the IaC source code to update the types and quantities of cloud facilities and obtain an updated cloud asset map;

[0051] The orchestration component module M5 is configured to extract a sample from the honeyspot strategy template and orchestrate the sample to obtain a template sample for a specified cloud facility;

[0052] Specifically, the orchestration component module M5 is primarily responsible for deploying cloud infrastructure using the IaC source code. Its API receives formatted description data from the control terminal, specifying the policy to be adopted and the user-defined sweet spot configuration. Based on the formatted configuration, it then retrieves the corresponding policy and sweet spot template for the specified cloud service from the sweet spot and policy template library. It then generates a new Terraform source code file, references the corresponding Terraform module from the sweet spot and policy template library, and orchestrates it together.

[0053] Furthermore, the orchestration component module M5 places decoy resources in storage buckets and cloud functions based on the template's needs, thereby concatenating the input and output parameters between the honeypots and fully constructing the deception scenario. Before the entire facility is deleted, the source code is saved to disk and assigned an ID for easy indexing and reuse. After the entire facility is orchestrated, all configuration parameters are passed back to the control terminal module M3, which ultimately calls Terraform to deploy the cloud service honeypot.

[0054] When modifying an existing sweetspot, the orchestration component module M5 receives formatted description data from the control terminal module M3, which specifies the resource IDs and the modified parts. The orchestration component module M5 first parses this data, locates the corresponding IaC source code, and modifies the relevant parts. The control terminal module M3 then calls Terraform to execute the changes, completing the deployment of the sweetspot.

[0055] The alarm feedback module M6 is used to process events generated by cloud facilities in the cloud asset map to generate corresponding alarm events, and push the alarm events to the control terminal module M3.

[0056] Specifically, taking AWS (Amazon Web Service, Amazon Technology Cloud Service) as an example, the alarm feedback module M6 relies on four major components: cloud audit service, cloud monitoring service, simple storage service, and simple notification service. At this time, all events generated in the cloud facility will pass through the cloud audit service, so it is only necessary to configure according to the input parameters, output parameters and intermediate checkpoints of the relevant honeypots, filter out some events that need to be processed, and then send the events to the designated log group of the cloud monitoring service. In the cloud monitoring service, the designated log group is screened, and the events that need to be pushed alarms are selected, and the designated simple notification service is called to push them to the control terminal module M3.

[0057] In practice, the generation of a single honeypot in a deception scenario progresses through the Cloud Asset Map Module M1, the Control Terminal Module M3, the Orchestration Component Module M5, the Alarm Feedback Module M6, and the Honeypot and Policy Module M2. First, the user customizes or specifies the honeypot configuration at the terminal. The Orchestration Component Module M5 then retrieves the required template from the template library and orchestrates it into an IaC template usable by Terraform. The required decoy resources in the cloud environment, such as the IAM credentials or storage bucket credentials to be compromised, are also generated here. The Control Terminal Module M3 simply calls Terraform to complete the deployment, and the honeypot is now present in the cloud environment.

[0058] For details, see Figure 3 , the alarm feedback module M6 specifically includes:

[0059] The decoy module M61 is used to combine storage buckets and cloud functions to generate decoy resources.

[0060] A real-time log module M62 is configured to guide an attacker to attack cloud facilities in the cloud asset graph based on the decoy resources, generate multiple attack logs, combine the multiple attack logs to obtain log report events, and send the log report events to a storage bucket for storage;

[0061] Audit module M63, configured to trigger a corresponding alarm mechanism according to a preset alarm condition, and send the log report event stored in the storage bucket to the event bus component based on the alarm mechanism;

[0062] The event bus module M64 is used to orchestrate the log report event to obtain an alarm event, and send the alarm time to the control terminal to perform a Terraform call to update the cloud facilities in the cloud asset map.

Claims

1. A cloud service honeypot generation method for active defense, characterized in that: The following steps are involved: generating a cloud asset map based on initial sweet spots and sweet spot deception scenarios obtained through simulation of real asset devices, wherein the cloud asset map has multiple cloud facilities, including but not limited to sweet spots, storage buckets, and cloud functions; When the authenticated user drags and modifies the cloud function, an updated cloud asset graph is obtained, a configuration file is exported based on the updated cloud asset graph, and a template sample is extracted from a preset honeyspot strategy template library based on the configuration file; The template samples are orchestrated to obtain multiple honeypot deployment templates that conform to corresponding cloud environments and attack paths, where the honeypot deployment templates are IaC templates available for Terraform; A plurality of IaC source code files are generated based on the IaC template, and a preset Terraform is called based on the IaC source code files to generate a plurality of honey spots.

2. The method for generating cloud service honeypots for active defense according to claim 1, characterized in that: The honey spot includes a pre-triggering condition and a consequence prediction strategy. Each pre-triggering condition corresponds to a unique honey spot transformation strategy. When an attacker triggers the pre-triggering condition, the corresponding honey spot service is transformed.

3. The method for generating cloud service honeypots for active defense according to claim 1, characterized in that: When the attacker attacks the honey spot along the attack path, when the number of alarm triggering is less than or equal to the trigger threshold, the template sample is eliminated, and the updated template sample is reselected from the preset honey spot strategy template library, and the updated honey spot is obtained based on the updated template sample.

4. The method for generating cloud service honeypots for active defense according to claim 1, characterized in that: The cloud asset graph corresponds to the currently running honeypot. During the entire honeypot operation, the assets in the cloud asset graph can be modified at any time. These modifications will be applied to the cloud infrastructure through Terraform's IaC source code changes.

5. A cloud service honeypot generation system for active defense, characterized in that: include: A cloud asset graph module is used to store and manage multiple cloud facilities and generate corresponding configuration files based on cloud facilities dragged and modified by authenticated users, where each cloud facility corresponds to a cloud service asset, and multiple cloud service assets are combined into a cloud asset graph; The honeypot and policy module is used to store multiple honeypot policy templates based on a relational database. Multiple different cloud facilities have a honeypot policy template with the same policy. A control terminal module, configured to automatically extract template samples that conform to the corresponding cloud environment and attack path from the honeyspot and policy module according to the configuration file, and generate IaC source code based on the template samples and the configuration file; A code calling module, configured to call Terraform based on the IaC source code to update the types and quantities of cloud facilities and obtain an updated cloud asset map; An orchestration component module, configured to extract a sample from the honeyspot policy template and orchestrate the sample to obtain a template sample for a specified cloud facility; The alarm feedback module is used to process events generated by cloud facilities in the cloud asset map to generate corresponding alarm events, and push the alarm events to the control terminal module.

6. The cloud service honeypot generation system for active defense according to claim 5, characterized in that: The alarm feedback module specifically includes: The decoy module is used to combine storage buckets and cloud functions to generate decoy resources; A real-time log module is configured to guide an attacker to attack cloud facilities within the cloud asset graph based on the bait resource to generate multiple attack logs, combine the multiple attack logs to obtain log report events, and send the log report events to a storage bucket for storage; An audit module, configured to trigger a corresponding alarm mechanism according to a preset alarm condition, and send the log report events stored in the storage bucket to the event bus module based on the alarm mechanism; The event bus module is used to orchestrate the log report event to obtain an alarm event, and send the alarm event to the control terminal to perform a Terraform call to update the cloud facilities in the cloud asset map.

Images