Anomalous behavior detection method and related apparatus

Abstract

An anomalous behavior detection method, which is used for improving the accuracy of anomalous behavior detection. In the anomalous behavior detection method, an event described in monitoring data is analyzed to extract entities appearing in the event and interaction behaviors executed by the entities, so as to construct a provenance graph for indicating interaction processes between the entities, and semantically abstract and classify the entities in the provenance graph. On the basis of a predefined anomalous behavior pattern, an interaction behavior that matches the anomalous behavior pattern is detected in the semantically abstracted provenance graph, such that a target behavior, the entity and behavior types of which both match the anomalous behavior pattern, can be identified, thereby realizing the detection of anomalous behaviors and ensuring the detection effect.

Description

A method and related device for detecting abnormal behavior

[0001] This application claims priority to Chinese Patent Application No. 202510125256.3, filed with the State Intellectual Property Office of China on January 26, 2025, entitled "A Method and Apparatus for Detecting Abnormal Behavior", the entire contents of which are incorporated herein by reference. Technical Field

[0002] This application relates to the field of computer security technology, and in particular to a method and related apparatus for detecting abnormal behavior. Background Technology

[0003] With the development of information technology and the widespread adoption of the internet, cyberattack methods have become increasingly complex. The detection and defense against Advanced Persistent Threat (APT) attacks have become one of the most challenging issues in the field of cybersecurity. APT attacks are typically meticulously planned by organized, targeted attackers, characterized by long attack durations, high stealth, complex attack methods, and rapid mutation. Therefore, they can deeply penetrate target systems, steal information, or cause damage over extended periods. Consequently, a highly secure system protection system is crucial to addressing APT risks.

[0004] To address the threat of APT attacks, various APT attack detection methods have been proposed. Current APT attack detection methods often require extensive collection and analysis of system information to identify attack-related anomalies.

[0005] Specifically, current APT attack detection methods often match collected system parameters with predefined rules to identify anomalous system parameters, which in turn help pinpoint the abnormal behavior causing the parameter anomalies. However, this method relies heavily on simple parameter matching, making it vulnerable to attackers modifying parameters to circumvent detection, thus affecting its effectiveness. Summary of the Invention

[0006] This application provides a method and related apparatus for detecting abnormal behavior, which can improve the detection accuracy of abnormal behavior.

[0007] Firstly, a method for detecting abnormal behavior is provided, comprising: executing a device to acquire monitoring data, wherein the monitoring data is used to indicate events that have occurred during the operation of the device. That is, the monitoring data is obtained by monitoring changes in the operation of the device and can describe some events that have occurred during the operation of the device.

[0008] Then, based on the monitoring data, the execution device constructs a source map, which is used to indicate the entities that appear in the event and the interaction behaviors between entities. That is, for each event, the execution device can semantically abstract the event as an operation performed by the execution entity on the target entity, where the operation performed by the execution entity on the target entity can be regarded as the interaction behavior between the execution entity and the target entity.

[0009] Secondly, based on semantic matching rules, the execution device transforms the first entity in the first source graph into a second entity, resulting in a second source graph. The first entity is the entity that matches the semantic matching rule, and the second entity is the semantically categorized entity of the first entity. The semantic matching rule can include one or more matching rules, and each matching rule corresponds to an entity of a certain category. That is, the execution device predefines multiple categories of entities for the semantic matching rules. If an entity in the first source graph matches a certain matching rule, it can be transformed into an entity of the category corresponding to that matching rule, thereby achieving semantic abstraction of the entity.

[0010] The execution device acquires abnormal behavior patterns, which indicate abnormal behaviors between entities. Finally, the execution device detects interaction behaviors that match the abnormal behavior patterns in the second source map to obtain the target behavior. The entity corresponding to the target behavior matches the entity corresponding to the abnormal behavior, and the target behavior matches the abnormal behavior.

[0011] In this solution, the events described in the monitoring data are analyzed to extract the entities appearing in the events and the interactive behaviors performed by these entities. This constructs a source graph indicating the interaction process between entities, and the entities in the source graph are semantically abstracted and categorized. Based on predefined abnormal behavior patterns, by detecting interactive behaviors matching the abnormal behavior patterns in the semantically abstracted source graph, the target behavior whose entity and behavior type both match the abnormal behavior pattern can be identified, thus achieving the detection of abnormal behavior and ensuring the effectiveness of the detection.

[0012] Specifically, this solution abstracts the monitored events into interactions between entities at the semantic level and constructs a source graph based on these interactions. This clearly and intuitively displays the chain of interactions between entities, facilitating matching with abnormal behavior patterns and significantly improving the accuracy of abnormal behavior detection.

[0013] In one possible implementation, the abnormal behavior pattern is used to indicate multiple abnormal behaviors, the target behaviors including multiple interaction behaviors in the source graph, and the multiple interaction behaviors are matched one-to-one with the multiple abnormal behaviors, and the entities corresponding to the multiple interaction behaviors are also matched one-to-one with the entities corresponding to the multiple abnormal behaviors.

[0014] In other words, when an abnormal behavior pattern includes multiple abnormal behaviors, the execution device needs to detect multiple interactive behaviors in the second source graph that match each of the multiple abnormal behaviors in order to consider that a corresponding abnormal behavior exists in the second source graph. If the second source graph does not contain multiple interactive behaviors that match all the abnormal behaviors indicated by a single abnormal behavior pattern, the execution device can consider that there is no abnormal behavior matching the abnormal behavior pattern in the second source graph, and therefore does not need to output any abnormal behavior.

[0015] In one possible implementation, the second source graph also records the occurrence time of interactions between entities, and the abnormal behavior pattern is used to indicate the execution sequence among multiple abnormal behaviors. That is, in the abnormal behavior pattern, there will be a specific execution sequence among multiple abnormal behaviors.

[0016] Then, the execution device detects interactive behaviors that match the abnormal behavior pattern in the second traceability graph. Specifically, it detects interactive behaviors that match multiple abnormal behaviors in terms of execution entity, target entity, behavior type, and execution sequence based on the interactive behaviors in the second traceability graph and the occurrence time of the interactive behaviors, thereby obtaining multiple interactive behaviors.

[0017] In other words, not only do multiple interactive behaviors correspond one-to-one with multiple abnormal behaviors in terms of the executing entity, target entity, and behavior type, but the execution sequence of these multiple interactive behaviors also corresponds one-to-one with the multiple abnormal behaviors.

[0018] In this solution, when multiple abnormal behaviors indicated by the abnormal behavior pattern have execution sequence requirements, the corresponding interactive behaviors also need to be detected in the second source map according to the execution sequence requirements to ensure that the interactive behaviors are detected accurately.

[0019] In one possible implementation, multiple abnormal behaviors include a first abnormal behavior and a second abnormal behavior, with the execution order of the first abnormal behavior preceding that of the second abnormal behavior.

[0020] The execution device may first detect the execution entity, target entity, and interaction behaviors whose behavior types match the first abnormal behavior in the second source graph to obtain the first interaction behavior. Then, the execution device determines candidate interaction behaviors that occur after the first interaction behavior in the second source graph. Next, the execution device detects the execution entity, target entity, and interaction behaviors whose behavior types match the second abnormal behavior among the candidate interaction behaviors to obtain the second interaction behavior. Here, multiple interaction behaviors include both the first and second interaction behaviors.

[0021] In this solution, considering that most abnormal behaviors occur in a chain, the execution device considers the execution sequence between interactive behaviors when detecting interactive behaviors in the second source map. This makes the detected abnormal behaviors more consistent with the actual attack characteristics and improves the detection accuracy of abnormal behaviors.

[0022] In one possible implementation, the abnormal behavior pattern is also used to indicate the frequency of abnormal behavior between entities, where the frequency of the target behavior matches the frequency indicated by the abnormal behavior pattern. That is, the frequency of the interaction behavior detected by the execution device needs to be greater than or equal to the frequency of the corresponding abnormal behavior.

[0023] In this solution, considering the characteristic that some abnormal behaviors occur frequently, the execution device takes into account the frequency of interaction behavior when detecting interaction behavior in the second traceability map. This makes the detected abnormal behaviors more in line with the actual scenario and more accurate, thereby improving the detection accuracy of abnormal behaviors.

[0024] In one possible implementation, the first source graph includes multiple nodes and at least one directed edge between the multiple nodes. Each of the multiple nodes is used to represent an entity that appears in the event, and the at least one directed edge is used to indicate the interaction behavior between entities. The at least one directed edge points from the source node representing the executing entity to the destination node representing the target entity.

[0025] In one possible implementation, the execution device detects interactive behaviors that match the abnormal behavior pattern in the second source graph. Specifically, this includes: matching the behavior type of the abnormal behavior with the edge type of the directed edges in the second source graph to obtain candidate directed edges that match the abnormal behavior; matching the execution entity of the abnormal behavior with the entity represented by the source node of the candidate directed edge; and matching the target entity of the abnormal behavior with the entity represented by the destination node of the candidate directed edge to obtain the target directed edge that matches the node in the candidate directed edges. The target directed edge is used to indicate the target behavior.

[0026] In one possible implementation, the entities indicated by the first source graph include at least one of threads, processes, files, libraries, sockets, and environment variables.

[0027] In one possible implementation, to acquire monitoring data, the execution device first obtains a monitoring task, which indicates the target event to be monitored. Based on a monitoring tool library, the execution device breaks down the monitoring task into multiple monitoring sub-tasks. These sub-tasks work together to monitor the target event. The monitoring tool library includes multiple monitoring tools for monitoring different events. Finally, the execution device uses the monitoring tools from the monitoring tool library to execute the multiple monitoring sub-tasks and obtain the monitoring data.

[0028] This solution breaks down monitoring tasks based on an existing monitoring tool library and uses multiple monitoring tools to collaboratively complete the resulting sub-tasks. This approach fully leverages existing resources, ensures collaborative work between different functional modules, and enables various basic monitoring tools (such as information collection components) to be uniformly scheduled and processed collaboratively. It eliminates the need to develop new monitoring tools for specific events, reducing development and maintenance costs and avoiding the introduction of new vulnerabilities and defects and the increased probability of failure due to the expansion of the attack surface.

[0029] In one possible implementation, after obtaining the target behavior, the execution device outputs an abnormal alarm message, which includes the target behavior, the execution entity corresponding to the target behavior, the target entity, and the time of occurrence.

[0030] In this solution, after detecting abnormal target behavior, the execution device outputs various auxiliary information such as entities related to the target behavior and the time of occurrence by combining the second source map. This provides security personnel with a comprehensive behavior chain and reference information, making it easier for them to quickly determine whether the currently identified abnormal behavior is an attack.

[0031] In one possible implementation, the semantic matching rules include entity matching rules and / or behavior matching rules. Based on the semantic matching rules, the first entity in the first source graph is transformed into a second entity, specifically including: in the first source graph, identifying the first entity whose interaction behavior matches the entity matching rule and / or whose interaction behavior matches the behavior matching rule; and transforming the first entity in the first source graph into a second entity to obtain the second source graph.

