Alarm method, device and system

Abstract

The invention provides an alarm method, device and system, and belongs to the technical field of networks. In the scheme provided by the invention, after the first equipment detects the alarm event based on the flowing data stream, the alarm data of the alarm event can be encapsulated in the message, the message is sent to the second equipment through which the data stream flows, and the stream identifier of the message is consistent with the stream identifier of the data stream. And after receiving the message, the second equipment can perform threat detection and / or threat disposal based on the alarm data. Therefore, the first equipment and the second equipment realize linkage detection and / or disposal of the threat entity. Moreover, the first device can directly package the alarm data in the message and issue the message to the second device, that is, the alarm data does not need to be detoured to the cloud platform for processing, so that the time consumption of threat detection and / or disposal is effectively shortened, and timely blocking of network attacks can be ensured.

Description

Technical Field

[0001] The present application relates to the field of network technology, and in particular to an alarm method, device and system. Background Art

[0002] To ensure network security, network devices (such as firewalls, switches, and routers) can perform threat detection on received data streams. If a malicious or suspicious network connection is detected, alarm data is generated and the alarm data and metadata of the data stream are reported to the cloud platform. Terminal devices can also perform threat detection on the log data they collect. If a malicious threat entity is detected, the threat entity can be handled (such as killing the process, isolating the file, isolating the host, or removing the account, etc.) and alarm data is generated. In addition, terminal devices can report alarm data and log data to the cloud platform.

[0003] After receiving the data reported by network devices and terminal devices, the cloud platform can associate the received data and find threat entities that the network devices and terminal devices have failed to block through threat analysis, as well as threat entities that have been blocked but not completely eradicated. After that, the cloud platform can generate a disposal strategy and send it to the terminal devices and network devices so that the terminal devices and network devices can handle the threat.

[0004] However, the above method requires the cloud platform to perform data association, threat analysis and disposal strategy issuance, which is time-consuming and cannot block network attacks in time. Summary of the invention

[0005] The present application provides an alarm method, device and system, which can solve the technical problem that the alarm method of the related art is time-consuming and cannot block network attacks in time.

[0006] In a first aspect, an alarm method is provided, the method comprising: a first device performs threat detection on a data stream passing through, if the first device detects an alarm event based on the threat detection, then the alarm data of the alarm event is encapsulated in a message, and the message is sent to a second device through which the data stream flows. The flow identifier of the message is consistent with the flow identifier of the data stream, and the alarm data in the message is used for the second device to perform threat detection and / or threat disposal.

[0007] Based on the method provided by the present application, the first device and the second device realize the linkage detection and / or disposal of the threat entity. In addition, since the first device can directly encapsulate the alarm data in the message and send it to the second device, that is, the alarm data does not need to be processed by the cloud platform, the time consumption of threat detection and / or disposal is effectively shortened, which can ensure the timely blocking of network attacks and effectively reduce the waste of computing resources of the cloud platform.

[0008] Optionally, the message may belong to the data flow, that is, the first device may send the alarm data along with the flow. Alternatively, the message may be a message in a reverse data flow of the data flow. The source address of the reverse data flow is the same as the destination address of the data flow, and the destination address of the reverse data flow is the same as the source address of the data flow.

[0009] Therefore, the first device can reuse the protocol channel between it and the second device to send alarm data. Therefore, when the second device associates the alarm data, it will not be affected by the deployment location of the network address translation (NAT) device. This solution has high application flexibility.

[0010] Optionally, if the data flow flows from the first device through the second device, the message may belong to the data flow; if the data flow flows from the second device through the first device, the message may be a message in the reverse data flow of the data flow.

[0011] That is, if the direction of the data flow is the same as the direction of sending the alarm data, the first device can encapsulate and send the alarm data along with the flow; if the direction of the data flow is opposite to the direction of sending the alarm data, the first device can encapsulate and send the alarm data through the message in the reverse data flow.

[0012] Optionally, the message in the reverse data flow may be a response message to the message in the data flow. The response message may be a message triggered by the message in the data flow.

[0013] Optionally, the response message may be received by the first device, that is, the response message is generated by other devices (such as attackers) and sent to the second device. Alternatively, the response message may be generated by the first device, that is, the first device may actively construct a response message to encapsulate the alarm data to ensure that the second device can perform threat detection and / or threat disposal based on the alarm data in a timely manner.

[0014] Optionally, the first device may be a network device, and the second device may be a terminal device; or, the first device and the second device may both be terminal devices; or, the first device may be a terminal device, and the second device may be a network device. The network device may be a router, a switch, or a firewall, and the terminal device may be a personal computer (PC), a workstation, or a server.

[0015] Optionally, if the first device is a network device, the data stream may be received by the first device, for example, the data stream may be sent by the attacker to the second device through the first device, or may be sent by the second device to the attacker or other terminal device through the first device. If the first device is a terminal device, the data stream may be received or initiated by the first device. For example, if the first device has been hacked by an attacker, the first device may initiate a data stream to the attacker or other terminal device, and the first device may perform threat detection on the initiated data stream.

[0016] Optionally, the alarm data may include at least one of the following data: the attack scenario type of the alarm event; the confidence level of the alarm event; the risk score of the attack scenario; the disposal action performed by the first device on the alarm event; the rule number of the detection rule for detecting the alarm event; the first disposal strategy for execution by the second device; an association type, which is used to indicate a manner of associating the alarm data to the process call chain of the second device; and an association value corresponding to the association type.

[0017] Among them, the attack scenario type may include: Trojan horse, backdoor virus, worm, virus, botnet, information disclosure, code execution and buffer overflow, etc. The confidence and risk score may both range from 60 to 100. The disposal action may be an alert or a block. The first disposal strategy may include an alert or an isolate host, and the association type may include a process, a file md5, a file name, a command and a content, etc. md5 refers to the message-digest algorithm version 5. Moreover, the file md5, the file name, the command and the content have corresponding association values.

[0018] Optionally, the message is an Internet protocol version 6 (IPv6) message, and the alarm data may be encapsulated in a destination options header (DOH) of the IPv6 message.

[0019] Optionally, if the second device is a terminal device and is the destination node of the message, the second device can directly obtain and process the alarm data in the DOH. If the second device is a network device, the IPv6 message can also include a segment routing header (SRH), and the segment list (segment list) of the SRH can carry the segment identifier (SID) of the second device, and the SID can be used to instruct the second device to obtain and process the alarm data in the DOH.

[0020] Optionally, if the first device detects an alarm event based on the threat detection, the process of encapsulating the alarm data of the alarm event in a message may include: if the first device detects an alarm event based on the threat detection, and the data flow and the alarm event meet the linkage processing conditions, then the alarm data of the alarm event is encapsulated in the message.

[0021] The first device encapsulates and sends the alarm data only after determining that the data flow and the alarm event meet the linkage processing conditions, which can avoid affecting the device performance due to frequent sending of alarm data.

[0022] As a first optional implementation method, the linkage handling condition may include a first condition and a second condition. The first condition includes: the source address of the data stream belongs to an untrusted area. The second condition includes at least one of the following conditions: the alarm event is: the suspicious file type is inconsistent; the alarm event is: a suspicious alarm event, the confidence of the alarm event is higher than the first threshold, and the data stream includes an executable file; the alarm event is: a suspicious attack intrusion event, and the confidence of the alarm event is higher than the second threshold.

[0023] The first threshold may be smaller than the second threshold. For example, the first threshold may be 70, the second threshold may be 80, and the executable file may include an executable (EXE), a dynamic link library (DLL), and a hypertext preprocessor (PHP) file. In the first implementation, since the data stream comes from an untrusted area, it can correspond to an attack intrusion scenario.

[0024] As a second optional implementation, the linkage handling condition may include a first condition and a second condition. The first condition includes: the source address and the destination address of the data flow both belong to the trusted area. The second condition includes: the alarm event is: suspicious server message block (SMB) sharing, suspicious high-risk vulnerability exploitation, or suspicious remote desktop protocol (RDP) desktop transmission, and the confidence of the alarm event is higher than a third threshold.

[0025] The third threshold may be greater than the first threshold, for example, the third threshold may be 80. In the second implementation, since the source address and the destination address of the data flow both belong to the trusted zone, it can correspond to the scenario of lateral movement in the intranet.

[0026] As a third optional implementation method, the linkage disposal condition may include a first condition and a second condition. The first condition includes: the source address of the data stream belongs to a trusted area, and the destination address of the data stream belongs to an untrusted area. The second condition includes at least one of the following conditions: the alarm event is: malicious domain name connection, malicious command and control (C&C) communication, or downloading of malicious files, and the confidence of the alarm event is higher than the fourth threshold; the alarm event is: suspicious domain generation algorithm (DGA) request, suspicious C&C communication, or downloading of suspicious files, and the confidence of the alarm event is higher than the fifth threshold; the process or parent process that initiates the data stream is a suspicious process; the alarm event is: suspicious vulnerability exploitation success abnormal connection event, and the confidence of the alarm event is higher than the sixth threshold.

[0027] The fourth threshold may be a threshold corresponding to a blocking alarm, for example, the fourth threshold may be 95. The fifth threshold and the sixth threshold may be less than the fourth threshold, for example, the fifth threshold may be 75, and the sixth threshold may be 70 or 75. In the third implementation, since the source address of the data flow belongs to a trusted area and the destination address belongs to an untrusted area, it may correspond to a lost external connection scenario.

[0028] Optionally, the method may further include: the first device receiving a second handling strategy sent by the second device, where the second handling strategy is generated after the second device detects a threat entity based on the alarm data; and the first device executing the second handling strategy.

