A method and system for monitoring network security events

Abstract

The present application relates to the technical field of data security, and particularly relates to a network security event monitoring method and system, which comprises obtaining security event records and boundary communication records in a security domain, and constructing a security domain topology; determining boundary anchor points representing actual communication passing from the boundary communication records, and associating the security event records with the boundary anchor points as starting points to form event sub-chains; when the records to be associated belong to different security domains, generating a boundary verification sequence, querying the boundary communication records according to communication characteristics, and combining with a log observable state to determine each boundary as passing confirmed, passing denied or unable to verify; adjusting the cross-domain association of the event chain according to the boundary verification state, determining the propagation relationship of the security event between the security domains, and generating a monitoring result. The present application realizes cross-domain propagation monitoring through boundary-by-boundary verification.

Description

Technical Field

[0001] This invention relates to the field of network security technology, specifically to a method and system for monitoring network security incidents. Background Technology

[0002] As network systems continue to expand, network environments are typically divided into multiple security domains based on business type, asset attributes, security level, or management requirements. These different security domains communicate with each other through boundary devices such as firewalls, routing devices, and gateways. After a network security incident occurs, it is usually necessary to analyze the correlations between related events by combining security event records generated within different security domains to reconstruct the propagation process of the network security incident.

[0003] In a cross-security-domain network environment, the propagation of network security incidents may involve multiple security domains and multiple boundary devices. Because security incident records and network communication records originate from different network locations and devices, different records generated during the same propagation process may differ in information such as communication entities, time, and communication status. Furthermore, network communication information may change as it passes through different network nodes, and related records generated by different devices may also be affected by factors such as network operating conditions and recording conditions. Therefore, when there are correlations between event records across multiple security domains, it is necessary to further determine whether the corresponding events formed a continuous propagation process as they crossed different security domains.

[0004] In summary, determining the continuity of the cross-security domain propagation process of cybersecurity incidents is a technical problem that urgently needs to be solved in this field.

[0005] Therefore, a method and system for monitoring network security incidents are proposed. Summary of the Invention

[0006] The purpose of this invention is to provide a method and system for monitoring network security incidents, achieving cross-domain propagation monitoring through boundary-by-boundary verification. This includes acquiring security event records and boundary communication records within a security domain to construct a security domain topology; determining boundary anchor points representing actual communication passage from the boundary communication records, and associating security event records with these boundary anchor points to form event sub-chains; when the records to be associated belong to different security domains, generating a boundary verification sequence, querying boundary communication records based on communication characteristics, and combining this with the observable status of the logs to determine each boundary as confirmed passage, denied passage, or unverifiable; adjusting the cross-domain association of the event chain based on the boundary verification status to determine the propagation relationship of security events between different security domains and generating monitoring results.

[0007] To achieve the above objectives, the present invention provides the following technical solution: A method for monitoring network security incidents, comprising: Acquire security event records and boundary communication records within the security domain, and construct a security domain topology based on the connection relationship between the security domain and boundary devices; determine the boundary anchor points representing the actual communication passage from the boundary communication records, and associate security event records with the boundary anchor points as the starting point to form an event sub-chain; When the security event records to be associated belong to different security domains, the cross-domain association relationship to be verified is determined, and the corresponding boundary verification sequence is generated according to the security domain topology. Based on the communication characteristics of the cross-domain association to be verified, query the boundary communication records and combine them with the observable status of the boundary device logs to determine each boundary as either a confirmed pass, a denied pass, or an unverifiable pass. Adjust the cross-domain association of the event chain according to the boundary verification status: allow cross-domain association when the confirmed pass is enabled, terminate the association and split the event chain when the denied pass is enabled, and stop the expansion and retain the confirmed event sub-chain when the unverifiable pass is unverifiable. Based on the processed event chain and boundary verification status, the propagation relationship of cybersecurity events between security domains is determined and monitoring results are generated.

[0008] Preferably, the process of constructing a security domain topology based on the connection relationship between security domains and boundary devices includes: acquiring security event records generated within multiple security domains and boundary communication records generated by boundary devices located between different security domains; determining the security domain to which the communication entity in the security event records belongs based on the correspondence between assets and security domains, and determining the security domain connected to each boundary device based on the connection relationship between boundary devices and security domains; using security domains as topology nodes, establishing inter-domain connection relationships between the topology nodes based on the security domains connected to each boundary device, and associating the corresponding boundary device identifier with the inter-domain connection relationship to form a security domain topology representing the connection relationship between each security domain and the boundary devices traversed by cross-security domain communication.

[0009] Preferably, the process of determining the boundary anchor point representing the actual passage of communication from the boundary communication records includes: determining the boundary passage record representing the permission or forwarding of the corresponding communication by the communication processing result from the boundary communication records; determining the correspondence between communication entities before and after the communication passes through the corresponding boundary device based on the communication entity identifier, communication direction, and time information in the boundary passage record, wherein, in the case of address translation occurring when the communication passes through the boundary device, the correspondence between communication entities before and after the address translation is determined based on the corresponding address translation information; forming a boundary passage evidence unit from the boundary passage record and the correspondence between communication entities, and determining the boundary passage evidence unit as the boundary anchor point.

[0010] Preferably, the process of forming event subchains includes: determining the communication entities located on both sides of the security domain boundary in the communication direction of the boundary anchor point, and using the communication entities as the association starting points of security event records in the corresponding security domains; according to the communication entity succession relationship, communication direction continuity, and time sequence relationship between security event records, associating the preceding security event record in the security domain on the communication source side of the boundary anchor point along the direction opposite to the communication direction, and associating the subsequent security event record in the security domain on the communication destination side of the boundary anchor point along the communication direction; and forming event subchains located in the corresponding security domains by associating the security event records.

[0011] Preferably, the process of determining each boundary as a confirmed pass, a denied pass, or an unverifiable state includes: determining the communication identifier to be matched at the corresponding boundary based on the communication entity identifier, communication direction, and time information corresponding to the cross-domain association to be verified, and querying the boundary communication records generated by the corresponding boundary device to find a boundary communication record that matches the communication identifier to be matched; determining the log observable state of the boundary device based on the device operating status of the boundary device within the boundary verification time range, the log collection status for the communication to be verified, and the data integrity of the boundary communication records; when a matching boundary communication record indicating that the communication to be verified has actually passed the corresponding boundary is found, the corresponding boundary is determined as a confirmed pass; when a matching boundary communication record indicating that the communication to be verified has been blocked, rejected, or discarded is found, or when the log observable state meets the preset observable conditions and no matching boundary communication record indicating that the communication to be verified has actually passed the corresponding boundary is found, the corresponding boundary is determined as a denied pass; when the log observable state does not meet the preset observable conditions and no matching boundary communication record indicating that the communication to be verified has actually passed the corresponding boundary is found, the corresponding boundary is determined as an unverifiable state.

[0012] Preferably, the process of adjusting the cross-domain association of the event chain according to the boundary verification status includes: sequentially obtaining the boundary verification status of each boundary in the boundary verification sequence according to the communication direction; when the current boundary is in the confirmed state, establishing an event association across the current boundary and allowing the event chain to continue to extend to the next boundary; when the current boundary is in the denied state, determining the current boundary as a link breakpoint, terminating the event association across the current boundary, and splitting the event chain at the current boundary; when the current boundary is in the unverifiable state, stopping the event chain from continuing to extend across the current boundary, retaining the event sub-chains that have been confirmed before the current boundary, and determining the current boundary as a propagation boundary to be verified, without determining the cross-domain association relationship across the current boundary as invalid.