[0032] For example, the semantic matching rule may only include entity matching rules. In this case, the execution device may detect the first entity that matches the entity matching rule in the source graph and then transform the first entity into the second entity. Alternatively, the semantic matching rule may include both entity matching rules and behavior matching rules. In this case, the execution device needs to detect entities in the source graph whose own behavior matches the entity matching rule and whose behavior also matches the behavior matching rule, thereby detecting the aforementioned first entity.

[0033] Secondly, an abnormal behavior detection device is provided, comprising: an acquisition module for acquiring monitoring data, the monitoring data indicating events that have occurred during device operation; a processing module for constructing a first source map based on the monitoring data, the first source map indicating entities appearing in the events and the interaction behaviors between entities; the processing module is further configured to transform a first entity in the first source map into a second entity based on semantic matching rules to obtain a second source map, the first entity being an entity that matches the semantic matching rules, and the second entity being an entity semantically categorized from the first entity; the processing module is further configured to acquire an abnormal behavior pattern, the abnormal behavior pattern indicating abnormal behaviors between entities; and the processing module is further configured to detect interaction behaviors matching the abnormal behavior pattern in the second source map to obtain a target behavior, the entity corresponding to the target behavior matching the entity corresponding to the abnormal behavior, and the target behavior matching the abnormal behavior.

[0034] In one possible implementation, the abnormal behavior pattern is used to indicate multiple abnormal behaviors, the target behaviors including multiple interactive behaviors in the second source graph, and the multiple interactive behaviors are matched one-to-one with the multiple abnormal behaviors.

[0035] In one possible implementation, the second traceability graph also records the occurrence time of the interaction behavior between entities, and the abnormal behavior pattern is also used to indicate the execution sequence between multiple abnormal behaviors; the processing module is also used to: based on the interaction behavior and the occurrence time of the interaction behavior in the second traceability graph, detect the interaction behavior in which the executing entity, target entity, behavior type and execution sequence all match multiple abnormal behaviors, and obtain multiple interaction behaviors.

[0036] In one possible implementation, the multiple abnormal behaviors include a first abnormal behavior and a second abnormal behavior, wherein the execution sequence of the first abnormal behavior precedes that of the second abnormal behavior; the processing module is further configured to: detect the execution entity, the target entity, and the interaction behavior whose behavior type matches the first abnormal behavior in the second source graph to obtain the first interaction behavior; determine candidate interaction behaviors that occur after the first interaction behavior in the second source graph; detect the execution entity, the target entity, and the interaction behavior whose behavior type matches the second abnormal behavior among the candidate interaction behaviors to obtain the second interaction behavior; wherein the multiple interaction behaviors include the first interaction behavior and the second interaction behavior.

[0037] In one possible implementation, the abnormal behavior pattern is also used to indicate the frequency of abnormal behavior between entities, with the frequency of the target behavior matching the frequency indicated by the abnormal behavior pattern.

[0038] In one possible implementation, the first source graph includes multiple nodes and at least one directed edge between the multiple nodes. Each of the multiple nodes is used to represent an entity that appears in the event, and the at least one directed edge is used to indicate the interaction behavior between entities. The at least one directed edge points from the source node representing the executing entity to the destination node representing the target entity.

[0039] In one possible implementation, the processing module is further configured to: match the behavior type of the abnormal behavior with the edge type of the directed edge in the second source graph to obtain candidate directed edges that match the abnormal behavior; match the execution entity of the abnormal behavior with the entity represented by the source node of the candidate directed edge; and match the target entity of the abnormal behavior with the entity represented by the destination node of the candidate directed edge to obtain the target directed edge that matches the node in the candidate directed edges, wherein the target directed edge is used to indicate the target behavior.

[0040] In one possible implementation, the entities indicated by the first source graph include at least one of threads, processes, files, libraries, sockets, and environment variables.

[0041] In one possible implementation, the acquisition module is specifically used to: acquire a monitoring task, which indicates a target event to be monitored; based on a monitoring tool library, break down the monitoring task into multiple monitoring sub-tasks, which are used to collaboratively monitor the target event; the monitoring tool library includes multiple monitoring tools for monitoring different events; and use the monitoring tools in the monitoring tool library to execute the multiple monitoring sub-tasks to obtain monitoring data.

[0042] In one possible implementation, the semantic matching rules include entity matching rules and / or behavior matching rules. The processing module is further configured to: in the first source graph, determine a first entity whose interaction behavior matches the entity matching rule and / or is performed, and whose interaction behavior matches the behavior matching rule; and transform the first entity into a second entity in the first source graph to obtain a second source graph.

[0043] In one possible implementation, the processing module is further configured to: output abnormal alarm information, which includes the target behavior, the execution entity corresponding to the target behavior, the target entity, and the time of occurrence.

[0044] Thirdly, an anomalous behavior detection device is provided, comprising: a processor, an accelerator, and a memory; the memory is used to store computer instructions, which, when executed by the processor, cause the anomalous behavior detection device to perform the method described above.

[0045] Fourthly, a computer-readable storage medium is provided that stores instructions which, when executed on a computer, cause the computer to perform the methods of any of the above aspects.

[0046] Fifthly, a computer program product containing instructions is provided, which, when executed on a computer, enable the computer to perform the methods described above.

[0047] In a sixth aspect, a chip system is provided, the chip system including a processor and a communication interface for communicating with a module other than the chip shown, the processor for running computer programs or instructions such that an apparatus on which the chip system is mounted can perform the methods of any of the above aspects.

[0048] In a seventh aspect, a computing device is provided, which includes an abnormal behavior detection device of the third aspect or a chip system of the sixth aspect, wherein the abnormal behavior detection device or the chip system in the computing device is used to implement the operation steps of the method of any of the above aspects.

[0049] Eighthly, a computing device cluster is provided, comprising at least one computing device, wherein any one computing device is used to run a computer program or instructions, such that the computing device cluster can perform the methods of any of the above aspects. Alternatively, some or all of the computing devices are used together to run a computer program or instructions, such that the computing device cluster can perform the methods of any of the above aspects.

[0050] Based on the implementation methods provided in the above aspects, this application can be further combined to provide more implementation methods. Attached Figure Description

[0051] Figure 1 is a schematic diagram of a system architecture provided in this application;

[0052] Figure 2 is a flowchart illustrating an abnormal behavior detection method provided in this application;

[0053] Figure 3 is a schematic diagram of a traceability diagram provided in this application;

[0054] Figure 4 is a schematic diagram of a system architecture provided in this application;

[0055] Figure 5 is a schematic diagram of the specific deployment of a system architecture provided in this application;

[0056] Figure 6 is a flowchart illustrating an abnormal behavior identification method provided in this application;

[0057] Figure 7 is a schematic diagram of a monitoring task being decomposed into multiple monitoring sub-tasks according to this application;

[0058] Figure 8 is a schematic diagram of detecting abnormal behavior in a source map provided in this application;

[0059] Figure 9 is a schematic diagram of the structure of an abnormal behavior detection device provided in this application;

[0060] Figure 10 is a schematic diagram of the structure of a computing device provided in this application;

[0061] Figure 11 is a schematic diagram of the structure of a computing device cluster provided in this application;

[0062] Figure 12 is a schematic diagram of another computing device cluster provided in this application;

[0063] Figure 13 is a schematic diagram of the structure of a computer-readable storage medium provided in this application. Detailed Implementation

[0064] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application are described below with reference to the accompanying drawings. Obviously, the described embodiments are merely some, and not all, of the embodiments of this application. Those skilled in the art will recognize that, with the emergence of new application scenarios, the technical solutions provided by this application are also applicable to similar technical problems.

[0065] The terms "first," "second," etc., used 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 descriptions can be used interchangeably where appropriate to allow embodiments to be implemented in a sequence other than that illustrated or described in this application. 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 device that includes a series of steps or modules is not necessarily limited to those explicitly listed, but may include other steps or modules not explicitly listed or inherent to such processes, methods, products, or devices. The naming or numbering of steps appearing in this application does not imply that the steps in the method flow must be performed in the chronological / logical order indicated by the naming or numbering. The execution order of named or numbered process steps can be changed according to the desired technical purpose, as long as the same or similar technical effect is achieved. The division of units in this application is a logical division. In practical applications, there may be other division methods. For example, multiple units may be combined or integrated into another system, or some features may be ignored or not executed. In addition, the shown or discussed mutual coupling, direct coupling, or communication connection may be through some interface, and the indirect coupling or communication connection between units may be electrical or other similar forms, none of which are limited in this application. Furthermore, the units or sub-units described as separate components may or may not be physically separated, may or may not be physical units, or may be distributed among multiple circuit units. Some or all of the units can be selected to achieve the purpose of the solution in this application according to actual needs.

[0066] Please refer to Figure 1, which is a schematic diagram of a system architecture provided in this application. As shown in Figure 1, in this system architecture, the execution device 10 can be implemented by one physical host (computing device) or multiple physical hosts (computing device cluster). The execution device is used to execute the abnormal behavior detection method provided in this application to determine abnormal behavior. Optionally, the execution device 10 cooperates with other computing devices, such as data storage devices, load balancers, etc.; the execution device 10 can be deployed on one physical site or distributed across multiple physical sites.

[0067] In addition, the system architecture includes a data storage system 11, which stores monitoring data or program code, among other data. Optionally, for persistent data storage, the data storage system 11 can be located external to the execution device 10 and exchange data with it via a network. Optionally, if the execution device 10 is a physical host, the data storage system 11 can also be located internally, such as exchanging data with the processor via a bus. In this case, the data storage system 11 functions as a hard disk. With the data storage system 11, the execution device 10 can use the data (such as monitoring data) in the data storage system 11 or call the program code in the data storage system to implement the abnormal behavior detection method provided in this application.

[0068] Optionally, users can interact with execution device 10 using their own devices. For example, a client is deployed on user device 12, and users interact with the execution device through the client on user device 12 to receive feedback from execution device 10 on various abnormal behaviors. User device 12 can represent any computing device, such as a personal computer, computer workstation, smartphone, tablet, laptop, or smart car.

[0069] User equipment 12 can interact with execution device 10 through a communication network of any communication mechanism / standard. The communication network can be a wide area network, a local area network, a point-to-point connection, or any combination thereof.

[0070] Optionally, during the process of implementing the abnormal behavior detection method by the execution device 10, the user device 12 can provide the execution device 10 with a monitoring task so that the execution device 10 can obtain monitoring data based on the monitoring task.

[0071] Please refer to Figure 2, which is a flowchart illustrating an abnormal behavior detection method provided in this application. As shown in Figure 2, the flowchart of this abnormal behavior detection method includes the following steps 201-205.

[0072] Step 201: Obtain monitoring data. The monitoring data is used to indicate events that have occurred during the operation of the equipment.

