A network threat detection system based on dynamic correlation analysis of multi-protocol sessions

Abstract

The present invention relates to a network threat detection system based on dynamic correlation analysis of multi-protocol sessions that detects intelligent hybrid cyber threats by dynamically linking encrypted and unencrypted traffic without a decryption process, comprising: a traffic collection unit that collects traffic data; a metadata extraction unit that extracts metadata for each session from the collected traffic data; a session grouping unit that creates session groups by grouping multiple sessions based on the same host for all sessions that occurred within a time window by referencing the metadata of each session; an AI correlation rule module that stores correlation rules, wherein each correlation rule determines the degree of threat according to conditions between metadata of different sessions or conditions regarding statistical values ​​of sessions within each session group; a correlation analysis unit that calculates a correlation score by applying the correlation rules stored in the AI ​​correlation rule module to analyze the multidimensional correlation between sessions of each session group; and a threat determination unit that determines whether there is a threat to each session group based on the calculated correlation score. By detecting attacks through the system described above by analyzing the dynamic correlation between encrypted protocol sessions and unencrypted protocol sessions in real time, it is possible to identify and block hybrid cyber attacks that are difficult to detect using a single protocol analysis method.

Description

Technology Field

[0001] The present invention relates to a network threat detection system based on dynamic correlation analysis of multiple protocol sessions, which detects cyber attacks by analyzing raw traffic collected on a network without decryption, and detects them by analyzing in real time the dynamic correlation between encrypted protocol sessions such as TLS (Transport Layer Security), QUIC, DTLS (Datagram Transport Layer Security), and SSH (Secure Shell) and non-encrypted protocol sessions such as HTTP (Hypertext Transfer Protocol), DNS (Domain Name System), FTP (File Transfer Protocol), and SMB (Server Message Block). Background Technology

[0002] As the majority of modern network traffic is encrypted, attackers prefer to conceal malicious activities within encrypted traffic. In particular, sophisticated attackers, such as state-sponsored attack groups, employ hybrid attack strategies that combine encryption protocols like TLS for Command & Control (C2) communications with non-encryption protocols like DNS and FTP for data leakage or the horizontal propagation of malware.

[0003] Conventional inspection methods based on decrypting encrypted traffic have the potential for severe performance degradation and violations of personal information protection laws. Specifically, they decrypt encrypted traffic, such as HTTPS traffic, and use predefined patterns or signatures on the decrypted traffic to detect malicious activity or security threats in network traffic [Patent Document 1]. For example, an HTTPS decryption proxy is placed between a client and a server to decrypt encrypted traffic to check for malicious software, and then re-encrypts it and transmits it to the target IP. While this approach has the advantage of allowing existing threat detection methods to be used as is when detecting encrypted malicious code traffic, it has the disadvantages of high costs for decryption, network performance degradation, increased latency, and undermining the original purpose of HTTPS, which is to guarantee privacy.

[0004] To address these problems, a technology capable of accurately detecting malicious code traffic without decrypting encrypted traffic, such as HTTPS traffic, has been proposed [Patent Documents 2, 3]. The aforementioned prior art determines whether a traffic is malicious code by using only the metadata of the encrypted traffic without decrypting the encrypted traffic. Since such prior art does not decrypt traffic data, it has the advantage of being processed very quickly and having low costs.

[0005] However, conventional technologies that analyze metadata without decryption are mostly limited to single-protocol analysis, presenting clear limitations in identifying complex attack flows that traverse multiple protocols. Therefore, there is a need for new technologies capable of effectively detecting multi-protocol-based intelligent threats without infringing on privacy. Prior art literature

[0006] Korean Registered Patent No. 10-2702108 (Published Sep. 04, 2024) Korean Registered Patent No. 10-0862321 (Published Oct. 13, 2008) Korean Patent Application No. 10-2025-0046972 (Filed Apr. 10, 2025) The problem to be solved

[0007] The objective of the present invention is to solve the problems described above by providing a network threat detection system based on dynamic correlation analysis of multiple protocol sessions, which detects cyber attacks by analyzing raw traffic collected on a network without decryption, and detects them by analyzing in real time the dynamic correlation between encrypted protocol sessions such as TLS (Transport Layer Security), QUIC, DTLS (Datagram Transport Layer Security), and SSH (Secure Shell) and non-encrypted protocol sessions such as HTTP (Hypertext Transfer Protocol), DNS (Domain Name System), FTP (File Transfer Protocol), and SMB (Server Message Block).

[0008] In particular, the objective of the present invention is to provide a network threat detection system based on dynamic correlation analysis of multiple protocol sessions, which does not analyze encryption protocol (TLS) sessions and non-encryption protocol (DNS, HTTP) sessions individually, but rather links heterogeneous protocol flows occurring on the 'same host' into a single logical 'behavior group' to identify and detect the overall context of an attack.

[0009] In addition, the objective of the present invention is to provide a network threat detection system based on dynamic correlation analysis of multiple protocol sessions that detects intelligent hybrid cyber threats by dynamically linking encrypted traffic and unencrypted traffic without a decryption process.

[0010] In addition, the objective of the present invention is to provide a network threat detection system based on dynamic correlation analysis of multiple protocol sessions that detects unknown threats without relying on known threat information (such as blacklists). means of solving the problem

[0012] To achieve the above objective, the present invention relates to a network threat detection system based on dynamic correlation analysis of multiple protocol sessions, comprising: a traffic collection unit for collecting traffic data; a metadata extraction unit for extracting metadata for each session from the collected traffic data; a session grouping unit for creating session groups by grouping multiple sessions based on the same host for all sessions that occurred within a time window by referencing the metadata of each session; an AI correlation rule module for storing correlation rules, wherein each correlation rule determines the degree of threat according to conditions between metadata of different sessions or conditions regarding statistical values ​​of sessions within each session group; a correlation analysis unit for calculating a correlation score by applying the correlation rules stored in the AI ​​correlation rule module to analyze the multidimensional correlation between sessions of each session group; and a threat determination unit for determining whether there is a threat to each session group based on the calculated correlation score.