[0013] Preferably, the process of generating monitoring results includes: determining the propagation path of network security events between security domains based on the event associations that cross each boundary in the processed event chain and the corresponding boundary verification status; determining the event sub-chains connected by boundaries that pass through the confirmed state as confirmed propagation relationships, determining the cross-domain associations that terminate at the boundaries that pass through the denied state as denied propagation relationships, and determining the cross-domain associations that stop expanding at the boundaries that cannot be verified as propagation relationships to be verified; and generating network security event monitoring results containing the corresponding event sub-chains, the security domains involved in the propagation, and the boundary verification status based on the confirmed propagation relationships, denied propagation relationships, and to be verified propagation relationships.

[0014] A network security incident monitoring system, comprising: The topology association module acquires security event records and boundary communication records within the security domain, constructs a security domain topology based on the connection relationship between the security domain and boundary devices, determines the boundary anchor points representing the actual communication passages from the boundary communication records, and associates security event records with the boundary anchor points as the starting point to form an event sub-chain. The cross-domain sequence module determines the cross-domain association relationship to be verified when the security event records to be associated belong to different security domains, and generates the corresponding boundary verification sequence according to the security domain topology. The boundary adjustment module queries boundary communication records based on the communication characteristics of the cross-domain association to be verified, and combines the observable status of the boundary device logs to determine each boundary as either a confirmed pass, a denied pass, or an unverifiable pass. Based on the boundary verification status, the cross-domain association of the event chain is adjusted: cross-domain association is allowed when the confirmed pass is achieved; the association is terminated and the event chain is split when the denied pass is achieved; and the expansion is stopped and the confirmed event sub-chain is retained when the unverifiable pass is achieved. The monitoring results module determines the propagation relationship of network security events between security domains and generates monitoring results based on the processed event chain and boundary verification status.

[0015] Compared with the prior art, the beneficial effects of the present invention are as follows: 1. By determining the correspondence between communication entities before and after communication passing through the boundary device based on the communication entity identifier, communication direction, and time information in the boundary communication record, and by establishing the correspondence before and after the address translation when it occurs, the boundary passage record can correspond to the actual communication process crossing the security domain boundary. The boundary passage evidence unit is used as the boundary anchor point for event association, providing an association starting point supported by actual communication passage records for the subsequent association of security event records on both sides of the security domain.

[0016] 2. By combining the query results of boundary communication records with the observable status of the boundary device's logs, a distinction is made between situations where communication actually passed, communication was explicitly blocked, and communication could not be determined due to insufficient log conditions. This allows for the determination of the verification meaning of a record not found based on the corresponding boundary's log collection status and data integrity, thus avoiding treating unobservable log situations and communication failure situations the same way, and providing a status basis for event chain processing under different boundary states.

[0017] 3. By adjusting the event chain according to the verification status of each boundary in sequence according to the communication direction, cross-domain association is established when the boundary is confirmed to pass, a link breakpoint is formed at the corresponding position and the event chain is split when the boundary is denied, and the extension is stopped when the boundary cannot be verified and the previously confirmed event sub-chain is retained, so that the extension range of the event chain corresponds to the verification results that each security domain boundary can provide, and the propagation process that has obtained verification support can be retained in the monitoring results. Attached Figure Description

[0018] Figure 1 A schematic diagram of a network security event monitoring method provided in an embodiment of the present invention; Figure 2 This is a schematic diagram of a network security incident monitoring system provided in an embodiment of the present invention; Figure 3 This invention provides a flowchart illustrating the process of determining each boundary as either a confirmed pass, a denied pass, or an unverifiable pass. Detailed Implementation

[0019] 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 embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0020] Please see Figures 1 to 3 This invention provides a method and system for monitoring network security incidents, the technical solution of which is as follows: A method for monitoring network security incidents, specifically as follows: Figure 1 and Figure 2 As shown, it includes: Acquire security event records and boundary communication records within the security domain, and construct a security domain topology based on the connection relationship between the security domain and boundary devices; determine the boundary anchor points representing the actual communication passage from the boundary communication records, and associate security event records with the boundary anchor points as the starting point to form an event sub-chain; When the security event records to be associated belong to different security domains, the cross-domain association relationship to be verified is determined, and the corresponding boundary verification sequence is generated according to the security domain topology. Specifically, based on the cross-domain association relationship to be verified, the corresponding starting security domain, target security domain, and communication direction are determined. In the security domain topology, an inter-domain connection path from the starting security domain to the target security domain that is consistent with the communication direction is determined. According to the communication direction, the boundary devices passed through in the inter-domain connection path are arranged to form a boundary verification sequence. When there are multiple reachable paths between the starting security domain and the target security domain that are consistent with the communication direction, and a unique corresponding path cannot be determined according to the existing topology connection relationship, candidate boundary verification sequences are formed according to the boundary devices passed through in each reachable path, and subsequent boundary verification is performed on each candidate boundary verification sequence.

[0021] Based on the communication characteristics of the cross-domain association to be verified, query the boundary communication records and combine them with the observable status of the boundary device logs to determine each boundary as either a confirmed pass, a denied pass, or an unverifiable pass. Adjust the cross-domain association of the event chain according to the boundary verification status: allow cross-domain association when the confirmed pass is enabled, terminate the association and split the event chain when the denied pass is enabled, and stop the expansion and retain the confirmed event sub-chain when the unverifiable pass is unverifiable. Based on the processed event chain and boundary verification status, the propagation relationship of cybersecurity events between security domains is determined and monitoring results are generated.

[0022] Example 1: Furthermore, the process of constructing a security domain topology based on the connection relationship between security domains and boundary devices includes: acquiring security event records generated within multiple security domains and boundary communication records generated by boundary devices set up between different security domains; determining the security domain to which the communication entity in the security event record belongs based on the correspondence between assets and security domains, and determining the security domain connected to each boundary device based on the connection relationship between boundary devices and security domains; using security domains as topology nodes, establishing inter-domain connection relationships between the topology nodes based on the security domains connected to each boundary device, and associating the corresponding boundary device identifier with the inter-domain connection relationship to form a security domain topology that represents the connection relationship between each security domain and the boundary devices traversed by cross-security domain communication.

[0023] Specifically, multiple security domains are determined based on the existing regional divisions of the network to be monitored. Each security domain can be divided according to business networks, security areas, or network address ranges, and a security domain identifier is configured for each. Security event records generated by security devices, hosts, or business systems within each security domain are obtained. The security event records include at least the event occurrence time and information used to identify the source and destination communication entities. The communication entity can be identified by at least one of asset identifiers, network addresses, and combinations of network addresses and ports. Simultaneously, boundary communication records generated by boundary devices set between different security domains are obtained. The boundary communication records include information used to identify the source and destination communication entities, the recording time, the boundary device identifier, and the communication processing result, and include the communication direction, or include ingress and egress interface identifiers that can determine the communication direction. The information used to identify the source and destination communication entities can include at least one or more of the following: source address, destination address, source port, destination port, and communication protocol.

[0024] Based on the pre-established correspondence between assets and security domains, the security domain to which each communication entity belongs in the security event log is determined. The correspondence between assets and security domains can be established based on asset identifiers, network addresses, network segments, or network area identifiers.

[0025] For border devices, the security domain they connect to is determined based on their interface configuration. Specifically, the security domain corresponding to each interface is determined based on the network segment, security area, or pre-configured interface-security domain correspondence connected to each interface. When different interfaces of a border device correspond to different security domains, the border device is identified as the border device between the corresponding security domains.