[0073] In this application, the execution device can acquire pre-collected monitoring data regarding the device's operation. This monitoring data is obtained by monitoring changes in the device's operation and describes events that have occurred during its operation. Specifically, the monitoring data can be obtained from monitoring the execution device itself or from monitoring other devices (such as network devices like servers, computers, switches, or routers). When the monitoring data is obtained from monitoring the execution device itself, the execution device detects its own abnormal behavior; when the monitoring data is obtained from monitoring other devices, the execution device detects the abnormal behavior of those other devices. This application does not specifically limit the scope of this application.

[0074] Furthermore, the monitoring data can be presented in the form of logs. Thus, the executing device can obtain the aforementioned monitoring data by retrieving logs from a centralized log management system during device operation. Moreover, the monitoring data can include one or more logs, and each log can describe one or more events that have occurred. That is, the monitoring data can be used to indicate one or more events that have occurred during device operation; this application does not specifically limit the number of events indicated by the monitoring data.

[0075] Specifically, when the execution device acquires monitoring data by monitoring its own operation, it can do so by monitoring its own operational process based on monitoring tasks issued by the user. For example, the execution device can use existing monitoring tools in the system (such as tools for collecting system information) to monitor various events and obtain monitoring data.

[0076] Optionally, if the execution device cannot directly complete a single monitoring task using an existing monitoring tool, the execution device can break down the monitoring task into multiple monitoring sub-tasks that can be completed using multiple monitoring tools.

[0077] For example, to obtain monitoring data, the executing device may first acquire a monitoring task and a monitoring tool library. The monitoring task is used to indicate the target event to be monitored. The monitoring tool library includes multiple monitoring tools for monitoring different events. Furthermore, no single monitoring tool in the monitoring tool library can directly perform the monitoring of the target event.

[0078] Then, based on the monitoring tools included in the monitoring toolkit, the execution device breaks down the monitoring task into multiple monitoring sub-tasks. These sub-tasks work together to monitor the target event. In other words, by executing multiple sub-tasks, the target event can be monitored.

[0079] In this way, the execution device can use the monitoring tools in the monitoring tool library to perform multiple monitoring sub-tasks, thereby obtaining monitoring data.

[0080] This solution breaks down monitoring tasks based on an existing monitoring tool library and uses multiple monitoring tools to collaboratively complete the resulting sub-tasks. This approach fully leverages existing resources, ensures collaborative work between different functional modules, and enables various basic monitoring tools (such as information collection components) to be uniformly scheduled and processed collaboratively. It eliminates the need to develop new monitoring tools for specific events, reducing development and maintenance costs and avoiding the introduction of new vulnerabilities and defects and the increased probability of failure due to the expansion of the attack surface.

[0081] Step 202: Based on the monitoring data, construct a first source map. The first source map is used to indicate the entities that appear in the event and the interaction behaviors between entities.

[0082] After acquiring the monitoring data, the execution device can analyze the events described in the monitoring data to extract the corresponding entities and the interaction behaviors between entities for each event. Specifically, for each event, the execution device can semantically abstract the event as an operation performed by the execution entity on the target entity. This operation can be considered as the interaction behavior between the execution entity and the target entity. Both the execution entity and the target entity are entities appearing in the event, with the execution entity being the entity that actively performs the interaction behavior, and the target entity being the interaction object when the execution entity performs the interaction behavior. Optionally, the entities indicated in the first source diagram may include at least one of the following: thread, process, file, library, socket, and environment variable. Of course, the entities indicated in the first source diagram can also be other entities, without specific limitations.

[0083] For example, suppose the event is that process A gains permission to read and modify file A. Then process A is the executing entity, file A is the target entity, and the interaction between the executing entity and the target entity is the modification permission. As another example, suppose the event is that process B accesses website B. Then process B is the executing entity, website B is the target entity, and the interaction between the executing entity and the target entity is accessing the external network.

[0084] Optionally, since an event can be abstracted as an interaction between two entities, the execution device can use nodes to represent entities and directed edges between nodes to represent interaction when constructing the first traceability graph, thereby realizing the construction of the first traceability graph based on events.

[0085] For example, the first source graph may include multiple nodes and at least one directed edge between the multiple nodes. Each of the multiple nodes represents an entity appearing in the event, and the at least one directed edge indicates the interaction behavior between entities. The at least one directed edge points from the source node representing the executing entity to the destination node representing the target entity.

[0086] In other words, an event can be represented by two nodes and a directed edge between them. The execution entity in the event is represented by the source node, and the target entity in the event is represented by the destination node, with the directed edge pointing from the source node to the destination node.

[0087] Please refer to Figure 3, which is a schematic diagram of a source graph provided in this application. As shown in Figure 3, the source graph includes nodes 1-4 and directed edges 1-3. Directed edge 1 points from node 1 to node 2. Node 1 represents process A, node 2 represents process B, and directed edge 1 represents process startup. Therefore, node 1, node 2, and directed edge 1 are used to jointly represent process A starting process B. Similarly, directed edge 2 points from node 2 to node 3. Node 3 represents file B, and directed edge 2 represents modifying file permissions. Therefore, node 2, node 3, and directed edge 2 are used to jointly represent the permissions of process B to start file B. Directed edge 3 points from node 2 to node 4. Node 4 represents website B, and directed edge 3 represents accessing the network. Therefore, node 2, node 4, and directed edge 3 are used to jointly represent process B accessing website B.

[0088] It should be noted that Figure 3 above is a simplified example of a source graph. A real source graph may include more nodes and directed edges, and a node may connect to multiple directed edges. In practical applications, the monitoring data acquired by the execution device may include a large number of events. In this case, the execution device needs to determine the entities in each event and the interaction behaviors between entities, and use the same entity to represent the entities appearing in different events, in order to achieve a unified representation of entities.

[0089] Step 203: Based on the semantic matching rules, the first entity in the first source graph is transformed into the second entity to obtain the second source graph. The first entity is the entity that matches the semantic matching rules, and the second entity is the entity that the first entity is semantically categorized.

[0090] The semantic matching rule can include one or more matching rules, and each matching rule corresponds to an entity of a certain category. That is, the execution device predefines multiple categories of entities for the semantic matching rule. If an entity in the first source graph matches a certain matching rule, the entity can be transformed into an entity of the category corresponding to that matching rule, thereby realizing the semantic abstraction of the entity.

[0091] For example, semantic matching rules include entity matching rules and / or behavior matching rules. Based on semantic matching rules, transforming a first entity in the first source graph into a second entity specifically includes: in the first source graph, identifying a first entity whose interaction behavior matches the entity matching rule and / or whose interaction behavior matches the behavior matching rule; and transforming the first entity in the first source graph into a second entity to obtain a second source graph.

[0092] For example, the semantic matching rule may only include entity matching rules. In this case, the execution device may detect the first entity that matches the entity matching rule in the source graph and then transform the first entity into the second entity. Alternatively, the semantic matching rule may include both entity matching rules and behavior matching rules. In this case, the execution device needs to detect entities in the source graph whose own behavior matches the entity matching rule and whose behavior also matches the behavior matching rule, thereby detecting the aforementioned first entity.

[0093] Understandably, in practical applications, when most applications or components exhibit abnormal behavior, they typically first launch some regular processes (such as Java processes) or other lower-level execution entities, which then perform the corresponding actions. Therefore, this solution first abstracts the entities in the first source graph semantically based on semantic matching rules, thereby abstracting the lower-level execution entities into entities under specific categories, which helps to quickly detect abnormal behavior subsequently.

[0094] For example, in the first source graph, the Java process (first entity) starts the bash process. However, at the abstraction level, based on semantic matching rules, it can be identified that the Java process semantically belongs to the Log4J Java library (second entity), so the Java process can be transformed into Log4J.

[0095] Step 204: Obtain the abnormal behavior pattern, which is used to indicate abnormal behavior between entities.

[0096] In this application, the abnormal behavior patterns acquired by the execution device can be pre-generated. For example, the abnormal behavior patterns can be defined by the user based on expert experience or previous attack cases; the abnormal behavior patterns can also be generated in advance by analyzing previous attack cases through artificial intelligence models. The execution device can acquire one or more abnormal behavior patterns, and each abnormal behavior pattern can be used to indicate abnormal behavior among a group of entities, that is, it can be used to indicate one or more abnormal behaviors.

[0097] For example, an abnormal behavior pattern could specifically instruct a process to modify the permissions of a file. Or, an abnormal behavior pattern could instruct a process to access a website.

[0098] Step 205: Detect the interaction behavior that matches the abnormal behavior pattern in the second source map to obtain the target behavior. The entity corresponding to the target behavior matches the entity corresponding to the abnormal behavior, and the target behavior matches the abnormal behavior.

[0099] Since the second source map indicates the interaction behavior between various entities, and the abnormal behavior pattern indicates the specific abnormal behavior between entities, the execution device can detect whether there is an interaction behavior that matches the abnormal behavior pattern in the source map, and then obtain the target behavior that matches the abnormal behavior pattern.

[0100] Specifically, when detecting interactive behavior in the second source map, it is necessary to detect interactive behaviors where the executing entity, target entity, and interactive behavior all match the abnormal behavior indicated by the abnormal behavior pattern. Therefore, the target behavior ultimately detected by the execution device matches the abnormal behavior indicated by the abnormal behavior pattern, and the entities corresponding to the target behavior (i.e., the executing entity and the target entity) also match the entities corresponding to the abnormal behavior. For example, suppose the abnormal behavior pattern indicates that process XX has the permission to modify file XX, and the second source map indicates that process A has the permission to modify file A. If process A matches process XX, file A matches file XX, and the modification permission indicated by the second source map is the same as the modification permission indicated by the abnormal behavior pattern, then it can be determined that process A's modification permission of file A is the target behavior.

[0101] Furthermore, since the second source graph represents entities as nodes and interaction behaviors as directed edges, when performing abnormal behavior detection in the second source graph, the directed edges in the second source graph can be matched with the abnormal behaviors, and the nodes connected by the directed edges can be matched with entities related to the abnormal behaviors, so as to achieve abnormal behavior detection.

[0102] For example, when detecting abnormal behavior in the second source graph, the execution device can match the behavior type of the abnormal behavior with the edge type of the directed edges in the second source graph to obtain candidate directed edges that match the abnormal behavior. The edge type of the directed edges in the second source graph indicates the type of interaction behavior represented by the directed edge. The candidate directed edges that match the abnormal behavior may include one or more directed edges.

[0103] Then, the execution device can match the execution entity of the abnormal behavior with the entity represented by the source node of the candidate directed edge, and match the target entity of the abnormal behavior with the entity represented by the destination node of the candidate directed edge. From the candidate directed edges, the target directed edge that matches the node is obtained, and the target directed edge is used to indicate the target behavior. That is, for each candidate directed edge, the execution device checks whether the entity represented by the node connected to the candidate directed edge matches the entity corresponding to the abnormal behavior, thereby determining the target behavior.

[0104] The above example illustrates the process by which the execution device first performs directed edge matching to obtain candidate directed edges, and then performs node matching on these candidate directed edges to detect the target behavior. In practical applications, the execution device may also perform node matching first, followed by directed edge matching; or, the execution device may perform node and directed edge matching simultaneously. This application does not impose a specific limitation on the matching order.