[0013] In addition, the present invention relates to a network threat detection system based on dynamic correlation analysis of multiple protocol sessions, wherein the traffic collection unit collects both encrypted traffic and unencrypted traffic data, and the metadata extraction unit extracts metadata from the collected encrypted traffic and unencrypted traffic, respectively, without decryption.

[0014] In addition, the present invention relates to a network threat detection system based on dynamic correlation analysis of multiple protocol sessions, wherein the session grouping unit identifies the same host using the IP address or domain of an internal source among the metadata of each session.

[0015] In addition, the present invention relates to a network threat detection system based on dynamic correlation analysis of multiple protocol sessions, wherein the metadata extraction unit generates a session feature vector for each session composed of metadata of each session, and further comprises a group vector generation unit that generates a group feature vector composed of statistical values ​​of metadata for sessions within each session group.

[0016] In addition, the present invention relates to a network threat detection system based on dynamic correlation analysis of multiple protocol sessions, wherein the correlation rule is characterized by being one or more of a first type of correlation rule that analyzes whether the destinations of different sessions within each session group are the same, a second type of correlation rule that analyzes the order of occurrence of different sessions within each session group, and a third type of correlation rule that analyzes statistics for all sessions in each session group.

[0017] In addition, the present invention relates to a network threat detection system based on dynamic correlation analysis of multiple protocol sessions, wherein the threat determination unit calculates a correlation score based on two or more correlation rules in the correlation analysis unit, makes a final determination by weighting and summing the correlation scores or calculates a final correlation score based on the maximum correlation score, and determines whether there is a threat or the degree of threat by comparing the final correlation score with a predetermined threshold.

[0018] In addition, the present invention is characterized in that, in a network threat detection system based on dynamic correlation analysis of multiple protocol sessions, it further comprises a feedback unit that automatically generates correlation rules by training a machine learning model using metadata of accumulated session groups and updates the automatically generated correlation rules to the AI ​​correlation rule module.

[0019] In addition, the present invention relates to a network threat detection system based on dynamic correlation analysis of multiple protocol sessions, wherein the feedback unit collects metadata of session groups having normal traffic, generates a normal model defining normal traffic of the normal session groups from these metadata, and generates correlation rules from the metadata of session groups deviating from the normal model.

[0020] In addition, the present invention relates to a network threat detection system based on dynamic correlation analysis of multiple protocol sessions, wherein the input data in the normal model comprises one or more of a session feature vector, a group feature vector, or a sub-feature vector of the session feature vector or the group feature vector.

[0021] In addition, the present invention relates to a network threat detection system based on dynamic correlation analysis of multiple protocol sessions, wherein the metadata is collected on a session basis, and the session is a session formed on the Transport Layer, and is a session by an application protocol or a protocol for secure communication, and the metadata includes control data necessary for the transmission and processing of traffic within each session, or statistical data regarding traffic within each session. Effects of the invention

[0022] As described above, according to the network threat detection system based on dynamic correlation analysis of multiple protocol sessions according to the present invention, by analyzing the dynamic correlation between encrypted protocol sessions and non-encrypted protocol sessions in real time to detect attacks, the effect of identifying and blocking hybrid cyber attacks that are difficult to detect with a single protocol analysis method is obtained.

[0023] In addition, according to the network threat detection system based on dynamic correlation analysis of multiple protocol sessions according to the present invention, by dynamically linking encrypted traffic and unencrypted traffic without a decryption process, scalability for various modern protocols is secured, and the accuracy of attack detection is increased and false positives are minimized through multidimensional correlation analysis.

[0024] In particular, the present invention can fundamentally resolve the detection gap in single protocol analysis.

[0025] Furthermore, according to the network threat detection system based on dynamic correlation analysis of multiple protocol sessions according to the present invention, by analyzing only the metadata exposed on the 'surface' of the session without decrypting encrypted communication content and detecting the "combination of abnormal behaviors different from normal" itself instead of finding specific attack codes (signatures), an effect is obtained that enables response to unknown new and variant attacks while ensuring personal information protection and high performance. Brief explanation of the drawing

[0026] FIG. 1 is a diagram illustrating the configuration of the entire system for implementing the present invention. FIG. 2 is a block diagram showing the configuration of a network threat detection system based on dynamic correlation analysis of multiple protocol sessions according to an embodiment of the present invention. FIG. 3 is an example diagram visually showing how sessions of multiple protocols (TLS, DNS, HTTP) occurring on the same host in an embodiment of the present invention are connected and analyzed as a single threatening act by 'correlation analysis'. FIG. 4 is an example screen providing judgment results in the form of a visualized dashboard and report according to an embodiment of the present invention. Specific details for implementing the invention

[0027] Hereinafter, specific details for implementing the present invention will be explained with reference to the drawings.

[0028] In addition, in describing the present invention, identical parts are denoted by the same reference numerals, and their repeated description is omitted.

[0029] First, examples of the configuration of the overall system for implementing the present invention will be described with reference to FIG. 1.

[0030] As seen in FIG. 1(a) or FIG. 1(b), the entire system for implementing the present invention comprises a first device (10) and a second device (20) for transmitting and receiving data, a network (80) for connecting the first device (10) and the second device (20) to enable communication, and a threat detection system (30) for connecting to the network (80) to acquire traffic data and detect attack activities.

[0031] First, the first device (10) and the second device (20) are devices that perform data communication, such as communication terminals and communication servers, and preferably have computing functions and communication functions, such as servers, PCs, smartphones, and tablet PCs.

[0032] Additionally, the threat detection system (30) is a system for detecting attack threats from a network perspective, and is equipped with a tap that connects to the network (80) to collect traffic data transmitted and received from the network (80), analyzes the collected traffic data to monitor it, and detects attack threats.