[0026] After determining the security domain affiliation of communication entities and the connection relationships of boundary devices, each security domain is used as a topology node. For boundary devices connecting different security domains, inter-domain connections are established between the corresponding topology nodes, and the boundary device identifier is associated with the corresponding inter-domain connection relationship.

[0027] Further, the process of determining the boundary anchor point representing the actual passage of communication from the boundary communication records includes: determining the boundary passage record representing the permission or forwarding of the corresponding communication from the boundary communication records; determining the correspondence between communication entities before and after the communication passes through the corresponding boundary device based on the communication entity identifier, communication direction, and time information in the boundary passage record, wherein, in the case of address translation occurring when the communication passes through the boundary device, the correspondence between communication entities before and after the address translation is determined based on the corresponding address translation information; forming a boundary passage evidence unit from the boundary passage record and the correspondence between communication entities, and determining the boundary passage evidence unit as the boundary anchor point.

[0028] Specifically, from the boundary communication records generated by the boundary device within a preset time range, records that represent actual communication and whose processing results indicate that the corresponding communication is allowed or forwarded are identified as boundary passage records. These boundary passage records can be records generated by the boundary device for traffic forwarding or communication sessions, rather than records that only represent the configuration status of communication control rules. When the "allowed" in the record only indicates that the communication control rule allows the corresponding communication but does not indicate that the actual communication has arrived and been processed by the boundary device, a boundary passage record is not determined solely based on the rule configuration. When the boundary communication record contains ingress and egress interface identifiers, the communication direction is determined based on the security domains corresponding to the ingress and egress interfaces, respectively.

[0029] For a defined boundary passage record, a pre-boundary communication identifier is determined before communication enters the boundary device, and a post-boundary communication identifier is determined after communication passes through the boundary device. The communication identifier can be composed of at least a number of the following: source address, source port, destination address, destination port, and communication protocol. For communication without address translation, the source communication entity and the destination communication entity are kept corresponding on both sides of the boundary device according to the communication direction. The records before and after the boundary are determined to belong to the same communication based on the communication protocol and time information. For example, if the records before and after the boundary have corresponding source addresses, source ports, destination addresses, destination ports, and communication protocols, and the difference in recording time is within a preset associated time range, the two are determined to be the pre-boundary communication identifier and post-boundary communication identifier corresponding to the same communication. The preset associated time range can be preset according to the log time granularity of the boundary device and the allowable time difference between communication forwarding and log formation.

[0030] When address translation occurs during communication through a border device, address translation information corresponding to the border passage record is obtained from the address translation record provided by the border device. The address translation record includes address translation session records or address translation logs that can characterize the mapping relationship between communication identifiers before and after address translation. The address translation information includes at least the mapping relationship between the communication identifier before and after translation. When the address translation information and the border passage record have the same session identifier, it is determined that the two correspond to the same communication based on the session identifier. When no unified session identifier is provided, address translation information corresponding to the border passage record is determined within a preset associated time range based on the border device identifier, communication protocol, communication direction, communication identifiers before and after translation, and recording time. The correspondence between communication entities before and after address translation is established based on the address translation information. For cases where source address translation, destination address translation, or both source and destination address translation occur, the correspondence between communication entities on both sides of the border device is determined based on the corresponding communication identifiers before and after translation.

[0031] When a unique correspondence between communication entities before and after a boundary can be determined based on the above information, the corresponding boundary is combined with the communication entity correspondence to form a boundary passage evidence unit. The boundary passage evidence unit at least represents the corresponding boundary device, communication direction, communication time, and the corresponding communication entities on both sides of the boundary. When address translation exists, the corresponding correspondence between communication entities before and after address translation is also included. When there are multiple candidate records within a preset association time range and a unique correspondence cannot be determined based on the existing communication identifier, communication direction, time information, and address translation information, no candidate record is directly determined as the boundary anchor point of the corresponding communication, and the candidate record and its candidate communication entity correspondence are retained. When a session identifier or other communication identifier that can distinguish the candidate communication is subsequently obtained, the correspondence is re-determined based on the session identifier or other communication identifier. For subsequent cross-domain association relationships to be verified, if a unique communication entity correspondence cannot be determined based on the candidate record when performing boundary verification at the corresponding boundary, the corresponding boundary is determined to be in an unverifiable state.

[0032] The formed boundary is determined as the boundary anchor point of the corresponding communication through the evidence unit. The communication entity before the boundary and the communication entity after the boundary in the boundary anchor point correspond to the security domains on both sides of the boundary device, respectively. Subsequently, the communication entities on both sides of the boundary anchor point are used as the association starting point for security event records in the corresponding security domain.

[0033] Furthermore, the process of forming event subchains includes: determining the communication entities located on both sides of the security domain boundary in the communication direction of the boundary anchor point, and using the communication entities as the association starting points of security event records in the corresponding security domains; based on the communication entity succession relationship, communication direction continuity, and time sequence relationship between security event records, associating the preceding security event record in the security domain on the communication source side of the boundary anchor point along the direction opposite to the communication direction, and associating the subsequent security event record in the security domain on the communication destination side of the boundary anchor point along the communication direction; and forming event subchains located in the corresponding security domains by associating the security event records.

[0034] In specific implementation, based on the communication direction recorded in the boundary anchor point and the correspondence between communication entities before and after the boundary device, the first communication entity corresponding to the boundary anchor point in the security domain on the communication source side and the second communication entity corresponding to the security domain on the communication destination side are determined. The first communication entity and the second communication entity are respectively used as the association starting point for security event records in the corresponding security domain. The communication entity is determined by the communication entity identifier corresponding to the aforementioned boundary anchor point. The communication entity identifier may include an asset identifier, a network address, or a combination of a network address and a port.

[0035] For the communication entity succession relationship between security event records, it is determined according to the propagation direction of the event chain and the source and destination communication entities in adjacent security event records. If the destination communication entity of the preceding security event record and the source communication entity of the following security event record have the same communication entity identifier, or if existing asset correspondence or address translation relationships can determine that they correspond to the same communication entity, then the two security event records are determined to satisfy the communication entity succession relationship. Based on this, if the preceding security event record represents communication from its source communication entity to its destination communication entity, and the following security event record continues from the source communication entity corresponding to that destination communication entity to the next destination communication entity, then the two are determined to satisfy the communication direction continuity. After considering the clock allowable deviation between the devices that generated the corresponding security event records, if the event time of the preceding security event record is earlier than the event time of the following security event record even outside the clock allowable deviation range, then the two are determined to satisfy the time sequence relationship. When the event time difference between two security event records is within the clock allowable deviation range, and the order of the two cannot be determined based on the event time, the time sequence relationship is not determined solely based on the event time. The time interval between the two can also be limited to a preset event association time range, which is determined based on the time granularity of the security event record, the pre-determined clock deviation between devices, and the allowable time interval between security events.

[0036] Within the security domain on the communication source side, the communication time corresponding to the first communication entity and the boundary anchor point is used as the initial association object and the initial reference time, respectively. Preceding security event records are searched in the direction opposite to the communication direction of the boundary anchor point. Specifically, from the security event records belonging to this security domain, a security event record is searched that corresponds to the current association object, has an event time earlier than the current reference time, and satisfies the continuity of the communication direction and the temporal sequence relationship. This record is identified as a preceding security event record. After identifying the preceding security event record, the source communication entity of this preceding security event record is used as the new association object, and the event time of this preceding security event record is used as the new reference time. Association continues in the same way in an earlier temporal direction until no preceding security event record satisfying the association conditions exists within this security domain.