[0105] Understandably, in most attack scenarios, an attacker's attack often consists of a series of abnormal behaviors to gradually achieve their objective. That is, the attacker achieves their goal by combining a series of actions, and a single action or part of that action, when occurring alone, is usually not considered abnormal. Therefore, in most scenarios, the aforementioned abnormal behavior pattern can also be composed of a series of abnormal behaviors.

[0106] For example, the aforementioned abnormal behavior pattern can be used to indicate multiple abnormal behaviors. Therefore, the target behavior detected based on the abnormal behavior pattern also includes multiple interactive behaviors in the second source graph, and each interactive behavior is matched one-to-one with each of the multiple abnormal behaviors; similarly, the entities corresponding to the multiple interactive behaviors are also matched one-to-one with the entities corresponding to the multiple abnormal behaviors.

[0107] In other words, when an abnormal behavior pattern includes multiple abnormal behaviors, the execution device needs to detect multiple interactive behaviors in the second source graph that match each of the multiple abnormal behaviors in order to consider that a corresponding abnormal behavior exists in the second source graph. If the second source graph does not contain multiple interactive behaviors that match all the abnormal behaviors indicated by a single abnormal behavior pattern, the execution device can consider that there is no abnormal behavior matching the abnormal behavior pattern in the second source graph, and therefore does not need to output any abnormal behavior.

[0108] Optionally, in some embodiments, the second source map also records the occurrence time of interactions between entities, and the abnormal behavior pattern is also used to indicate the execution sequence between multiple abnormal behaviors. That is, in the abnormal behavior pattern, there is a specific execution sequence between multiple abnormal behaviors. For example, multiple abnormal behaviors are executed sequentially, and a chain reaction is only triggered when these multiple abnormal behaviors are executed sequentially, thus achieving the attack objective.

[0109] Therefore, when the execution device detects interaction behaviors matching abnormal behavior patterns in the second source map, it can detect interaction behaviors whose execution entity, target entity, behavior type, and execution sequence all match multiple abnormal behaviors based on the interaction behaviors and their occurrence times in the second source map, thus obtaining multiple interaction behaviors. In other words, multiple interaction behaviors not only correspond one-to-one with multiple abnormal behaviors in terms of execution entity, target entity, and behavior type, but also their execution sequence corresponds one-to-one with multiple abnormal behaviors.

[0110] In summary, when multiple abnormal behaviors indicated by the abnormal behavior pattern have execution sequence requirements, the corresponding interactive behaviors also need to be detected in the second source graph according to the execution sequence requirements to ensure that the interactive behaviors are detected accurately.

[0111] For example, suppose that multiple abnormal behaviors include a first abnormal behavior and a second abnormal behavior, and the execution sequence of the first abnormal behavior precedes that of the second abnormal behavior. That is, the first abnormal behavior is executed before the second abnormal behavior.

[0112] When the execution device detects interactive behavior in the second traceability diagram, it can first detect the execution entity, the target entity, and interactive behavior whose behavior type matches the first abnormal behavior in the second traceability diagram to obtain the first interactive behavior.

[0113] Then, the execution device determines candidate interaction behaviors that occur after the first interaction behavior in the second traceability diagram. These candidate interaction behaviors may include one or more interaction behaviors.

[0114] Furthermore, the execution device continues to detect the execution entity, the target entity, and the interaction behavior whose behavior type matches the second abnormal behavior among the candidate interaction behaviors, thus obtaining the second interaction behavior. The multiple interaction behaviors among the aforementioned target behaviors include the first interaction behavior and the second interaction behavior.

[0115] In other words, when multiple abnormal behaviors indicated by the abnormal behavior pattern have an execution sequence, the execution device can sequentially detect the interactive behaviors that match each abnormal behavior in the second source map according to the execution sequence of the multiple abnormal behaviors, so as to ensure that the finally detected target behavior can meet the execution sequence requirements of the abnormal behavior pattern.

[0116] It should be noted that the above explanation is based on the example of an abnormal behavior pattern including the first and second abnormal behaviors. In practical applications, an abnormal behavior pattern can include more abnormal behaviors, and this application does not make any specific limitation on this.

[0117] For example, suppose the abnormal behavior pattern specifically indicates that: program XX starts program YY, then program YY modifies the permissions of file XX, and then program YY continues to access website XX; then, when detecting based on this abnormal behavior pattern in the second source graph, it is also necessary to ensure that the multiple interactive behaviors detected meet the execution sequence requirements of the abnormal behavior pattern. Taking Figure 3 as an example, suppose directed edge 1 corresponds to occurrence time 1, directed edge 2 corresponds to occurrence time 2, and directed edge 3 corresponds to occurrence time 3, and occurrence time 1 is before occurrence time 2, and occurrence time 2 is before occurrence time 3. Then, the execution entity, target entity, behavior type, and execution sequence corresponding to the multiple interactive behaviors shown in Figure 3 all match the multiple abnormal behaviors. Therefore, it can be determined that the interactive behavior represented by directed edge 1-directed edge 3 in Figure 3 is the target behavior.

[0118] In this solution, considering that most abnormal behaviors occur in a chain, the execution device considers the execution sequence between interactive behaviors when detecting interactive behaviors in the second source map. This makes the detected abnormal behaviors more consistent with the actual attack characteristics and improves the detection accuracy of abnormal behaviors.

[0119] Optionally, in addition to the execution sequence between abnormal behaviors, the abnormal behavior pattern can also be used to indicate the frequency of occurrence of abnormal behaviors between entities. Furthermore, the frequency of occurrence of the target behavior detected based on the abnormal behavior pattern matches the frequency of occurrence indicated by the abnormal behavior pattern.

[0120] That is, each of the one or more abnormal behaviors indicated in the abnormal behavior pattern has a corresponding occurrence frequency, i.e., the number of times the abnormal behavior occurs within a fixed time period. With the occurrence time of each interaction recorded in the second source map, the execution device can also calculate the occurrence frequency of the same type of interaction between the same two entities. Thus, when the execution device detects an interaction matching the abnormal behavior pattern in the second source map, it can detect an interaction whose occurrence frequency also matches the occurrence frequency of the abnormal behavior. In other words, the occurrence frequency of the interaction detected by the execution device needs to be greater than or equal to the occurrence frequency of the corresponding abnormal behavior.

[0121] For example, suppose the abnormal behavior pattern indicates that a program attempts to log in to the management backend using a username and password, and this occurs 20 times within 10 seconds. Then, when the execution device detects target behavior in the second traceability diagram, it needs to detect program attempts to log in to the management backend that occur 20 times or more within 10 seconds.

[0122] In this solution, considering the characteristic that some abnormal behaviors occur frequently, the execution device takes into account the frequency of interaction behavior when detecting interaction behavior in the second traceability map. This makes the detected abnormal behaviors more in line with the actual scenario and more accurate, thereby improving the detection accuracy of abnormal behaviors.

[0123] The above describes the process by which the execution device obtains the abnormal target behavior by detecting interaction behaviors that match the abnormal behavior pattern in the second traceability graph.

[0124] In some embodiments, to facilitate timely alerting of security personnel to handle abnormal behavior, the execution device may output an anomaly alarm message after receiving the target behavior. This alarm message includes the target behavior, the corresponding execution entity, the target entity, and the time of occurrence. Of course, the alarm message may also include other relevant information such as the frequency of occurrence of the target behavior.

[0125] In this solution, after detecting abnormal target behavior, the execution device outputs various auxiliary information such as entities related to the target behavior and the time of occurrence by combining the second source map. This provides security personnel with a comprehensive behavior chain and reference information, making it easier for them to quickly determine whether the currently identified abnormal behavior is an attack.

[0126] The above describes the workflow of the abnormal behavior detection method provided in this application. For ease of understanding, the following will detail the execution process of this abnormal behavior detection method in practical applications, using specific examples.

[0127] Please refer to Figures 4 and 5. Figure 4 is a schematic diagram of a system architecture provided in this application; Figure 5 is a schematic diagram of the specific deployment of a system architecture provided in this application. As shown in Figure 4, the system architecture includes a software layer and a hardware layer. The software layer includes the following software modules: cloud situational awareness service, operating system (OS) security monitor, resource consumption collector, account management collector, process management collector, file operation collector, and system information collection module.

[0128] Among these, the cloud-based situational awareness service can provide global attack detection capabilities. The OS security monitor is used to decompose, distribute, and coordinate event tasks, improving overall monitoring capabilities. Resource consumption data collectors collect system resource consumption data, account management data collectors collect account management data, process management data collectors collect process management data, and file operation data collectors collect file operation data. The system information collection module can specifically utilize mechanisms such as proc, auditd, ebpf, and ko to collect system status information, system audit logs, kernel events, and kernel module monitoring information from different levels.

[0129] The hardware layer specifically includes general-purpose hardware, tracer hardware, and input / output (I / O) management hardware. General-purpose hardware includes a central processing unit (CPU), memory, hard disks, basic network devices, and standard I / O interfaces. Tracer hardware includes hardware tracers, performance counters, and debug interfaces. I / O management hardware is used to implement device management and control, I / O channel scheduling, and data transfer buffering.

[0130] The collaboration between the software and hardware layers is as follows: The OS security monitor schedules and assigns tasks to various data collectors in the system. Each data collector uses the system information collection mechanism to collect system operating status and security-related data from the hardware layer. The Tracer hardware works with the performance data collector to record and analyze hardware performance indicators and abnormal events. The I / O management hardware interacts and exchanges information with other hardware in conjunction with the operating system.

[0131] As shown in Figure 5, the cloud situational awareness service can be deployed on a cloud server and interact with various edge devices to obtain data such as logs or source maps submitted by the edge devices. Furthermore, the cloud situational awareness service can achieve global anomaly detection by training a deep learning model, providing global source attack detection capabilities and enabling attack detection across the entire cluster (i.e., all edge devices interacting with the cloud server). The edge devices can be, for example, the execution devices mentioned above.

[0132] The software layer in the edge device can specifically include a data analysis engine and a log collection engine. The data analysis engine is responsible for analyzing complex monitoring tasks and decomposing them into a task queue consisting of numerous monitoring subtasks. Furthermore, the data analysis engine is responsible for integrating and processing log data to construct a source graph, which facilitates semantic analysis and edge anomaly detection. The log collection engine is responsible for hardware-assisted information collection, kernel-mode information collection, and user-mode information collection.

[0133] Please refer to Figure 6, which is a schematic diagram of a process for identifying abnormal behavior provided in this application. As shown in Figure 6, the process for identifying abnormal behavior includes the following steps S1-S4.

[0134] Step S1: Monitor the decomposition and distribution of tasks.

[0135] In step S1, the edge device can obtain monitoring tasks based on the requirements of the global source tracing analysis service and determine the applicability and complexity of the monitoring task. For complex monitoring tasks that cannot be directly implemented by the basic information collector, they are decomposed into multiple monitoring sub-tasks, and these sub-tasks are assigned to the existing collectors in the system (such as the resource consumption collector, account management collector, process management collector, and file operation collector mentioned above). Each collector can aggregate all monitoring tasks or monitoring sub-tasks into a unified collection queue, thereby ensuring the uniformity of the underlying implementation and deployment of monitoring capabilities.