[0029] Wherein, if the first device is a network device and the second device is a terminal device, or if both the first device and the second device are terminal devices, the second handling strategy may include: blocking the source IP of the data flow, and / or, isolating the host of the second device. If the first device is a terminal device and the second device is a network device, the second handling strategy may include: host isolation, and / or, linkage detection strategy. The linkage detection strategy is used for the first device to execute so that the second device can be linked with the first device to detect and eradicate the threat entity in the first device.

[0030] In a second aspect, an alarm method is provided, the method comprising: a second device receives a message from a first device, the message encapsulating alarm data, and the second device performs threat detection and / or threat disposal based on the alarm data. The alarm data is obtained by the first device performing threat detection on a data flow passing through the first device, the data flow also flows through the second device, and the flow identifier of the message is consistent with the flow identifier of the data flow.

[0031] Optionally, the second device is a terminal device, and the process of the second device performing threat detection and / or threat disposal based on the alarm data may include: the second device determines a process call chain associated with the alarm data in the second device, and performs threat detection and / or threat disposal based on the process call chain.

[0032] Optionally, the alarm data may include: an association type; the process in which the second device determines a process call chain associated with the alarm data in the second device may include: the second device determines a process call chain associated with the alarm data in the second device based on the association type.

[0033] Optionally, the second device is a network device, and the first device is a terminal device. Accordingly, the process of the second device performing threat detection and / or threat disposal based on the alarm data may include: the second device determines the associated data associated with the first device in the second device, and performs threat detection and / or threat disposal based on the alarm data and the associated data. The associated data may include other alarm data and / or log data.

[0034] Optionally, the alarm data may further include: a first handling strategy; the method may further include: the second device executing the first handling strategy.

[0035] Optionally, the method may further include: if the second device detects a threat entity based on the alarm data, sending a second handling strategy to the first device, where the second handling strategy is for the first device to execute.

[0036] According to a third aspect, an alarm device is provided. The alarm device may include at least one module. The at least one module may be used to implement the alarm method provided by the first aspect or the second aspect.

[0037] In a fourth aspect, an alarm device is provided, the alarm device comprising a processor and a memory. The processor is used to execute instructions stored in the memory to implement the alarm method provided in the first aspect or the second aspect.

[0038] In a fifth aspect, a computer-readable storage medium is provided, in which a computer program is stored. When the computer program is executed, the alarm method provided in the first aspect or the second aspect is implemented.

[0039] In a sixth aspect, a computer program product is provided, which includes a program or code, and when the program or code is executed, the alarm method provided in the first aspect or the second aspect is implemented.

[0040] In a seventh aspect, a threat handling system is provided, which includes a first device and a second device, wherein the first device is used to execute the method provided in the first aspect, and the second device is used to execute the method provided in the second aspect.

[0041] Optionally, the system may further include a cloud platform, which may be a public cloud platform or a private cloud platform. The first device and the second device may also report data to the cloud platform, and the cloud platform may perform threat analysis based on the received data, and issue disposal strategies to the first device and the second device respectively. The data reported by the first device and the second device may include at least one of the following: alarm data, metadata of traffic data, log data, and threat disposal results, etc.

[0042] In summary, the present application provides an alarm method, device and system. In the solution provided by the present application, after the first device performs threat detection on the received data stream, if an alarm event is detected, the alarm data of the alarm event can be encapsulated in a message and the message can be sent to the second device. The second device can associate the alarm data with the process call chain, and perform threat detection and threat disposal based on the process call chain. As a result, the first device and the second device realize the linkage detection and disposal of the threat entity. In addition, since the first device can directly encapsulate the alarm data in the message and send it to the second device, that is, the alarm data does not need to be processed by the cloud platform, the time consumption of threat detection and disposal is effectively shortened, which can ensure that network attacks are blocked in time, and can effectively reduce the waste of computing resources of the cloud platform. BRIEF DESCRIPTION OF THE DRAWINGS

[0043] Figure 1It is a schematic diagram of an application scenario of an alarm method provided in an embodiment of the present application;

[0044] Figure 2 It is a schematic diagram of an application scenario of another alarm method provided in an embodiment of the present application;

[0045] Figure 3 It is a flowchart of an alarm method provided in an embodiment of the present application;

[0046] Figure 4 It is a schematic diagram of an implementation method of an alarm method provided in an embodiment of the present application;

[0047] Figure 5 It is a schematic diagram of another implementation method of the alarm method provided in an embodiment of the present application;

[0048] Figure 6 This is a schematic diagram of the structure of an IPv6 message provided in an embodiment of the present application;

[0049] Figure 7 It is a structural diagram of a DOH provided in an embodiment of the present application;

[0050] Figure 8 It is a structural diagram of an option field provided in an embodiment of the present application;

[0051] Fig. 9 It is a schematic diagram of a packaging format of alarm data provided in an embodiment of the present application;

[0052] Fig.10 This is a schematic diagram of the structure of an SRv6 message provided in an embodiment of the present application;

[0053] Fig.11 It is a structural schematic diagram of an alarm device provided in an embodiment of the present application;

[0054] Fig.12 is a structural schematic diagram of another alarm device provided in an embodiment of the present application;

[0055] Fig.13 It is a structural diagram of another alarm device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0056] The following describes in detail the alarm method, device and system provided by the embodiments of the present application in conjunction with the accompanying drawings. In order to make the technical solution provided by the embodiments of the present application clearer, before specifically describing the technical solution provided by the embodiments of the present application, the relevant terms are first explained.

[0057] Ransomware: A type of malware that encrypts a user's files or system and then demands a ransom for a decryption key or to restore access to the system. Ransomware is usually spread through email, brute force attacks, and network exploits. Once a user's system is infected, the ransomware displays a warning window and demands that the user pay a ransom, otherwise the user's files or system will be permanently locked.

[0058] Data leakage: refers to the process in which sensitive data is leaked to unauthorized persons, organizations, or websites without authorization or permission. Such sensitive data may include personal information, financial information, business secrets, intellectual property, network information, etc. Data leakage may lead to personal privacy leakage, financial loss, damage to business reputation, etc. Therefore, it is very important to protect data security and privacy.

[0059] Mining Trojan: A type of malware that uses the computing power of an infected computer to mine cryptocurrencies for profit. This Trojan is usually installed on a computer without the user's knowledge, and then uses the computer's central processing unit (CPU) or graphics processing unit (GPU) resources to mine cryptocurrencies. Since mining requires a lot of computing power, this Trojan can cause the computer to become very slow or even cause the system to crash. In addition, mining Trojans may also cause increased electricity bills because they consume a lot of power resources.

[0060] Remote control Trojan: Also known as remote control software, it can remotely control the infected computer without authorization. Attackers can use remote control Trojans to steal sensitive information on the infected computer, monitor user activities, manipulate computer operations, etc. Remote control Trojans are usually spread through emails, malicious websites, file sharing, etc. Once infected, it will run in the background and is not easily detected by users.

[0061] Zero-day vulnerabilities: refers to security vulnerabilities that have not yet been discovered or publicly disclosed, so there is no known solution or patch to fix it. These vulnerabilities are often exploited by hackers or attackers to gain unauthorized access or execute malicious code. Because these vulnerabilities have not yet been discovered or publicly disclosed, they pose a great threat to the security of systems and applications.

[0062] Compromised host (also called compromised device): refers to a computer system that has been hacked and invaded. Hackers can invade computer systems in various ways, such as exploiting vulnerabilities, malware, and social engineering. Once hackers invade a computer system, they can execute malicious code in the system, steal sensitive information (data leakage, lateral movement), and destroy the system (ransom, data erasure). Compromised hosts are a serious security threat to both individuals and organizations, because hackers can use compromised hosts to attack other computers or use compromised hosts for ransom, etc.

[0063] Metadata: refers to some metadata information of network traffic recorded during network communication, such as source Internet protocol (IP) address, destination IP address, protocol type, port number, packet size and timestamp, etc. This metadata information can be used for network traffic analysis, security monitoring and / or network performance optimization. Metadata information can include network layer 3 and 4 information elements and application protocol information elements.

[0064] Ransomware, data leakage, distributed denial of service attack (DDOS), 0day vulnerabilities, mining Trojans, and remote control Trojans are always the key pain points of enterprise security. The entire attack chain of a network attack can usually be divided into several steps, including attack intrusion (such as vulnerability exploitation, scanning, and brute force cracking), attack vector delivery and execution, external C&C communication, execution of targets (such as ransomware, mining, DDOS, and data leakage), and lateral movement. At present, the speed of attackers is accelerating. Once the vulnerability is exposed (about 15 minutes), scanning begins. 80% of ransomware samples begin to encrypt within 5 minutes of starting to run, and the encryption speed is above 30 megabits per second (Mb / S). For these network attacks, it is necessary to conduct high-precision attack analysis, identify compromised devices and threat entities on them, and eradicate attacks as early as possible in the entire attack chain to mitigate risks and gain time for attack repair and eradication.

[0065] The attack intrusion stage, external C&C communication, downloading of malicious samples, data leakage, lateral movement, etc. in the above attack scenarios are at the forefront and indispensable in the entire attack chain. Most network security vendors will discover the compromised host through malicious connections and link terminal devices to eradicate malicious attacks.

[0066] To ensure network security, network devices (such as firewalls, switches, and routers) can block malicious network connections or detect suspicious network connections and generate alarm data based on threat detection methods such as intrusion prevention systems (IPS) rule matching, threat intelligence matching, and / or artificial intelligence (AI) model prediction after receiving data streams. After that, the network device can send metadata generated by the original data stream or filtered metadata, as well as alarm data, to the public cloud or private cloud platform.

[0067] Terminal devices can collect log data and perform threat detection based on host IPS (HIPS) rule matching, intelligence matching, AI model prediction, user and entity behavior analytics (UEBA) and / or graph reasoning. For threat entities determined to be malicious, the terminal device can handle the threat entity, such as killing the process, isolating files and / or removing accounts, and send the original log data or filtered log data collected by the terminal device, as well as the alarm data to the public cloud or private cloud platform. The terminal device can be a PC, workstation or server, etc.