[0037] Within the security domain on the communication destination side, the communication time corresponding to the second communication entity and the boundary anchor point is used as the initial association object and the initial reference time, respectively. Subsequent security event records are searched along the communication direction represented by the boundary anchor point. Specifically, from the security event records belonging to this security domain, security event records that correspond to the source communication entity and the current association object, have an event time later than the current reference time, and satisfy the continuity of the communication direction and the temporal sequence relationship are searched. These are identified as subsequent security event records. After identifying subsequent security event records, the destination communication entity of the subsequent security event record is used as the new association object, and the event time of the subsequent security event record is used as the new reference time. The association continues in the same way in a later temporal direction until there are no subsequent security event records that satisfy the association conditions within this security domain.

[0038] When multiple security event records that satisfy the communication entity acceptance relationship, communication direction continuity and time sequence relationship exist in the same association step, each security event record is regarded as a candidate association record, and subsequent association is continued along the corresponding candidate association record to retain the corresponding event association branch. The preceding security event record obtained from the communication source side association and the subsequent security event record obtained from the communication destination side association are connected according to the event time and communication entity acceptance relationship to form an event sub-chain located in the corresponding security domain.

[0039] During the continued association process, when the security event record to be associated, as determined according to the above association conditions, belongs to a different security domain than the current security event record, a cross-domain event association between the two is not directly established. Instead, the association relationship between the two is determined as a cross-domain association relationship to be verified, and the subsequent boundary verification process determines whether the corresponding event subchain is allowed to continue association across the security domain boundary.

[0040] Further, the process of determining each boundary as a confirmed pass, a denied pass, or an unverifiable state includes: determining the communication identifier to be matched at the corresponding boundary based on the communication entity identifier, communication direction, and time information corresponding to the cross-domain association to be verified, and querying the boundary communication records generated by the corresponding boundary device to find a boundary communication record that matches the communication identifier to be matched; determining the log observable state of the boundary device based on the device operating status of the boundary device within the boundary verification time range, the log collection status for the communication to be verified, and the data integrity of the boundary communication records; when a matching boundary communication record indicating that the communication to be verified has actually passed the corresponding boundary is found, the corresponding boundary is determined as a confirmed pass; when a matching boundary communication record indicating that the communication to be verified has been blocked, rejected, or discarded is found, or when the log observable state meets the preset observable conditions and no matching boundary communication record indicating that the communication to be verified has actually passed the corresponding boundary is found, the corresponding boundary is determined as a denied pass; when the log observable state does not meet the preset observable conditions and no matching boundary communication record indicating that the communication to be verified has actually passed the corresponding boundary is found, the corresponding boundary is determined as an unverifiable state, specifically as follows: Figure 2 As shown.

[0041] Specifically, based on the communication entity identifier, communication direction, and event time in the security event records on both sides of the cross-domain association to be verified, the communication identifier and boundary verification time range of the communication to be verified are determined. The communication identifier may include at least a number of the following: source address, destination address, source port, destination port, and communication protocol. The base time range is determined by the earlier and later event times in the security event records on both sides, and a preset time tolerance is extended forward and backward respectively to form the boundary verification time range. The preset time tolerance can be predetermined based on the clock allowable deviation between the security event record and the boundary communication record, the log formation delay, and the allowable time difference of inter-domain communication.

[0042] For the current boundary to be verified in the boundary verification sequence, the communication identifier expected before the communication reaches the boundary is determined according to the communication identifier and communication direction of the communication to be verified, and a corresponding communication identifier to be matched is formed accordingly. When no address translation occurs when the communication passes through the current boundary, the communication identifier to be matched is determined according to the communication entity identifier in the cross-domain association relationship to be verified. When an address translation occurs, the communication identifier to be matched before and after the communication passes through the boundary is determined according to the mapping relationship between the communication identifier before and after the translation represented by the address translation information corresponding to the boundary.

[0043] In the boundary communication records generated by the boundary device corresponding to the current boundary to be verified, the time is limited by the boundary verification time range, and the corresponding record is queried according to the communication identifier to be matched and the communication direction. When the source communication entity identifier, destination communication entity identifier, communication protocol and communication direction in the boundary communication record correspond to the corresponding information in the communication identifier to be matched, and the recording time is within the boundary verification time range, it is regarded as a matching boundary communication record. When the combination of network address and port is used to distinguish communication sessions, the correspondence is also made according to the source port and destination port. For communication that has undergone address translation, the corresponding matching boundary communication record is determined according to the communication identifier before and after the translation at the boundary and their mapping relationship.

[0044] For the observable log status of the current boundary device, within the boundary verification time range, the device operating status, the log collection status for the communication to be verified, and the data integrity of the boundary communication records are determined respectively. Specifically, based on the boundary device's operating records, online status, or status monitoring records, it is determined whether the device is providing inter-domain communication processing functions normally within the boundary verification time range. Based on the boundary device's log recording configuration and log collection status, it is determined whether the communication range to which the communication to be verified belongs and whether its corresponding allow, forward, block, deny, or discard processing results fall within the range that should be recorded and are in a normal collection state. Based on the log collection records independent of the matching boundary communication record query results for the communication to be verified, the continuity of the recording time of the boundary communication records, or the data missing status, it is determined whether there are log collection interruptions, recording interruptions, or data missingnesses affecting the query of the communication to be verified within the boundary verification time range. The determination of the log collection status and data integrity is not based on whether a matching boundary communication record corresponding to the communication to be verified is found. Specifically, it can be determined whether log collection is in a normal state based on the log collection process records within the boundary verification time range, whether there are recording interruptions based on the continuous recording status of the boundary communication records within this time range, and whether there are data missingnesses affecting the query of the corresponding records in combination with the existing data missing status. When the above information is insufficient to determine the log collection status or data integrity within the boundary verification time range, it is uncertain whether the log observable status meets the preset observable conditions.

[0045] When the boundary device is operating normally within the boundary verification time range, the communication to be verified and its corresponding communication processing results are within the range that should be recorded and collected normally, and there is no log collection interruption, recording interruption or data loss that affects the query of the communication to be verified, the log observable state is determined to meet the preset observable conditions; when at least one of the above conditions is not met, the log observable state is determined to not meet the preset observable conditions.

[0046] After completing the boundary communication record query, if a boundary communication record matching the communication to be verified is found and the communication processing result indicates that the corresponding communication has actually been allowed or forwarded through the current boundary, the current boundary is determined to be in a confirmed state. If no matching boundary communication record indicating that the communication to be verified has actually passed through the current boundary is found, but a boundary communication record matching the communication to be verified is found and the communication processing result indicates that the corresponding communication has been blocked, rejected, or discarded, the current boundary is determined to be in a denied state.

[0047] When neither a matching boundary communication record indicating that the communication to be verified actually passed through the current boundary is found, nor a matching boundary communication record that can directly indicate that the corresponding communication was blocked, rejected, or discarded is obtained, the boundary verification status of the current boundary is determined according to the log observability status. If the log observability status meets the preset observability condition, the absence of a record indicating actual passage is used as boundary counter-evidence to negate the communication to be verified passing through the current boundary, and the current boundary is determined to be in a passed-denied state. If the log observability status does not meet the preset observability condition, the communication to be verified is not denied to pass through the current boundary based on the lack of a matching boundary communication record, and the current boundary is determined to be in an unverifiable state. The passed-denied state is used to indicate that the boundary communication records and their log observability status that the current boundary device can provide do not support the communication to be verified actually passing through the corresponding boundary. For the passed-denied state determined based on the absence of a record indicating actual passage, the missing record as boundary counter-evidence and the corresponding log observability status are recorded as the basis for determining the boundary verification status.