[0033] At this time, as shown in FIG. 1(a), the threat detection system (30) connects to a network (80) to which the first device (10) and the second device (20) are connected and collects traffic data. Alternatively, as shown in FIG. 1(b), traffic data can be collected from a network (80) to which the first device (10) communicates with the second device (20) located at a distance. That is, traffic data can be collected on a network (80) connected to either the first or second device (10, 20) that is communicating.

[0034] At this time, preferably, the attack detection system (30) can analyze or monitor communication traffic by copying (mirroring) it using a network tap, etc. Alternatively, the attack detection system (30) can be constructed separately from the network tap (not shown) and receive, analyze, and monitor communication traffic collected from the network tap.

[0035] Alternatively, as another embodiment, the threat detection system (30) may be implemented within the first device or the second device (20) to collect and monitor traffic data transmitted and received at the network level of the device (e.g., operating system TCP / IP stack, etc.).

[0036] Next, the configuration of a network threat detection system based on dynamic correlation analysis of multiple protocol sessions according to an embodiment of the present invention will be described with reference to FIG. 2.

[0037] As shown in FIG. 2, a network threat detection system (30) based on dynamic correlation analysis of multiple protocol sessions according to an embodiment of the present invention is composed of a traffic collection unit (31) for collecting traffic data, a metadata extraction unit (32) for extracting metadata, a session grouping unit (33) for grouping sessions, a correlation analysis unit (34) for performing correlation analysis, and a threat determination unit (35) for determining an attack threat using the results of the correlation analysis.

[0038] Additionally, it may be configured to further include an AI correlation rule module (41) equipped with correlation rules, a threat intelligence DB (42), a management reporting unit (36) that manages and outputs analysis results or judgment results, a group vector generation unit (38) that generates statistical values ​​of sessions within each group into a vector, or a feedback unit (37) that accumulates correlation analysis results or threat judgment results and reflects them in the AI ​​correlation rule module (41) or threat DB (42).

[0039] First, the traffic collection unit (31) collects traffic data transmitted and received on the network (80). This will be referred to as raw traffic (or raw traffic data). Additionally, the collected traffic data is transmitted to the metadata extraction unit (32).

[0040] In particular, the traffic collection unit (31) collects network traffic using a passive network capture module such as a network tap. That is, it acquires network traffic by copying (mirroring) it without interfering with it. Through this, the network can be monitored without affecting network equipment or hosts.

[0041] Alternatively, the traffic collection unit (31) can collect traffic using the SPAN (Switched Port Analyzer) port of a network switch, etc. That is, the traffic collection unit (31) can collect all packets entering and exiting a specific port or VLAN by copying them to another port (SPAN target port) using SPAN.

[0042] Through this, the traffic collection unit (31) can collect all raw packets passing through the network infrastructure by mirroring them in a non-intrusive manner.

[0043] Additionally, preferably, the traffic collection unit (31) can capture traffic with high performance by using a ring buffer to overcome the performance overhead of the operating system (OS) TCP / IP stack. A ring buffer is a buffer that uses a fixed-size memory space in a circular manner. Data is filled sequentially, and when the buffer is full, the oldest data is overwritten with new data. That is, it has a FIFO (First-In-First-Out) structure in which data is added from the tail and removed from the head, and recycles memory space.

[0044] That is, the traffic collection unit (31) stores packets copied from the network in a ring buffer and reads and analyzes packets from the ring buffer. Since this process is performed in real time, the traffic collection unit (33) can process all packets without missing any, and can efficiently manage system resources by preventing frequent memory allocation and deallocation.

[0045] Meanwhile, preferably, as an example, the traffic data is communication data, such as packets transmitted or received by an encrypted protocol session or an unencrypted protocol session.

[0046] In addition, preferably, encryption protocols include TLS (Transport Layer Security) / SSL (Secure Sockets Layer), QUIC, DTLS (Datagram Transport Layer Security), SSH (Secure Shell), etc. In addition, non-encryption protocols include HTTP (Hypertext Transfer Protocol), DNS (Domain Name System), FTP (File Transfer Protocol), SMB (Server Message Block), etc.

[0047] In addition, the traffic data collected during an encryption protocol session includes packets for transmitting and receiving application data after key exchange, in addition to packets from the handshake process.

[0048] The raw traffic data collected from encrypted protocol sessions and non-encrypted protocol sessions will be referred to as encrypted traffic data or non-encrypted traffic data, respectively.

[0049] Next, the metadata extraction unit (32) extracts metadata for each session from the collected raw traffic (or raw traffic data). In addition, it generates a Session Feature Vector for each of the metadata.

[0050] That is, the metadata extraction unit (32) extracts encrypted traffic metadata and unencrypted traffic metadata from the collected traffic without decryption. In particular, the metadata extraction unit (32) extracts metadata according to the standard specifications (pre-determined rules) of each protocol without decryption.

[0051] At this time, metadata is collected on a session basis. In particular, a traffic session (or communication session) is a session formed at the transport layer, such as TCP / IP (or UDP), and refers to a session by application protocols such as DNS, HTTP, and POP3, or protocols such as SSL and TLS for secure communication.

[0052] In this case, the metadata consists of control data (control information) necessary to properly transmit and process communication traffic within the session, or statistical data regarding the communication traffic within the session. In particular, metadata such as control information is extracted from data excluding the actual data to be transmitted, and preferably, is extracted from the header or part of the payload (footer) of the communication traffic. Additionally, the statistical data within the session consists of predetermined statistical values, such as the duration of communication within the session and transmitted / received bytes.

[0053] In particular, metadata is collected for each session, and each session information (session data) consists of a (session) protocol and a (session) time. The session protocol indicates the type of protocol forming the session on the transport protocol, and the session time indicates the duration of the corresponding protocol (e.g., session start / end times). In other words, session time is data used to determine when and in what order multiple types of protocols are executed.