[0068] After receiving traffic metadata and alarm data from network devices, as well as log data and alarm data from terminal devices, the public cloud or private cloud platform can associate data based on unified assets, and conduct threat analysis based on multiple methods such as rule matching, intelligence matching, graph reasoning and / or AI reasoning. In addition, the cloud platform can effectively discover the terminal devices where attacks that cannot be blocked by network devices and terminal devices are located, the threat entities corresponding to the attacks, and the threat entities that have not been completely eradicated on network devices and terminal devices. The cloud platform can also generate disposal strategies and send them to terminal devices and network devices for execution by the two devices. For example, network devices execute strategies such as isolating hosts and restricting access to network segments, and terminal devices execute strategies such as isolating files, killing processes, and blocking ports.

[0069] However, in the above solution, from the detection of malicious connections by network devices to the issuance of disposal policies to terminal devices, there is an offline detour through the public cloud or private cloud platform, and data association, threat assessment and disposal policy issuance need to be performed on the public cloud or private cloud platform. As a result, the overall time consumption is at least 10 seconds, and the continued malicious attack in the terminal device may cause relatively large harm, such as ransomware attacks, DDoS, data leakage and worm propagation.

[0070] Furthermore, after the alarm data generated by the network device is sent to the cloud platform, it needs to be associated with the log data and alarm data sent by the terminal device for further threat analysis. This process will waste the computing resources of the cloud platform. Furthermore, if the NAT device is between the firewall and the terminal device, the cloud platform also needs to obtain the NAT log in order to convert the public network address of the data flow corresponding to the threat detected by the network device (such as the firewall) into an intranet address and then associate it with the data flow reported by the terminal device. As a result, the process of tracing the alarm data generated by the network device to the terminal device becomes more complicated due to the networking topology.

[0071] Figure 1 is a schematic diagram of an application scenario of an alarm method provided in an embodiment of the present application, such as Figure 1 As shown, the application scenario may include: a cloud platform 01, a first device 02, and a second device 03. The cloud platform 01 may be a server cluster composed of multiple servers, and the cloud platform 01 may be a public cloud platform or a private cloud platform. The first device 02 may be a network device, and the second device 03 may be a terminal device; or, both the first device 02 and the second device 03 may be terminal devices; or, the first device 02 may be a terminal device, and the second device 03 may be a network device. The network device may be a firewall, a router, or a switch, etc., and the terminal device may be a PC, a workstation, or a server, etc.

[0072] Figure 2 FIG. 1 is a schematic diagram of an application scenario of another alarm method provided in an embodiment of the present application. Figure 2 As shown, the alarm method can be applied to three different scenarios, where scenario 1 is an attack and intrusion scenario, scenario 2 is an intranet lateral movement scenario, and scenario 3 is a compromised external connection scenario. Figure 2 The trusted boundary in is the network boundary between the trusted area (such as the enterprise intranet) and the untrusted area (such as the public network).

[0073] In the attack and intrusion scenario shown in scenario 1, a hacker or attacker in an untrusted area initiates a connection to a terminal device in a trusted area through a network device. Accordingly, in this attack and intrusion scenario, the first device 02 may be a network device, and the second device 03 may be a terminal device.

[0074] In the intranet lateral movement scenario shown in scenario 2, the terminal device that has been hacked by the attacker (also referred to as a compromised terminal device or a compromised host) conducts lateral penetration of other terminal devices in the trusted area. In this lateral penetration scenario, the first device 02 can be a terminal device that has been hacked by the attacker, or can be a network device connected to the terminal device, and the second device 03 can be other terminal devices in the trusted area.

[0075] In the compromised external connection scenario shown in scenario 3, the terminal device that has been hacked by the attacker initiates a connection to the attacker in the untrusted area through the network device to request more information (such as requesting instructions for the next attack action) or send data to the outside. In this compromised external connection scenario, the first device 02 can be a terminal device that has been hacked by the attacker, and the second device 03 can be a network device. Alternatively, the first device 02 can be a network device, and the second device 03 can be a terminal device.

[0076] In an embodiment of the present application, the first device 02 can perform threat detection on the data stream passing through. If an alarm event is detected, the alarm data of the alarm event is encapsulated in a message, and the message is sent to the second device 03 through which the data stream flows, and the flow identifier of the message is consistent with the flow identifier of the data stream. The second device 03 can perform threat detection and / or threat disposal based on the alarm data in the message. The flow identifier of the message carrying the alarm data is consistent with the flow identifier of the data stream in which the alarm event is detected, that is, the alarm data is carried directly through the message of the data stream or the message of the reverse data stream of the data stream. In this way, the second device can quickly obtain the alarm data obtained by the first device, and the first device 02 and the second device 03 realize the linkage detection and / or disposal of the threat entity. In addition, since the alarm data does not need to be processed by the cloud platform, the time consumption of threat detection and / or disposal is effectively shortened, and the waste of processing resources of the cloud platform is effectively reduced. That is, the solution provided in the embodiment of the present application can link two devices together in a simple and low-cost manner to efficiently and quickly perform threat detection and / or threat disposal.

[0077] Figure 3 This is a flowchart of an alarm method provided by an embodiment of the present application, which can be applied to Figure 1 or Figure 2 In the application scenario shown.

[0078] like Figure 3 As shown, the method includes:

[0079] Step 101: The first device performs threat detection on the data flow passing through.

[0080] In the embodiment of the present application, a detection module (eg, an intrusion prevention engine) is deployed in the first device, and the first device can perform threat detection on the data stream passing through the detection module. The threat detection may also be referred to as threat matching or threat analysis.

[0081] If the first device is a network device, the data stream passing through may be a data stream received by the first device. Figure 2In the scenario 1 shown, the network device can receive the data stream (e.g., request stream) sent by the attacker to the terminal device, and can perform threat detection on the data stream. In scenario 2, the network device can receive the data stream (e.g., request stream) sent by the compromised terminal device to other terminal devices, and can perform threat detection on the data stream. In scenario 3, the network device can receive the data stream (e.g., request stream) sent by the compromised terminal device to the attacker, and can perform threat detection on the data stream.

[0082] If the first device is a terminal device, the data stream flowing through may be a data stream received by the first device, or may be a data stream actively initiated by the first device. Figure 2 In the scenario 2 shown, the compromised terminal device can initiate a data stream (such as a request stream) to other terminal devices in the network, and can perform threat detection on the initiated data stream. In scenario 3, the compromised terminal device can initiate a data stream (such as a request stream) to the attacker, and can perform threat detection on the initiated data stream. In scenario 2, the compromised terminal device may also receive data streams sent by other devices (such as attackers), and can perform threat detection on the received data streams.

[0083] Optionally, the threat detection method may include at least one of rule matching, intelligence matching, and AI model prediction. If the first device is a terminal device, the threat detection method may also include UEBA and graph reasoning. For example, refer to Figure 4 and Figure 5 , an intrusion prevention engine is deployed in the first device. After the first device obtains the data stream passing through, it can first perform protocol parsing on the data stream, and then perform threat detection on the data stream through the intrusion prevention engine. The intrusion prevention engine can identify suspicious or malicious data streams through threat intelligence matching, signature library (i.e., IPS rules or HIPS rules) matching, and AI engine matching.

[0084] from Figure 4 and Figure 5 It can be seen that when the intrusion prevention engine matches threat intelligence, it can first perform a local cache match, that is, it can match the data stream with the locally cached threat intelligence. If the local cache match does not hit, a remote intelligence query can be performed and the query results (that is, the threat intelligence matched from the cloud) can be cached locally. In addition, when using the AI ​​engine for threat detection, the intrusion prevention engine can use a local small model for threat detection, or it can link the AI ​​large model in the cloud for threat detection. Among them, the small AI model stored locally on the first device can be compressed and cropped by the large AI model in the cloud.

[0085] Step 102: If the first device detects an alarm event based on the threat detection, the alarm data of the alarm event is encapsulated in a message.

[0086] The flow identifier of the message is consistent with the flow identifier of the data flow. The flow identifier is used to identify the data flow. For example, the flow identifier can be tuple information, and the tuple information is, for example, five-tuple information, and the five-tuple information includes: source Internet protocol (IP) address, source port, destination IP address, destination port and transport layer protocol. The flow identifier of the message is consistent with the flow identifier of the data flow, which can mean: the flow identifier of the message is the same as the flow identifier of the data flow; or, the flow identifier of the message is the same as the flow identifier of the reverse data flow of the data flow. For example, device 1 and device 2 exchange messages, device 1 sends a message to device 2 through data flow 1, and device 2 sends a message to device 1 through data flow 2, wherein the source address in the flow identifier of data flow 1 is the same as the destination address in the flow identifier of data flow 2, and the destination address in the flow identifier of data flow 1 is the same as the source address in the flow identifier of data flow 2, then data flow 2 is called the reverse data flow of data flow 1, and data flow 1 is the reverse data flow of data flow 2. In other words, the flow identifier of the message is the same as the flow identifier of the reverse data flow of the data flow, which can be: the source and destination addresses in the flow identifier of the message are opposite to the source and destination addresses of the data flow, that is, the source address of the message is the same as the destination address of the data flow, and the destination address of the message is the same as the source address of the data flow.

[0087] In an embodiment of the present application, the message may belong to the data stream, that is, the first device may directly encapsulate the alarm data in the message of the data stream flowing through, that is, the first device may send the alarm data along with the stream. Alternatively, the message may be a message of the reverse data stream of the data stream, that is, the first device does not need to change the content of the message in the data stream, and may encapsulate the alarm data in the message of the reverse data stream. Among them, the message in the reverse data stream may also be referred to as a reverse message. The source address of the reverse data stream is the same as the destination address of the data stream, and the destination address of the reverse data stream is the same as the source address of the data stream.