[0136] By breaking down and distributing complex monitoring tasks, the advantages of existing resources can be fully utilized, ensuring collaborative work between different functional modules and enabling unified scheduling and coordinated processing of various basic information collection components. This process not only reduces development and maintenance costs but also avoids the introduction of new vulnerabilities and defects and the increased probability of failures due to the expansion of the attack surface.

[0137] Specifically, the execution process of step S1 may include the following steps S11-S13.

[0138] S11, Distribution of monitoring tasks.

[0139] Specifically, based on the needs of the global source tracing and analysis service, the cloud server first distributes various monitoring tasks to various end devices to collect monitoring data from some end devices.

[0140] S12, Decomposition of complex monitoring tasks and coordination of monitoring tools.

[0141] For each acquired monitoring task, the edge device can match the monitoring capabilities of existing monitoring tools (i.e., various data collectors) with the monitoring task. If the monitoring task matches an existing monitoring tool (i.e., the monitoring tool can directly perform the monitoring task), the edge device can assign the monitoring task to the monitoring tool. If the monitoring task cannot match an existing monitoring tool (i.e., the monitoring tool cannot directly perform the monitoring task), the edge device decomposes the monitoring task into multiple monitoring sub-tasks adaptable to the existing monitoring tools, and then distributes these multiple monitoring sub-tasks to various monitoring tools for collaborative data collection. Furthermore, the edge device indirectly achieves the monitoring task by comprehensively analyzing the data collected by each collaborative monitoring tool.

[0142] S13, Development and supplementation of monitoring capabilities.

[0143] In addition, if a monitoring task cannot be accomplished through task decomposition, one can consider developing a dedicated monitoring tool to further enhance its capabilities.

[0144] Step S2: Summarize and process the monitoring data.

[0145] In step S2, the executing device can acquire the monitoring data collected during the monitoring task in step S1, and construct a source tracing map by summarizing and processing the monitoring data. Specifically, step S2 may include the following steps S21-S22.

[0146] S21, Log parsing.

[0147] Specifically, the monitoring data collected by the monitoring tool can be stored in the form of logs. Therefore, the process of processing the monitoring data by the edge device can involve parsing all logs related to the monitoring data to identify the events described in the logs, thereby determining the entities included in the events and the interaction behaviors between entities. Entities can typically include threads, processes, files, libraries, sockets (network resources), and environment variables, while interaction behaviors can include reading and writing files, modifying file permissions, modifying variables, and accessing the network.

[0148] S22, Source tracing graph construction.

[0149] By aligning identical entities obtained from the analysis logs and based on the interaction behavior between entities, the edge device can construct a directed acyclic graph as a source graph.

[0150] Step S3: Semantic-level abstraction of monitoring information.

[0151] First, the edge device can construct semantic abstraction rules based on the source graph built in step S2. In constructing these rules, not only are the matching rules for the inherent attributes of entities (such as filenames and process IDs) precisely defined, but adjacency attribute association analysis is also innovatively introduced. Specifically, by deeply mining and matching the attributes of the entity's adjacent nodes (i.e., nodes representing the target entity) (such as the libraries called and network resources accessed) and the interaction pattern attributes between nodes (such as the type, time, and frequency of interaction behavior), a more comprehensive and refined set of semantic abstraction rules is constructed. By introducing adjacency attribute association analysis, the limitations of traditional methods that only focus on single entity attributes can be overcome, providing a deeper perspective on abstract semantics. This enables a comprehensive consideration of entity relationships and contextual information, significantly improving the accuracy and comprehensiveness of log analysis.

[0152] Secondly, edge devices can perform deep understanding and matching of source maps. Based on the constructed semantic abstraction rule system, deep semantic analysis and multi-dimensional matching of malicious entities and suspicious behaviors are performed on the source map. That is, edge devices can accurately locate potential attackers and suspicious behaviors through attribute feature recognition at the entity level and association pattern analysis at the interaction level.

[0153] Specifically, step S3 may include the following steps S31-S32.

[0154] S31, Construction of semantic abstraction rules based on adjacency attribute analysis.

[0155] Specifically, edge devices can construct templates for semantic abstraction, where the templates include the determination of entity attributes and their matching methods. The process of semantic abstraction rules for edge devices can include the following four stages.

[0156] Phase 1: Identify inherent attributes. That is, the edge device can first identify the inherent attributes of the entity, including key features such as file name and process ID.

[0157] Phase 2: Define the matching method. That is, for the identified inherent attributes, the edge device can define detailed matching methods. For entity attributes requiring only simple matching, text comparison is sufficient; for entity attributes with diverse common patterns, regular expression matching can be used.

[0158] Phase 3: Construction of Adjacent Node Attributes and Interaction Pattern Attributes, and Their Matching Methods. First, the attributes of adjacent nodes can be repeated from Phase 1 and Phase 2 to define their attribute matching methods.

[0159] For interaction pattern attribute matching, two main aspects are considered: the type of interaction behavior and the interaction characteristics. Specifically, the edge device can construct different matching methods for different interaction behavior types. For example, for called libraries, regular expressions can be defined to match information such as version number, imported function name, and loading time; for accessed network resources, information such as Uniform Resource Locator (URL), access frequency, and data transfer volume can be recorded; for process relationships, attributes such as creation time, command-line arguments, and permission level can be matched. For interaction characteristics, the edge device can define the matching method for the interaction order, frequency, and time window between each node representing the execution entity and its adjacent nodes.

[0160] Finally, the edge device constructs a semantic abstraction rule set. That is, for common entities and interaction behaviors, the edge device can construct a semantic abstraction rule set based on the above template rules.

[0161] S32, Deep matching and understanding of monitoring information based on semantic abstraction rules.

[0162] Specifically, edge devices can obtain structured data containing various entities and their interactions from the constructed source map. This structured data includes the inherent attributes of entities (such as process ID, file path, etc.) and the attributes of interactions (such as the type, timing, and frequency of interactions). This structured data provides the foundation for subsequent semantic matching and behavior recognition.

[0163] Then, the edge device uses a semantic matching algorithm to match the acquired entities and their interactions with predefined malicious entities and suspicious behaviors to initially identify suspicious behaviors in the source map. Specifically, the matching process is divided into two levels: 1. Entity attribute matching, which matches the inherent attributes of the executing entity (such as process ID, file path, etc.) and the relevant attributes of adjacent entities (i.e., the target entity), checking whether these attributes match known semantic rules of malicious subjects; 2. Interaction pattern matching, which further analyzes the interaction behavior between the executing entity and the target entity to determine whether these interaction behaviors match the suspicious behaviors defined in the malicious behavior rules (such as abnormally frequent network connections, specific file access patterns, etc.).

[0164] Step S4, Abnormal behavior identification.

[0165] Specifically, based on preset abnormal behavior patterns, the edge device can further perform time-series-level behavior chain iterative tracing based on the malicious subjects and suspicious behaviors identified in step S3, as well as their interaction relationships. If the edge device identifies multiple interactive behaviors in the source map that match the preset abnormal behavior patterns, it can mark them as potential attack events (i.e., the aforementioned target behaviors). In this way, by capturing the complex associations and interactions between the behavioral subjects and the behaviors they initiate, a deeper understanding of the background and semantics of the behaviors can be achieved. Through semantic association analysis and context awareness, the problems of insufficient event association and shallow semantic understanding in traditional detection can be effectively solved, significantly improving the accuracy of abnormal behavior detection, reducing the false alarm rate, and enhancing the ability to identify complex attacks.

[0166] Specifically, step S4 may include step S41. Step S41 is for abnormal behavior detection based on abstract semantic pattern matching, and specifically includes the following three steps.

[0167] 1. Timing Matching: Based on the malicious entities and suspicious behaviors identified in step S3, the system further matches behavioral patterns in the time sequence of suspicious behaviors to identify whether consecutive behavioral chains conform to preset abnormal behavior patterns, such as the startup of a main program, file access, and network connection in a specific order. Once the entity attributes, the type and timing of the interaction behavior all meet the rule conditions, the edge device can determine that these behaviors conform to the abnormal behavior pattern.

[0168] 2. Anomaly Marking: When the edge device detects a target behavior that matches an abnormal behavior pattern, it marks the target behavior as a potential anomaly. During the marking process, the edge device also attaches detailed information about the target behavior, such as the specific attributes of the target behavior, the subjects involved, the interaction relationships, and the timing characteristics, to facilitate subsequent analysis.

[0169] 3. Output Phase: The edge device records the target behaviors marked as potentially abnormal and generates a report for subsequent review and processing. The output report not only includes the detected target behaviors but also detailed semantic information about those behaviors, such as the specific pattern matching results of the anomalies, behavior chain analysis, timestamps and frequencies of the abnormal behaviors, providing comprehensive reference information for security personnel.

[0170] To facilitate understanding, the following will use specific cases to explain in detail how to break down monitoring tasks and identify abnormal behavior based on source maps.

[0171] Please refer to Figure 7, which is a schematic diagram of a monitoring task decomposed into multiple monitoring subtasks according to this application. As shown in Figure 7, taking the attack behavior of privilege escalation (i.e., raising privileges from user privileges to administrator privileges) using environment variables as an example, a monitoring task can be issued to monitor this attack behavior. This monitoring task is specifically "reading environment variables". Since the reading and parsing of environment variables is completed through the built-in functions of the shell terminal, it usually does not trigger system calls, so traditional monitoring tools have difficulty capturing this type of behavior. However, environment variable operations are very common in actual attacks. Based on this, the terminal device can decompose the monitoring task for environment variables into four monitoring subtasks and process them through a process-oriented method.

[0172] First, the initial monitoring subtask involves reading system variables: periodically scanning and recording the current system's environment variable key-value pairs. Executing this first monitoring subtask ensures a comprehensive understanding of the dynamic changes in system environment variables.

[0173] Secondly, the second monitoring subtask is command line operation monitoring: Since the modification of environment variables is usually achieved through the command line (for example, attackers achieve a reverse shell through remote arbitrary code execution vulnerabilities), it is necessary to capture the history of executed command lines to help record all command lines that may involve environment variable operations.

[0174] Next, the third monitoring subtask is variable matching: using existing text matching tools, check whether the recorded command lines involve any of the system variables that were just read, in order to help quickly identify commands that may involve environment variable operations.

[0175] Finally, the fourth monitoring subtask is variable read / write analysis: if a command line involving environment variables is matched, a more detailed analysis will be performed on that command line. Specifically, the specific instructions in the command line can be used to determine whether environment variables are being read, modified, or created. For example, for operations involving commands like `export` and `unset`, special attention can be paid to their modification behavior of environment variables; while for operations involving commands like `echo` and `printenv`, the focus is on their reading behavior of environment variables.

[0176] After the monitoring task is decomposed, the edge device can use a queue to deduplicate and optimize the execution plan of the multiple monitoring subtasks. For example, when there are duplicate subtasks after decomposing multiple different monitoring tasks, only one of them is selected for allocation, thereby eliminating redundancy through a unified collection queue and improving monitoring efficiency.