[0048] Furthermore, the process of adjusting the cross-domain association of the event chain according to the boundary verification status includes: sequentially obtaining the boundary verification status of each boundary in the boundary verification sequence according to the communication direction; when the current boundary is in the confirmed state, establishing an event association across the current boundary and allowing the event chain to continue to extend to the next boundary; when the current boundary is in the denied state, determining the current boundary as a link breakpoint, terminating the event association across the current boundary, and splitting the event chain at the current boundary; when the current boundary is in the unverifiable state, stopping the event chain from continuing to extend across the current boundary, retaining the event sub-chains that have been confirmed before the current boundary, and determining the current boundary as a boundary to be verified for propagation, without determining the cross-domain association relationship across the current boundary as invalid.

[0049] Specifically, based on the communication direction corresponding to the cross-domain association to be verified, each boundary in the boundary verification sequence is taken as the current boundary in the order from the starting security domain to the target security domain, and the boundary verification status of the current boundary is obtained according to the aforementioned boundary verification process. Processing begins with the first boundary in the boundary verification sequence. When the current boundary allows the event chain to continue to expand, the next boundary is taken as the new current boundary and processing continues until all boundaries in the boundary verification sequence have been processed, or the expansion stops at one of the boundaries.

[0050] When the current boundary is in a confirmed state, based on the matching boundary communication record corresponding to the current boundary and the correspondence between communication entities before and after the current boundary, the communication entity before the boundary and the communication entity after the boundary are determined, and a cross-boundary connection relationship is established between them. The event sub-chains that have been confirmed before the current boundary are associated with the communication entity after the boundary through the cross-boundary connection relationship. If an event sub-chain with the communication entity as the association starting point has been formed in the security domain after the boundary, the corresponding event sub-chains are connected according to the communication direction. If no corresponding event sub-chain has been formed, the communication entity after the boundary is used as the communication entity to continue association. If there is a next boundary in the boundary verification sequence, the communication entity after the current boundary is used as the current communication entity for subsequent association, and the next boundary is processed according to the aforementioned boundary verification process. When all boundaries in the boundary verification sequence are in a confirmed state, a cross-domain event association corresponding to the cross-domain association relationship to be verified is established.

[0051] When the current boundary is in a denied state, no event association is established across the current boundary, and the current boundary is determined as a link breakpoint. Expansion beyond the current boundary based on the cross-domain association to be verified is stopped. Event sub-chains formed by boundaries that have already passed and are confirmed to be passed before the current boundary are retained. Event sub-chains formed after the current boundary are not deleted because the current boundary is determined to be a link breakpoint, but are retained as event sub-chains independent of the cross-domain association to be verified. They are no longer connected to the event sub-chains before the link breakpoint based on the cross-domain association to be verified, and this does not affect the event sub-chains from continuing to participate in event associations based on other cross-domain associations to be verified. Thus, the corresponding event chain is split at the current boundary.

[0052] When the current boundary is in an unverifiable state, no definite event association is established across the current boundary, and the expansion beyond the current boundary based on the cross-domain association to be verified is stopped. The event sub-chains formed by the boundary connections with confirmed states before the current boundary are retained, and the current boundary is determined as the propagation boundary to be verified. Cross-domain associations to be verified that cross the current boundary are retained and not determined to be invalid. The event sub-chains after the current boundary are not merged into the currently confirmed event sub-chains. When boundary communication records or log observable state information that can be used for the verification of the current boundary are subsequently obtained, the aforementioned boundary verification process can be re-executed for the propagation boundary to be verified, and the corresponding event chain can be adjusted according to the re-determined boundary verification state.

[0053] After processing the boundary verification sequence in the above manner, retain the event sub-chain formed by the continuous boundary connections in the confirmed pass state, and record the corresponding cross-boundary event associations; for the boundary in the denied pass state, record its corresponding link breakpoint; for the boundary in the unverifiable state, record its corresponding unverifiable propagation boundary and unverifiable cross-domain association, so as to determine the propagation relationship between security domains based on the processed event chain and the boundary verification state.

[0054] Furthermore, the process of generating monitoring results includes: determining the propagation path of network security events between security domains based on the event associations that cross each boundary in the processed event chain and the corresponding boundary verification status; determining the event sub-chains connected by boundaries that pass through the confirmed state as confirmed propagation relationships, determining the cross-domain associations that terminate at the boundaries that pass through the denied state as denied propagation relationships, and determining the cross-domain associations that stop expanding at the boundaries that cannot be verified as propagation relationships to be verified; and generating network security event monitoring results containing the corresponding event sub-chains, the security domains involved in the propagation, and the boundary verification status based on the confirmed propagation relationships, denied propagation relationships, and to be verified propagation relationships.

[0055] In practice, the event chain after the aforementioned boundary verification and cross-domain association adjustment is obtained. According to the chronological order and communication direction of the security event records in the event chain, the security domain to which each event sub-chain belongs and the corresponding security domain boundaries between adjacent event sub-chains are determined. For positions in the event chain involving cross-security domain associations, the corresponding cross-domain association relationship and the boundary verification status of the corresponding boundary are obtained. The event sub-chains, security domain boundaries, and subsequent event sub-chains are sequentially matched according to the communication direction, thereby forming the propagation path of network security events between security domains. When the processed event chain has multiple event association branches, the corresponding propagation path is determined according to the communication direction and chronological order of each event association branch.

[0056] For a boundary in the propagation path that is in the confirmed pass state, the event sub-chains on both sides of the boundary are determined to have a confirmed propagation relationship based on the previously established cross-boundary event association; when multiple consecutive boundaries are in the confirmed pass state, the event sub-chains in the corresponding security domains are connected sequentially according to the communication direction, and the continuously connected event sub-chains are determined as the confirmed propagation path portion.

[0057] For boundaries that are in a negative state and identified as link breakpoints, the propagation relationship across the boundary represented by the original cross-domain association relationship to be verified is identified as a negative propagation relationship, and the corresponding negative state and link breakpoint are recorded, while the propagation relationship confirmed before the link breakpoint is retained; for event sub-chains that exist after the link breakpoint, they are not identified as continuous propagation relationships with event sub-chains before the link breakpoint based on the negative propagation relationship.

[0058] For boundaries that are in an unverifiable state and are identified as unverifiable propagation boundaries, cross-domain associations that stop expanding at that boundary are identified as unverifiable propagation relationships, and the corresponding unverifiable state and unverifiable propagation boundary are recorded. Propagation relationships that have been confirmed before the unverifiable propagation boundary are retained; for cross-domain associations that cross the unverifiable propagation boundary, they are not identified as confirmed propagation relationships or denied propagation relationships, and their unverifiable propagation attributes are maintained.

[0059] After determining the above propagation relationships, according to the communication direction and event time sequence in each propagation path, the event sub-chains, the security domains to which the event sub-chains belong, the corresponding security domain boundaries between adjacent event sub-chains, and the boundary verification status of each boundary are mapped. Based on the boundary verification status, the confirmed propagation relationships, denied propagation relationships, or unverified propagation relationships between adjacent event sub-chains are recorded to form network security event monitoring results. For denied propagation relationships, the corresponding link breakpoints are recorded, and for unverified propagation relationships, the corresponding unverified propagation boundaries are recorded.