[0088] Optionally, if the message is a message of the reverse data flow, it may be any message in the reverse data flow received by the first device. For example, the any message is a message of the reverse data flow received by the first device when the first device detects an alarm event.

[0089] Optionally, if the message is a message of a reverse data flow, the message may be a message actively constructed by the first device. For example, the first device actively constructs a TCP reset (reset, RST) message and carries alarm data in the TCP RST message. The source address of the actively constructed message is the same as the destination address of the data flow where the alarm event is detected.

[0090] Optionally, if the message is a message of a reverse data flow, the message may be a response message of a message in the data flow. A response message may refer to a message triggered by a message in a data flow. For example, taking the transmission control protocol (TCP) as an example, the message in the data flow may be a synchronization (SYN) message, and the response message may be an acknowledgement (ACK) message. Alternatively, the message in the data flow may be an ACK message, and the response message may be another ACK message for responding to the ACK message or a data message triggered by the ACK message to be sent. Alternatively, the message in the data flow may be a data message, and the response message may be an ACK message. Alternatively, the message in the data flow may be a data message, and the response message may be a data message. The embodiment of the present application does not limit the type of the response message, and only needs to ensure that the response message is a message for responding to the message triggered by a message in the data flow.

[0091] In the embodiment of the present application, the response message may be a response message sent by other devices and received by the first device, that is, after the first device detects the alarm event, the alarm data is encapsulated in the received response message. Alternatively, the response message may also be generated by the first device, that is, after the first device detects the alarm event, it may actively construct a response message to encapsulate the alarm data.

[0092] It is understandable that if the data stream flows from the first device through the second device, the message can be a message in the data stream. That is, the first device can directly encapsulate the alarm data in the message of the data stream sent to the second device. If the data stream flows from the second device through the first device, the message can be a message in the reverse data stream of the data stream, that is, the second device can encapsulate the alarm data in the message in the received reverse data stream, or in the constructed reverse message.

[0093] For example, in Figure 2 In the scenarios 1 and 2 shown, the data stream flows from the first device to the second device, and the first device can directly encapsulate the alarm data in the message of the data stream. Alternatively, in scenario 3, if the first device is a terminal device and the second device is a network device, the first device can also directly encapsulate the alarm data in the message of the data stream initiated by it.

[0094] exist Figure 2In the scenario 3 shown, if the first device is a network device and the second device is a terminal device, the first device can encapsulate the alarm data in the message of the reverse data flow sent by the second device after performing threat detection on the data flow sent by the second device. Alternatively, the first device can actively construct a response message sent to the second device to encapsulate the alarm data. The source address of the actively constructed response message is the same as the destination address of the data flow where the alarm event is detected.

[0095] Optionally, the alarm data encapsulated by the first device in the message may include at least one of the following:

[0096] 1. The attack scenario type (class) of the alarm event, which can also be called the threat type. The threat type may include: Trojan horse, backdoor virus, worm, virus, botnet, information disclosure, code execution, and buffer overflow, etc.

[0097] 2. The confidence of the alarm event may be in the range of 60 to 100, and the range may be divided into multiple levels, for example, four levels: very high, high, medium, and low.

[0098] 3. The risk score of the attack scenario may range from 60 to 100, and the range may be divided into multiple levels, for example, four levels: fatal, high risk, medium risk, and low risk.

[0099] 4. The first device performs an action on the alarm event, which may include an alert and a block. The value of the alert may be 0, and the value of the block may be 1.

[0100] 5. The rule number of the detection rule that detected the alarm event. The rule number can also be called the threat ID.

[0101] 6. A first response for execution by the second device, which may include: an alert and host isolation, wherein the value of the alert may be 0 and the value of the host isolation may be 1.

[0102] 7. Correlate type, which is used to indicate the method of associating the alarm data to the process call chain of the second device, which may include up to 32 optional methods: process, file md5 (file_md5), file name (file_name), command (command), user name (user_name), asset identifier (asset_id) and content (content), etc.

[0103] 8. The correlation value (correlate_value) corresponding to the correlation type. The length of the correlation value can be 64 bytes, which can include md5, file_name, command, user_name, asset_id and content, etc.

[0104] Among them, the association type and the association value can be determined based on the triggering method of the alarm event. For example, if the alarm event is triggered by a suspicious or malicious file, such as the alarm event in scenario 1 is "suspicious file type inconsistency", or the alarm event in scenario 3 is "downloading malicious files", then the association type can include file md5 and / or file name. If the alarm event is triggered by a suspicious or malicious network connection, such as the alarm event in scenario 1 is "suspicious attack intrusion event", or the alarm event in scenario 3 is "malicious domain name connection", then the association type can be process. If the alarm event is triggered by a suspicious or malicious command, such as the alarm event in scenario 3 is "malicious C&C communication" or "suspicious C&C communication", then the association type can be command. If the alarm event is triggered by suspicious or malicious content, such as the alarm event in scenario 2 is "suspicious SMB sharing" or "suspicious RDP desktop transmission", then the association type can be content. If the alarm event is triggered by a terminal device, for example, in scenario 3, the alarm event is "abnormal connection event of suspected successful exploitation of vulnerability", the association type may be a user name or an asset identifier.

[0105] Step 103: The first device sends the message to the second device through which the data flow flows.

[0106] After the first device completes encapsulation of the alarm data in the message, it can send the message to the second device through which the data stream flows. The alarm data in the message can be used for threat detection and / or threat disposal by the second device. Since the flow identifier of the message is consistent with the flow identifier of the data stream, the above step 103 can also be understood as: the first device can reuse the protocol channel between it and the second device to transmit the alarm data. Based on this, the second device can directly associate the alarm data (for example, with the process call chain, or with other alarm data and log data), and the association process will not be affected by the NAT deployment location, and its application flexibility is high.

[0107] In the scenario where the first device encapsulates the alarm data in the message of the data flow, or encapsulates the alarm data in the message of the received reverse data flow (such as the response message), the process of encapsulating the alarm data will delay the sending of the message, and the second device will perform the attack action based on the information carried by the message after receiving the message. For example, the threat entity in the second device needs to decide the next attack action based on the content of the response message. Therefore, this solution can also suspend the execution of the attack and buy time for defense.

[0108] Optionally, for Figure 2 In the scenario 1 shown in the figure, after the network device detects the alarm event, it can also send a blocking packet to the attacker; Figure 2 In the scenarios 2 and 3 shown, after the network device detects the alarm event, it can also send a blocking packet to the victim terminal device, wherein the blocking packet can be a TCP reset packet.

[0109] Step 104: The second device performs threat detection and / or threat handling based on the alarm data.

[0110] In an embodiment of the present application, after receiving the message sent by the first device, the second device can parse the message to obtain the alarm data encapsulated by the first device. For example, the message encapsulating the alarm data can be an IPv6 message, and the alarm data can be encapsulated in an extended message header of the IPv6 message. The second device can parse the IP layer of the IPv6 message to obtain the alarm data. After that, the second device can perform threat detection and / or threat disposal based on the alarm data.

[0111] It is understandable that the second device may first perform threat detection based on the alarm data, and if a threat entity is detected, the threat entity may be subjected to threat disposal. If the second device does not detect a threat entity, there is no need to perform threat disposal operations. Alternatively, after the second device obtains the alarm data, it may also directly perform threat disposal based on the alarm data. For example, if the alarm data includes a first disposal strategy, the second device may directly execute the first disposal strategy.

[0112] Optionally, the second device may determine whether threat detection needs to be performed first based on the confidence level in the alarm data. If the confidence level is less than a threshold, the second device may first perform threat detection based on the alarm data, and then determine whether threat disposal needs to be performed based on the detection result. If the confidence level is greater than a threshold, the second device may directly perform threat disposal. For example, Figure 2In the scenario 3 shown, if the confidence in the alarm data sent by the network device to the terminal device is greater than the threshold, the terminal device can determine that it has been compromised. At this time, if the process call chain associated with the terminal device through the alarm data is a threat entity that can be directly handled, the terminal device can directly handle the threat entity. Among them, the terminal device can be pre-configured with the conditions that need to be met by the threat entity that can be directly handled. For example, the condition may include: the threat entity is a file associated with an external process, or a file without a trusted signature associated with an external process.

[0113] In the embodiment of the present application, if the second device is a network device, the threat handling method may include at least one of the following: blocking sessions, host isolation, and limiting access to network segments, etc. If the second device is a terminal device, the threat handling method may include at least one of the following: killing processes, file isolation, infected file recovery, account removal, port blocking, and host micro-isolation, etc.

[0114] In a first optional implementation, the second device may be a terminal device, such as a PC, a workstation or a server. Figure 4 As shown, the second device can determine the process call chain associated with the alarm data in the second device, that is, the second device can associate the alarm data with the process call chain in the second device. Afterwards, the second device can perform threat detection and / or threat disposal based on the associated process call chain. For example, the second device can perform threat detection and / or threat disposal based on the alarm data and the associated process call chain.

[0115] Optionally, the second device may determine the process call chain associated with the alarm data based on the association mode indicated by the association type field in the alarm data and the association value of the association mode. For example, if the association type is a process, the second device may directly determine that the associated process call chain is the process call chain corresponding to the process that receives the data stream. If the association type is a file md5, the second device may determine the associated process call chain based on the md5 in the association value field. If the association type is a file name, the second device may determine the associated process call chain based on the file name in the association value field. If the association type is a command, the second device may determine the associated process call chain based on the command in the association value field. If the association type is content, the second device may determine the associated process call chain based on the content in the association value field.