[0054] In addition, each metadata within each session consists of a name (metadata name / type) and its data value (metadata value). The name / type is data used to refer to or identify the corresponding metadata, and the data value represents the value of the corresponding metadata. That is, each metadata is specified by the metadata name / type, metadata value, protocol (of the session to which it belongs), and time (of the session to which it belongs).

[0055] For example, metadata consists of TLS SNI, JA3, certificate information, DNS query, source, destination, protocol type, session duration, transmitted and received bytes, etc.

[0056] In addition, the Session Feature Vector for each session is generated by composing these metadata values.

[0057] Session feature vector ={protocol:TLS, session start time: 08:11:24, TLS SNI: mail.naver.com, JA3: 771 4865-4866-4867- ..., source IP: 211.122.21.01, ...}

[0058] Each session feature vector differs by session type or session protocol, and is composed of each metadata value according to predefined rules for each session. In other words, depending on whether the session protocol is TLS, DNS, HTTP, etc., the types of metadata differ slightly, and the session feature vectors are configured differently.

[0059] Meanwhile, JA3 / JA3S, SNI, HTTP methods, and DNS queries are identifiable metadata. Identifying metadata is a core identifier that represents the 'identity' or 'intent' of each session. It specifies which client application (JA3), which server domain (SNI, DNS query), and what action (HTTP method) it intends to perform. These serve as the 'links' that logically connect multiple protocol sessions.

[0060] 'Identifiable metadata' refers to data that goes beyond identifying the communication counterpart (server) to enabling the identification of the characteristics of the communication, the type of application used, and even the intent of the communication without opening the encrypted payload.

[0061] JA3 / JA3S are hash values ​​that identify the unique characteristics of an SSL / TLS client application like a fingerprint. In other words, they are generated by combining various parameters (e.g., TLS version, encryption method, extension list) included in the Hello packets exchanged during the SSL / TLS handshake process. Specifically, JA3 is generated based on the Client Hello packet sent by the client to the server, and JA3S is generated based on the Server Hello packet that the server responds to the client.

[0062] In particular, JA3 / JA3S hashes are unique 'fingerprints' of the TLS libraries and settings used by specific client or server applications, which can identify whether the communicating entity is a legitimate web browser or a specific malicious code.

[0063] In addition, SNI (Server Name Indication) is an extension of the TLS (Transport Layer Security) protocol that serves to inform the server which domain a client intends to connect to when a single web server operates multiple websites (domains).

[0064] In addition, HTTP methods are commands that define what kind of work a client requests a web server to perform, and consist of GET (querying server resources), POST (creating new resources or transmitting data), PUT (modifying / creating resources), PATCH (modifying resources), DELETE (deleting resources), etc.

[0065] A DNS query is a request sent to a DNS server to convert a domain name entered by a user (e.g., www.example.com) into an IP address that the computer can understand (e.g., 192.0.2.1).

[0066] In other words, SNI or DNS queries specify the 'target domain' that the client intends to connect to, thereby enabling the identification of the primary intent of the communication. HTTP methods ('GET', 'POST') indicate the specific intent of whether to 'query' or 'transmit data' regarding the target.

[0067] In addition, the list of cipher suites or extensions exchanged during the TLS handshake can identify the technical characteristics of which encryption level and function the communication session intends to use.

[0068] Furthermore, metadata—such as source / destination, sender / receiver, session connection time (duration), exchanged URLs, connection method, protocol, data size, filename, and file type—is data that indicates the session state of the traffic. In other words, session metadata related to the transmission and reception of traffic is quantitative data that represents the 'state' and 'behavior' of the session. Information such as how long the connection has lasted and how much data has been exchanged provides important contextual information for determining the normal or abnormal state of the session.

[0069] Additionally, session metadata is explicitly used in the logic to detect TLS_Short_Connection (abnormally short connection) threats by checking the session duration within the connection_state_remove event handler.

[0070] Taking a TLS session as an example, the metadata in the TLS handshake data includes information necessary to establish communication between the client and the server. This metadata contains various elements exchanged to establish an encrypted session and consists of the TLS version, cipher suite, random value, SSL certificate, and key exchange information. This metadata plays a crucial role in the handshake process, enabling the client and server to authenticate each other and exchange the information required to establish an encrypted session.

[0071] Specifically, the TLS version indicates the TLS protocol version supported by the client and the server. Additionally, a cipher suite is a set that defines encryption methods, hash functions, key exchange mechanisms, and the like. SSL certificates are used to verify the server's identity and validate whether the client can trust it. Key exchange information contains the data required for key exchange methods such as RSA and Diffie-Hellman.

[0072] Furthermore, encrypted traffic metadata consists of control data extracted during the handshake negotiation process prior to the start of encryption. In the previous example, JA3 / JA3S (unique client / server fingerprints), SNI (target domain), certificate information (issuer, validity period, public key, etc.), and a list of cipher suites (a list of ciphers for negotiation) are extracted from encrypted traffic such as TLS. These consist of information related to the 'configuration' of the encrypted communication.

[0073] In addition, metadata for unencrypted traffic (e.g., DNS, HTTP) is extracted from headers and control information that are always transmitted in plaintext according to protocol specifications. For example, DNS query / response data (query domain, response IP), HTTP Host headers (destination website), HTTP User-Agent (client software information), and HTTP methods (request actions such as GET, POST, etc.) are extracted. These consist of information related to the 'content' of the actual data communication.

[0074] The present invention performs a linked analysis of two fundamentally different types of metadata. For example, it compares whether a domain queried via DNS (unencrypted) matches the SNI connected via TLS (encrypted).

[0076] Next, the session grouping unit (33) creates a session group by grouping multiple traffic sessions based on the source of the traffic by referring to the metadata of each session traffic.

[0077] Preferably, grouping is performed on all sessions that occur within a time window. The time window is determined in advance. That is, session traffic that is sequential in time is separated by time window, and within each separated time window, the traffic within that time window is grouped.