[0060] Example 2: The process of determining the log observable state of the boundary device also includes: Based on the communication characteristics of the communication to be verified, determine the communication control rules that the communication to be verified matches at the corresponding boundary device and the log generation strategy corresponding to the communication control rules, and determine whether the communication to be verified should generate a boundary communication record containing the identifier of the communication to be matched under the corresponding communication processing result based on the log generation strategy. Only when the communication processing result corresponding to the communication to be verified falls within the recording range of the log generation strategy, and the log collection status and data integrity within the boundary verification time range meet preset conditions, will the absence of a matching boundary communication record indicating that the communication to be verified actually passed the corresponding boundary be used as boundary counter-evidence to determine the negative state of the passage; otherwise, the absence of a matching boundary communication record will not be used as boundary counter-evidence.

[0061] Specifically, based on at least several of the following: source communication entity identifier, destination communication entity identifier, source port, destination port, communication protocol, communication direction, and corresponding ingress interface, egress interface, or security domain of the communication to be verified, a match is made with the communication control rules that are in effect within the boundary verification time range of the boundary device. If multiple communication control rules can match the communication to be verified, the communication control rule corresponding to the communication to be verified is determined according to the rule priority or rule matching order actually adopted by the corresponding boundary device, and the communication processing action and log generation strategy corresponding to that communication control rule are obtained.

[0062] The log generation strategy is determined based on the log configuration of the boundary device within the boundary verification time range. This strategy can be a log strategy configured by the communication control rule itself, a log configuration referenced by the communication control rule, or a unified log configuration effective for the communication control rule. Based on the log generation strategy, it determines whether the corresponding communication processing results in allow, forward, block, deny, or discard fall within the scope of records to be recorded, and determines the generation conditions for the corresponding records. For log generation strategies that generate records according to communication establishment, communication processing, or session termination, it determines whether the boundary communication record corresponding to the communication to be verified should be formed within the boundary verification time range based on the corresponding log generation timing. If the log generation strategy does not require recording the corresponding communication processing result, the boundary communication record corresponding to that processing result is not considered a record that should be generated.

[0063] For cases used to verify whether the communication to be verified has actually passed the current boundary, it is determined whether the communication control rules generate a boundary communication record containing the identifier of the communication to be matched according to the corresponding log generation strategy when the communication to be verified is allowed or forwarded. If the allow or forwarding process falls within the scope of recording, the log collection status and data integrity within the boundary verification time range are further determined in the aforementioned manner, and it is determined whether the corresponding record can be collected normally after it is generated, and whether there are log collection interruptions, record interruptions, or data missingnesses within the time range that affect the query of the corresponding record.

[0064] When the communication to be verified is permitted or forwarded, a corresponding boundary communication record should be generated according to the log generation strategy. The generation time of this record must fall within the boundary verification time range. Simultaneously, if the logs are in normal collection mode and data integrity meets preset conditions within this time range, it is determined that the communication to be verified has actually passed through this communication processing result and possesses the corresponding log observable conditions. If, under these conditions, no matching boundary communication record representing the actual passage of the current boundary is found, the missing record is used as a boundary counter-evidence to determine the passage is negated. This boundary counter-evidence serves as the basis for determining the boundary verification state under the current log observable conditions and is recorded in conjunction with the log generation strategy, log collection status, and data integrity information used to determine the log observable conditions.

[0065] When the log generation strategy corresponding to the communication control rule matching the communication to be verified does not set the corresponding communication processing result to the range to be recorded, or the corresponding record has not yet reached the generation time according to the log generation strategy, or there is a log collection interruption, recording interruption or missing data affecting the query of the corresponding record within the boundary verification time range, the failure to find the matching boundary communication record will not be used as boundary counter-evidence, and the corresponding boundary will be judged as belonging to the unverifiable state according to the aforementioned log observable state and boundary verification state determination process.

[0066] The process of verifying each boundary in the boundary verification sequence further includes: When the current boundary is determined to be in a confirmed pass state, the boundary post-communication identifier and pass time in the corresponding matching boundary communication record are obtained, and the boundary post-communication identifier is used as the input communication identifier for the next boundary to pass verification. Based on the topological connection relationship and address translation relationship between the current boundary and the next boundary, the input communication identifier is mapped to the communication identifier to be matched corresponding to the next boundary, and the boundary verification time range corresponding to the next boundary is determined based on the passage time and the preset transmission delay range between the current boundary and the next boundary. Based on the communication identifier to be matched and the boundary verification time range, query the boundary communication record corresponding to the next boundary, so as to transmit the confirmed communication entity correspondence and time constraints boundary by boundary according to the boundary verification sequence.

[0067] Specifically, each boundary is verified sequentially according to the order in the boundary verification sequence. When the current boundary is determined to be in a confirmed passed state, the post-boundary communication identifier and the corresponding passing time after communication passed the current boundary are obtained from the matching boundary communication record used to determine this state. The post-boundary communication identifier may include at least several of the following: source address, destination address, source port, destination port, and communication protocol formed after communication passed the current boundary; the passing time is the recording time in the matching boundary communication record that can characterize the corresponding communication being processed or forwarded by the current boundary. The post-boundary communication identifier is used as the input communication identifier when communication is passed from the current boundary to the next boundary.

[0068] The topological connection between the current boundary and the next boundary is determined based on the security domain topology, and the expected communication identifier when communication reaches the next boundary is determined based on the input communication identifier. When there is no address translation between the current boundary and the next boundary that would change the communication identifier, the input communication identifier is passed to the next boundary according to the communication direction, forming a communication identifier to be matched corresponding to the next boundary. When there is a known address translation relationship, the input communication identifier is mapped accordingly based on the mapping relationship between the communication identifier before and after address translation, to obtain the communication identifier to be matched corresponding to the communication reaching the next boundary. When the next boundary itself has address translation and the corresponding boundary communication record contains communication identifiers before and after translation, the communication identifiers before and after translation corresponding to the communication identifier to be matched are determined based on the address translation relationship of the boundary, for querying the corresponding boundary communication record.

[0069] The boundary verification time range for the next boundary is determined using the passage time corresponding to the current boundary as the time reference, and based on the preset transmission delay range between the current boundary and the next boundary. Specifically, let the passage time of the current boundary be... The preset transmission delay range from the current boundary to the next boundary is... According to to Determine the basic verification time range for the next boundary. If there is a device clock skew or log generation time skew, a preset time tolerance can be added before and after the basic verification time range to form the actual boundary verification time range used for the next boundary. The preset transmission delay range is determined in advance based on the network connection relationship between the current boundary and the next boundary, as well as the allowable communication transmission delay.

[0070] In the boundary communication records corresponding to the next boundary, the query record time is within the boundary verification time range, and the communication identifier and communication direction correspond to the communication identifier to be matched. The boundary verification status of the next boundary is determined according to the aforementioned boundary verification process. When the next boundary is also determined to be in the confirmed pass state, the boundary communication identifier and pass time corresponding to the next boundary are obtained, and these two are used as the basis for determining the communication identifier and time range when verifying subsequent boundaries. The verification continues along the boundary verification sequence in the same manner.

[0071] When any current boundary is determined to be in a rejected or unverifiable state, unconfirmed communication identifiers and time information following that boundary are no longer used as confirmed inputs for subsequent boundary verification. Instead, the link breakpoints or unverified propagation boundaries are processed according to the aforementioned event chain cross-domain association adjustment process. Therefore, the communication identifiers and time constraints used for subsequent boundaries in the boundary verification sequence are derived from the confirmed matching boundary communication records of the preceding boundary.