[0116] For example, the second device can establish a data traceability graph in real time based on the process call chain, process operation file, registry, network, terminal alarm data and network device alarm data. In addition, the second device can perform threat detection based on the traceability graph, and the threat detection method can include causal association rule matching and graph AI engine detection. Based on the threat detection, the second device can detect attack events in a timely and accurate manner and lock the threat entity.

[0117] In a second optional implementation, the first device may be a terminal device, and the second device may be a network device, such as a firewall, a switch, or a router. The network device can determine the associated data associated with the first device in the second device, and the associated data may include other alarm data and / or log data of the first device. Afterwards, the second device may perform threat detection and / or threat disposal based on the alarm data and the associated data. For example, if the second device determines that the first device has been compromised based on threat detection, it may perform threat disposal on the first device, such as blocking the session or performing host isolation.

[0118] In the second implementation, if Figure 5 As shown, the second device can perform association analysis based on a unified asset, where the asset can refer to a terminal device. After the second device performs association analysis based on the asset, it can determine other associated data in the second device that is associated with the first device, and perform threat detection and / or threat disposal based on the received alarm data and the determined associated data. Since the second device obtains more data, the reliability of threat detection and / or threat disposal can be ensured to be high.

[0119] As described in step 102 above, the alarm data encapsulated by the first device may include the attack scenario type, confidence level, risk score, and disposal action, or may also include a rule number. The functions of various types of data in the alarm data are introduced below:

[0120] Attack scenario type: Different attack scenarios display different attack behaviors. For example, the main feature of ransomware is file encryption, and the attack behavior is abnormal file operation; the main feature of mining is CPU consumption, and the attack behavior is mainly abnormal CPU consumption; the main feature of data leakage is the outbound transmission of sensitive privacy data. The second device can determine the threat detection rules and models to be used in subsequent threat detection based on the attack scenario type.

[0121] Confidence: represents the credibility of the alarm judgment. The closer it is to 100, the more credible the judgment is. The second device can use this confidence during the threat detection process, that is, the confidence will affect the results of subsequent threat detection.

[0122] Risk score: represents the risk level of the corresponding threat, and the risk score can affect the handling priority. For example, the risk score of ransomware is higher than that of mining, which means that compared with mining, ransomware needs to be handled in real time. In addition, different customers may set different risk scores for the same attack scenario. The second device can combine the risk score and other indicators (such as confidence) to determine whether to handle the threat in real time.

[0123] Disposal action: represents the way the first device handles the alarm. If the disposal action is blocking, it means that the first device has sufficient evidence to prove that the data flow is malicious. The second device can determine whether it needs to quickly dispose of the entity associated with the alarm data based on the disposal action. For example, if the second device is a terminal device, and the disposal action in the alarm data encapsulated by the first device is blocking, the second device can quickly dispose of the process call chain associated with the alarm data.

[0124] Rule number: The logical identifier corresponding to the detection rule. Since some vulnerability scenarios are special, the rule numbers for these vulnerability scenarios will have certain special features when they are arranged, such as being limited to a certain rule number range. Based on this, the second device can perceive these special vulnerability exploitation scenarios based on the rule number, and can determine the detection rules required for subsequent threat detection based on the vulnerability exploitation scenario. It can be understood that the rule number can solve the problem of too coarse granularity in the classification of attack scenario types.

[0125] Step 105: If the second device detects a threat entity based on the alarm data, the second device sends a second handling strategy to the first device.

[0126] Optionally, in the embodiment of the present application, after the second device performs threat detection based on the alarm data, if a threat entity is detected, a second handling strategy may be generated and sent to the first device. The second handling strategy may be used for execution by the first device.

[0127] For example, for Figure 2 In the illustrated scenarios 1 and 2, and the case where the first device is a network device in scenario 3, the second handling strategy sent by the second device may include: blocking the source IP of the data stream, and / or, isolating the second device from the host. For the case where the first device is a terminal device and the second device is a network device in scenario 3, the second handling strategy may include: host isolation, and / or, linkage detection strategy. The linkage detection strategy is used for execution by the first device so that the second device can be linked with the first device to detect and eradicate the threat entity in the first device.

[0128] Step 106: The first device executes the second handling strategy.

[0129] Optionally, if the first device receives the second handling strategy sent by the second device, the first device may also execute the second handling strategy to effectively block network attack behaviors. Figure 2 In the illustrated scenarios 1 and 2, and in scenario 3 where the first device is a network device, the first device may block the source IP of the data stream and / or perform host isolation on the second device. In scenario 3 where the first device is a terminal device, the first device may perform host isolation and / or execute the linkage detection strategy issued by the second device so that the second device can detect and eradicate the threat entity in the first device.

[0130] The following describes the encapsulation method of the alarm data in the message. In the embodiment of the present application, the first device can encapsulate the alarm data in an IPv6 message. Figure 6 As shown, the IPv6 message includes the following fields: version, traffic class, flow label, payload length, next header, hop limit, source address, destination address, hop by hop options header, DOH, routing header, and payload, etc. The first device may carry the alarm data in an extended message header of the IPv6 message.

[0131] In the embodiment of the present application, the extended message header may be DOH. Figure 7 As shown, the DOH may include a next header, an extension header length, and options fields. Figure 8 As shown, the option field may include an option type, an option data length, and an option data field. The value of the option type field may be an unoccupied value, and the option data length may be determined based on the content of the alarm data, and may be aligned to four bytes. The first 64 bits of the option data field may be fixed-length content, and the data length of the associated value may be confirmed based on the value of the correlate_value length field.

[0132] The data format of this option data field can refer to Fig. 9 ,like Fig. 9As shown, the option data field may include: a 32-bit threat identification field, a 5-bit type (class) field, a 2-bit confidence level (CL) field, a 2-bit risk level (RL) field, a 1-bit action (A) field, a 5-bit correlation type (correlate_type, CT) field, a 6-bit correlation value length (correlate_value length, CVL), a 1-bit response strategy (response, R) field, and a reserved (reserved) field. If the value of CVL is not 0, the reserved field may be followed by an associated value field for storing the associated value. Among them, the class field is used to carry the attack scenario type, the R field is used to carry the first disposal strategy, the CL field is used to carry the confidence level, and the RL field is used to carry the risk score level. The first device encapsulates the confidence level and the risk score level into the message, which can effectively save the number of bytes transmitted.

[0133] The encapsulation format of the above-mentioned alarm data is only an example. It can be understood that the types of information included in the alarm data encapsulated in the message, the number of bits occupied by each type of information, the organization and arrangement of each type of information, etc. can all be set as needed, and the embodiments of the present application do not limit this.

[0134] It can be understood that if the second device is a terminal device and is the destination node of the message, the second device can directly obtain and process the alarm data encapsulated in the DOH. If the second device is a network device, the IPv6 message can also include an SRH, that is, the IPv6 message can be a segment routing based on IPv6 (SRv6) message. In addition, the segment list of the SRH can carry the SID of the second device, and the SID is used to instruct the second device to obtain and process the alarm data encapsulated in the DOH.

[0135] like Fig.10As shown, the SRv6 message may include an IPv6 message header, an SRH and an IPv6 payload. Among them, the SRH includes the following fields: next header, header extension length (Hdr Ext Len), routing header type (routing type), number of remaining segments (segment left, SL), last entry (last entry), flags, tags, segment list and optional TLV. Among them, the segment list includes segment list [0] to segment list [n], a total of n+1 identification fields (n can be an integer greater than or equal to 1), each identification field is used to carry the SID of a node in the message forwarding path, and the SID can be the IPv6 address of the node. The SL field in the SRH can be used to index the segment list, starting from the current value and decreasing in sequence until SL is 0, indicating that the index of the forwarding path defined by this segment list ends. Nodes that do not support SRv6 can act as forwarding (transit) nodes and forward by IPv6.

[0136] In the embodiment of the present application, the SRv6 path orchestration capability can be used to specify one or several nodes (i.e., network devices) on the path through which the message passes to obtain and process the alarm information in the DOH. For example, the network device indicated by each SID in the segment list can obtain and process the alarm data in the DOH to achieve the purpose of quickly blocking the threat.

[0137] Optionally, in the above step 102, the first device may encapsulate the alarm data in a message and send it to the second device after detecting that the alarm event and the data stream meet the linkage processing condition. Correspondingly, if the alarm data and the data stream do not meet the linkage processing condition, the second device does not need to send the alarm data to the second device via a message, that is, it does not need to be linked with the second device. The linkage processing condition may include a first condition and a second condition. By setting the linkage processing condition, it is possible to avoid the first device frequently sending alarm data and affecting the performance of the device and the system.

[0138] As a first possible example, the first condition may include: the source address of the data flow belongs to an untrusted area, that is, the data flow comes from an untrusted area. The second condition may include at least one of the following conditions:

[0139] The alarm event is: suspicious file type inconsistency;

[0140] The alarm event is: a suspicious alarm event, the confidence level of the alarm event is higher than a first threshold, and the data stream includes an executable file;

[0141] The alarm event is: a suspicious attack intrusion event, and the confidence level of the alarm event is higher than the second threshold.

[0142] The first threshold may be smaller than the second threshold. For example, the first threshold may be 70, the second threshold may be 80, and the executable file may include EXE, DLL, and PHP files.

[0143] As a second possible example, the first condition may include: the source address and the destination address of the data flow both belong to the trusted area. The second condition may include: the alarm event is: suspicious SMB sharing, suspicious high-risk vulnerability exploitation, or suspicious RDP desktop transmission, and the confidence of the alarm event is higher than a third threshold. The third threshold may be greater than the first threshold, for example, the third threshold may be 80.

[0144] As a third possible example, the first condition may include: the source address of the data flow belongs to the trusted area, and the destination address of the data flow belongs to the untrusted area. The second condition may include at least one of the following conditions:

[0145] The alarm event is: malicious domain name connection, malicious C&C communication, or downloading of malicious files, and the confidence of the alarm event is higher than the fourth threshold;

[0146] The alarm event is: suspicious DGA request, suspicious C&C communication, or downloading of suspicious files, and the confidence of the alarm event is higher than the fifth threshold;

[0147] The process or parent process that initiates the data flow is a suspicious process;

[0148] The alarm event is: an abnormal connection event of a suspected vulnerability being successfully exploited, and the confidence level of the alarm event is higher than a sixth threshold.

[0149] The fourth threshold may be a threshold corresponding to a blocking alarm, for example, the fourth threshold may be 95. The fifth threshold and the sixth threshold may both be smaller than the fourth threshold, for example, the fifth threshold may be 75, and the sixth threshold may be 70 or 75.

[0150] Based on the first condition of the above three examples, it can be seen that the first example can be applied to Figure 2 The scenario 1 shown is an attack intrusion scenario. This second example can be applied to Figure 2 In the scenario 2 shown, that is, the scenario of lateral movement within the intranet. This third example can be applied to Figure 2 The method provided in the embodiment of the present application designs different linkage processing conditions for different attack scenarios, which can minimize the impact on device and system performance while ensuring network security.

[0151] It is understandable that the sequence of steps of the alarm method provided in the embodiment of the present application can be adjusted appropriately, and the steps can be increased or decreased accordingly. For example, the above steps 105 and 106 can be deleted according to the situation.

[0152] In summary, the embodiment of the present application provides an alarm method. After the first device detects an alarm event based on the data flow flowing through, the alarm data of the alarm event can be encapsulated in a message, and the message is sent to the second device through which the data flow flows, and the flow identifier of the message is consistent with the flow identifier of the data flow. After the second device receives the message, it can perform threat detection and / or threat disposal based on the alarm data. Thus, the first device and the second device realize the linkage detection and / or disposal of the threat entity. In addition, since the first device can directly encapsulate the alarm data in the message and send it to the second device, that is, the alarm data does not need to be processed by the cloud platform, the time consumption of threat detection and / or disposal is effectively shortened, and the network attack can be blocked in time, and the waste of computing resources of the cloud platform can be reduced. For example, the method provided in the embodiment of the present application can effectively mitigate the impact of network attack behaviors such as extortion, mining, data leakage, lateral movement and DDOS, and win time for completely repairing the attack.

[0153] The present application also provides an alarm system, such as Figure 1 , Figure 2 , Figure 4 and Figure 5 As shown, the alarm system may include a first device and a second device. The first device and the second device may implement the alarm method provided by the above method embodiment, that is, the first device and the second device may be linked to perform threat detection and / or threat handling.

[0154] Optionally, continue to refer to Figure 1 , Figure 4 and Figure 5 , the alarm system may also include a cloud platform. Figure 4 and Figure 5 As shown, the second device may include an event management module, which can send the result of the second device's threat disposal based on the alarm data to the cloud platform for processing. In addition, the second device can also send the result of threat detection (such as the alarm data generated by the second device) and / or data associated with the alarm data sent by the first device (such as a process call chain or associated data, etc.) to the cloud platform. The first device can also send alarm data to the cloud platform. If the first device is a network device, it can also send metadata of the data flow and / or network log data to the cloud platform; if the first device is a terminal device, it can also send terminal log data to the cloud platform.

[0155] The cloud platform can conduct threat analysis based on the received data, and send a disposal strategy to the first device and the second device for execution by the first device and the second device. For example, the cloud platform can perform unified modeling and analysis on the various data received, discover advanced covert attacks, and lock the compromised host (i.e., the compromised terminal device) and the corresponding threat entity. Afterwards, the cloud platform can send disposal strategies such as isolating the host and / or limiting the host access scope to the corresponding network device for execution, and send disposal strategies such as process kill, file isolation, account deletion, and / or host micro-isolation to the terminal device corresponding to the attack for execution.

[0156] Optionally, the cloud platform can also visualize the received data, and can also visualize the cloud platform's own threat analysis results and the issued disposal strategies.

[0157] It is understandable that in this alarm system, the first device and the second device work together to perform threat detection, which can effectively detect and deal with most threat entities in the network. Furthermore, the first device and the second device can also report data to the cloud platform, and the cloud platform will conduct further threat analysis, which can effectively avoid missing threat entities. For example, the cloud platform can detect advanced covert attacks that the first device and the second device cannot detect. Compared with the first device and the second device not working together, but reporting data directly to the cloud platform, that is, only the cloud platform performs unified modeling and analysis, the solution provided by the embodiment of the present application can effectively reduce the waste of cloud computing resources.

[0158] The network device, terminal device and cloud platform may include multiple functional modules to implement the above method. The following is an exemplary introduction to the functional modules included in the network device, terminal device and cloud platform. As shown in Table 1, the network device may include an intrusion prevention engine and a policy module. The terminal device may include a traffic analysis engine, a data collection engine, a threat detection engine and a threat disposal module. The cloud platform may include a threat analysis module and a threat disposal module.

[0159] Table 1

[0160]

[0161] The present application also provides an alarm device, which can be applied to Figure 1 , Figure 2 , Figure 4 or Figure 5 The first device in the application scenario shown in the figure can be used to implement the steps performed by the first device in the above method embodiment. Fig.11 As shown, the alarm device comprises:

[0162] The detection module 201 is used to perform threat detection on the data stream passing through. The function of the detection module 201 can refer to the relevant description of step 101 in the above method embodiment. If the first device is a network device, the function of the detection module 201 can also refer to the functional description of the intrusion prevention engine in Table 1; if the first device is a terminal device, the function of the detection module 201 can also refer to the functional description of the traffic analysis engine in Table 1.

[0163] The encapsulation module 202 is used to encapsulate the alarm data of the alarm event in a message if an alarm event is detected based on threat detection, and the flow identifier of the message is consistent with the flow identifier of the data flow. The functional implementation of the encapsulation module 202 can refer to the relevant description of step 102 in the above method embodiment, and can refer to the functional description of the policy module in Table 1.

[0164] The sending module 203 is used to send the message to the second device through which the data flow flows, and the alarm data in the message is used for the second device to perform threat detection and / or threat disposal. The function of the sending module 203 can refer to the relevant description of step 103 in the above method embodiment.

[0165] Optionally, the message belongs to the data flow, or the message is a message in a reverse data flow of the data flow.

[0166] Optionally, if the data flow flows from the first device through the second device, the message belongs to the data flow; if the data flow flows from the second device through the first device, the message is a message in the reverse data flow of the data flow.

[0167] Optionally, the message in the reverse data flow is a response message to the message in the data flow.

[0168] Optionally, the response message may be received by the first device, or the response message may be generated by the first device.

[0169] Optionally, the first device is a network device, and the second device is a terminal device; or, both the first device and the second device are terminal devices; or, the first device is a terminal device, and the second device is a network device.

[0170] Optionally, if the first device is a network device, the data stream may be received by the first device; or, if the first device is a terminal device, the data stream may be received or initiated by the first device.

[0171] Optionally, the alarm data may include at least one of the following data: the attack scenario type of the alarm event; the confidence level of the alarm event; the risk score of the attack scenario; the disposal action performed by the first device on the alarm event; the rule number of the detection rule for detecting the alarm event; the first disposal strategy for execution by the second device; an association type, which is used to indicate a manner of associating the alarm data to the process call chain of the second device; and an association value corresponding to the association type.

[0172] Optionally, the message may be an IPv6 message, and the alarm data is encapsulated in the DOH of the IPv6 message.

[0173] Optionally, if the second device is a network device, the IPv6 message may further include an SRH, and the segment list of the SRH includes an SID of the second device, where the SID is used to instruct the second device to obtain the alarm data in the DOH.

[0174] Optionally, the encapsulation module 202 may be configured to: if the first device detects an alarm event based on the threat detection, and the data stream and the alarm event meet linkage processing conditions, encapsulate the alarm data of the alarm event in a message.

[0175] Optionally, the linkage handling condition includes a first condition and a second condition. The first condition includes: the source address of the data flow belongs to an untrusted area; the second condition includes at least one of the following conditions:

[0176] The alarm event is: suspicious file type is inconsistent;

[0177] The alarm event is: a suspicious alarm event, the confidence level of the alarm event is higher than a first threshold, and the data stream includes an executable file;

[0178] The alarm event is a suspicious attack intrusion event, and the confidence level of the alarm event is higher than a second threshold.

[0179] Optionally, the linkage handling conditions include a first condition and a second condition; the first condition includes: the source address and the destination address of the data flow both belong to the trusted area; the second condition includes: the alarm event is: suspicious SMB sharing, suspicious high-risk vulnerability exploitation, or suspicious RDP desktop transmission, and the confidence level of the alarm event is higher than a third threshold.

[0180] Optionally, the linkage handling condition includes a first condition and a second condition; the first condition includes: the source address of the data flow belongs to a trusted area, and the destination address of the data flow belongs to an untrusted area. The second condition includes at least one of the following conditions:

[0181] The alarm event is: malicious domain name connection, malicious C&C communication, or downloading of malicious files, and the confidence of the alarm event is higher than the fourth threshold;

[0182] The alarm event is: a suspicious domain generation algorithm DGA request, suspicious C&C communication, or downloading of a suspicious file, and the confidence level of the alarm event is higher than the fifth threshold;

[0183] The process or parent process that initiates the data flow is a suspicious process;

[0184] The alarm event is: an abnormal connection event of a suspected vulnerability being successfully exploited, and the confidence level of the alarm event is higher than a sixth threshold.

[0185] Alternatively, if Fig.11 As shown, the device may also include:

[0186] The receiving module 204 is used to receive a second handling strategy sent by the second device, where the second handling strategy is generated by the second device after detecting a threat entity based on the alarm data. The function of the receiving module 204 can be realized by referring to the relevant description of step 105 in the above method embodiment.