[0078] At this time, traffic sessions whose source is the same host are grouped into a single session group. Additionally, preferably, the same host of the traffic source can be identified by an internal source IP address, domain, etc. The criteria for the same host of the source can be determined in advance.

[0079] In other words, multiple collected individual sessions are generated into a logical 'session group' that occurred within a time window based on specific, identical criteria, such as the 'same internal source IP address'. Based on the 'same internal source IP address', all individual sessions (TLS, DNS, HTTP, etc.) that occurred within a specific time window are dynamically reorganized into a single logical 'session group'. This 'session group' becomes the basic unit of correlation analysis.

[0080] Next, the group vector generation unit (38) generates a vector of statistical values ​​for the metadata of the sessions within each group.

[0081] In other words, statistical values ​​of metadata for sessions within each group are calculated, and these are generated as Group Feature Vectors. Specifically, each statistic, the method of calculating its value, and the generation of the feature vector are set according to predefined rules.

[0082] For example, traffic statistics for sessions within each group consist of the total number of DNS queries, average DNS TTL, number of TLS sessions, average TLS session duration, number of JA3 types, and HTTP POST request ratio.

[0083] In addition, these traffic statistics for sessions within each group are generated as group feature vectors in the following form.

[0084] Group feature vector = {Number of DNS queries: 15, Average DNS TTL: 250 seconds, Number of TLS sessions: 10, Average TLS session duration: 30 seconds, Number of JA3 types: 2, HTTP POST request rate: 0.1, ...}

[0085] The session feature vector described earlier represents the microscopic characteristics of individual sessions. This is the primary data used by the correlation analysis unit to analyze relationships between sessions (e.g., destination mismatch, order violation).

[0086] In contrast, the group feature vector represents the macroscopic characteristics of the entire session group. This is key data used by the correlation analysis unit to analyze statistical abnormalities of the entire group (e.g., abnormal rates of specific protocols, outliers in average session time).

[0087] Next, the AI ​​correlation rule module (41) stores the correlation rules.

[0088] Correlation rules represent rules that determine the presence of a threat or the degree of threat (threat level, correlation score, etc.) based on conditions regarding metadata between different sessions or statistics of sessions within a group.

[0089] Correlation rules regarding the association between sessions are classified into temporal proximity, destination association, sequentiality of actions, and statistical normality of actions.

[0090] First, the correlation rule of Destination Association (Type 1 correlation rule) analyzes whether different protocol sessions are logically directed toward the same destination. For example, the domain queried via DNS and the server connected via TLS must be logically identical.

[0091] In other words, correlation rules compare destination-related metadata (SNI, DNS queries, HTTP Host headers, etc.) extracted from each protocol. For instance, if the Host header value of HTTP traffic within a single TCP session differs from the SNI value of TLS traffic, it indicates tunneling intended to penetrate the internal network. Additionally, during the TLS handshake, it verifies whether the Server Name (SNI) requested by the client matches the Certificate Name (CN) actually presented by the server. If there is a discrepancy, it is considered a clear anomaly, such as a Man-in-the-Middle (MITM) attack.

[0092] Next, the correlation rule of the behavioral sequence (Type 2 correlation rule) analyzes the order of occurrence of session events.

[0093] In other words, correlation rules compare the order of session protocol events occurring within the same group with a predefined normal / abnormal sequence. For instance, normal web browsing proceeds in the order of 'DNS query -> TCP connection -> TLS handshake'. If the TLS handshake occurs first without a DNS query, it corresponds to a threat such as "malware connecting to a hardcoded IP." That is, for normal communication, a DNS query for the relevant domain must precede the TLS connection. By detecting the act of connecting directly to an IP address while skipping this normal sequence of behavior, it identifies patterns in which malware connects to a hardcoded C2 server.

[0094] Next, the correlation rule for the statistical normality of behavior (Type 3 correlation rule) analyzes the statistics for the entire session (or session metadata) of the session group. That is, it analyzes the traffic statistics of the session group in comparison to the statistics of normal traffic.

[0095] In particular, the correlation rule for the statistical normality of behavior is a rule established by the aforementioned Group Feature Vector, that is, traffic statistics for sessions within the group (total number of DNS queries, average DNS TTL, number of TLS sessions, average TLS session duration, number of JA3 types, HTTP POST request ratio, etc.).

[0096] In other words, correlation rules are based on conditions that deviate from normal traffic statistics, and when those conditions are met, threat judgments and correlation scores are established. For example, a correlation rule is set stating that "typical users have a proportional relationship between the number of DNS queries and TLS sessions, and a low HTTP POST request rate." Additionally, by quantitatively measuring connection frequency and time intervals, such as "connecting to the same destination server five or more times within 10 seconds," the periodic C2 communication (Beaconing) behavior of malware is modeled and detected.

[0097] As an example, the correlation rule for statistical normality can be established as follows.

[0098] "IF (Average DNS TTL < 60 seconds) AND (Average TLS session duration < 1 second) AND (Number of TLS sessions > 40) THEN Threat level determined as 'High'"

[0099] In this case, threat levels such as 'high' can be converted into correlation scores, etc., according to predetermined rules.

[0100] Next, the Temporal Proximity correlation rule (Type 4 correlation rule) measures how close different session events (session metadata) are in time. Automated attack scripts tend to perform multiple actions sequentially within a very short period of time.

[0101] In other words, the correlation rule calculates the difference in session (event) occurrence times (Delta Time) and compares it with a threshold. For example, if the time interval between the start of two different TLS sessions originating from the same source host (within the same group) is less than 0.2 seconds, it is determined to correspond to a botnet C2 connection, etc., and the correlation score is calculated according to a predetermined rule.

[0102] That is, the AI ​​correlation rule module (41) serves as a repository of rules referenced by the real-time correlation analysis unit and an execution engine. It must be operated stably so as not to affect the real-time performance of the system.