[0177] Ultimately, the edge devices ensure efficient operation by assigning each monitoring subtask to a specific monitoring tool. In implementation, for the task of reading system variables, a lightweight monitor can be designed to scan and record current system environment variable key-value pairs as needed. For command-line operation monitoring, a real-time monitoring module based on Extended Berkeley Packet Filter (eBPF) technology can be used to capture command-line operations. In the variable matching stage, existing text matching tools are used to identify command lines containing environment variables. In the variable read / write analysis stage, based on the above monitoring details, a dedicated analysis monitor is deployed to deeply analyze the matched command lines, ensuring accurate identification and recording of environment variable read, modification, or creation operations.

[0178] Once all monitoring subtasks have been assigned, the monitoring framework can be started to record logs and build a source map, so as to fully understand the operational behavior in the system and to trace and analyze abnormal behavior.

[0179] First, by executing monitoring subtasks, the monitored information can be logged, achieving log recording. Specifically, the operations in the system are categorized into different types, such as reading, writing, executing, and modifying. Each operation generates a log entry, recording the event type, involved objects (e.g., files, variables, commands), the specific content of the operation, the execution time, and the executing user. All generated logs are stored in a centralized log management system, ensuring the logs are structured and easy to manage. Furthermore, edge devices can classify and store logs according to event type and monitoring module, facilitating subsequent retrieval and analysis.

[0180] Secondly, the source graph is constructed: the edge device analyzes the logs in chronological order. In the log records, each entity is treated as a node, and the directed edges between nodes represent the interaction behaviors between entities, ultimately forming the form of <executing entity, interaction behavior, target entity>. After the log processing is complete, the final source graph is formed by merging the identical entities in all directed edges.

[0181] Taking environment variable monitoring as an example, the log records the command line for environment variable operation and the process information of the process executing the command. For example, it can be: / usr / bash -c "export PATH=\" / new / bin:$PATH\"" (PID 1234).

[0182] Based on the above log, it can be easily identified that its execution entity is / usr / bash, the executed interaction behavior is export, and the target entity is the environment variable Path. Therefore, this log event can be converted into the following formatted information: <bash process (PID 1234), write operation (export), environment variable PATH>.

[0183] By analyzing the complete log file, a global traceability graph can be constructed, and further analysis can be carried out on the behavior of process 1234 before and after operating on the environment variable, etc., to identify abnormal behaviors. Based on the above steps, not only can the operations of environment variables be monitored efficiently, but also a comprehensive analysis of the operations of environment variables can be achieved through logs and traceability graphs, thereby improving the security and traceability of the system.

[0184] When the logs and traceability graph are obtained, machine learning and other methods are usually used to analyze possible abnormal behaviors. However, due to the black-box nature of the AI model, the output abnormalities are not interpretable, and there is also a problem of high false alarm rate. Personnel still need to exclude them one by one, which greatly increases the labor cost of security personnel.

[0185] Therefore, in this application, a semantic association attack detection method based on adjacency attribute analysis is proposed. In this case, first, an edge matching rule is defined for the traceability graph to match the interaction patterns between entities, and five node matching rules are defined to match the inherent attributes of nodes. Subsequently, semantic abstraction can be carried out with the help of these matching rules, and abnormal behavior matching can be performed. Among them, the edge matching rule and the node matching rule are the above-mentioned semantic matching rules.

[0186] Exemplarily, the edge matching rule can specifically be: def matchEdgeType(edges:set,patterns:list[str])->bool, which is used to match the edge types between nodes. Among them, the parameter edges is used to represent the set of all edge types between the source node and the destination node. The parameter patterns is used to represent a list of edge type strings, and the default is ['.*'] for matching all edge types. Here, the dot (.) represents any single character except the newline characters (\n, \r). The asterisk (*) represents zero or more occurrences of the previous sub-expression. So this symbol represents matching any string composed of multiple non-\n and non-\r characters.

[0187] The return value of the edge matching rule is specifically: if any edge type in edges is the same as any edge type in patterns, then return True (i.e., match), otherwise return False (not match). It should be noted that in this edge matching rule, the matching is performed by using == for string equality matching.

[0188] The first example node matching rule is: `def matchFilePattern(info:list,fileNamePatterns:list[str])->bool`, which is used to match file names using regular expressions. The `info` parameter represents a list of node information for the source or destination node. The `fileNamePatterns` parameter represents a list of regular expression pattern strings for filenames, defaulting to matching all files with `['.*']`.

[0189] The return value of this node matching rule is as follows: it returns True if the node filename matches any pattern in the list, otherwise it returns False. Furthermore, the matching in this node matching rule uses the regular expression matching function `re.match`.

[0190] The second example node matching rule is: `def matchProcReadLib(info:list,libPatterns:list[str])->bool`, which is used to match library files read by the process using regular expressions. Here, the `info` parameter represents a list of node information for the source or destination node. The `libPatterns` parameter represents a list of regular expression pattern strings for library filenames, defaulting to matching all files with `['.*']`.

[0191] The return value of this node matching rule is as follows: it returns True if any library filename read by the process matches any pattern in the list, otherwise it returns False. Furthermore, the matching in this node matching rule uses the regular expression matching function `re.match`.

[0192] The third exemplary node matching rule is: `def matchProcPattern(info:list,procNamePatterns:list[str],argPatterns:list[str])->bool`, used to match process names and parameters using regular expressions. Here, the parameter `info` represents a list of node information for the source or destination node, obtained using `graph.node_info[id]`. The parameter `procNamePatterns` represents a list of regular expression pattern strings for the process name, defaulting to matching all processes with `['.*'`. The parameter `argPatterns` represents a list of pattern strings for the process parameters, defaulting to matching all parameters with `['.*'`.

[0193] The return value of this node matching rule is as follows: it returns True if both the process name and the parameter match the pattern, otherwise it returns False. Furthermore, in this node matching rule, `procName` uses `re.match` for regular expression matching; `arg` uses the `in` operator for substring matching, that is, it determines whether a specific parameter appears in the process parameters.

[0194] The fourth exemplary node matching rule is: `def matchSocketPattern(info:list,ipPattern:str,portPattern:str)->bool`, used to match IP addresses and port numbers using regular expressions (i.e., to match sockets). The `info` parameter represents a list of node information for the source or destination node, obtained using `graph.node_info[id]`. The `ipPattern` parameter represents the regular expression pattern for IP addresses, defaulting to matching all IP addresses with '.*'. The `portPattern` parameter represents the regular expression pattern for port numbers, defaulting to matching all ports with '.*'.

[0195] The return value of this node matching rule is as follows: it returns True if both the IP address and port number match the pattern, otherwise it returns False. Furthermore, this node matching rule uses the regular expression matching function `re.match` for regular expression matching.

[0196] The fifth exemplary node matching rule is: `matchEnvPattern(info:list,env_name:str)->bool`, used to match environment variable names. Here, the `info` parameter represents a list of node information for the source or destination node, obtained using `graph.node_info[id]`. The `env_name` parameter represents the name of the environment variable to be matched, defaulting to an empty string.

[0197] The return value of this node matching rule is as follows: if env_name is empty, it returns whether all environment variable flags (info[2]) are read; otherwise, it returns True if the environment variable name matches, and False if it does not match. In addition, in this node matching rule, the matching is performed by matching strings with the same equality.

[0198] Based on the node matching and edge matching rules described above, semantic rules for predefined abnormal behavior patterns can be used to identify potential anomalies. Continuing with Log4Shell as an example, the abnormal behavior pattern can be defined as (Log4J)->(connectNetwork and creatShellProc), meaning the entity Log4J connects to the network and creates the process.

[0199] For example, please refer to Figure 8, which is a schematic diagram of detecting abnormal behavior in a source graph according to this application. As shown in Figure 8, based on the chronological order of the (Log4J)->(connectNetwork and createShellProc) behavior, the behavior pattern is matched on the source graph. If some nodes on the source graph are found to satisfy the Log4J pattern association, they are abstracted as Log4J entities. Then, according to the above matching rules, if the nodes representing Log4J entities exhibit previously uncommon behavior patterns such as connecting to the network and creating a process in subsequent behaviors (Log4J is originally used for log reading and writing, usually in file reading and writing mode), it can be determined that the behavior conforms to the abnormal behavior pattern, and thus it is marked on the source graph and the corresponding results are output. Specifically, the abnormal detection results obtained after performing the detection in the source graph are shown in Table 1.

[0200] Table 1

[0201] In summary, this application innovatively proposes a semantic association attack detection method based on adjacency attribute analysis. This method constructs a semantic abstract rule system based on inherent attributes, adjacency node attributes, and interaction pattern attributes, combined with deep iterative matching technology of multi-dimensional monitoring information at the entity, interaction, and temporal levels. This addresses the problems of weak interpretability and low semantic level of simple parameter matching in traditional anomaly detection AI, significantly improving the accuracy of anomaly behavior detection, reducing false positive rates, and lowering security operation costs. Furthermore, this application innovatively proposes a lightweight OS-based collaborative security monitoring architecture, designing a multi-level modular monitoring framework including event-level monitoring tools, security information-level collectors, and system information collection mechanisms. By decomposing complex monitoring tasks into multiple atomic-level security information collection tasks, it solves the problems of repetitive development, high maintenance costs, and easy introduction of new vulnerabilities in traditional solutions, achieving the effects of reducing development and maintenance costs, improving monitoring coverage, and improving the cost-effectiveness of performance overhead.

[0202] Based on this, this application effectively addresses the key challenges of existing situational awareness systems in terms of interpretability, accuracy, and cost-effectiveness through the innovative design of semantic association analysis and collaborative monitoring architecture, providing strong support for improving network security protection capabilities.

[0203] The method provided in this application has been described in detail above. Next, the device provided in this application for performing the above method will be described.

[0204] Please refer to Figure 9, which is a schematic diagram of the structure of an abnormal behavior detection device provided in this application. As shown in Figure 9, the abnormal behavior detection device includes: an acquisition module 901, used to acquire monitoring data, which is used to indicate events that have occurred during the operation of the device; a processing module 902, used to construct a first source map based on the monitoring data, which is used to indicate entities appearing in the events and the interaction behaviors between entities; the processing module 902 is also used to transform a first entity in the first source map into a second entity based on semantic matching rules to obtain a second source map, where the first entity is an entity that matches the semantic matching rules, and the second entity is an entity that has been semantically categorized from the first entity; the processing module 902 is also used to acquire an abnormal behavior pattern, which is used to indicate abnormal behaviors between entities; the processing module 902 is also used to detect interaction behaviors that match the abnormal behavior pattern in the second source map to obtain a target behavior, where the entity corresponding to the target behavior matches the entity corresponding to the abnormal behavior, and the target behavior matches the abnormal behavior.

[0205] In one possible implementation, the abnormal behavior pattern is used to indicate multiple abnormal behaviors, the target behaviors including multiple interactive behaviors in the second source graph, and the multiple interactive behaviors are matched one-to-one with the multiple abnormal behaviors.