[0072] Before adjusting the cross-domain association of the event chain based on the boundary verification status, the following steps are also included: Cross-boundary consistency verification is performed on the matching boundary communication records corresponding to the adjacent boundaries that are determined to be in the confirmed pass state in the boundary verification sequence. The cross-boundary consistency verification includes determining whether the post-boundary communication identifier of the previous boundary and the pre-boundary communication identifier of the subsequent boundary correspond after mapping by the corresponding address translation relationship, whether the communication direction is consistent, and whether the passing time satisfies the time sequence relationship between the adjacent boundaries. When the cross-boundary consistency verification passes, the confirmed pass state of the corresponding boundary is retained. When the cross-boundary consistency check fails, the matching boundary communication record that fails the cross-boundary consistency check is excluded from the boundary pass evidence of the corresponding boundary, and the matching boundary communication record that satisfies the cross-boundary consistency check is queried again; when no matching boundary communication record that satisfies the cross-boundary consistency check is found, the corresponding boundary is determined to be in an unverifiable state.

[0073] Specifically, according to the communication direction in the boundary verification sequence, the preceding and following boundaries, which are both determined to be in a confirmed passed state, are obtained sequentially, and the matching boundary communication records used to determine the confirmed passed state are obtained respectively. The boundary post-communication identifier and passage time after communication passes through the boundary are obtained from the matching boundary communication record corresponding to the preceding boundary, and the boundary pre-communication identifier and passage time before communication enters the boundary are obtained from the matching boundary communication record corresponding to the following boundary. The communication identifier, communication direction, and passage time are used as the basis for cross-boundary consistency verification.

[0074] For consistency verification of communication identifiers, when there is no address translation between adjacent boundaries that would change the communication identifier, the post-boundary communication identifier of the preceding boundary is mapped to the pre-boundary communication identifier of the following boundary. When there is an address translation between adjacent boundaries, the post-boundary communication identifier of the preceding boundary is mapped to the expected communication identifier before communication reaches the following boundary, based on the address translation relationship, and then mapped to the pre-boundary communication identifier in the corresponding matching boundary communication record of the following boundary. The mapping of communication identifiers is determined based on at least several of the following: source address, destination address, source port, destination port, and communication protocol. Simultaneously, it is determined whether the communication direction represented by the two matching boundary communication records is consistent with the communication direction in the boundary verification sequence.

[0075] For consistency verification of transit time, the transit time corresponding to the previous boundary is taken as the preceding time, and the transit time corresponding to the next boundary is taken as the following time. It is determined whether the following time is later than the preceding time, and whether the time difference between the two is within the preset transmission delay range corresponding to the adjacent boundary. If there is a device clock deviation or log formation time deviation, a preset time tolerance is added to the preset transmission delay range. When the communication identifiers correspond, the communication directions are consistent, and the transit times meet the above time sequence relationship, the matching boundary communication records corresponding to the adjacent boundary are determined to have passed the cross-boundary consistency verification, and the confirmed transit status of the corresponding boundary is retained.

[0076] When the matching boundary communication record corresponding to an adjacent boundary does not meet the above consistency conditions in at least one of the communication identifier, communication direction, or passage time, it is determined that the corresponding matching boundary communication record has failed the cross-boundary consistency check, and the matching boundary communication record that has failed the check is excluded from the boundary passage evidence of the corresponding boundary. Based on the boundary communication identifier and passage time that have been confirmed to have passed the previous boundary, the communication identifier to be matched for the next boundary is determined according to the aforementioned communication identifier mapping relationship. The boundary check time range is re-determined according to the passage time and the preset transmission delay range between adjacent boundaries. The candidate matching boundary communication record is re-queried in the boundary communication record corresponding to the next boundary, and cross-boundary consistency checks are performed according to the aforementioned communication identifier, communication direction, and passage time.

[0077] If at least one matching boundary communication record satisfying the cross-boundary consistency check is found, this record is used as evidence of the boundary's passage, and its "passed and confirmed" status is maintained. If multiple matching boundary communication records satisfy the check, each is retained as candidate boundary passage evidence, and the same consistency check method is used to verify the corresponding boundary's matching boundary communication record. If no matching boundary communication record satisfying the cross-boundary consistency check is found, the "passed and confirmed" status of the boundary is no longer maintained using the excluded records. The boundary is designated as "unverifiable," and the event chain is stopped from extending across the boundary according to the aforementioned event chain handling method for unverifiable states.

[0078] Example 3: This embodiment takes a network including security domain A, security domain B, security domain C, security domain D and security domain E as an example, and introduces a network security event monitoring system of this application, wherein a boundary device FW1 is set between security domain A and security domain B, a boundary device FW2 is set between security domain B and security domain C, a boundary device FW3 is set between security domain C and security domain D, and a boundary device FW4 is set between security domain B and security domain E.

[0079] The topology association module obtains security event records generated by each security domain and boundary communication records generated by FW1 to FW4. Based on the asset information corresponding to the communication entity in the security event record, it determines the security domain to which the entity belongs. Based on the interface connection relationship of each boundary device, it establishes the security domain topology of A—FW1—B—FW2—C—FW3—D and B—FW4—E.

[0080] In the boundary communication records of FW1, a boundary passage record is identified where the communication processing result is allowed and the communication is actually forwarded from security domain A to security domain B. Based on the communication entity identifier, communication direction, and time information in this record, the correspondence between communication entities before and after the communication passes through FW1 is determined. The boundary passage record and the correspondence between communication entities form a boundary passage evidence unit, which serves as a boundary anchor point. Taking the communication entities on both sides of this boundary anchor point as the association starting point, security event records that are associated earlier in the reverse time and satisfy the communication entity succession relationship within security domain A, and security event records that are associated later in the communication direction and satisfy the communication entity succession relationship within security domain B, are respectively used to form corresponding event sub-chains.

[0081] During the continued association of event subchains, the cross-domain sequence module determines that security event EB1 in security domain B and security event EC1 in security domain C satisfy the communication entity succession relationship, communication direction continuity, and temporal sequence relationship. Since EB1 and EC1 belong to different security domains, a cross-domain propagation relationship is not directly established between them. Instead, they are identified as cross-domain association relationships to be verified. Based on the security domain topology, it is determined that the communication from security domain B to security domain C needs to pass through FW2, forming the corresponding boundary verification sequence. For subsequent cross-domain association relationships to be verified involving security domain C to security domain D and security domain B to security domain E, boundary verification sequences including FW3 and FW4 are formed respectively.

[0082] The boundary adjustment module determines the communication identifier to be matched and the boundary verification time range based on the communication entity identifier, communication direction, and time information corresponding to each cross-domain association to be verified, and queries the boundary communication records of the corresponding boundary devices. For FW2, a boundary communication record matching the communication to be verified is found, and based on the corresponding record type and field semantics, it can represent that the communication to be verified actually arrived at FW2 and was allowed or forwarded by FW2. Therefore, this boundary communication record is determined as a matching boundary communication record representing that the communication to be verified actually passed through FW2, FW2 is determined to be in a confirmed state, a cross-domain event association is established between security domain B and security domain C, and the event chain is allowed to continue to expand. For FW4, a boundary communication record matching the communication to be verified was found, and the communication processing result was rejection. Therefore, FW4 is determined to be in a passed but denied state. The corresponding cross-domain association is terminated at FW4 and it is determined to be a link breakpoint. For FW3, no matching boundary communication record representing the actual passage of the communication to be verified was found. At the same time, it is determined that there is a log collection interruption within the corresponding boundary verification time range, and the log observability status does not meet the preset observability conditions. Therefore, FW3 is determined to be in an unverifiable state. The event chain is stopped from continuing to extend to security domain D. The event sub-chains previously confirmed by FW3 are retained, and FW3 is determined to be the propagation boundary to be verified.

