A method and device for accurately associating network end relationships in XDR
By utilizing a custom TLS handshake extension field to transmit a unique device identifier in the XDR environment, the problem of inaccurate device association in dynamic network environments is solved, enabling rapid device association and efficient technical application. This simplifies management and maintenance in complex network environments. The customized technical application also simplifies device management and maintenance.
Patent Information
- Application Number
- CN202411822032.X
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2024-12-11
- Publication Date
- 2025-11-18
- Estimated Expiration
- 2044-12-11
AI Technical Summary
In XDR environments, existing device association schemes rely on single identifiers, which can easily lead to misjudgments or incomplete information in dynamic and complex network environments. This makes it difficult to achieve accurate association between device behaviors and activities, affecting the effectiveness of security incident response and threat detection.
By using a custom extension field to transmit the device's unique identifier during the TLS handshake phase, and leveraging the collaborative work of the EDR management center and NDR devices, a custom TLS handshake extension field is used to transmit the device's unique identifier, authentication information, and security policies. Combined with the NDR's bypass monitoring and resolution mechanism, this enables precise association of devices at different security control points.
It enables rapid device association and security analysis, improves the efficiency of security incident detection and response, simplifies management and maintenance in complex network environments, and enhances the accuracy of device identification and management through unified unique device identifiers and combined applications.
Smart Images