[0103] Meanwhile, the AI ​​correlation rule module (41) is updated by the feedback unit (37). That is, the feedback unit (37) is responsible for an asynchronous or periodic learning process that trains a machine learning model based on accumulated data and generates new rules. Only verified rules generated here are updated in the AI ​​correlation rule module (41).

[0104] Next, the threat intelligence DB (42) stores threat information such as malicious IPs, domains, and malware hashes. That is, the threat intelligence DB (42) stores the latest threat information, such as known malicious IPs, domains, and C2 server information.

[0105] The stored threat information is used by the threat determination unit (35) to determine whether there is a final threat. That is, the threat determination unit (35) makes a determination by comparing it with the stored threat information. In addition, the correlation analysis unit (34) analyzes using the threat intelligence DB (42). Through this, the accuracy of the determination or analysis can be increased.

[0106] In particular, preferably, the threat intelligence DB (42) stores threat information (or signature) as a value corresponding to metadata (IP, domain, JA3, etc.). That is, it stores threat information of specific metadata rather than correlation analysis between sessions.

[0107] Next, the correlation analysis unit (34) analyzes the multidimensional correlation between the grouped sessions and calculates the correlation score. In particular, it performs correlation analysis within the grouped sessions according to the correlation rules.

[0108] That is, the correlation analysis unit (34) calculates a correlation score by performing a multidimensional correlation analysis on the traffic sessions within each session group generated by the session grouping unit (33) above.

[0109] A correlation rule represents a rule that considers a combination of two or more session metadata as a specific threat if it meets specific conditions. In particular, the correlation rule is determined by referring to the correlation rule provided in the AI ​​correlation rule module (41).

[0110] As previously explained, the associations of events within a session group are analyzed multidimensionally across multiple types, such as temporal proximity, destination association, sequentiality of actions, and statistical normality of actions, and correlation scores are calculated for each.

[0111] In particular, the correlation analysis unit (34) applies the correlation rules of the AI ​​correlation rule module (41) during the analysis process. In particular, the correlation analysis unit (34) applies the latest updated rules from the AI ​​correlation rule module (41).

[0112] Additionally, the correlation analysis unit (34) transmits the calculated result to the threat determination unit (35).

[0113] Figure 3 visually shows how sessions of multiple protocols (TLS, DNS, HTTP) occurring on the same host are connected and analyzed as a single threatening act through 'correlation analysis'.

[0115] Next, the threat determination unit (35) determines whether there is a final threat based on the correlation score calculated earlier by the correlation analysis unit (34). That is, it determines whether there is a threat to the session group.

[0116] That is, the threat determination unit (35) compares the correlation score with a predetermined threshold and determines whether there is a threat based on the comparison result. Preferably, if the correlation score exceeds the threshold, it is considered a 'suspicious act'.

[0117] In particular, for one session group, a correlation score can be calculated for each by two or more correlation rules in the correlation analysis unit (34) mentioned above. The final decision can be made by weighting the correlation scores and summing them, or by using the maximum correlation score.

[0118] For example, a predefined risk weight (e.g., 3 points for using a self-signed certificate, 2 points for using a non-standard port) is assigned to each 'weak threat indication'. Additionally, the weight scores of all indications detected within a single 'session group' are summed to calculate the final threat score (ML Score). If this score exceeds a set threshold (e.g., 5 points), it is finally determined to be a 'confirmed threat' based solely on the system's own analysis, without querying an external database.

[0119] Additionally, the threat determination unit (35) can make a final determination of a 'confirmed threat' by precisely comparing the specific metadata of the session group with the threat intelligence DB (42).

[0120] The determined result is transmitted to the management reporting department (36).

[0121] Next, the feedback unit (37) learns the metadata of the accumulated session group using a machine learning model to automatically generate a new correlation rule, and updates (updates) the automatically generated correlation rule to the AI ​​correlation rule module (41).

[0122] That is, the feedback unit (37) continuously learns the metadata of the accumulated session group through a machine learning model and identifies new types of attack patterns to automatically generate new correlation rules. The generated correlation rules are updated in the AI ​​correlation rule module (41), and the correlation analysis unit (34) performs correlation analysis based on the updated correlation rules. The correlation rules can be continuously generated and updated.

[0123] Specifically, the feedback unit (37) collects session traffic (or session group metadata) that has normal traffic, creates a model (or normal model) that defines normal traffic of a normal session group from these, and creates correlation rules from session traffic (or session group metadata) that deviates from the normal model.

[0124] In this case, preferably, the normal model can be classified into models that generate correlation rules based on specific types, such as correlation rules for temporal proximity, correlation rules for destination association, correlation rules for behavioral sequence, and correlation rules for statistical normality of behavior. In other words, a normal model can be generated differently for each type and trained accordingly.

[0125] In addition, a normal model is generated by defining the distribution of sessions within a group of normal behaviors or the groups themselves, that is, by establishing the shape and boundaries of 'normal clusters'.

[0126] In this case, the input data in the normal model consists of a session feature vector, a group feature vector, a feature vector of all of them, or sub-feature vectors of those feature vectors.

[0127] As previously explained, the Session Feature Vector is generated by composing the metadata values ​​of the corresponding session. Additionally, the Group Feature Vector is generated by composing the traffic statistics values ​​for the sessions within the corresponding group.

[0128] Furthermore, a sub-feature vector refers to a feature vector composed of only a portion of each feature vector. For example, since the correlation rule for Temporal Proximity is related only to metadata such as each session's protocol and start / end times, a sub-feature vector can be constructed using only this metadata from the session feature vector.

[0129] Preferably, numerous collected normal traffic vectors (or group feature vectors) are trained using a machine learning model such as a clustering algorithm (e.g., DBSCAN, K-Means) or an autoencoder. In other words, the normal model is a machine learning model that classifies normal session traffic as described above.