[0083] The monitoring results module determines the propagation relationships between security domains based on the processed event chains and the boundary verification status of each boundary. Specifically, the event sub-chain formed by connecting FW1 and FW2 is identified as a confirmed propagation relationship; candidate cross-domain associations that terminate due to FW4 being in a denied state are identified as denied propagation relationships, and the link breakpoint corresponding to FW4 is recorded; cross-domain associations that stop expanding due to FW3 being in an unverifiable state are identified as propagation relationships to be verified, and the propagation boundary to be verified corresponding to FW3 is recorded. Based on the above event sub-chains, the security domains involved, the corresponding boundaries, and their boundary verification status, network security event monitoring results are generated.

[0084] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A method for monitoring network security incidents, characterized in that, include: Acquire security event records and boundary communication records within the security domain, and construct the security domain topology based on the connection relationship between the security domain and boundary devices; Determine the boundary anchor point representing the actual communication passage from the boundary communication record, and associate security event records with the boundary anchor point as the starting point to form an event sub-chain; When the security event records to be associated belong to different security domains, the cross-domain association relationship to be verified is determined, and the corresponding boundary verification sequence is generated according to the security domain topology. Based on the communication characteristics of the cross-domain association to be verified, query the boundary communication records and combine them with the observable status of the boundary device logs to determine each boundary as either a confirmed pass, a denied pass, or an unverifiable pass. Adjust the cross-domain association of the event chain according to the boundary verification status: allow cross-domain association when the confirmed pass is enabled, terminate the association and split the event chain when the denied pass is enabled, and stop the expansion and retain the confirmed event sub-chain when the unverifiable pass is unverifiable. Based on the processed event chain and boundary verification status, the propagation relationship of cybersecurity events between security domains is determined and monitoring results are generated.

2. The method for monitoring network security incidents according to claim 1, characterized in that, The process of constructing a security domain topology based on the connection relationship between security domains and boundary devices includes: acquiring security event records generated within multiple security domains and boundary communication records generated by boundary devices set up between different security domains; determining the security domain to which the communication entity in the security event record belongs based on the correspondence between assets and security domains, and determining the security domain connected to each boundary device based on the connection relationship between boundary devices and security domains; using security domains as topology nodes, establishing inter-domain connection relationships between the topology nodes based on the security domains connected to each boundary device, and associating the corresponding boundary device identifier with the inter-domain connection relationship to form a security domain topology that represents the connection relationship between each security domain and the boundary devices traversed by cross-security domain communication.

3. The method for monitoring network security incidents according to claim 1, characterized in that, The process of determining the boundary anchor point representing the actual passage of communication from the boundary communication records includes: determining the boundary passage record representing the permission or forwarding of the corresponding communication from the boundary communication records; determining the correspondence between communication entities before and after the communication passes through the corresponding boundary device based on the communication entity identifier, communication direction, and time information in the boundary passage record, wherein, in the case of address translation occurring when the communication passes through the boundary device, the correspondence between communication entities before and after the address translation is determined based on the corresponding address translation information; forming a boundary passage evidence unit from the boundary passage record and the correspondence between communication entities, and determining the boundary passage evidence unit as the boundary anchor point.

4. The method for monitoring network security incidents according to claim 1, characterized in that, The process of forming event subchains includes: determining the communication entities located on both sides of the security domain boundary in the communication direction of the boundary anchor point, and using the communication entities as the association starting points of security event records in the corresponding security domains; based on the communication entity succession relationship, communication direction continuity, and time sequence relationship between security event records, associating the preceding security event record in the security domain on the communication source side of the boundary anchor point along the direction opposite to the communication direction, and associating the subsequent security event record in the security domain on the communication destination side of the boundary anchor point along the communication direction; and forming event subchains located in the corresponding security domains by associating the security event records.

5. The method for monitoring network security incidents according to claim 1, characterized in that, The process of determining each boundary as either a confirmed pass, a denied pass, or an unverifiable pass includes: determining the communication identifier to be matched at the corresponding boundary based on the communication entity identifier, communication direction, and time information corresponding to the cross-domain association to be verified; querying the boundary communication records generated by the corresponding boundary device to find a boundary communication record that matches the communication identifier to be matched; determining the log observable state of the boundary device based on the device operating status of the boundary device within the boundary verification time range, the log collection status for the communication to be verified, and the data integrity of the boundary communication records; when a matching boundary communication record indicating that the communication to be verified has actually passed the corresponding boundary is found, the corresponding boundary is determined as a confirmed pass; when a matching boundary communication record indicating that the communication to be verified has been blocked, rejected, or discarded is found, or when the log observable state meets the preset observable conditions and no matching boundary communication record indicating that the communication to be verified has actually passed the corresponding boundary is found, the corresponding boundary is determined as a denied pass; when the log observable state does not meet the preset observable conditions and no matching boundary communication record indicating that the communication to be verified has actually passed the corresponding boundary is found, the corresponding boundary is determined as an unverifiable pass.

6. The method for monitoring network security incidents according to claim 1, characterized in that, The process of adjusting the cross-domain association of the event chain according to the boundary verification status includes: sequentially obtaining the boundary verification status of each boundary in the boundary verification sequence according to the communication direction; when the current boundary is in the confirmed state, establishing an event association across the current boundary and allowing the event chain to continue to extend to the next boundary; when the current boundary is in the denied state, determining the current boundary as a link breakpoint, terminating the event association across the current boundary, and splitting the event chain at the current boundary; when the current boundary is in the unverifiable state, stopping the event chain from continuing to extend across the current boundary, retaining the event sub-chains that have been confirmed before the current boundary, and determining the current boundary as a boundary to be verified for propagation, without determining the cross-domain association relationship across the current boundary as invalid.

7. The method for monitoring network security incidents according to claim 1, characterized in that, The process of generating monitoring results includes: determining the propagation path of network security events between security domains based on the event associations that cross each boundary in the processed event chain and the corresponding boundary verification status; identifying event sub-chains connected by boundaries that pass through confirmed states as confirmed propagation relationships, identifying cross-domain associations that terminate at boundaries that pass through denial states as denial propagation relationships, and identifying cross-domain associations that stop expanding at boundaries that cannot be verified as propagation relationships to be verified; and generating network security event monitoring results containing the corresponding event sub-chains, the security domains involved in the propagation, and the boundary verification status based on the confirmed propagation relationships, denial propagation relationships, and to-be-verified propagation relationships.

8. A network security incident monitoring system, characterized in that, include: The topology association module acquires security event records and boundary communication records within the security domain, and constructs the security domain topology based on the connection relationship between the security domain and boundary devices. Determine the boundary anchor point representing the actual communication passage from the boundary communication record, and associate security event records with the boundary anchor point as the starting point to form an event sub-chain; The cross-domain sequence module determines the cross-domain association relationship to be verified when the security event records to be associated belong to different security domains, and generates the corresponding boundary verification sequence according to the security domain topology. The boundary adjustment module queries boundary communication records based on the communication characteristics of the cross-domain association to be verified, and combines the observable status of the boundary device logs to determine each boundary as either a confirmed pass, a denied pass, or an unverifiable pass. Based on the boundary verification status, the cross-domain association of the event chain is adjusted: cross-domain association is allowed when the confirmed pass is achieved; the association is terminated and the event chain is split when the denied pass is achieved; and the expansion is stopped and the confirmed event sub-chain is retained when the unverifiable pass is achieved. The monitoring results module determines the propagation relationship of network security events between security domains and generates monitoring results based on the processed event chain and boundary verification status.

Images