[0206] In one possible implementation, the second traceability graph also records the occurrence time of the interaction behavior between entities, and the abnormal behavior pattern is also used to indicate the execution sequence between multiple abnormal behaviors; the processing module 902 is also used to: based on the interaction behavior and the occurrence time of the interaction behavior in the second traceability graph, detect the interaction behavior in which the executing entity, target entity, behavior type and execution sequence all match multiple abnormal behaviors, and obtain multiple interaction behaviors.

[0207] In one possible implementation, the multiple abnormal behaviors include a first abnormal behavior and a second abnormal behavior, wherein the execution sequence of the first abnormal behavior precedes that of the second abnormal behavior; the processing module 902 is further configured to: detect the execution entity, the target entity, and the interaction behavior whose behavior type matches the first abnormal behavior in the second source graph to obtain the first interaction behavior; determine candidate interaction behaviors that occur after the first interaction behavior in the second source graph; detect the execution entity, the target entity, and the interaction behavior whose behavior type matches the second abnormal behavior in the candidate interaction behaviors to obtain the second interaction behavior; wherein the multiple interaction behaviors include the first interaction behavior and the second interaction behavior.

[0208] In one possible implementation, the abnormal behavior pattern is also used to indicate the frequency of abnormal behavior between entities, with the frequency of the target behavior matching the frequency indicated by the abnormal behavior pattern.

[0209] In one possible implementation, the first source graph includes multiple nodes and at least one directed edge between the multiple nodes. Each of the multiple nodes is used to represent an entity that appears in the event, and the at least one directed edge is used to indicate the interaction behavior between entities. The at least one directed edge points from the source node representing the executing entity to the destination node representing the target entity.

[0210] In one possible implementation, the processing module 902 is further configured to: match the behavior type of the abnormal behavior with the edge type of the directed edge in the second source graph to obtain candidate directed edges that match the abnormal behavior; match the execution entity of the abnormal behavior with the entity represented by the source node of the candidate directed edge; and match the target entity of the abnormal behavior with the entity represented by the destination node of the candidate directed edge to obtain the target directed edge that matches the node in the candidate directed edges, wherein the target directed edge is used to indicate the target behavior.

[0211] In one possible implementation, the entities indicated by the first source graph include at least one of threads, processes, files, libraries, sockets, and environment variables.

[0212] In one possible implementation, the acquisition module 901 is specifically used to: acquire a monitoring task, which is used to indicate a target event to be monitored; based on a monitoring tool library, split the monitoring task into multiple monitoring sub-tasks, which are used to collaboratively monitor the target event; the monitoring tool library includes multiple monitoring tools for monitoring different events; and use the monitoring tools in the monitoring tool library to execute the multiple monitoring sub-tasks to obtain monitoring data.

[0213] In one possible implementation, the semantic matching rules include entity matching rules and / or behavior matching rules. The processing module 902 is further configured to: in the first source graph, determine a first entity whose interaction behavior matches the entity matching rule and / or is performed, and whose interaction behavior matches the behavior matching rule; and transform the first entity into a second entity in the first source graph to obtain a second source graph.

[0214] In one possible implementation, the processing module 902 is further configured to: output abnormal alarm information, which includes the target behavior, the execution entity corresponding to the target behavior, the target entity, and the occurrence time.

[0215] Both the acquisition module 901 and the processing module 902 can be implemented in software or hardware. For example, the implementation of the processing module 902 will be described below. Similarly, the implementation of the acquisition module 901 can be found in the implementation description of the acquisition module 901.

[0216] As an example of a software functional unit, processing module 902 may include code running on a computing instance. The computing instance may include at least one of a physical host (computing device), a virtual machine, or a container. Further, the aforementioned computing instance may be one or more. For example, processing module 902 may include code running on multiple hosts / virtual machines / containers. It should be noted that the multiple hosts / virtual machines / containers used to run the code may be distributed within the same region or in different regions. Further, the multiple hosts / virtual machines / containers used to run the code may be distributed within the same availability zone (AZ) or in different AZs, each AZ including one or more geographically proximate data centers. Typically, a region may include multiple AZs.

[0217] Similarly, multiple hosts / virtual machines / containers used to run this code can be distributed within the same Virtual Private Cloud (VPC) or across multiple VPCs. Typically, a VPC is set up within a region. Communication between two VPCs within the same region, as well as between VPCs in different regions, requires a communication gateway to be set up within each VPC to enable interconnection between VPCs.

[0218] As an example of a hardware functional unit, the processing module 902 may include at least one computing device, such as a server. Alternatively, the processing module 902 may be implemented using a central processing unit (CPU), an application-specific integrated circuit (ASIC), or a programmable logic device (PLD). The PLD may be a complex programmable logical device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), a data processing unit (DPU), a neural network processing unit (NPU), a system-on-chip (SoC), an offload card, an accelerator card, or any combination thereof.

[0219] The processing module 902 includes multiple computing devices that can be distributed within the same region or in different regions. Similarly, the processing module 902 can be distributed within the same Availability Zone (AZ) or in different AZs. Likewise, the processing module 902 can be distributed within the same Virtual Private Cloud (VPC) or multiple VPCs. These multiple computing devices can be any combination of computing devices such as servers, ASICs, PLDs, CPLDs, FPGAs, GALs, DPUs, NPUs, SoCs, offloading cards, and accelerator cards.

[0220] Please refer to Figure 10, which is a schematic diagram of the structure of a computing device provided in this application. The computing device 1000 shown in Figure 10 can be used to execute the abnormal behavior detection method provided in this embodiment. As shown in Figure 10, the computing device 1000 includes: a bus 1002, a processor 1004, a memory 1006, and a communication interface 1008. The processor 1004, the memory 1006, and the communication interface 1008 communicate with each other via the bus 1002. The computing device 1000 can be a server or a terminal device. It should be understood that this application does not limit the number of processors and memories in the computing device 1000.

[0221] Bus 1002 can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, only one line is used in Figure 10, but this does not imply that there is only one bus or one type of bus. Bus 1002 can include pathways for transmitting information between various components of computing device 1000 (e.g., memory 1006, processor 1004, communication interface 1008).

[0222] The processor 1004 may include any one or more processors such as a central processing unit (CPU), a graphics processing unit (GPU), a microprocessor (MP), or a digital signal processor (DSP).

[0223] The memory 1006 may include volatile memory, such as random access memory (RAM). The processor 1004 may also include non-volatile memory, such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid state drive (SSD).

[0224] The memory 1006 stores executable program code, and the processor 1004 executes this executable program code to implement the functions of the aforementioned acquisition module and processing module, thereby realizing the above-mentioned abnormal behavior detection method. That is, the memory 1006 stores instructions for executing the abnormal behavior detection method.

[0225] The communication interface 1008 uses transceiver modules such as, but not limited to, network interface cards and transceivers to enable communication between the computing device 1000 and other devices or communication networks.

[0226] This application also provides a computing device cluster. The computing device cluster includes at least one computing device. The computing device can be a server, such as a central server, an edge server, or a local server in a local data center. In some embodiments, the computing device can also be a terminal device such as a desktop computer, a laptop computer, or a smartphone.

[0227] Please refer to Figure 11, which is a schematic diagram of a computing device cluster provided in this application. As shown in Figure 11, the computing device cluster includes at least one computing device 1000. The memory 1006 in one or more computing devices 1000 in the computing device cluster may store the same instructions for executing a detection method for abnormal behavior.

[0228] In some possible implementations, the memory 1006 of one or more computing devices 1000 in the computing device cluster may also store partial instructions for executing a method for detecting abnormal behavior. In other words, a combination of one or more computing devices 1000 can jointly execute instructions for executing a method for detecting abnormal behavior.

[0229] It should be noted that the memory 1006 in different computing devices 1000 within the computing device cluster can store different instructions, each used to execute a portion of the functions of the abnormal behavior detection method apparatus. That is, the instructions stored in the memory 1006 of different computing devices 1000 can implement the functions of one or more of the aforementioned acquisition and processing modules.

[0230] In some possible implementations, one or more computing devices in a computing device cluster can be connected via a network. This network can be a wide area network (WAN) or a local area network (LAN), etc. Figure 12 illustrates one possible implementation. Figure 12 is a schematic diagram of another computing device cluster structure provided in this application. As shown in Figure 12, in computing device cluster 1200, two computing devices 1000A and 1000B are connected via a network. Specifically, they are connected to the network through communication interfaces in each computing device. In this type of possible implementation, the memory 1006 in computing device 1000A stores instructions for executing the functions of the acquisition module. Simultaneously, the memory 1006 in computing device 1000B stores instructions for executing the functions of the processing module.

[0231] It should be understood that the functions of computing device 1000A shown in Figure 12 can also be performed by multiple computing devices 1000. Similarly, the functions of computing device 1000B can also be performed by multiple computing devices 1000.

[0232] This application also provides a chip comprising a processing unit and a communication unit. The processing unit may be, for example, a processor, and the communication unit may be, for example, an input / output interface, pins, or circuits. The processing unit can execute computer execution instructions stored in a storage unit to cause the chip within the electronic device to perform the methods described in the above embodiments. Optionally, the storage unit may be an in-chip storage unit, such as a register or cache. Alternatively, the storage unit may be an external storage unit located within a wireless access device, such as a read-only memory (ROM) or other types of static storage devices capable of storing static information and instructions, such as random access memory (RAM).

[0233] Referring to Figure 13, which is a schematic diagram of the structure of a computer-readable storage medium provided in this application. This application also provides a computer-readable storage medium in which, in some embodiments, the method disclosed in Figure 2 can be implemented as computer program instructions encoded in a machine-readable format on a computer-readable storage medium or on other non-transitory media or articles of art.

[0234] Figure 13 schematically illustrates a conceptual partial view of an example computer-readable storage medium arranged according to at least some of the embodiments shown herein, the example computer-readable storage medium including a computer program for executing computer processes on a computing device.

[0235] In one embodiment, the computer-readable storage medium 1300 is provided using a signal bearer medium 1301. The signal bearer medium 1301 may include one or more program instructions 1302, which, when executed by one or more processors, can provide the functions or parts thereof described above with reference to FIG2.

[0236] In some examples, the signal carrying medium 1301 may include a computer-readable medium 1303, such as, but not limited to, a hard disk drive, a compact disc (CD), a digital video optical disc (DVD), a digital magnetic tape, a memory, ROM, or RAM, etc.

[0237] In some embodiments, the signal-bearing medium 1301 may include a computer-recordable medium 1304, such as, but not limited to, a memory, a read / write (R / W) CD, a R / W DVD, etc. In some embodiments, the signal-bearing medium 1301 may include a communication medium 1305, such as, but not limited to, digital and / or analog communication media (e.g., fiber optic cables, waveguides, wired communication links, wireless communication links, etc.). Therefore, for example, the signal-bearing medium 1301 may be transmitted by a wireless communication medium 1305 (e.g., a wireless communication medium conforming to the IEEE 1002.X standard or other transmission protocols).