Figure CN119583193B_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of computer information security technology, and in particular to a method and apparatus for accurately associating network-end relationships in XDR. Background Technology
[0002] With the rapid development of information technology, enterprises face increasingly complex and covert cybersecurity threats. Traditional Security Operations Center (SOC) tools are often limited to a single data source or security control point, such as Endpoint Detection and Response (EDR) or Network Detection and Response (NDR), leading to fragmented and insufficient threat detection and response capabilities. The SOC is the core of an enterprise security team, responsible for 24 / 7 monitoring, analysis, and response to potential security threats, while EDR and NDR focus on monitoring and responding to endpoint devices and network traffic, respectively. EDR solutions are primarily used to detect, investigate, and respond to malicious activities on endpoints (such as computers, servers, and mobile devices), while NDR focuses on network-level traffic monitoring, analyzing potential attack patterns and anomalous behaviors.
[0003] To address this issue, Extended Detection and Response (XDR) technology emerged. XDR is an integrated security architecture that integrates data and functions from multiple security control points, encompassing telemetry data from the cloud, network, and endpoints, to provide more comprehensive threat detection and automated response capabilities. XDR's advantage lies in its ability to provide unified analysis and response across multiple security layers (endpoints, networks, email, cloud, etc.), moving beyond the limitations of a single control point and thus improving the overall scope and efficiency of security monitoring.
[0004] However, effectively correlating and identifying device behavior and activities at different security control points remains a challenging problem in XDR environments. Extracting and correlating relevant threat information from cross-platform data within multi-layered and multi-dimensional security data has become crucial for improving XDR performance.
[0005] Existing, traditional device association schemes often rely on single identifiers, such as MAC addresses (Media Access Control Addresses) and IP addresses (Internet Protocol Addresses). In dynamic and complex network environments, this can lead to misjudgments or incomplete information. While MAC addresses are unique identifiers for network hardware and are commonly used to identify devices in local area networks (LANs), IP addresses are crucial for identifying and locating devices on the internet. However, in dynamic IP environments, device IPs can change, causing misidentification and disruptions in monitoring systems. Furthermore, accurate correlation of device behavior and activities across different control points is essential for effective security incident response and threat detection, especially when facing increasingly sophisticated attack methods. Summary of the Invention
[0006] This invention proposes a method and apparatus for accurately associating network-end relationships in XDR, in order to solve the problem that existing XDR devices with more complex network environments are difficult to accurately associate.
[0007] The present invention achieves the above objectives through the following technical solutions:
[0008] This invention provides a method for accurately associating network endpoint relationships in XDR, comprising:
[0009] Receive device unique identifier requests from EDR terminals and NDR devices;
[0010] In response to the device unique identifier request from the EDR terminal and the device unique identifier request from the NDR device, a corresponding device unique identifier is assigned to the respective NDR device and EDR terminal.
[0011] The device identification information of the group is obtained from the NDR device. Each group of device identification information includes the unique device identifier of the NDR device and the unique device identifiers of multiple EDR terminals. The unique device identifier of the NDR device is the unique device identifier of the NDR device itself. The unique device identifier of the EDR terminal is obtained by monitoring the corresponding NDR device and parsing the TLS extension field according to the preset TLS custom handshake extension field. The TLS extension field is constructed by the EDR management center according to the preset TLS custom handshake extension field and the unique device identifier of the EDR terminal.
[0012] Specifically, a unique device identifier is assigned to each of the aforementioned NDR devices and EDR terminals, including:
[0013] The first API interface is generated based on the device unique identifier request of the EDR terminal. A batch or a corresponding device unique identifier is sent to the EDR management center through the first API interface. The EDR management center is used to assign the received corresponding device unique identifier to each EDR terminal under its management and to permanently save the correspondence between the EDR terminal and the corresponding device unique identifier.
[0014] A second API interface is generated based on the device unique identifier request of the NDR device. A corresponding device unique identifier is assigned to the NDR device through the second API interface. The NDR device is used to obtain the corresponding device unique identifier from the XDR device and permanently store it if it has not obtained the device unique identifier from the XDR device before.
[0015] Specifically, the steps for setting the TLS custom handshake extension field are as follows:
[0016] The format and meaning of the extended fields are determined. The extended fields include a protocol header, a protocol header checksum, an encryption algorithm, an extended data length, and extended data. The extended data includes the unique identifier of the device, which is one or more of the following: device ID, authentication information, and security policy version.
[0017] The data encryption algorithm is determined, and the data encryption algorithm is one of plaintext transmission, Base64, AES encryption, DES encryption, and RSA encryption.
[0018] Specifically, the EDR management center constructs the TLS extension field based on the preset TLS custom handshake extension field and the device unique identifier of the EDR terminal, including:
[0019] A random integer is generated, and 4 bytes are obtained based on the integer to fill the protocol header;
[0020] Calculate and fill the protocol header checksum based on the protocol header;
[0021] The protocol header checksum is filled with the encryption code corresponding to the determined encryption algorithm.
[0022] The unique device identifiers corresponding to one or more EDR terminals are packaged together, encrypted using the encryption algorithm and the corresponding key, and then filled with the extended data;
[0023] The length of the extended data is calculated based on the extended data, and the extended data length is filled in to complete the construction of the TLS extended field.
[0024] Specifically, the NDR device parses the TLS extension field according to the preset TLS custom handshake extension field to obtain the device unique identifier of the EDR terminal;
[0025] Read the protocol header;
[0026] Read the protocol header for verification;
[0027] Determine whether the extended data is custom extended data. If so, proceed to the next step; otherwise, ignore the TLS extended field.
[0028] Read the encryption algorithm;
[0029] Read the custom extended data length;
[0030] Read the custom extended data and decrypt it using the corresponding encryption algorithm to obtain the original data of the TLS extended field.
[0031] Specifically, the NDR device monitors and parses the TLS extension fields, including:
[0032] The NDR device bypasses the heartbeat interface of the EDR terminal;
[0033] When the NDR device detects that the EDR management center sends the TLS extension field to the EDR terminal, the NDR monitoring obtains the TLS extension field from the heartbeat interface of the EDR terminal;
[0034] The NDR device parses the TLS extension field according to the preset TLS custom handshake extension field to obtain and save the unique device identifier of the EDR terminal;
[0035] The TLS extension field is constructed by the EDR management center in response to the heartbeat request sent by the EDR terminal, based on the preset TLS custom handshake extension field and the device unique identifier of the corresponding EDR terminal.
[0036] Specifically, the NDR device monitors and parses the TLS extension fields, including:
[0037] The NDR device monitors the heartbeat requests sent from the EDR management center to the XDR device;
[0038] The NDR device obtains the TLS extension field based on the heartbeat request sent by the EDR management center;
[0039] The TLS extension field is constructed by the EDR management center by batch packaging the unique device identifiers of multiple EDR terminals together according to the preset TLS custom handshake extension field. The EDR management center sends a heartbeat request to the XDR device after constructing the TLS extension field.
[0040] Specifically, it also includes:
[0041] Based on the device identification information of the obtained group, obtain the basic information and security information of the EDR terminal and NDR device within the same group;
[0042] The basic information and security information of the EDR terminals and NDR devices within the same group are correlated to obtain the correlation analysis results.
[0043] Another aspect of the present invention discloses a device for precise association of network endpoint relationships in XDR, comprising:
[0044] The receiving module is used to receive the device unique identifier request of the EDR terminal and the device unique identifier request of the NDR device;
[0045] The allocation module is used to respond to the device unique identifier request of the EDR terminal and the device unique identifier request of the NDR device, and allocate the corresponding device unique identifier to the corresponding NDR device and EDR terminal respectively.
[0046] The acquisition module is used to acquire device identification information of groups from the NDR device. Each group of device identification information includes the unique device identifier of the NDR device and the unique device identifiers of multiple EDR terminals. The unique device identifier of the NDR device is the unique device identifier of the NDR device itself. The unique device identifier of the EDR terminal is obtained by monitoring the corresponding NDR device and parsing the TLS extension field according to the preset TLS custom handshake extension field. The TLS extension field is constructed by the EDR management center according to the preset TLS custom handshake extension field and the unique device identifier of the EDR terminal.
[0047] The beneficial effects of this invention are as follows:
[0048] This invention proposes a precise network-end relationship association method in XDR, which enables rapid association and security analysis of devices and hosts through automation and system integration, improving the efficiency of security incident detection and response. Simultaneously, by using unified unique device identifiers and group data definitions, it simplifies management and maintenance in complex network environments. Attached Figure Description
[0049] Figure 1 This is a network deployment diagram of the precise network-end relationship association method in XDR in the embodiments of this application;
[0050] Figure 2 This is a schematic diagram of the heartbeat request processing flow of the EDR terminal in the embodiments of this application;
[0051] Figure 3 This is a schematic diagram illustrating the process of an NDR device monitoring and parsing TLS extension fields in an embodiment of this application. Detailed Implementation
[0052] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. The components of the embodiments of the present invention described and shown in the accompanying drawings can generally be arranged and designed in various different configurations.
[0053] Therefore, the following detailed description of the embodiments of the invention provided in the accompanying drawings is not intended to limit the scope of the claimed invention, but merely to illustrate selected embodiments of the invention. All other embodiments obtained by those skilled in the art based on the embodiments of the invention without inventive effort are within the scope of protection of the invention.
[0054] It should be noted that similar labels and letters in the following figures indicate similar items. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures.
[0055] In the description of this invention, it should be understood that the terms "upper," "lower," "inner," "outer," "left," "right," etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings, or the orientation or positional relationship commonly used when the product of this invention is in use, or the orientation or positional relationship commonly understood by those skilled in the art. They are only used to facilitate the description of this invention and to simplify the description, and are not intended to indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on this invention.
[0056] Furthermore, the terms "first," "second," etc., are used only to distinguish descriptions and should not be interpreted as indicating or implying relative importance.
[0057] In the description of this invention, it should also be noted that, unless otherwise explicitly specified and limited, terms such as "set" and "connection" should be interpreted broadly. For example, "connection" can be a fixed connection, a detachable connection, or an integral connection; it can be a mechanical connection or an electrical connection; it can be a direct connection or an indirect connection through an intermediate medium; it can be a connection within two components. Those skilled in the art can understand the specific meaning of the above terms in this invention according to the specific circumstances.
[0058] In this invention, the term "XDR" stands for Extended Detection and Response; "EDR" stands for Terminal Detection and Response; and "NDR" stands for Network Detection and Response. In the accompanying drawings, "EDR-CENTER" refers to the EDR management center.
[0059] The specific embodiments of the present invention will now be described in detail with reference to the accompanying drawings.
[0060] This invention involves the collaborative operation of three systems: XDR, EDR, and NDR.
[0061] The XDR system is responsible for uniformly assigning unique identifiers to NDR devices and EDR terminal devices, ensuring that each NDR device and each EDR terminal has a unique identifier.
[0062] The NDR system analyzes traffic in a bypass manner, automatically discovers each EDR device and host connected to the network, and obtains the unique device identifier of each EDR terminal connected to the network. Furthermore, it defines the unique device identifier of the NDR device and the unique device identifiers of multiple detected EDR terminals as a group, and periodically reports this group to the XDR system.
[0063] The XDR device receives device identification information from packets received from the NDR, manages it, and stores it.
[0064] The XDR system collects data from the NDR and EDR systems and performs correlation analysis on the basic information and security information of the NDR and EDR systems collected in the same group to discover potential security threats or abnormal behaviors.
[0065] To implement the above technical solution, this invention utilizes the TLS handshake phase, employing custom extension fields for data transmission and detection. During the TLS handshake, the client and server can exchange custom TLS extension fields (Client hello custom extension). These fields can be used to convey additional information, such as unique device identifiers, security policies, or other information that needs to be transmitted and identified in encrypted communication. The TLS custom handshake extension fields are pre-defined by NDR, EDR, and XDR. The specific customization content is as follows:
[0066] The format and meaning of the extended fields are determined. These extended fields include the protocol header, protocol header checksum, encryption algorithm, data length, and data content. The data content is user-defined and may include device ID, authentication information, security policy version, etc. The TLS custom handshake extended fields are shown in Table 1 below:
[0067] Table 1
[0068] Extended Types Protocol header Protocol header verification Encryption Algorithm Extended data length Extended data If the value is greater than 62 and less than or equal to 2569, the default value is 66. Byte(4) Byte(2) Byte(1) Byte(2) Byte (0 ... 2^16 - 9)
[0069] The explanations of each part of the TLS custom handshake extension fields are shown in Table 2 below:
[0070] Table 2:
[0071] name illustrate Extended Types Extended types are limited to >62 and <=2569, with 66 being the default. Protocol header It occupies 4 bytes and marks the protocol. Protocol header verification It occupies 2 bytes and is used to verify the validity of the data. Encryption Algorithm It occupies 1 byte and defaults to Base64. Refer to the dictionary "Encryption Algorithms" for more information. Extended data length It occupies 2 bytes, extending the length of the data. Extended data Occupying 0 - 2^16 - 9 bytes, user-defined content
[0072] To ensure the data is properly encrypted and authenticated during transmission of these extended fields, preventing man-in-the-middle attacks or data tampering, the extended data portion can be transmitted encrypted. This solution lists several encryption algorithms for reference, such as plaintext transmission, Base64, AES encryption, DES encryption, and RSA encryption. See Table 3 for details.
[0073] Table 3:
[0074] Encryption algorithm encoding illustrate 0 Plaintext transmission 1 Base64 encoding 2 AES encryption 3 DES encryption 4 RSA encryption
[0075] like Figure 1 As shown:
[0076] A101. First, EDR, NDR, and XDR, based on the preceding protocol description, jointly determine the TLS custom extension fields. EDR and NDR need to confirm the user's extended data, encryption / decryption method, and key. Both parties must securely store their keys, respectively on the NDR and EDR management center sides. XDR confirms that it provides network API interfaces, including: API interfaces for generating unique device identifiers, API interfaces for collecting packet device identifiers, and a heartbeat interface for listening to the NDR management center. The NDR management center's heartbeat interface is used to send data to XDR.
[0077] A102, as Figure 2 As shown, the EDR management center is initialized. The main task of the EDR management center is to continuously monitor and record various information of the EDR terminal devices. The EDR management center requests a batch or a single identifier from the API interface generated by the XDR device unique identifier, assigns it to each terminal it manages, and permanently and securely stores the correspondence between the EDR terminal and the device unique identifier locally.
[0078] A103, NDR initialization: If the NDR has not obtained the device unique identifier from the XDR, it first requests the API interface for generating the device unique identifier from the XDR system to obtain a device unique identifier as its own device unique identifier, and permanently and securely stores it locally.
[0079] A104, such as Figure 2 As shown, the NDR device is deployed in bypass mode on the switch to listen for and parse traffic packets on interfaces identified by the EDR terminal or EDR management center. It then uses a pre-defined encryption algorithm and key to decrypt the extended fields. The decrypted data is reconstructed into a readable format for further verification of the uniqueness of device information and final analysis and processing. The unique identifier mapping between the EDR terminal and the device—the local device mapping table—is permanently and securely stored locally. The steps for the EDR management center to construct TLS extended fields and for the NDR to parse TLS extended fields are as follows:
[0080] The EDR management center constructs TLS extended fields through the following steps:
[0081] Randomly generate an integer, and obtain 4 bytes H1=Byte[0], H2=Byte[1], H3=Byte[2], H4=Byte[3] to fill the "protocol header" position;
[0082] Calculate Byte[0] = H1 ^ H3, Byte[2] = H2 ^ H4, and fill the two bytes of Byte[0] and Byte[1] with the "checksum" bit;
[0083] Fill the "encryption algorithm" bit with the encryption code corresponding to the encryption algorithm determined by the three parties;
[0084] Pack the unique device identifiers of one or more EDR terminals together, encrypt them using a known encryption algorithm and key, and then fill in the "extended data" bits;
[0085] Calculate the extended data length and fill the "extended data length" bit;
[0086] Finally, the construction of the TLS extension fields is complete.
[0087] NDR parsing of TLS extension fields involves the following steps:
[0088] Read custom extension data of the agreed TLS extension Type;
[0089] Read 4 bytes as the protocol header Byte[4], H1=Byte[0], H1=Byte[1], H2=Byte[2], H3=Byte[3];
[0090] Read 2 bytes for protocol header verification Byte[2], C0=Byte[0], C1=Byte[1];
[0091] If H0^H2^C0==0X00 && H1^H3^C1==0x00, then it proves that it is custom extended data; otherwise, please ignore the data packet.
[0092] Read 1 byte as the encryption algorithm Byte [1], with a value of Algorithm=0x(Byte[0]);
[0093] Read 2 bytes as the custom extended data length Byte[2], with a value of Length=0x(Byte[0]Byte[1]);
[0094] Read Length bytes as custom extended data Byte[Length], and decrypt it using the corresponding encryption algorithm to obtain the original data.
[0095] like Figure 1 As shown, the NDR device bypasses and monitors and parses the TLS extension fields in the following two cases:
[0096] (A1041) One scenario involves the EDR management center being deployed on the "right side" of the switch. The EDR terminal sends a heartbeat to the EDR management center. The NDR device bypasses this process, monitoring and parsing the EDR terminal's heartbeat interface, resolving the TLS custom extension field, obtaining a unique device identifier, and storing / updating the corresponding terminal's local cache data on the NDR device. The EDR terminal itself does not participate in the construction of the TLS custom extension field. The EDR terminal sends a heartbeat request to the EDR management center, which calculates and constructs the corresponding terminal's TLS extension field (containing the terminal's identification information) based on the information agreed upon by all three parties and returns it to the corresponding EDR terminal. Subsequent heartbeat requests from the EDR terminal to the EDR management center only require this TLS extension field, allowing the NDR device to monitor, parse, and obtain the EDR terminal's unique device identifier.
[0097] (A1042) Another scenario involves the EDR management center being deployed on the "left side" of the switch. The EDR management center manages all relevant EDR endpoint information. Based on the agreed-upon terms from all three parties, the EDR management center packages the unique device identifiers of multiple EDR endpoints together to construct a TLS extension field and sends a heartbeat request to the XDR. The NDR device can then monitor, parse, and obtain the unique device identifiers of multiple EDR endpoints.
[0098] In some embodiments, the method further includes obtaining basic information and security information of the EDR terminal and NDR device within the same group based on the obtained device identification information of the group; performing correlation analysis on the basic information and security information of the EDR terminal and NDR device within the same group to obtain correlation analysis results. The correlation analysis process is the existing correlation analysis process in existing XDR, and will not be described in detail here.
[0099] Another aspect of the present invention discloses a device for precise association of network endpoint relationships in XDR, comprising:
[0100] The receiving module is used to receive the device unique identifier request of the EDR terminal and the device unique identifier request of the NDR device;
[0101] The allocation module is used to respond to the device unique identifier request of the EDR terminal and the device unique identifier request of the NDR device, and allocate the corresponding device unique identifier to the corresponding NDR device and EDR terminal respectively.
[0102] The acquisition module is used to acquire device identification information of groups from the NDR device. Each group of device identification information includes the unique device identifier of the NDR device and the unique device identifiers of multiple EDR terminals. The unique device identifier of the NDR device is the unique device identifier of the NDR device itself. The unique device identifier of the EDR terminal is obtained by monitoring the corresponding NDR device and parsing the TLS extension field according to the preset TLS custom handshake extension field. The TLS extension field is constructed by the EDR management center according to the preset TLS custom handshake extension field and the unique device identifier of the EDR terminal.
[0103] The advantages of this invention compared to the prior art are:
[0104] 1. Design and Application of Custom TLS Handshake Extension: One of the key technical aspects of this invention is the use of a custom extension (Client Hello Custom Extension) to transmit user-extended data during the TLS handshake phase. This innovative design embeds device identification data into the TLS handshake message, enabling the transmission of specific information without decryption within encrypted traffic. This technology not only identifies and associates devices in complex XDR environments but also copes with diverse and dynamic network architecture changes, thus laying a solid foundation for secure device association.
[0105] 2. Customization of TLS Handshake Extension Fields: By customizing the TLS extension fields, the present invention can transmit specific user data, including device identifiers, context information, etc., thereby helping NDR and EDR systems accurately associate different devices. Especially in a large-scale distributed environment, it enables the unique identification and management of devices. This customized extension field design can cope with various network conditions and is the core means to achieve multi-device collaborative security detection.
[0106] 3. Bypass Monitoring and Association Analysis Mechanism of NDR System: The present invention analyzes network traffic in a bypass manner, automatically discovers and identifies each EDR terminal and host connected to the network, and obtains the unique identifier of each terminal. The NDR system associates its own unique identifier with the identified multiple terminal device identifiers, defines them as a group, and regularly reports them to the XDR system. This mechanism embeds identification data in the TLS handshake stage, enabling NDR to accurately identify devices without decrypting the communication content, thus achieving efficient cross-system collaboration and accurate device association, taking into account both security and privacy protection, with high innovation and application value, and should be protected.
[0107] 4. Association and Collaborative Design of EDR-NDR in XDR Environment: The present invention realizes the association and collaborative work of EDR and NDR systems in the XDR environment. By customizing the TLS extension fields, it shares key information between different devices, thereby forming an efficient cross-system linkage response mechanism. This method significantly improves the collaboration efficiency between multiple devices and systems, providing strong support for security operations.
[0108] The above are only the preferred embodiments of the present invention. It should be noted that for those of ordinary skill in the art, without departing from the technical principle of the present invention, several improvements and refinements can be made, and these improvements and refinements should also be regarded as the protection scope of the present invention.
Claims
1. A method for accurate association of network end relationships in XDR, characterized in that, The application comprises the following steps: receiving the device unique identification request of the EDR terminal and the device unique identification request of the NDR device; allocating the corresponding device unique identification to the corresponding NDR device and EDR terminal in response to the device unique identification request of the EDR terminal and the device unique identification request of the NDR device; obtaining the grouped device identification information from the NDR device, wherein each group of the device identification information comprises the device unique identification of the NDR device and the device unique identification of a plurality of EDR terminals, the device unique identification of the NDR device is the device unique identification of the NDR device itself, the device unique identification of the EDR terminal is obtained by monitoring the NDR device and analyzing the TLS extension field according to the preset TLS custom handshake extension field, the TLS extension field is obtained by the EDR management center according to the preset TLS custom handshake extension field and the device unique identification of the EDR terminal, and the TLS custom handshake extension field is predefined by the NDR, EDR and XDR.
2. The method of claim 1, wherein the method comprises: allocating the corresponding device unique identification to the corresponding NDR device and EDR terminal, comprising the following steps: generating a first API interface according to the device unique identification request of the EDR terminal, sending one or a plurality of corresponding device unique identifications to the EDR management center through the first API interface, and the EDR management center is used for allocating the received corresponding device unique identification to each EDR terminal managed by the EDR management center, and permanently saving the corresponding relationship between the EDR terminal and the device unique identification; generating a second API interface according to the device unique identification request of the NDR device, allocating one corresponding device unique identification to the NDR device through the second API interface, and the NDR device is used for obtaining the corresponding device unique identification from the XDR device and permanently saving the device unique identification in the case that the device unique identification is not obtained from the XDR device.
3. The method of claim 1, wherein the method comprises: The setting steps of the TLS custom handshake extension field are as follows: determining the format and meaning of the extension field, the extension field comprises a protocol header, a protocol header check code, an encryption algorithm, an extension data length and extension data, the extension data comprises the device unique identification, and the device unique identification is one or more of device ID, authentication information and security policy version; determining the data encryption algorithm, and the data encryption algorithm is one of plaintext transmission, Base64, AES encryption, DES encryption and RSA encryption.
4. The method of claim 3, wherein the method comprises: The EDR management center constructs the TLS extension field according to the preset TLS custom handshake extension field and the device unique identification of the EDR terminal, comprising the following steps: generating an integer at random, and obtaining a 4-byte padding protocol header according to the integer; calculating and padding the protocol header check code according to the protocol header; padding the protocol header check code according to the encryption code corresponding to the determined encryption algorithm; packing the device unique identification of one or more EDR terminals together, encrypting the device unique identification of the EDR terminal by using the encryption algorithm and the corresponding secret key, and then padding the extension data; According to the extension data, the extension data length is calculated and filled, and the construction of the TLS extension field is completed.
5. The method of claim 4, wherein the method comprises: The NDR device parses the TLS extension field according to the preset TLS custom handshake extension field to obtain the device unique identifier of the EDR terminal. Reading the protocol header; Reading the protocol header verification; Determining whether the extension data is custom extension data, if yes, entering the next step, otherwise ignoring the TLS extension field; Reading the encryption algorithm; Reading the custom extension data length; Reading the custom extension data, and decrypting the original data of the TLS extension field by using the corresponding encryption algorithm.
6. The method of claim 1, wherein the method is used in XDR. The NDR device monitors and parses the TLS extension field, including: The NDR device monitors the heartbeat interface of the EDR terminal; When the NDR device monitors that the EDR management center sends the TLS extension field to the EDR terminal, the NDR device obtains the TLS extension field from the heartbeat interface of the EDR terminal; The NDR device parses the TLS extension field according to the preset TLS custom handshake extension field to obtain and save the device unique identifier of the EDR terminal. The TLS extension field is constructed according to the preset TLS custom handshake extension field and the device unique identifier of the corresponding EDR terminal after the EDR management center responds to the heartbeat request sent by the EDR terminal.
7. The method of claim 1, wherein the method is used in XDR. The NDR device monitors and parses the TLS extension field, including: The NDR device monitors the heartbeat request sent by the EDR management center to the XDR device; The NDR device obtains the TLS extension field according to the heartbeat request sent by the EDR management center; The NDR device parses the TLS extension field according to the preset TLS custom handshake extension field to obtain and save the device unique identifier of the EDR terminal. The TLS extension field is constructed by the EDR management center by packing the device unique identifiers of multiple EDR terminals together according to the preset TLS custom handshake extension field, and the EDR management center sends the heartbeat request to the XDR device after constructing the TLS extension field.
8. The method of claim 1, wherein the method is used in XDR. Further comprising: According to the obtained device identifier information of the group, the basic information and security information of the EDR terminal and the NDR device in the same group are obtained; The basic information and security information of the EDR terminal and the NDR device in the same group are associated and analyzed to obtain an association analysis result.
9. A device for accurately associating network end relationships in XDR, characterized in that, Comprising: A receiving module, the receiving module is used for receiving the device unique identifier request of the EDR terminal and the device unique identifier request of the NDR device; An allocation module, the allocation module is used for responding to the device unique identifier request of the EDR terminal and the device unique identifier request of the NDR device, and allocating corresponding device unique identifiers to the corresponding NDR device and EDR terminal respectively; An obtaining module is configured to obtain device identification information of groups from the NDR device, each group of the device identification information comprising a device unique identification of an NDR device and device unique identifications of a plurality of EDR terminals, the device unique identification of the NDR device being the device unique identification of the NDR device itself, the device unique identifications of the EDR terminals being obtained by monitoring the NDR device and parsing a TLS extension field according to a preset TLS custom handshake extension field, the TLS extension field being constructed by the EDR management center according to the preset TLS custom handshake extension field and the device unique identifications of the EDR terminals, and the TLS custom handshake extension field being predefined by the NDR, the EDR and the XDR.
Citation Information
Patent Citations
Alarm source positioning method and device, equipment and storage medium
CN115442279A
Coordinated monitoring of heterogeneous domains in extended detection and response (XDR) systems
WO2024226645A1