[0187] The execution module 205 is used to execute the second disposal strategy. The implementation of the functions of the execution module 205 can refer to the relevant description of step 106 in the above method embodiment.

[0188] In summary, an embodiment of the present application provides an alarm device, which is applied to a first device. After the device detects an alarm event based on the data stream flowing through, it can encapsulate the alarm data of the alarm event in a message, and send the message to the second device through which the data stream flows, and the flow identifier of the message is consistent with the flow identifier of the data stream. After the second device receives the message, it can perform threat detection and / or threat disposal based on the alarm data. As a result, the first device and the second device realize the linkage detection and / or disposal of the threat entity. In addition, since the device can directly encapsulate the alarm data in the message and send it to the second device, that is, the alarm data does not need to be processed by the cloud platform, the time consumption of threat detection and / or disposal is effectively shortened, and it can ensure that network attacks are blocked in time.

[0189] The present application also provides another alarm device, which can be applied to Figure 1 , Figure 2 , Figure 4 or Figure 5 The second device in the application scenario shown in FIG. 1 can be used to implement the steps performed by the second device in the above method embodiment. Fig.12 As shown, the alarm device comprises:

[0190] The receiving module 301 is used to receive a message from a first device, in which the message is encapsulated with alarm data, and the alarm data is obtained by the first device performing threat detection on the data stream flowing through. Among them, the data stream also flows through the second device, and the flow identifier of the message is consistent with the flow identifier of the data stream. The functional implementation of the receiving module 301 can refer to the relevant description of step 103 in the above method embodiment. If the second device is a terminal device, the function of the receiving module 301 can also refer to the functional description of the data acquisition engine in Table 1.

[0191] The processing module 302 is used to perform threat detection and / or threat disposal based on the alarm data. The functional implementation of the processing module 302 can refer to the relevant description of step 104 in the above method embodiment. If the second device is a terminal device, the function of the processing module 302 can also refer to the functional description of the data collection engine, threat detection engine and threat disposal engine in Table 1.

[0192] Optionally, the second device is a terminal device, and the processing module 302 can be used to: determine a process call chain associated with the alarm data in the second device; and perform threat detection and / or threat disposal based on the process call chain.

[0193] Optionally, the alarm data includes: an association type; the processing module 302 may be configured to: determine a process call chain associated with the alarm data in the second device based on the association type.

[0194] Optionally, the second device is a network device, and the first device is a terminal device; the processing module 302 can be used to: determine associated data in the second device that is associated with the first device, the associated data including other alarm data and / or log data; and perform threat detection and / or threat disposal based on the alarm data and the associated data.

[0195] Optionally, the alarm data may include: a first handling strategy; the processing module 302 may also be used to execute the first handling strategy.

[0196] Alternatively, if Fig.12 As shown, the device may also include:

[0197] The sending module 303 is used to send a second handling strategy to the first device if the processing module 302 detects a threat entity based on the alarm data. The second handling strategy is used for execution by the first device. The function of the sending module 303 can refer to the relevant description of step 105 in the above method embodiment.

[0198] In summary, an embodiment of the present application provides an alarm device, which is applied to a second device. The message sent by the first device received by the device is encapsulated with alarm data, and the device can perform threat detection and / or threat disposal based on the alarm data. As a result, the first device and the second device realize the linkage detection and / or disposal of the threat entity. In addition, since the alarm data does not need to be processed by the cloud platform, the time consumption of threat detection and / or disposal is effectively shortened, which can ensure that network attacks are blocked in a timely manner.

[0199] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working process of the alarm device and each module described above can refer to the corresponding process in the aforementioned method embodiment, and will not be repeated here.

[0200] It should be understood that the alarm device provided in the embodiment of the present application can also be implemented by an application-specific integrated circuit (ASIC) or a programmable logic device (PLD), and the above PLD can be a complex programmable logical device (CPLD), a field programmable gate array (FPGA), a generic array logic (GAL) or any combination thereof. In addition, the method provided in the above method embodiment can also be implemented by software. When the method provided in the above method embodiment is implemented by software, each functional module in the alarm device can also be a software module.

[0201] Fig.13 is a schematic diagram of the structure of another alarm device provided in an embodiment of the present application. The alarm device can be Figure 1 , Figure 2 , Figure 4 or Figure 5 The first device in the application scenario shown in the figure can implement the steps performed by the first device in the above method embodiment. Alternatively, the alarm device can be Figure 1 , Figure 2 , Figure 4 or Figure 5 The second device in the application scenario shown can implement the steps performed by the second device in the above method embodiment. Fig.13 The alarm device includes: a processor 401, a memory 402, a network interface 403 and a bus 404.

[0202] The memory 402 stores a computer program 4021, which is used to implement various application functions. The processor 401 is used to execute the computer program 4021 to implement the alarm method provided by the above method embodiment. For example, the processor 401 can be used to execute the computer program 4021 to implement the above method embodiment. Fig.11 or Fig.12 The functions of each module are shown.

[0203] The processor 401 may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), ASICs, FPGAs, GPUs, or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor.

[0204] The memory 402 may be a volatile memory or a nonvolatile memory, or may include both volatile and nonvolatile memories. Among them, the nonvolatile memory may be a read-only memory (ROM), a programmable ROM (PROM), an erasable programmable ROM (EPROM), an electrically erasable programmable ROM (EEPROM), or a flash memory. The volatile memory may be a random access memory (RAM), which is used as an external cache. By way of example and not limitation, many forms of RAM are available, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link dynamic random access memory (SLDRAM), and direct rambus RAM (DRRAM).

[0205] There may be multiple network interfaces 403, and the network interfaces 403 are used to achieve communication connection (which may be wired or wireless) with other devices, wherein the other devices may be devices such as terminals, servers or VMs.

[0206] The bus 404 is used to connect the processor 401, the memory 402 and the network interface 403. In addition to the data bus, the bus 404 may also include a power bus, a control bus and a status signal bus, etc. However, for the sake of clarity, various buses are labeled as bus 404 in the figure.

[0207] An embodiment of the present application also provides a computer-readable storage medium, which stores instructions. When the instructions are executed by a processor, the processor executes the steps performed by the host or the acceleration chip in the above method embodiment.

[0208] An embodiment of the present application also provides a computer program product comprising instructions, which, when executed on a processor, enables the processor to execute the steps executed by a host or an acceleration chip in the above method embodiment.

[0209] In the embodiments of the present application, the terms "first", "second" and "third" are used for descriptive purposes only and should not be understood as indicating or implying relative importance. In the embodiments of the present application, the term "at least one" refers to one or more, and "multiple" refers to two or more. In the embodiments of the present application, the term "and / or" is merely a description of the association relationship of associated objects, indicating that three relationships may exist. For example, A and / or B can represent: A exists alone, A and B exist at the same time, and B exists alone. In addition, the character " / " in this article generally indicates that the previously associated objects are in an "or" relationship.

[0210] The above is only an optional implementation of the present application, but the protection scope of the present application is not limited thereto. Any technician familiar with the technical field can easily think of various equivalent modifications or replacements within the technical scope disclosed in the present application, and these modifications or replacements should be included in the protection scope of the present application. Therefore, the protection scope of the present application shall be based on the protection scope of the claims.

Claims

1. An alarm method, characterized in that: The method comprises: The first device performs threat detection on the data stream passing through; If the first device detects an alarm event based on the threat detection, the alarm data of the alarm event is encapsulated in a message, and the flow identifier of the message is consistent with the flow identifier of the data flow; The first device sends the message to a second device through which the data flow flows, and the alarm data in the message is used for the second device to perform threat detection and / or threat handling.

2. The method according to claim 1, characterized in that The message belongs to the data flow, or the message is a message in a reverse data flow of the data flow.

3. The method according to claim 2, characterized in that If the data flow flows from the first device through the second device, the message belongs to the data flow; If the data flow flows from the second device through the first device, the message is a message in a reverse data flow of the data flow.

4. The method according to claim 2 or 3, characterized in that: The message in the reverse data flow is a response message to the message in the data flow.

5. The method according to claim 4, characterized in that The response message is received by the first device, or the response message is generated by the first device.

6. The method according to any one of claims 1 to 5, characterized in that: The first device is a network device, and the second device is a terminal device; Alternatively, both the first device and the second device are terminal devices; Alternatively, the first device is a terminal device, and the second device is a network device.

7. The method according to any one of claims 1 to 6, characterized in that: If the first device is a network device, the data stream is received by the first device; Alternatively, if the first device is a terminal device, the data stream is received or initiated by the first device.

8. The method according to any one of claims 1 to 7, characterized in that: The warning data includes at least one of the following data: The attack scenario type of the alarm event; The confidence level of the warning event; a risk score for the attack scenario; a handling action performed by the first device on the alarm event; The rule number of the detection rule that detected the alarm event; a first handling strategy for execution by the second device; an association type, where the association type is used to indicate a manner of associating the alarm data with a process call chain of the second device; The associated value corresponding to the associated type.

9. The method according to any one of claims 1 to 8, characterized in that: The message is an Internet Protocol version 6 IPv6 message, and the alarm data is encapsulated in a destination options header DOH of the IPv6 message.

10. The method according to claim 9, characterized in that If the second device is a network device, the IPv6 message further includes a segment routing header SRH, and the segment list of the SRH includes a segment identifier SID of the second device, and the SID is used to instruct the second device to obtain the alarm data in the DOH.

11. The method according to any one of claims 1 to 10, characterized in that: If the first device detects an alarm event based on the threat detection, the alarm data of the alarm event is encapsulated in a message, including: If the first device detects an alarm event based on the threat detection, and the data flow and the alarm event meet linkage processing conditions, the alarm data of the alarm event is encapsulated in a message.