[0130] For example, a normal group model is trained with a pattern such as, "For typical users, the number of DNS queries and TLS sessions are proportional, and the HTTP POST request rate is low."

[0131] When the traffic feature vector (or group feature vector) for each session group is generated, it is input into the existing 'normal model'. If the new vector is located far from the normal cluster (clustering-based) or if the autoencoder fails to properly reconstruct it (if the reconstruction error is large), this vector is detected as an 'anomaly'.

[0132] It analyzes the features of the detected 'outlier' vector and generates it using rules (or correlation rules) based on logical functions.

[0133] For example, assume that an outlier vector exhibits characteristics such as {number of DNS queries: 1, average DNS TTL: 30 seconds, number of TLS sessions: 50, average TLS session duration: 0.5 seconds, ...}. The AI ​​module analyzes this and automatically generates a new correlation rule such as "IF (average DNS TTL < 60 seconds) AND (average TLS session duration < 1 second) AND (number of TLS sessions > 40) THEN determine threat level as 'high'".

[0134] The newly generated correlation rule is added to the AI ​​correlation rule module (41) and updated.

[0135] Preferably, correlation rules are automatically generated by applying an association rule mining method.

[0136] In other words, while decision trees are optimized for 'classification,' association rule mining (such as Apriori and FP-Growth algorithms) is optimized for finding 'hidden relationships between items' within the data. It identifies "which features appear together when the probability of an anomaly is high."

[0137] The specific generation process is as follows.

[0138] First, perform transaction data transformation.

[0139] Each feature vector (session / group feature vector) identified as an 'outlier' is converted into a single 'transaction'. At this time, continuous values ​​(e.g., average TLS session duration = 0.8 seconds) are discretized into meaningful categories (e.g., duration = short).

[0140] For example, in the case of an outlier vector {average DNS TTL: 30 seconds, average TLS duration: 0.5 seconds, number of JA3 types: 5}, this can be converted into an outlier discrete vector {DNS_TTL=very short, TLS_duration=short, JA3_types=many}.

[0141] Next, perform Frequent Itemset Mining.

[0142] Identify combinations of features that frequently occur together (frequent item sets) across the entire transformed 'outlier' transaction data. (Use Apriori algorithm)

[0143] For example, if the combination {TLS_duration=short, JA3_type=many} is found in 70% of the outlier samples, it becomes a strong candidate pattern.

[0144] Next, rule generation and filtering are performed. Association rules in the form of IF {A} THEN {B} are generated based on the identified frequent item sets. From the numerous generated rules, only statistically significant rules with high confidence and lift are finally selected.

[0145] In this case, confidence represents the proportion of groups containing B among the groups containing A (accuracy of the rule), and lift represents the actual frequency of A and B appearing together relative to the probability of them appearing by chance (interest of the rule).

[0146] Finally, derive the final rule.

[0147] As an example, the following high-quality rules are automatically generated through filtering.

[0148] "IF (TLS_Duration=Short) AND (JA3_Type=Many) THEN Threat level determined as 'High'" (Confidence: 95%, Improvement: 3.2)

[0149] While decision trees primarily find paths leading to a single conclusion (normal / abnormal), association rules excel at discovering complex interrelationships between features, such as "if A and B appear, C also appears." Additionally, they have a high probability of detecting unexpected combinations of tools used by attackers (e.g., combinations of specific User-Agents and specific JA3 hashes).

[0150] Next, the management reporting unit (36) provides the determined results to the manager in a visualized form. That is, the management reporting unit (36) provides the final determination results in the form of a visualized dashboard and report so that the security manager can intuitively recognize and respond quickly to the results.

[0151] Preferably, the management reporting unit (36) displays the threat status as a status graph (or network, directed graph, etc.) composed of nodes and edges. Each node represents a starting point (source), a transit point, a final destination, etc., and the edges represent the path through which traffic passes.

[0152] In addition, the color of the path or edge is displayed differently depending on the type of protocol. In addition, the color is displayed differently depending on the type or risk level of each node. In addition, the type or name of the corresponding device, etc., can be displayed for each node.

[0153] In particular, a node represents a communicating entity and indicates an individual entity (device, server, etc.) on a network. The key attributes of a node consist of a unique identifier (e.g., IP address, domain name), node type (internal host, legitimate external server, malicious server, DNS server, etc.), and the node's risk score (0 to 100).

[0154] Furthermore, edges represent session and behavioral relationships, indicating one or more correlated network sessions that occurred between two nodes. The key attributes of an edge consist of the session protocol, traffic direction (unidirectional, bidirectional), session start time, total amount of transmitted data, risk score, and threat type. The color of the edge indicates the protocol type, and the thickness of the edge indicates the volume of communication traffic. Additionally, the arrow and style of the edge indicate whether it is a normal / general session, suspicious, or confirmed threat.

[0155] Furthermore, a 'waypoint' refers to an intermediate stage of a logical connection occurring at the Application Layer. Waypoints are primarily extracted through HTTP redirection chains or DNS analysis (e.g., CNAME records).

[0156] In addition, preferably, a status graph is displayed for each session group.

[0157] Figure 4 is a screen that provides judgment results in the form of a visualized dashboard and report, showing how detected threats are reported to a security manager. As shown in Figure 4, the starting point, intermediate points, and final destination of an attack can be identified at a glance through the network relationship diagram, and the specific details of the threat can be immediately recognized through the alert panel on the right.

[0158] Next, the effects of the present invention will be explained.

[0159] First, the system according to the present invention can secure hybrid attack detection capabilities. That is, it identifies the entire complex attack flow crossing between encryption and non-encryption protocols as a single threat event, thereby resolving detection gaps in existing security solutions.

[0160] Furthermore, the system according to the present invention can simultaneously achieve personal information protection and high-performance detection. That is, since it does not decode traffic, it can detect threats with high performance while complying with personal information protection regulations.