[0238] One or more program instructions 1302 may be, for example, computer-executable instructions or logical implementation instructions. In some examples, the computing device may be configured to provide various operations, functions, or actions in response to one or more program instructions 1302 conveyed to the computing device via a computer-readable medium 1303, a computer-recordable medium 1304, and / or a communication medium 1305.

[0239] It should also be noted that the device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. In addition, in the accompanying drawings of the device embodiments provided in this application, the connection relationship between modules indicates that they have a communication connection, which can be implemented as one or more communication buses or signal lines.

[0240] Through the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general-purpose hardware, or it can be implemented by special-purpose hardware including application-specific integrated circuits, special-purpose CPUs, special-purpose memory, special-purpose components, etc. Generally, any function performed by a computer program can be easily implemented by corresponding hardware, and the specific hardware structure used to implement the same function can also be diverse, such as analog circuits, digital circuits, or special-purpose circuits. However, for this application, software program implementation is more often the preferred implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a readable storage medium, such as a computer floppy disk, USB flash drive, mobile hard disk, ROM, RAM, magnetic disk, or optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, training equipment, or network device, etc.) to execute the methods of the various embodiments of this application.

[0241] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product.

[0242] A computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions according to this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transferred from one computer-readable storage medium to another. For example, computer instructions can be transferred from one website, computer, training device, or data center to another website, computer, training device, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can store or a data storage device such as a training device or data center that integrates one or more available media. The available media can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., DVDs), or semiconductor media (e.g., solid-state drives (SSDs)).

Claims

1. A method for detecting abnormal behavior, characterized in that, include: Acquire monitoring data, which is used to indicate events that have occurred during equipment operation; Based on the monitoring data, a first source map is constructed, which is used to indicate the entities that appear in the event and the interaction behaviors between entities. Based on semantic matching rules, the first entity in the first source graph is transformed into a second entity to obtain a second source graph. The first entity is the entity that matches the semantic matching rules, and the second entity is the entity that the first entity is semantically categorized. Obtain abnormal behavior patterns, which are used to indicate abnormal behavior between entities; In the second source map, an interaction behavior that matches the abnormal behavior pattern is detected to obtain the target behavior. The entity corresponding to the target behavior matches the entity corresponding to the abnormal behavior, and the target behavior matches the abnormal behavior.

2. The method according to claim 1, characterized in that, The abnormal behavior pattern is used to indicate multiple abnormal behaviors, the target behaviors include multiple interactive behaviors in the second source graph, and the multiple interactive behaviors are matched one by one with the multiple abnormal behaviors.

3. The method according to claim 2, characterized in that, The second source map also records the occurrence time of the interaction behavior between entities, and the abnormal behavior pattern is also used to indicate the execution sequence between the multiple abnormal behaviors; Detecting interaction behaviors that match the abnormal behavior pattern in the second source map includes: Based on the interaction behaviors and their occurrence times in the second source map, interaction behaviors that match the multiple abnormal behaviors in terms of execution entity, target entity, behavior type, and execution sequence are detected, thus obtaining the multiple interaction behaviors.

4. The method according to claim 3, characterized in that, The plurality of abnormal behaviors include a first abnormal behavior and a second abnormal behavior, wherein the execution sequence of the first abnormal behavior precedes that of the second abnormal behavior; The interaction behaviors that match multiple abnormal behaviors in terms of the detection execution entity, target entity, behavior type, and execution sequence include: The execution entity, target entity, and interaction behavior whose behavior type matches the first abnormal behavior are detected in the second source map to obtain the first interaction behavior; In the second source map, candidate interactive behaviors that occur after the first interactive behavior are identified; Among the candidate interactive behaviors, the executing entity, the target entity, and the interactive behaviors whose behavior types match the second abnormal behavior are detected to obtain the second interactive behavior; The plurality of interactive behaviors include the first interactive behavior and the second interactive behavior.

5. The method according to any one of claims 1-4, characterized in that, The abnormal behavior pattern is also used to indicate the frequency of abnormal behavior between entities, and the frequency of the target behavior matches the frequency indicated by the abnormal behavior pattern.

6. The method according to any one of claims 1-5, characterized in that, The first source graph includes multiple nodes and at least one directed edge between the multiple nodes. Each of the multiple nodes is used to represent an entity that appears in the event. The at least one directed edge is used to indicate the interaction behavior between entities. The at least one directed edge is from the source node representing the executing entity to the destination node representing the target entity.

7. The method according to claim 6, characterized in that, The detection of interaction behaviors matching abnormal behavior patterns in the second source map includes: The behavior type of the abnormal behavior is matched with the edge type of the directed edges in the second source graph to obtain candidate directed edges that match the abnormal behavior. The entity executing the abnormal behavior is matched with the entity represented by the source node of the candidate directed edge, and the target entity of the abnormal behavior is matched with the entity represented by the destination node of the candidate directed edge. The target directed edge is obtained from the candidate directed edges, and the target directed edge is used to indicate the target behavior.

8. The method according to any one of claims 1-7, characterized in that, The entities indicated by the first source graph include at least one of threads, processes, files, libraries, sockets, and environment variables.

9. The method according to any one of claims 1-8, characterized in that, The acquisition of monitoring data includes: Obtain a monitoring task, which is used to indicate a target event to be monitored; Based on the monitoring tool library, the monitoring task is divided into multiple monitoring sub-tasks, which are used to collaboratively monitor the target event. The monitoring tool library includes multiple monitoring tools for monitoring different events. Multiple monitoring sub-tasks are performed using the monitoring tools in the aforementioned monitoring tool library to obtain monitoring data.

10. The method according to any one of claims 1-9, characterized in that, The semantic matching rules include entity matching rules and / or behavior matching rules. The step of transforming the first entity in the first source graph into a second entity based on semantic matching rules includes: In the first source map, the first entity is identified as matching the entity matching rule and / or whose interactive behavior matches the behavior matching rule. In the first source graph, the first entity is transformed into the second entity to obtain the second source graph.

11. A device for detecting abnormal behavior, characterized in that, include: The acquisition module is used to acquire monitoring data, which is used to indicate events that have occurred during the operation of the equipment; The processing module is used to construct a first source map based on the monitoring data. The first source map is used to indicate the entities that appear in the event and the interaction behaviors between the entities. The processing module is further configured to transform the first entity in the first source graph into a second entity based on semantic matching rules to obtain a second source graph, wherein the first entity is an entity that matches the semantic matching rules, and the second entity is an entity that is semantically categorized from the first entity. The acquisition module is also used to acquire abnormal behavior patterns, which are used to indicate abnormal behavior between entities. The processing module is further configured to detect interactive behaviors that match the abnormal behavior pattern in the second source map, obtain target behaviors, wherein the entity corresponding to the target behaviors matches the entity corresponding to the abnormal behaviors, and the target behaviors match the abnormal behaviors.

12. The apparatus according to claim 11, characterized in that, The abnormal behavior pattern is used to indicate multiple abnormal behaviors, the target behaviors include multiple interactive behaviors in the second source graph, and the multiple interactive behaviors are matched one by one with the multiple abnormal behaviors.

13. The apparatus according to claim 12, characterized in that, The second source map also records the occurrence time of the interaction behavior between entities, and the abnormal behavior pattern is also used to indicate the execution sequence between the multiple abnormal behaviors; The processing module is further configured to: Based on the interaction behaviors and their occurrence times in the second source map, interaction behaviors that match the multiple abnormal behaviors in terms of execution entity, target entity, behavior type, and execution sequence are detected, thus obtaining the multiple interaction behaviors.

14. The apparatus according to claim 13, characterized in that, The plurality of abnormal behaviors include a first abnormal behavior and a second abnormal behavior, wherein the execution sequence of the first abnormal behavior precedes that of the second abnormal behavior; The processing module is further configured to: The execution entity, target entity, and interaction behavior whose behavior type matches the first abnormal behavior are detected in the second source map to obtain the first interaction behavior; In the second source map, candidate interactive behaviors that occur after the first interactive behavior are identified; Among the candidate interactive behaviors, the executing entity, the target entity, and the interactive behaviors whose behavior types match the second abnormal behavior are detected to obtain the second interactive behavior; The plurality of interactive behaviors include the first interactive behavior and the second interactive behavior.

15. The apparatus according to any one of claims 11-14, characterized in that, The abnormal behavior pattern is also used to indicate the frequency of abnormal behavior between entities, and the frequency of the target behavior matches the frequency indicated by the abnormal behavior pattern.

16. The apparatus according to any one of claims 11-15, characterized in that, The first source graph includes multiple nodes and at least one directed edge between the multiple nodes. Each of the multiple nodes is used to represent an entity that appears in the event. The at least one directed edge is used to indicate the interaction behavior between entities. The at least one directed edge is from the source node representing the executing entity to the destination node representing the target entity.

17. The apparatus according to claim 16, characterized in that, The processing module is further configured to: The behavior type of the abnormal behavior is matched with the edge type of the directed edges in the second source graph to obtain candidate directed edges that match the abnormal behavior. The entity executing the abnormal behavior is matched with the entity represented by the source node of the candidate directed edge, and the target entity of the abnormal behavior is matched with the entity represented by the destination node of the candidate directed edge. The target directed edge is obtained from the candidate directed edges, and the target directed edge is used to indicate the target behavior.

18. The apparatus according to any one of claims 11-17, characterized in that, The entities indicated by the first source graph include at least one of threads, processes, files, libraries, sockets, and environment variables.

19. The apparatus according to any one of claims 11-18, characterized in that, The acquisition module is also used for: Obtain a monitoring task, which is used to indicate a target event to be monitored; Based on the monitoring tool library, the monitoring task is divided into multiple monitoring sub-tasks, which are used to collaboratively monitor the target event. The monitoring tool library includes multiple monitoring tools for monitoring different events. Multiple monitoring sub-tasks are performed using the monitoring tools in the aforementioned monitoring tool library to obtain monitoring data.

20. The apparatus according to any one of claims 11-19, characterized in that, The semantic matching rules include entity matching rules and / or behavior matching rules. The processing module is further configured to: In the first source map, the first entity is identified as matching the entity matching rule and / or whose interactive behavior matches the behavior matching rule. In the first source graph, the first entity is transformed into the second entity to obtain the second source graph.

21. A computing device, characterized in that, It includes a memory and a processor; the memory stores code, and the processor is configured to execute the code, and when the code is executed, the computing device performs the method as claimed in any one of claims 1 to 10.

22. A computing device cluster, characterized in that, It includes at least one computing device, each computing device including a processor and memory; A processor of at least one computing device is configured to execute instructions stored in the memory of at least one computing device to cause a cluster of computing devices to perform operational steps of the method as claimed in any one of claims 1 to 10.

23. A computer storage medium, characterized in that, The computer storage medium stores instructions that, when executed by the computer, cause the computer to perform the method of any one of claims 1 to 10.

24. A computer program product, characterized in that, The computer program product stores instructions that, when executed by a computer, cause the computer to perform the method of any one of claims 1 to 10.

Images