12. The method according to claim 11, characterized in that The linkage handling condition includes a first condition and a second condition; The first condition includes: the source address of the data flow belongs to an untrusted area; The second condition includes at least one of the following conditions: The alarm event is: the suspicious file type is inconsistent; The alarm event is: a suspicious alarm event, the confidence level of the alarm event is higher than a first threshold, and the data stream includes an executable file; The alarm event is a suspicious attack intrusion event, and the confidence level of the alarm event is higher than a second threshold.

13. The method according to claim 11, characterized in that The linkage handling condition includes a first condition and a second condition; The first condition includes: the source address and the destination address of the data flow both belong to the trusted area; The second condition includes: the alarm event is: suspicious service message block SMB sharing, suspicious high-risk vulnerability exploitation, or suspicious remote desktop protocol RDP desktop transmission, and the confidence of the alarm event is higher than a third threshold.

14. The method according to claim 11, characterized in that The linkage handling condition includes a first condition and a second condition; The first condition includes: the source address of the data flow belongs to the trusted area, and the destination address of the data flow belongs to the untrusted area; The second condition includes at least one of the following conditions: The alarm event is: malicious domain name connection, malicious command and control communication, or downloading of malicious files, and the confidence level of the alarm event is higher than a fourth threshold; The alarm event is: a suspicious domain name generation algorithm DGA request, a suspicious command and control communication, or downloading of a suspicious file, and the confidence level of the alarm event is higher than a fifth threshold; The process or parent process that initiates the data flow is a suspicious process; The alarm event is: an abnormal connection event in which a suspected vulnerability is successfully exploited, and the confidence level of the alarm event is higher than a sixth threshold.

15. The method according to any one of claims 1 to 14, characterized in that: The method further comprises: The first device receives a second handling strategy sent by the second device, where the second handling strategy is generated by the second device after detecting a threat entity based on the alarm data; The first device executes the second handling strategy.

16. An alarm method, characterized in that: The method comprises: The second device receives a message from the first device, wherein the message is encapsulated with alarm data, and the alarm data is obtained by the first device performing threat detection on a data flow flowing through the first device, wherein the data flow also flows through the second device, and a flow identifier of the message is consistent with a flow identifier of the data flow; The second device performs threat detection and / or threat handling based on the alarm data.

17. The method according to claim 16, characterized in that The second device is a terminal device, and the second device performs threat detection and / or threat handling based on the alarm data, including: The second device determines a process call chain associated with the alarm data in the second device; The second device performs threat detection and / or threat handling based on the process call chain.

18. The method according to claim 17, characterized in that The alarm data includes: an association type; the second device determines a process call chain associated with the alarm data in the second device, including: The second device determines a process call chain associated with the alarm data in the second device based on the association type.

19. The method according to claim 16, characterized in that The second device is a network device, and the first device is a terminal device; the second device performs threat detection and / or threat handling based on the alarm data, including: The second device determines, in the second device, associated data associated with the first device, where the associated data includes other alarm data and / or log data; The second device performs threat detection and / or threat handling based on the warning data and the associated data.

20. The method according to any one of claims 16 to 19, characterized in that: The alarm data includes: a first handling strategy; the method further includes: The second device executes the first handling policy.

21. The method according to any one of claims 16 to 20, characterized in that: The method further comprises: If the second device detects a threat entity based on the warning data, the second device sends a second handling strategy to the first device, where the second handling strategy is for the first device to execute.

22. An alarm device, characterized in that: Applied to a first device, the apparatus comprises: A detection module is used to detect threats on the data streams passing through it; An encapsulation module, configured to encapsulate alarm data of the alarm event in a message if an alarm event is detected based on the threat detection, wherein the flow identifier of the message is consistent with the flow identifier of the data flow; The sending module is used to send the message to a second device through which the data flow flows, and the alarm data in the message is used for the second device to perform threat detection and / or threat disposal.

23. The device according to claim 22, characterized in that The message belongs to the data flow, or the message is a message in a reverse data flow of the data flow.

24. The device according to claim 23, characterized in that If the data flow flows from the first device through the second device, the message belongs to the data flow; If the data flow flows from the second device through the first device, the message is a message in a reverse data flow of the data flow.

25. The device according to claim 23 or 24, characterized in that The message in the reverse data flow is a response message to the message in the data flow.

26. The device according to claim 25, characterized in that The response message is received by the first device, or the response message is generated by the first device.

27. The device according to any one of claims 22 to 26, characterized in that The first device is a network device, and the second device is a terminal device; Alternatively, both the first device and the second device are terminal devices; Alternatively, the first device is a terminal device, and the second device is a network device.

28. The device according to any one of claims 22 to 27, characterized in that If the first device is a network device, the data stream is received by the first device; Alternatively, if the first device is a terminal device, the data stream is received or initiated by the first device.

29. The device according to any one of claims 22 to 28, characterized in that The warning data includes at least one of the following data: The attack scenario type of the alarm event; The confidence level of the warning event; a risk score for the attack scenario; a handling action performed by the first device on the alarm event; The rule number of the detection rule that detected the alarm event; a first handling strategy for execution by the second device; an association type, where the association type is used to indicate a manner of associating the alarm data with a process call chain of the second device; The associated value corresponding to the associated type.

30. The device according to any one of claims 22 to 29, characterized in that The message is an Internet Protocol version 6 IPv6 message, and the alarm data is encapsulated in a destination options header DOH of the IPv6 message.

31. The device according to claim 30, characterized in that If the second device is a network device, the IPv6 message further includes a segment routing header SRH, and the segment list of the SRH includes a segment identifier SID of the second device, and the SID is used to instruct the second device to obtain the alarm data in the DOH.

32. The device according to any one of claims 22 to 31, characterized in that The packaging module is used for: If the first device detects an alarm event based on the threat detection, and the data flow and the alarm event meet linkage processing conditions, the alarm data of the alarm event is encapsulated in a message.

33. The device according to claim 32, characterized in that The linkage handling condition includes a first condition and a second condition; The first condition includes: the source address of the data flow belongs to an untrusted area; The second condition includes at least one of the following conditions: The alarm event is: the suspicious file type is inconsistent; The alarm event is: a suspicious alarm event, the confidence level of the alarm event is higher than a first threshold, and the data stream includes an executable file; The alarm event is a suspicious attack intrusion event, and the confidence level of the alarm event is higher than a second threshold.

34. The device according to claim 32, characterized in that The linkage handling condition includes a first condition and a second condition; The first condition includes: the source address and the destination address of the data flow both belong to the trusted area; The second condition includes: the alarm event is: suspicious service message block SMB sharing, suspicious high-risk vulnerability exploitation, or suspicious remote desktop protocol RDP desktop transmission, and the confidence of the alarm event is higher than a third threshold.

35. The device according to claim 32, characterized in that The linkage handling condition includes a first condition and a second condition; The first condition includes: the source address of the data flow belongs to the trusted area, and the destination address of the data flow belongs to the untrusted area; The second condition includes at least one of the following conditions: The alarm event is: malicious domain name connection, malicious command and control communication, or downloading of malicious files, and the confidence level of the alarm event is higher than a fourth threshold; The alarm event is: a suspicious domain name generation algorithm DGA request, a suspicious command and control communication, or a download of a suspicious file, and the confidence level of the alarm event is higher than a fifth threshold; The process or parent process that initiates the data flow is a suspicious process; The alarm event is: an abnormal connection event in which a suspected vulnerability is successfully exploited, and the confidence level of the alarm event is higher than a sixth threshold.

36. The device according to any one of claims 22 to 35, characterized in that The device also includes: A receiving module, configured to receive a second handling strategy sent by the second device, where the second handling strategy is generated after the second device detects a threat entity based on the alarm data; An execution module is used to execute the second disposal strategy.

37. An alarm device, characterized in that: Applied to a second device, the apparatus comprises: a receiving module, configured to receive a message from a first device, wherein the message is encapsulated with alarm data, wherein the alarm data is obtained by the first device performing threat detection on a data flow passing through the first device, wherein the data flow also flows through the second device, and a flow identifier of the message is consistent with a flow identifier of the data flow; A processing module is used to perform threat detection and / or threat handling based on the alarm data.

38. The device according to claim 37, characterized in that The second device is a terminal device, and the processing module is used to: Determining a process call chain associated with the alarm data in the second device; Threat detection and / or threat handling are performed based on the process call chain.

39. The device according to claim 38, characterized in that The alarm data includes: an associated type; and the processing module is used to: A process call chain associated with the alarm data in the second device is determined based on the association type.

40. The device according to claim 37, characterized in that The second device is a network device, and the first device is a terminal device; the processing module is used to: Determine association data associated with the first device in the second device, where the association data includes other alarm data and / or log data; Threat detection and / or threat handling are performed based on the warning data and the associated data.

41. The device according to any one of claims 37 to 40, characterized in that The alarm data includes: a first handling strategy; the processing module is further used to execute the first handling strategy.

42. The device according to any one of claims 37 to 41, characterized in that The device also includes: A sending module is used to send a second handling strategy to the first device if the processing module detects a threat entity based on the alarm data, and the second handling strategy is used to be executed by the first device.

43. An alarm device, characterized in that: The method comprises a memory and a processor, wherein the processor is used to execute instructions stored in the memory to implement the method according to any one of claims 1 to 21.

44. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, and when the computer program is executed, the method according to any one of claims 1 to 21 is implemented.

45. A computer program product, characterized in that The computer program product comprises a program or a code, and when the program or the code is executed, the method according to any one of claims 1 to 21 is implemented.

46. ​​An alarm system, characterized in that: The system comprises: a first device and a second device, wherein the first device is used to execute the method according to any one of claims 1 to 15, and the second device is used to execute the method according to any one of claims 16 to 21.

Images