[0161] In addition, the system according to the present invention can secure intelligent / active threat response capabilities. That is, through the feedback unit (37), it learns not only known attacks but also new and variant attack patterns without signatures and automatically generates detection rules, thereby enabling intelligent and active threat response.

[0162] The system according to the present invention can maximize detection accuracy and reliability. That is, by real-time linkage with the threat intelligence DB (42), the suspicious behavior analyzed internally is cross-verified with externally verified threat information, thereby minimizing false positives and maximizing the reliability of detection.

[0163] The system according to the present invention performs multi-dimensional and composite vector analysis. That is, it does not determine a threat based on a single abnormal sign. It detects multiple 'weak signals,' assigns risk weights to each signal, and makes a final determination based on a composite score calculated by summing them. Through this, it is possible to identify complex threats that are difficult to detect, such as 'low and slow' intelligent attacks.

[0164] In addition, since the system according to the present invention analyzes the abnormality of the behavior itself without relying on known threat information, it can detect new and variant threats that are not in signatures or blacklists.

[0165] Furthermore, the system according to the present invention performs self-contained threat judgment. That is, it does not rely at all on external threat intelligence databases (lists of malicious IPs / domains). It independently determines whether a threat exists based solely on the correlation and statistical anomalies of data collected internally. This is a key feature that enables the detection of new threats not yet registered in external databases, such as zero-day attacks.

[0166] The system according to the present invention can improve security visibility and support rapid decision-making. That is, the management reporting unit (36) visualizes complex attack flows using intuitive network relationship diagrams, etc., so that the security manager can quickly identify threat situations and make clear decisions, such as prioritizing responses.

[0167] Although the invention made by the inventor has been specifically described according to the above embodiments, the present invention is not limited to the above embodiments and can be modified in various ways without departing from the gist thereof. Explanation of the symbols

[0168] 10: First device 20: Second device 30: Attack Detection System 31: Traffic Collection Unit 32: Metadata Extraction Unit 33: Session Grouping Unit 34 : Correlation Analysis Unit 35 : Threat Assessment Unit 36: Management Reporting Department 37: Feedback Department 38 : Group Vector Generation Section 41: AI Correlation Rule Module 42: Threat Intelligence DB 80 : Network

Claims

Claim 1 A network threat detection system based on dynamic correlation analysis of multi-protocol sessions comprises: a traffic collection unit for collecting traffic data; a metadata extraction unit for extracting metadata for each session from the collected traffic data; a session grouping unit for creating session groups by grouping multiple sessions based on the same host for all sessions that occurred within a time window by referencing the metadata of each session; and a correlation rule for storing, wherein each correlation rule is a condition between metadata of different sessions and An AI correlation rule module that determines the level of threat based on conditions regarding the statistical values ​​of sessions within each session group; and a correlation analysis unit that calculates a correlation score by applying correlation rules stored in the AI ​​correlation rule module to analyze the multidimensional correlation between sessions in each session group. and, based on each calculated correlation score, includes a threat determination unit that determines whether there is a threat to each session group, and the metadata extraction unit generates a session feature vector for each session composed of the metadata of each session, and further includes a group vector generation unit that generates a group feature vector composed of the calculated statistical values ​​by calculating the statistical values ​​of the metadata for sessions within each session group, wherein the metadata is collected on a session basis, and the session is a session formed on the Transport Layer, and is a session by an application protocol or a protocol for secure communication, and the metadata includes control data required for the transmission and processing of traffic within each session, and statistical data regarding the traffic within each session, and the correlation rule includes a first type of correlation rule that analyzes whether the destinations of different sessions within each session group are the same, a second type of correlation rule that analyzes the occurrence order of different sessions within each session group, and a third type of correlation rule that analyzes statistics for all sessions in each session group, and the third type of correlation rule is a rule set as a condition for the traffic statistics of the group feature vector, and the group feature vector includes the total number of DNS queries, average DNS TTL, A network threat detection system based on dynamic correlation analysis of multiple protocol sessions, characterized by including the number of TLS sessions, average TLS session duration, number of JA3 types, and HTTP POST request rate. Claim 2 A network threat detection system based on dynamic correlation analysis of multiple protocol sessions, wherein, in claim 1, the traffic collection unit collects both encrypted traffic and unencrypted traffic data, and the metadata extraction unit extracts metadata from the collected encrypted traffic and unencrypted traffic, respectively, without decryption. Claim 3 A network threat detection system based on dynamic correlation analysis of multiple protocol sessions, wherein, in claim 1, the session grouping unit identifies the same host using the IP address or domain of an internal source among the metadata of each session. Claim 4 delete Claim 5 delete Claim 6 A network threat detection system based on dynamic correlation analysis of multiple protocol sessions, wherein, in claim 1, the threat determination unit calculates a correlation score based on two or more correlation rules in the correlation analysis unit, makes a final determination by weighted summing the correlation scores or calculates a final correlation score based on the maximum correlation score, and determines whether there is a threat or the degree of threat by comparing the final correlation score with a predetermined threshold. Claim 7 A network threat detection system based on dynamic correlation analysis of multiple protocol sessions, characterized in that, in claim 1, it further includes a feedback unit that automatically generates correlation rules by training a machine learning model using metadata of accumulated session groups and updates the automatically generated correlation rules to the AI ​​correlation rule module. Claim 8 A network threat detection system based on dynamic correlation analysis of multiple protocol sessions, wherein, in claim 7, the feedback unit collects metadata of session groups having normal traffic, generates a normal model defining normal traffic of the normal session groups from these metadata, and generates correlation rules from the metadata of session groups deviating from the normal model. Claim 9 A network threat detection system based on dynamic correlation analysis of multiple protocol sessions, characterized in that, in claim 8, the input data in the normal model includes one or more of a session feature vector, a group feature vector, or a sub-feature vector of the session feature vector or the group feature vector. Claim 10 delete

Images