Systems and methods for network threat detection based on new and / or updated network threat information

Abstract

Systems, methods, and apparatus are described for detecting and / or analyzing network threats based on updated network threat intelligence associated with the network threats. Packet filtered output data, such as a packet communication log and / or a packet copy, may be generated based on a first network threat intelligence associated with a network threat. Update criteria based on subsequently updated cyber-threat intelligence may then be applied to the packet filtered output data.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to U.S. Provisional Patent Application Serial No. 63 / 430,479, filed on December 6, 2022, and also claims priority to U.S. Provisional Patent Application Serial No. 63 / 391,987, filed on July 25, 2022. The entire contents of each of the application serial number 63 / 430,479 and the application serial number 63 / 391,987 are incorporated herein by reference. Background Art

[0003] Threats to computer network security may take various forms (e.g., attempts to cause unauthorized data transfer, hacking attempts, viruses, bots, other types of malware, etc.). The scope of this threat continues to expand, as do attempts by malicious actors to exploit weaknesses in computer network security. Threats typically involve using the Internet to probe, access, and / or attack computers and other devices that can be connected to the Internet on an enterprise network. For example, desktop computers, mobile devices, locally deployed or cloud enterprise application servers, public-facing web servers, and other types of computing devices can be directly connected to networks owned and / or operated and managed by an enterprise (such as a commercial company, government, etc.). These enterprise networks can in turn be connected to the Internet, allowing enterprise hosts to access other publicly addressed Internet-connected hosts (e.g., public-facing web servers, application servers, etc.). In some cases, such publicly addressed Internet-connected hosts may be malicious.

[0004] An enterprise may attempt to protect its network by filtering traffic between enterprise hosts and hosts of other networks. Such filtering may attempt to analyze (e.g., collect relevant information) and in some cases block packet communications that cross the boundaries of the enterprise network. In order to determine packets for which information should be collected, which packets to block, etc., the filtering device may be configured with filtering rules to attempt to match packets with one or more criteria based on network threat intelligence. These filtering rules may be generated based on network threat intelligence. Network threat intelligence can be received from many sources and may include various specific or non-specific information about network threats.

[0005] Cybersecurity threats can be dynamic and can change over time. In addition, as more and more independent systems detect some threats and / or are affected by such threats, new information about such threats may become available. For these and other reasons, cyber threat intelligence about a given threat can be updated as the threat intelligence evolves. As the intelligence is updated, the intelligence can become more accurate and / or more detailed, can have a higher reliability, and / or can reflect an increased understanding of the severity of the threat. When new cyber threat intelligence related to a particular threat is received, filtering rules related to the threat can be updated based on the updated information in the new intelligence. These updated rules can be applied to subsequently received packet communications to filter those communications based on the improved information.

[0006] Implementing updates to packet communication filtering rules can improve the detection and / or prevention of threats that attack the network after such updates. However, because the previous filtering is based on rules created using older (and perhaps less specific and / or less accurate) information, previous attacks caused by the same threat may not be detected. Although such previous filtering may have generated data that records some information about the previously filtered packets and / or may have saved copies of the previously filtered packets, it is disadvantageous to apply updated threat intelligence to data obtained based on filtering before the update. For example, without knowing (or at least suspecting) that the protected network has experienced an obvious or ongoing attack, the analyst may not think of or have available resources to apply updated threat intelligence to data filtered before the update. In addition, the amount of data associated with the previous filtering, the increasing number of network threats, and the specialized skills and resources required to maintain awareness of when the threat intelligence of a given threat is updated are further factors that may hinder the retroactive application of updated threat intelligence to data generated from filtering before the update. And because the amount of previously filtered data can be controlled by deleting older data, if the relationship between older data and network threats is not determined before the planned deletion, important data may be lost. Summary of the invention

[0007] A simplified summary is presented below to provide a basic understanding of some aspects of the present disclosure. The summary is not intended to identify the key or important elements of the present disclosure, and is not intended to indicate the scope of the present disclosure. The following summary only presents some concepts of the present disclosure in a simplified form as a preface to the following description.

[0008] The network threat analysis system (which may include one or more servers or other computing devices) may apply updated network threat intelligence to packet filtering output data generated based on earlier network threat intelligence. For example, and based on receiving the first network threat intelligence, the network threat analysis system may initially generate packet filtering rules, the packet filtering rules including one or more criteria for filtering packet communications to detect network threats involved in the first network threat intelligence. The network threat analysis system may send the packet filtering rules and other rules generated based on other network threat intelligence and related to other network threats to the packet security gateway. Using those rules, the packet security gateway may filter packet communications, may generate packet filtering output data (e.g., packet logs and captured packets) of filtered packets that match the criteria of those rules, and may forward the packet filtering output data to the network threat analysis system. After receiving the second network threat intelligence, the network threat analysis system may determine that the second network threat intelligence and the first network threat intelligence may be related to the same network threat, and may further determine that the second network threat intelligence may include information that may be used to generate updated standards associated with the same network threat. The updated standards may provide additional insights into the packet filtering output data generated by the packet security gateway using filtering rules based on the first network threat intelligence. To focus application of the updated criteria to data that may be associated with the same cyber threat, the cyber threat analysis system may identify packet logs and / or captured packets generated using pre-updated filtering rules based on the first cyber threat intelligence for the cyber threat.

[0009] The updated criteria may include data configured to match new and / or changed network threat indicators (e.g., values ​​of parameters and / or characteristics of filtered packets) associated with a network threat. The updated criteria may be applied by determining whether the identified packet log includes values ​​that match one or more of the updated criteria (e.g., one or more parameters and / or characteristics of filtered packets). The updated criteria may be applied to data in captured packets that may have been omitted from packet logs corresponding to those captured packets. For example, the updated criteria may allow for a determination that packets corresponding to certain packet logs do not match the updated criteria and, therefore, should no longer be associated with a network threat. Based on the application of the updated criteria, and based on a match or mismatch with the updated criteria, one or more outputs may be generated.

[0010] These and other features are described in greater detail below. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] Certain features are illustrated by way of example and not limitation in the figures of the accompanying drawings and in which like reference numerals refer to similar elements.

[0012] Figure 1 is a diagram illustrating an example environment associated with detecting and / or analyzing cyber threats based on updated cyber threat intelligence.

[0013] Figure 2 is a block diagram of an example network threat analysis system.

[0014] Figure 3A and Figure 3B is a sequence diagram illustrating an example of events associated with detecting and / or analyzing cyber threats based on updated cyber threat intelligence.

[0015] Figure 4 An example of log data sent from a packet security gateway to a network threat analysis and / or mitigation system is shown.

[0016] Figure 5A , Figure 5B , Figure 5C and Figure 5D An example of composite log data is shown.

[0017] Fig. 6A , Figure 6B , Figure 6C , Fig.6D , Fig. 6E and Fig. 6F is a flow chart of an example method for detecting and / or analyzing cyber threats based on updated cyber threat intelligence.

[0018] Figure 7 is a diagram illustrating an example environment associated with detecting and / or analyzing cyber threats based on updated cyber threat intelligence.

[0019] Fig. 8A and Figure 8B is a sequence diagram illustrating an example of events associated with filtering, aggregation, and / or retention control based on updated network threat intelligence.

[0020] Fig. 9A , Fig. 9B , Fig. 9C , Fig.9D , Fig.9E , Fig.9F and Figure 9G It is shown that Fig. 8A and Figure 8B A diagram of an example of data stored at a time associated with an event.

[0021] Fig. 10A and Fig. 10B is a sequence diagram illustrating another example of events associated with filtering, aggregation, and / or retention control based on updated network threat intelligence.

[0022] Fig.11Aand Fig. 11B is a sequence diagram illustrating further examples of events associated with filtering, aggregation, and / or retention control based on updated network threat intelligence.

[0023] Fig. 12A and Fig. 12B is a flow chart of an example method for filtering, aggregating, and / or retaining controls based on updated cyber threat intelligence.

[0024] Fig.13A and Fig. 13B is a sequence diagram illustrating additional examples of events associated with filtering, aggregation, and / or retention control based on updated cyber threat intelligence.

[0025] Fig.14A and Fig. 14B is a flow chart of another example method for filtering, aggregating, and / or retaining controls based on updated cyber threat intelligence. DETAILED DESCRIPTION

[0026] A cyber threat may include an attempt or suspected attempt by one or more threat actors to take some type of unauthorized action that affects a target entity's computing device and / or network. Threat actors may include criminals, criminal organizations, countries, or other individuals or groups. Unauthorized actions may include damaging and / or disabling devices (e.g., ransomware, hacking networked control systems to disable and / or damage industrial equipment), accessing and / or stealing data (e.g., exfiltration), causing computing devices and / or networks to perform operations that benefit the threat actor (e.g., generating spam, mining cryptocurrency, performing denial of service attacks, etc.) and / or any other type of action not authorized by the target entity. Without limiting the generality of the foregoing in any way, cyber threats may include viruses and other malware, phishing attacks, attempts to hack web servers, and the like.

[0027] Cyber ​​threat intelligence (CTI) may include information about a cyber threat. Such information may relate to the nature of the threat. For example, CTI may indicate that the threat involves a virus or other malware, a bot, a phishing attack, an exfiltration, a hacker attack attempt, and / or some other type of known or suspicious activity. CTI may include information about a threat actor associated with or suspected of being associated with a cyber threat. CTI may include a network threat indicator (NTI) or multiple NTIs associated with a cyber threat. NTI may include one or more values ​​and / or some other indication of a parameter or characteristic that may be observed in conjunction with packet data communicated via a network. For example, the NTI may include a 5-tuple value (a host / resource identifier specifying an L3 host IP address, an L4 port, and / or an associated L3 protocol type) or a portion thereof, one or more other L3 header field values ​​or a portion thereof, one or more other L4 header field values ​​or a portion thereof, one or more L2 header field values ​​or a portion thereof, a protocol version, a host name or a portion thereof, a domain name (e.g., a fully qualified domain name (FQDN)), a portion of a domain name (e.g., a top-level domain and / or a subdomain), a universal resource identifier (URI) or a portion thereof, a universal resource locator (URL) or a portion thereof, a certificate or a portion thereof, a certificate identifier or a portion thereof, a certificate authority identifier or a portion thereof, a size of a packet or a portion of a packet, a metric associated with a data payload portion of a packet, an HTTP request method type (e.g., GET, PUT, PUSH, CONNECT, etc.), etc. The NTI may include metadata associated with one or more packets. For example, the NTI may include one or more types of information associated with one or more parameters or characteristics that may be observed based on the behavior of a packet and / or a set of packets (or an action generated by a packet and / or a set of packets). For example, NTI may include the time associated with communicating a packet, whether the packet has a specified time relationship or other relationship with one or more other packets, directionality (e.g., incoming or outgoing), etc. NTI may include information indicating a protocol decoder (e.g., instructions) and / or a packet payload inspection algorithm. NTI may relate to a flow and may indicate a packet count or other information of a flow. A flow or microflow may refer to a collection of packets with the same 5-tuple value generated by the same (e.g., single) event / action at a source host. A flow may be unidirectional (e.g., a packet flows from a first host as a source to a second host as a destination) or bidirectional (e.g., a packet flows from a first host as a source to a second host as a destination and a packet flows from a second host as a source to a first host as a destination). Packets of a bidirectional flow may have the same 5-tuple value, but their source field value and destination field value may be transposed according to the direction of the packet (e.g., from a client to a server, or from a server to a client). A flow may include an application layer flow, which may be distributed over multiple L3 / L4 flows and their associated packets.

[0028] CTI may be received from one or more sources as CTI data in any of a variety of forms. CTI data may include reports from CTI providers. CTI data may include data delivered via an application programming interface (API) (e.g., in real time), text files, data downloaded from open source resources, and / or other types of data, and may be in any format. CTI data may be received from an external source (e.g., a CTI provider described below) or from an internal source. For example, the network threat analysis system 130 described below may generate CTI data (e.g., based on CTI data received from other sources and / or based on network traffic and / or behavior observed by the network threat analysis system 130). CTI data may explicitly identify one or more NTIs, and / or NTIs may be derived from information in the CTI data. CTI data and CTI may be and often are incomplete. For example, CTI data may include one type of NTI for a network threat, but may lack other types of NTIs and / or may lack threat context associated with one or more NTIs indicated by the CTI data. Over time, as more is learned about a network threat, new CTI for that threat may include additional types of NTI and / or changes to the NTI provided in previous CTI for that threat. Changes in NTI may cause later CTI data to include NTI that was not included in earlier CTI data, and / or later CTI data to not include NTI included in earlier CTI data. CTI may include a threat level, the value of which indicates a confidence value associated with the network threat. Similarly or alternatively, the threat level of a particular network threat may be determined, assigned, and / or modified based on an analysis of the CTI for that particular threat. The threat level may, for example, indicate a confidence level in the accuracy of the CTI and / or the likelihood that the threat is an actual threat. Similarly or alternatively, the threat level may indicate the potential severity of the network threat (e.g., a quantitative and / or qualitative estimate of the potential data loss, corruption, business interruption, or other possible impact of the network threat). The threat level associated with a network threat may increase (or decrease) over time. The threat level and context of CTI (and / or NTI) may be time-specific (e.g., may depend on a specific time range of relevance).

[0029] Typically, the CTI for a given network threat may evolve and / or otherwise change over time. As more information is learned about a particular network threat, the CTI about that threat may become more accurate and / or reliable. Conversely, older CTI may become (or have become) less reliable. For example, older CTI may have indicated that the network threat was less severe and / or less worrisome, while later CTI may indicate that the network threat is more problematic than originally thought. As another example, older CTI may have provided certain information (e.g., one or more NTIs) for detecting network threats, but some of that information may later be determined to be inapplicable and / or irrelevant, and later CTI may include more focused and / or more accurate information. As a further example, a threat actor may change the method used to attack a network (e.g., to disguise its later attempts or otherwise avoid repeating behaviors that a network security system may identify), and later CTI may indicate new and / or changed NTIs and / or other information related to the changed attack method.

[0030] CTI can be used to create packet filtering rules for a packet security gateway. Packet filtering rules can be used to filter data packets passing through the packet security gateway. Packet filtering can include comparing the criteria of the packet filtering rules with observable parameters and / or characteristics of the filtered packets, and determining whether there are any matches. The criteria of the packet filtering rules can be based on NTI and / or other information obtained from CTI (and / or can include other criteria). For example, if CTI indicates (e.g., by providing values) certain NTIs that may be associated with network threats, the packet filtering rule criteria based on the CTI can include information that can be compared with the packet (e.g., the values ​​of those NTIs) to determine whether those NTIs are present in the packet. Various types of packet filtering output data can be generated by the filtering process. For example, the packet filtering gateway can generate log data, wherein each packet log (e.g., each individual data record) can correspond to an individual packet and can include various data fields indicating the values ​​of various parameters and / or characteristics of the packet. These packet logs from the packet filtering gateway can be generated for packets that match the filtering criteria of the packet filtering rules, and the packet logs can be different from the logs generated by other types of devices (e.g., firewalls) that can create logs for all traffic. One or more values ​​in the packet log may include values ​​that match filtering criteria from filtering rules (e.g., may include values ​​that match one or more NTIs from one or more filtering rule criteria associated with the packet log). The packet log may be a flow-level log (e.g., L3 / L4-level flow log, L5-L7 application / application flow logs), which may include a set of packet logs for each packet. In addition to log data, packet filtering output data may also include captured packets. Captured packets may be copies of packets corresponding to one or more packet logs.

[0031] Based on the updated CTI received for a particular network threat, the packet matching criteria of the packet filtering rules associated with the network threat may also be updated. The updated packet matching criteria may include information for matching an NTI type that is different from the NTI type matched by the earlier packet matching criteria. For example, the earlier criteria may match the NTI of a specified network address (or network address range), while the updated criteria may match the NTI of a specified domain name. The updated packet matching criteria may include information for matching an NTI type that is the same as the NTI type matched by the earlier packet matching criteria but may have a different value. For example, the earlier criteria may match the NTI of a specified network address range, while the updated criteria may match the NTI of a specified different network address range or a specified specific network address.

[0032] When new CTI for a network threat is received, applying the new CTI to existing packet filter output data (e.g., log data and / or captured packets) that was collected based on older CTI may have significant benefits. For example, applying the new CTI to the existing packet filter output data may provide a more accurate assessment of whether the network was affected by the network threat during the time period before the new CTI. Applying the newer CTI to the existing packet filter output data may also reveal additional information that may improve future detection and / or prevention of network threats to which the newer CTI relates. Applying the newer CTI to the existing packet filter output data may also reduce the resources required to store the data. For example, portions of the existing packet filter output data may be determined to be less relevant, and therefore it may be appropriate to delete such data or reduce the amount of time such data is retained.

[0033] However, applying newer CTI to existing packet filter output data (e.g., log data and / or captured packets) brings various challenges. The amount of packet filter output data and the amount of new CTI may continue to grow at a considerable rate. Even if it is not impossible, it may be impractical to apply the new CTI of the expanded amount to the existing packet filter output data of the expanded amount. However, at least some of these challenges can be solved by using the earlier CTI related to a specific network threat to guide the application of the newer CTI to the existing packet filter output data. If the newer CTI is related to a specific network threat, the earlier CTI related to (or possibly related to) the network threat can be used to identify the parts of the existing packet filter output data that are more likely to be related to the network threat. Then, the newer CTI can be applied to those identified parts. This improves efficiency by avoiding wasting processing resources to apply the new CTI to a large amount of packet filter output data that may be irrelevant to the network threat involved in the new CTI.

[0034] Figure 1 1 is a diagram illustrating an environment 100 associated with detecting and / or analyzing network threats based on updated CTI and / or based on updated packet matching criteria corresponding to the updated CTI. Figure 1 In the accompanying drawings and subsequent drawings, the letter "n" is used to indicate any integer value of 2 or greater, and need not represent the same value anywhere it is used. A series of three dots is used in the drawings to indicate that there may be one or more additional elements similar to the elements at one or both ends of the series of three dots. Various similar elements shown in the drawings have similar reference numerals including the attached incremental portions. Elements with similar reference numerals can be referred to collectively or generally using similar portions of the reference numerals of the elements. For example, the first networks 105.1 to 105.n can be collectively referred to as the first network 105, and any one of those first networks 105 can be referred to as the (described) first network 105.

[0035] like Figure 1 As shown, the environment 100 may include one or more first networks 105. Alternatively, the environment 100 may include a single first network 105. Each first network 105 may, for example, include one or more networks of various types (e.g., a local area network (LAN), a wide area network (WAN), a virtual private network (VPN), a software defined network (SDN), or a combination thereof) associated with one or more individuals and / or entities (e.g., a government, a company, a service provider). As explained in more detail below, each of the first networks 105 may be served and / or protected by a packet security gateway (PSG 110), which is controlled and / or managed by or interfaced with a network threat analysis system 130. In particular, each first network 105 may include one or more hosts that communicate with one or more external hosts in one or more other networks via the PSG 110 and the second network 125. Those external hosts may include any one of the external hosts 140.1 to 140.n and / or Figure 1 1. One or more of external hosts 140 may be part of a network that communicates via second network 125, similar to third networks 151 and 155 described below. Second network 125 may, for example, include the Internet or a portion thereof. Network 105 may be a protected network (due to the presence of PSG 110), and networks other than network 105 (e.g., second network 125) may be unprotected networks.

[0036] The host can be used as a network node and / or can include a device connected to the network and having an L3 network address assigned to one or more network interfaces of the device. The host can include a computing device, such as a server, a desktop computer, a laptop computer, a tablet computer, a mobile device (e.g., a smart phone), a router, a gateway, a proxy, a firewall, a switch, an access point, etc. The computing device may include one or more processors configured to execute instructions, a memory storing executable instructions and / or other data, and one or more network interfaces, and the computing device is configured to send and / or receive data via the network via the network interface. The first network 105.1 may include hosts 120.1-1 to 120.1-n, which are configured to communicate with one or more external hosts 140 and / or with one or more other external hosts via PSG 110.1. Similarly, the first network 105.n may include hosts 120.n-1 to 120.nn, which are configured to communicate with one or more external hosts 140 and / or with one or more other external hosts via PSG 110.n. Some or all of the first networks 105 may also route external communications via other devices, such as firewalls, Internet Service Provider (ISP) gateways, proxy servers, etc. For example, a host in the first network 105 may include a firewall, proxy server, and / or other devices in a network path between other hosts in the network and the PSG 110 of the network, and / or external communications to or from the PSG 110 may be routed via an ISP gateway in a network path between the PSG 110 and the second network 125. The environment 100 may further include one or more third networks, such as third networks 151 and 155, which include hosts configured to communicate with hosts in other networks, but may not include the PSG 110. For example, hosts 152-1 to 152-n of the third network 151 may communicate with hosts in other networks via a firewall (FW) 153, and hosts 156-1 to 156-n of the third network 155 may communicate with hosts in other networks via an Internet Service Provider (ISP) server 157.

[0037] The network threat analysis system 130 (hereinafter referred to as system 130) may include one or more computing devices (e.g., one or more servers) configured to communicate with PSG 110 via network 125. Those communications may be direct and / or may be via one or more intermediate systems (e.g., intermediate systems that receive log data and / or captured packets from PSG 110 and forward the log data and / or those captured packets to system 130 or another system that system 130 can query). As described in more detail below, those communications may include filtering rules sent from system 130 to PSG 110, which PSG may apply to packets passing through those gateways. As also described below, those communications may also include packet filtering output data received from PSG 110. The packet filtering output data may include log data, including packet logs of packets that match the criteria of the filtering rules. The packet filtering output data may also or alternatively include copies of matching packets (and / or packets related to matching packets). System 130 may further be configured to generate filtering rules based on CTI data received from one or more providers of CTI (e.g., via network 125). Figure 1 As shown, environment 100 may include one or more cyber threat intelligence providers (CTIPs) 135.1 through 135.n.

[0038] like Figure 1As shown, PSG 110 can be located at or near the network boundary between the first network 105 and the second network 125, and PSG 110 can be an interface between the first network and the second network. PSG can filter packet data traffic passing through PSG by applying filtering rules received from system 130. The traffic can include packets sent from a host in the first network 105 to an external host via the second network 125, and packets received from an external host and sent to a host in the first network 105 via the second network 125. The filtering rules can, for example, include elements of filtering rules described in one or more of the following: U.S. Patent No. 9,866,576 (titled "Rule-Based Network-Threat Detection" and incorporated herein by reference) or U.S. Patent Application Publication No. 2017 / 0324709 (titled "Efficient Packet Capture for Cyber ​​Threat Analysis" and incorporated herein by reference). The filtering rules can include information identifying network threats, threat levels of threats, and criteria that may be matched. The criteria may include information that can be used to match one or more NTIs associated with a threat. If one or more criteria of the filter rule matches corresponding parameters and / or characteristics of a packet (or a stream or other packet group including a packet), the packet passing through PSG 110 may match the filter rule. The filter rule may further include one or more operators that may be applied to packets that match the filter rule criteria. For example, an "allow" operator may allow a packet to continue to its destination. As another example, a "block" operator may cause a packet to be discarded or otherwise prevent a packet from continuing to reach its destination. The filter rule may also include instructions or other information that causes a matching packet (and / or a packet in a stream or otherwise associated with a matching packet) to be captured. The capture packet may include a copy of the stored packet and / or information associated with the packet. Both blocked and allowed packets may be captured. PSG 110 may also generate packet logs based on the matched packets, and those packet logs and captured packets may be sent to system 130.

[0039] The PSG 110 may include one or more processors and a memory. The memory may store instructions that, when executed by the one or more processors, cause the PSG 110 to filter packets based on filtering rules (e.g., determine whether a packet matches one or more criteria of a filtering rule, apply an operator, capture a packet), generate a packet log based on packet matching, forward the packet log and captured packets to the system 130, receive and store filtering rules and other instructions from the system 130, configure or reconfigure the PSG 110, and / or perform other operations. The PSG 110 may include a first interface for connecting the PSG 110 to a host in the first network 105 and a second interface for connecting the PSG to the second network 125, which interfaces may be transparent at L2 and / or L3. In particular, those interfaces may lack assigned IP addresses or media access control (MAC) addresses, thereby allowing packets to pass through the PSG 110 without modifying the L2 or L3 headers of those packets. The PSG 110 may include additional interfaces (e.g., management interfaces) having assigned network addresses and / or allowing the PSG 110 to communicate with the system 130 and / or with other computing devices (e.g., hosts associated with administrators or other users). The PSG 110 may include features of a PSG and / or features of other devices that perform operations similar to those described above for the PSG 110, described in one or more of U.S. Patent No. 9,866,576, U.S. Patent Application Publication No. 2017 / 0324709, or U.S. Patent No. 9,137,205 (entitled “Methods and Systems for Protecting aSecured Network” and incorporated herein by reference). Similarly or alternatively, the PSG 110 may perform the functions of (and / or incorporate into) other types of devices (e.g., firewalls, proxy servers, other devices at the boundaries between networks).

[0040] Figure 21 is a block diagram of an example of a system 130. Although shown as a single computing device (e.g., a server) for convenience, the system 130 may alternatively include multiple computing devices, and the operations and / or functions of the system 130 described herein may be distributed between those multiple computing devices (e.g., multiple servers). If implemented as multiple computing devices, the computing devices of the system 130 may communicate via one or more networks (e.g., via one or more local networks and / or via the network 125). The system 130 may include a memory 201. The memory 201 may include one or more non-transitory physical memories of any type (e.g., volatile, non-volatile). The system 130 may further include one or more processors 211 and one or more network interfaces 212. The memory 201, (multiple) processors 211, and (multiple) network interfaces 212 may communicate via one or more data buses 210. The memory 201 may store instructions that, when executed by (multiple) processors 211, cause the system 130 to perform operations as described herein. Those instructions may be organized into and / or be part of one or more modules. Those modules may include a database management module 202, which includes instructions for storing data (e.g., CTI data from CTIP 135 and / or other sources, filter rules, packet logs, and / or packet captures from PSG 110) in a database 131 (which may include a separate computing device and / or one or more portions of memory 201), for retrieving such data, for deleting such data, for rearranging and / or indexing such data, for updating data, etc. The modules may include a rule module 203, which includes instructions for analyzing CTI data, for generating packet filter rules based on CTI data, for communicating packet filter rules to PSG 110, and / or for configuring packet filter rules based on a profile associated with a particular PSG 110 (e.g., a subscriber or customer profile), etc. The modules may include an intelligent update module 204 that stores instructions for determining that multiple CTI data are related (or may be related) to the same network threat, for determining differences between CTI data related (or may be related) to the same network threat, and for applying the determined differences to packet logs and / or captured packets generated based on an earlier version of CTI for the network threat. The module 204 may also store instructions for generating a report of the analysis performed by the module 204, which may be sent to and / or used by other systems and / or users (e.g., for performing forensic analysis on the composite log data and / or other information, which may or may not be associated with improvement rules used by one or more PSGs 110).Module 204 may interact with module 203 (e.g., to update packet filtering rules based on differences between multiple CTI data of network threats), with module 202 (e.g., to identify and / or obtain packet logs and / or captured packets associated with specific network threats), and / or with other modules. Network interface(s) 212 may connect system 130 to network 125, database 131, and / or other networks for data transmission.

[0041] Figure 3A and Figure 3B is a sequence diagram illustrating an example of events associated with detecting and / or analyzing a network threat based on updated CTI and / or based on updated NTI. Figure 3B yes Figure 3A For the purpose of explanation, the Figure 3A and Figure 3B The number, order, and / or timing of the example events shown may be changed, additional events may occur, and / or may be omitted or repeated. Figure 3A and Figure 3B One or more of the events shown in .

[0042] In event 301, system 130 may receive CTI data from CTIP 135.1. The CTI data may include one or more data messages and / or files, and may include CTI associated with one or more different network threats. The CTI data received in event 301 may include CTI 300.1 T1 , which is related to the first network threat and reflects the knowledge of CTI provider 135.1 at time T1. CTI 300.1 T1 The nature of the first cyber threat may be indicated (e.g., the type of attack that may be attempted, a suspicious entity associated with the attack, a suspected source of the attack, and / or other information), or any such indication may be absent. T1One or more NTIs associated with the first network threat may be indicated. As explained above, the NTI may include one or more values ​​of parameters or characteristics that may be observed in one or more packets or in conjunction with the communication of one or more packets. The NTI may include one or more specific values ​​(e.g., a specific source and / or destination address, a specific source and / or destination port, a specific protocol, a specific domain, etc.), may include a range of values ​​(e.g., a range of source and / or destination addresses, a range of source and / or destination ports, a portion of a domain), and / or may include a combination of multiple specific values ​​and / or ranges of values. The NTI may include information that is not part of the data within the actual packet but is observable based on the manner and / or time at which the packet is transmitted or received. Examples of such NTI may include the time (or time range) at which a packet passes through the PSG 110, whether a packet passes through the PSG 110 together with other packets that meet one or more criteria, whether data exists (e.g., regardless of the content of the data), etc. In Figure 3A In the example, CTI 300.1 T1 The CTI 300.1 may include limited information regarding the nature of the first cyber threat and may further include data specifying or indicating that the threat level associated with the first cyber threat is low (or unknown). T1 The indicated NTI(s) may also be limited (e.g., only a source address range and / or a destination address range). In event 302, system 130 may include CTI 300.1 T1 stored in database 131. System 130 can store CTI 300.1 T1 stored together with an identifier of the first cyber threat, which identifier may be used as CTI 300.1 T1 or generated by system 130. Figure 3A Not shown, but the CTI data received in event 301 may include additional CTI for additional network threats, which may also be stored in database 131 in event 302.

[0043] System 130 may receive CTI data from multiple CTI providers in a manner similar to that described with respect to CTI provider 135.1. For example, in event 303, system 130 may receive data including CTI 300.n from CTIP 135.n. CTI 300.n may be associated with one or more additional network threats and may indicate one or more NTIs and / or one or more other types of information about those additional network threats. In event 304, system 130 may store CTI 300.n and other CTI received in the CTI data of event 303 in database 131. CTI providers 135.1 and 135.n and / or other CTI providers may send additional CTI data to system 130 before event 301, after event 301, and before and / or after event 303, which additional CTI data may include additional CTI associated with additional network threats (indicating NTIs and / or other information), which may also be stored in database 131.

[0044] In event 305, system 130 may, based on CTI 300.1 T1 , CTI 300.n, and / or other CTI received by system 130 to generate one or more filtering rules. Rule generation for event 305 may, for example, include one or more operations such as those described in connection with one or more of the aforementioned patents or patent application publications. The generated filtering rule(s) may include one or more criteria, which may include criteria for matching CTI 300.1 T1 The generated filter rule(s) may also include criteria including information for matching one or more NTIs indicated by CTI 300.n and / or other CTIs received by system 130. The filter rule(s) may similarly include one or more operators and may include indications of whether packets matching the criteria of the filter rule(s) should be captured (and / or whether packet flows associated with such matching packets should be captured). Figure 3A and Figure 3BIn the example of , the filtering rule generated for the first network threat in event 305 includes criteria, including a source address range and a destination address range, instructions to record source and destination addresses, source and destination ports, and protocol types for matching packets, and instructions to capture matching packets and related packet flows. However, because the threat level of the first network threat is low at time T1, the filtering rule may not indicate that other information about the packet must be determined or recorded. The filtering rule and other filtering rules generated in event 305 are sent to PSG 110 in events 306 and 307, and are stored in database 131 in event 308.

[0045] In event 309, PSG 110.1 receives a packet from host 120.1 that is sent to an external host (e.g., to external host 140). In event 310, PSG 110.1 filters the packet by applying the criteria of the filter rule received in event 306. PSG 110.1 may compare the received packet (and / or the time and / or relationship of the received packet to other packets, and / or other information about the received packet) to the criteria specified by the filter rule applied as part of filtering event 310. If the packet (and / or information about the packet) matches the criteria of the filter rule, PSG 110.1 may take the action specified by the filter rule (e.g., log the packet, log and capture the packet, log and capture the flow associated with the packet) and may apply an operator (e.g., allow the packet to continue, block the packet). If the packet is not blocked, the packet may be allowed to proceed toward its destination in event 311.

[0046] In event 312, PSG 110.1 receives a packet from an external host (e.g., external host 140) that is destined for (e.g., addressed to) host 120.1 of first network 105. The packet received in event 312 may be a packet in response to a packet sent from host 120.1, or may not be such a response (e.g., the packet of event 312 may be an initial packet of a flow between the external host and host 120.1). In event 313, similar to the filtering of event 310, PSG 110.1 filters the packet by applying the criteria of the filtering rules to the packet to determine whether the transit packet matches the criteria from any packet filtering rules. If a match is found, PSG 110.1 may take one or more actions, including applying one or more operators of one or more matching rules, logging the matching packets, and / or capturing the matching packets. If the packet is not blocked (e.g., if the packet does not match the rules, or if the packet matches a rule that does not include a blocking operator), the packet may be allowed to proceed toward its destination in event 314. Events related to transiting packets communicated between host 120.1 and external hosts, such as events 309 through 314, may occur additionally many times. Some packets may be blocked and prevented from advancing to external hosts or host 120.1. In event 315, PSG 110.1 may forward packet filter output data generated in events 310 and 313 and in other similar events to system 130. The forwarded packet filter output data may include log data (e.g., packet logs including packets filtered during events 310 and 313 and during other filtering events). The forwarded packet filter output data may also include packets captured (pcaps) during events 310, 313, and / or other filtering events.

[0047] Figure 4 An example of log data 401 that may be sent in event 315 is shown. Example log data 401, as well as composite log data and / or other log data described herein, is intended to provide examples of the types of information that may be included in such log data in a convenient explanation format. The format and / or content of the log data may vary from Figure 4 For example, the log data need not be in a tabular form. As another example, the log data need not include all of the information shown in log data 401, and / or may include other types of information.

[0048] In the example log data 401, each entry is a packet log corresponding to a packet that matches one or more criteria of a filtering rule during filtering and includes a packet log for the packet. Figure 4The values ​​of one or more parameters and / or other characteristics (time, PSG_id, Host_id, etc.) shown in the top header row. In the example format of log data 401, each entry can be a row. In packet logs having other types of formats, the entries / logs can take other forms. Each cell in the "time" column can hold a value representing the time when the packet corresponding to the row including the cell passed through PSG 110.1 (e.g., was filtered by it). For convenience, each value in the time column is a 9-digit value in the form of HH:MM:SS:sss that represents a time value of a day with millisecond precision, and wherein the first and second digits represent hours (HH), the third and fourth digits represent minutes (MM), the fifth and sixth digits represent seconds (SS), and the remaining digits represent milliseconds (s). Additional digits can be included to add date components to the time value (e.g., HH can be expanded to four or more digits to measure hours from an arbitrarily selected reference date).

[0049] Each cell in the "PSG_id" column may hold a value identifying the PSG that filtered the packet corresponding to the row that includes the cell. As explained below, log data 401 may be combined with similar log data from other PSGs 110, and the value of the PSG_id column may be used in the combined log data to distinguish data attributable to different PSGs and / or networks. For convenience, the PSG_id values ​​are referred to as Figure 1 1 in the same reference numeral as PSG 110.1 in FIG. 105. The actual PSG_id value may, for example, include a MAC address or other unique value associated with the PSG. Each cell in the "Host_id" column may hold a value identifying a host 120.1 of network 105.1 that is associated with the filtered packets corresponding to the row that includes the cell. This host 120.1 may be a host that sends packets to an external host or a host to which packets received from an external host are sent. For convenience, the values ​​in the Host_id column are referred to as Figure 1 The actual Host_id value may, for example, include a MAC address or other unique value associated with the host 120.1.

[0050] Each cell in the "Log_id" column may hold a value that is a unique identifier for the packet log corresponding to the row that includes the cell. Figures 4 to 5DIn the example of , a relatively short value ("L" followed by 4 digits) is used for the Log_id value, but the actual value may be much longer to facilitate the use of a unique identifier value in a larger number of packet logs. Each cell in the "Rule_id" column can hold a value that identifies a filter rule associated with a filtered packet (e.g., a filter rule that includes criteria that the filtered packet corresponding to the row that includes the cell matches). For convenience, Figure 4 , an arbitrarily selected Rule_id value of the form "r***" is shown in . Although not shown, the packet log may also include cells for identifiers of network threats associated with filtering rules that include criteria matched by filtered packets corresponding to the row that includes the cells. For example, such values ​​may include network threat identifiers as described above in connection with event 302. For one or more packet logs, cells in the network threat identifier column may be blank, and / or values ​​in this column may be modified (e.g., based on a later determination that the log is relevant or not relevant to a particular network threat).

[0051] Each cell in the "Source_addr" column can store a value representing the source address of the filtered packet corresponding to the row including the cell, and each cell in the "Dest_addr" column can store a value representing the destination address of the filtered packet. The source address and the destination address can be an Internet Protocol (IP) address. For convenience, the values ​​in the Source_addr and Dest_addr columns are arbitrarily selected values ​​in the form of "IP***" indicating an IP address. The format of the actual Source_addr and Dest_addr values ​​can be IPv4, IPv6 and / or other IP version addresses. Similarly or alternatively, Source_addr and Dest_addr values ​​can include non-IP addresses. Each cell in the "S_port" column can store a value representing the source port of the filtered packet corresponding to the row including the cell, and each cell in the "D_port" column can store a value representing the destination port of the filtered packet. For convenience, the values ​​in the S_port and D_port columns are arbitrarily selected values ​​in the form of "port*" representing a source port or a destination port. The actual S_port and D_port values ​​may have numerical values ​​that identify the ports. Each cell in the "Prot." column may hold a value that identifies the protocol associated with the packet corresponding to the row that includes the cell. For convenience, the values ​​in the Prot. column are arbitrarily selected letters that represent the protocol. The actual Prot. value may be an identifier of an L4 protocol (e.g., TCP, IP, etc.), an identifier of a higher layer protocol (e.g., DNS, FTP, HTTP, HTTPS, TLS / SSL, etc.), and / or an identifier of another type of protocol. Figure 4 In the example of , the values ​​of the source address, destination address, source port, destination port, and protocol of each packet that matches the criteria of the filtering rule are recorded, even though the filtering rule associated with the first network threat only includes matching criteria based on the source address and destination address NTI. However, this is not necessarily the case. The filtering rule may indicate that only cells associated with the NTI of the matching criteria are recorded, or may indicate that any other combination of values ​​(whether or not part of the matching criteria of the filtering rule) are recorded. Figure 4 As further shown in , each cell in the “Dir.” column can store a value indicating whether the packet corresponding to the row including the cell is incoming from an external host (e.g., “IN”) or outgoing from host 120.1 (e.g., “OUT”).

[0052] like Figure 4 As further shown in , the example log data 401 may include one or more additional columns. Each additional column may correspond to a different parameter or characteristic, and the cell of such additional column may store the value of the corresponding parameter or characteristic of the filtered packet corresponding to the row including the cell. Such additional parameter or characteristic may correspond to the NTI (or other information) associated with the standard of the packet filtering rule. For one or more packet logs, the cells in some or all additional columns may be blank. For example, and in order to save processing resources of the PSG and / or to minimize waiting time, if one or more parameters / characteristics corresponding to the additional column are not associated with the standard of the rule matched by the filtered packet, and / or if the filtered packet is being captured and the value of one or more parameters / characteristics of the additional column can be extracted later (if necessary), the value of the one or more parameters / characteristics may not be extracted from the packet filtered due to the filtering rule associated with the network threat with a lower threat level value. The parameters / characteristics associated with the additional column may include one or more of any threat indicators described herein and / or other threat indicators or parameters / characteristics associated with the packet.

[0053] Each cell in the "Flow_id" column may hold a value identifying the flow associated with the filtered packet corresponding to the row that includes the cell. For convenience, Figure 4 Arbitrarily selected Flow_id values ​​of the form "flow*" are shown in . For example, a Flow_id value may be used to identify captured packets of a flow that includes filtered packets. Similarly or alternatively, a Flow_id value may be used to cross-reference (and / or generate) separate packet logs that point to one or more specific flows. Each cell in the "PcapId" column may hold a value indicating that the filtered packets (and / or flow including filtered packets) corresponding to the row including the cell were not captured, or a value indicating a file or other reference for obtaining a capture of the filtered packets (and / or flow including filtered packets). In Figures 4 to 5D In the example shown in FIG. 1 , a value of 0 is used to indicate that a packet is not captured, and an indication that a packet is captured is displayed as an arbitrarily selected value of the form "cap*.".

[0054] Return to Figure 3A After receiving packet filtering output data (e.g., packet log(s) and / or captured packet(s)) from PSG 110.1 in event 315, system 130 may store the received packet filtering output data in database 131 (event 316). When storing packet log(s) as part of event 316, the packet logs may be appended to or otherwise combined with packet logs from other PSGs 110. Events 321 through 328 may be similar to events 309 through 316, respectively, but may be performed for packet communications between PSG 110.n and hosts 120.n of network 105.n and external hosts. Similar events may occur for hosts 120 and PSGs 110 of other first networks 105. Although Figure 3A The events associated with PSG 110.n are shown to occur after the events associated with PSG 110.1, but this is for convenience and to avoid ambiguity. Figure 3A In particular, events associated with PSG 110.1 may be temporarily interspersed with events associated with PSG 110.n and / or similar events associated with other PSGs 110. In addition, after sending the packet log(s) and / or captured packets to system 130 (e.g., as shown for events 315 and 327), PSG 110 may continue to receive and filter packet communications based on filtering rules provided by system 130. Similarly, system 130 may continue to receive CTI data, generate and / or update filtering rules based on CTI in the CTI data, and send those filtering rules to PSG 110 for application to packet communications.

[0055] At event 341, system 130 may receive CTI data from CTI provider 135.1. The CTI data may include information related to earlier CTI 300.1. T1 The first cyber threat involved is related to CTI 300.1 T2 For example, CTI 300.1 T2 The CTI provider 135.1 may reflect the knowledge at time T2 after time T1 and may indicate additional NTI and / or changed NTI that may be used to detect packet communications associated with the first network threat. T2 Other information about the first network threat may be included. For example, CTI 300.1 T2The information may include information regarding an increase or decrease in the threat level associated with the first network threat (and / or may include information indicating (e.g., to system 130) that the threat level should be changed), may include additional information and / or changed information regarding the nature of the first network threat, etc. Figure 3A and Figure 3B Example of CTI 300.1 T2 and CTI 300.1 T1 is received from the same CTI provider (CTI provider 135.1), but this is not necessarily the case. For example, including CTI 300.1 T2 The CTI data may be received from a CTI provider 135 . n or from another CTI provider 135 different from CTI provider 135 . 1 , and / or may be generated internally by the system 130 .

[0056] In Event 342 ( Figure 3B ) (which may be after event 341), system 130 may determine CTI 300.1 T2 and CTI300.1 T1 The event 342 may be determined, for example, based on the determination of the event contained in CTI 300.1 T2 The cyber threat identifiers contained in (or otherwise associated with) CTI 300.1 T1 Other examples of how a determination of event 342 may be made (e.g., if CTI 300.1 T1 and CTI 300.1 T2 If either or both of the following are missing a cyber threat identifier, then if CTIP 135.1 does not identify CTI 300.1 T1 and CTI 300.1 T2 Related to the same network threat, if CTI 300.1 T1 and CTI300.1 T2 are received from sources using different cyber threat identifiers, etc.) in combination with Fig. 6E Describe. CTI300.1 T2 and CTI 300.1 T1 The determination that events 342 may belong to the same network threat may not be certain. For example, the determination of event 342 may include determining that CTI 300.1 T2 and CTI 300.1 T1 May be related to the same network threat and have similar effects to CTI300.1 T1 Correlate packet logs and / or packet capture applications based on CTI 300.1T2 The standard may therefore be useful, but may not yet be derived from CTI 300.1 T2 and CTI 300.1 T1 System 130 may, for example, determine CTI 300.1 T2 and CTI 300.1 T1 may belong to the same network threat, but it is also possible to determine that there are one or more that may also be related to CTI 300.1 T2 Other instances of earlier CTI that are related to the same cyber threat. In this case, and as explained in more detail below, system 130 may be able to identify other instances of earlier CTI that may be related to CTI 300.1. T2 Each of the multiple instances of earlier CTIs involving the same cyber threat is a CTI 300.1 T2 Perform something similar to the following on CTI 300.1 T2 Compared to CTI300.1 T1 Describe those steps.

[0057] In event 343, system 103 may determine CTI 300.1 T2 Relative to CTI 300.1 T1 The updated criteria corresponding to the first network threat may include, for example, CTI 300.1 T1 One or more changes in one or more NTIs indicated (e.g., CTI 300.1 T1 Changes in the indicated NTI value, CTI300.1 T1 The indicated omission of one or more NTIs) and / or information about one or more new NTIs (e.g., the absence of CTI 300.1 T1 The determination of event 343 may include determining that the threat level of the first cyber threat has increased or decreased, the nature of the first cyber threat has changed (and / or new information has become available about it), the type of company or other organization targeted by the first cyber threat has changed (and / or new information has become available about it), and / or there is other new and / or changed information about the first cyber threat. If CTI for the same cyber threat is received from multiple providers 135, the presence of CTI for the same cyber threat from multiple providers may be noteworthy and may be a basis for taking one or more actions (e.g., changing a confidence level associated with the cyber threat, triggering analysis of other cyber threats from those multiple providers, etc.).

[0058] At event 344, system 130 may retrieve from database 131 previously stored data related to the CTI 300.1 T1 The packet logs and captured packets associated with the packet filter rule(s) of the CTI 300.1 may include the first network threat (if any) and / or the packet capture information based on the CTI 300.1. T1 The packet log associated with the filter rule of the example embodiment may include identifying the packet log associated with the identified packet log as a subset of the packet logs received by the system 130 in events 315 and / or 327 (and / or received by the system 130 from other PSGs 110 and / or at other times), and retrieving the identified subset of the packet logs. Event 344 may include identifying the captured packets associated with the identified packet log as a subset of the captured packets received by the system 130 in events 315 and / or 327 (and / or received by the system 130 from other PSGs 110 and / or at other times), and retrieving the identified subset of the captured packets. For log data such as example log 401, this may include identifying and retrieving packets that have a match to a previously generated packet based on CTI 300.1 T1 The generated filter rules correspond to the rows of Rule_id values ​​and the packet captures associated with those rows.

[0059] In event 345, system 130 may analyze the retrieved packet logs and / or captured packets based on the changes determined in event 343 by applying the updated criteria determined in event 343 to the packet logs and / or packets previously identified as being related (or potentially related) to the first network threat. The updated criteria may include matching the new and / or changed NTI determined in event 343 and / or the CTI 300.1. T2 Information about other criteria that may be changed or added. Non-limiting examples of the analysis of step 345 may include: FIG. 5A to FIG. 5D Described. The packet logs and / or captured packets associated (or potentially associated) with any particular network threat may be a very small portion of the total amount of stored packet logs and / or packets. Applying criteria (and / or other criteria) including information for matching new and / or changed NTIs to a smaller portion of the stored data (the portion is more likely to be relevant) rather than to the entire stored packet logs and captured packets associated with all network threats is more efficient and more likely to quickly detect the previous impact of the network threat. After applying the criteria (and / or other criteria) including information for matching new and / or changed NTIs to the reduced data set associated with the first network threat, and as explained below, the relevant portion of the reduced data set can be further reduced. This can reduce the time required to detect and / or quantify the impact of the first network threat, can help identify hosts affected by the first network threat, and / or can otherwise facilitate targeted actions.

[0060] Figure 5A Example composite log data 501 including packet logs that may be retrieved by system 130 in step 344 is shown. The composite log data may include packet logs received from multiple PSGs 110. Figure 3A and Figure 3B In the example of FIG. 300 , the first network threat is associated with Rule_id value r002. Composite log data 501 may include all packet logs stored by system 130 (e.g., in events 313 and 328) that include Rule_id value r002. Composite log data 501 may be significantly reduced in size (e.g., reduced by multiple orders of magnitude) relative to all packet logs stored in database 131. By combining the updated criteria for the first network threat (based on CTI 300.1 T2 ) is applied to the composite log data 501, and / or by not applying the updated criteria to other log data, analysis and detection of the first network threat can be significantly more efficient.

[0061] But as a first example of how the updated standard may be applied to composite log data 501, the earlier CTI 300.1 T1 The indicated NTI may have included a source address range containing IP3, IP23, and IP33 and a destination address range containing IP4 and IP24. Later CTI 300.1 T2 Those NTIs may be narrowed down to a specific source address IP23 and a specific destination address IP4. If criteria based on the narrowed source and destination address NTIs are applied to the composite log data 501, the system 130 may confirm that rows that match the updated criteria (e.g., rows a, j, and o that include source address IP23 and destination address IP4) (and corresponding filtered packets) may be associated with the first network threat. The system 130 may similarly determine that rows that do not match the updated criteria (e.g., rows that do not include source address IP23 and destination address IP4) (and corresponding filtered packets) may not be associated with the first network threat (or are unlikely to be associated with it), and / or may determine that such rows (and corresponding filtered packets) may be ignored and / or otherwise designated as less relevant.

[0062] But as a second example of how updated criteria may be applied to composite log data 501, CTI 300.1 T1 There may be no mention of any time indication associated with the first cyber threat. CTI 300.1 T2New information showing that the first network threat is a type of malware observed beaconing to a command and control server during certain time windows may be included, and may further indicate that the new NTI specifies that packet communications associated with the first network threat occurred between 10 p.m. and 2:00 a.m. When the criteria based on the new NTI are applied to the composite log data 501, the system 130 may confirm that rows that match the updated criteria (e.g., rows ae, p, and q with times between 10 p.m. and 2:00 a.m.) (and corresponding filtered packets) may be related to the first network threat. The system 130 may similarly determine that rows that do not match the updated criteria (e.g., rows that do not include times between 10 p.m. and 2:00 a.m.) (and corresponding filtered packets) may not be related to the first network threat (or are unlikely to be related to it), and / or may determine that such rows (and corresponding filtered packets) may be ignored and / or otherwise designated as less relevant.

[0063] But as a third example of how updated criteria may be applied to composite log data 501, CTI 300.1 T2 New information may be included indicating that a first network threat has been observed that is associated with certain types of traffic. Network 105.1 may be operated by that type of traffic, but network 105.n may be operated by an unrelated type of traffic. The new information (the traffic types associated with the network threat) may be used to modify (or create) filtering rules for those types of traffic (e.g., by including updated criteria configured to match PSG_id values ​​associated with network 105.1). If the updated criteria is applied to composite log data 501, system 130 may confirm that rows that match the updated criteria (e.g., rows b, f, h, j, k, m, and o that include PSG_id values ​​associated with network 105.1) (and corresponding filtered packets) may be associated with the first network threat. System 130 may similarly determine that rows that do not match the updated criteria (e.g., rows that do not include a PSG_id value associated with network 105.1) (and corresponding filtered packets) may not be related to (or are unlikely to be related to) the first network threat, and / or may determine that such rows (and corresponding filtered packets) may be ignored and / or otherwise designated as less relevant.

[0064] When initially created at the time of filtering, packet logs related (or potentially related) to the first network threat may lack information related to packets not generated by the earlier CTI 300.1 T1 Indicated but later by CTI 300.1 T2As part of a passive / background update process, system 130 may populate one or more of those fields based on captured packets corresponding to those packet logs. For example, system 130 may have additional processing resources that can be used for such a purpose, thereby freeing up resources of PSG 110 for filtering operations. However, without such a passive / background update process, or if such a process has not had time to complete as of step 345, packet logs identified as being related (or potentially related) to the first network threat (e.g., based on Rule_id value r002) may lack information that is not associated with an earlier CTI 300.1. T1 Indicated but later by CTI 300.1 T2 In this case, and as will be later based on CTI 300.1 T2 The updated criteria are applied to packet logs and / or portions of packets previously identified as being associated (or potentially associated) with the first network threat, the system 130 may examine captured packets to obtain data for one or more unpopulated packet log data fields corresponding to one or more NTIs that may be matched by the updated criteria, and may modify those packet logs by adding the data obtained from the captured packets to the previously unpopulated fields of the packet logs corresponding to those captured packets. The updated criteria may then be applied to the modified packet logs. But as a first example of a situation in which the updated criteria may be used in this manner, a single IP address may be associated with multiple domain names. One or more of those domain names may be associated with malicious activity, but one or more other domain names may be benign. As described above with respect to the previous example, the earlier CTI 300.1 T1 The indicated NTI may have included a source address range containing IP3, IP23, and IP33 and a destination address range containing IP4 and IP24. However, CTI 300.1 T1 Any information about the domain associated with the first network threat may not be included. In addition to the NTI specifying the source address and / or destination address range, the later CTI 300.1 T2 It may also be indicated that the domain names "www.ndgfare3.com" and "www.kxoidcxe.com" are designated as NTIs associated with the first network threat. T1 Associated threat level is low and / or CTI 300.1 T1There is no information about the relevant domain name in the filter rule r002, so the filter rule r002 may not be configured to cause PSG 110 to check the domain name of the filtered packets or include the domain name in the packet log of the packets that match one or more criteria of the filter rule r002. However, because those packets are captured, the extractable domain name can be added to the corresponding corresponding packet log.

[0065] Figure 5B Example composite log data 502 is shown including packet logs that may be obtained by system 130 in step 344 and that have been further modified to populate fields in one of the additional columns corresponding to a domain name (DN) based on inspection of captured packets (e.g., filtered packets and / or packets of a flow that includes filtered packets) that respectively correspond to those packet logs. T2 When the updated criteria of the indicated new NTI (specifying the domain names "www.ndgfare3.com" and "www.kxoidcxe.com") are applied to the modified packet log, the system 130 can confirm that the rows that match the updated criteria (e.g., rows a, f, h, jm, and o that include one of the domain names "www.ndgfare3.com" or "www.kxoidcxe.com") (and the corresponding filtered packets) are likely to be related to the first network threat. The system 130 can similarly determine that the rows that do not match the updated criteria (e.g., rows that do not include one of the domain names "www.ndgfare3.com" or "www.kxoidcxe.com") (and the corresponding filtered packets) are likely not related to (or are unlikely to be related to) the first network threat, and / or can determine that such rows (and the corresponding filtered packets) can be ignored and / or otherwise designated as less relevant.

[0066] But as another example of a situation where data from captured packets can be used when applying updated standards, certain types of malware may intentionally introduce errors into packet fields associated with and / or required by specific protocols. Such malware may, for example, be designed to thwart detection methods that focus on certain protocols and / or may be fooled when a protocol is "broken." CTI 300.1 T1 may not include any information about the protocol errors associated with the first network threat. However, CTI 300.1 T2 One or more NTIs based on syntax errors in Protocol B may be indicated. T1 Associated threat level is low and / or CTI 300.1 T1There is no information about protocol errors in the filter rule r002, so filter rule r002 may not be configured to cause PSG 110 to check filtered packets for such errors or include indications of such errors in the packet logs for packets that match one or more criteria of filter rule r002. However, because those packets are captured, this information can be extracted from those packets and added to the corresponding corresponding packet logs.

[0067] Figure 5C Example composite log data 503 is shown including packet logs that may be obtained by system 130 in step 344 and that have been modified to populate fields in one of the additional columns corresponding to protocol errors based on inspection of captured packets (e.g., filtered packets and / or packets of a flow that includes filtered packets) that respectively correspond to those packet logs. T2 When the updated criteria of the indicated new NTI are applied to the modified packet log, the system 130 can confirm that the rows that match the updated criteria (e.g., rows a, f, g, j, l, and m that include "B" in the "Prot." field and "Syntax Error" in the "Protocol Error" field) (and the corresponding filtered packets) are likely to be related to the first network threat. The system 130 can similarly determine that the rows that do not match the updated criteria (e.g., rows that do not include "B" in the "Prot." field and "Syntax Error" in the "Protocol Error" field) (and the corresponding filtered packets) are likely not related to the first network threat (or are unlikely to be related to it), and / or can determine that such rows (and the corresponding filtered packets) can be ignored and / or otherwise designated as less relevant.

[0068] But as a further example of where data from captured packets can be used when applying updated standards, certain types of network threats can be associated with authentication certificates signed by specific authentication authorities. CTI 300.1 T1 There may be no mention of authentication certificate details that could be associated with the first cyber threat. However, CTI 300.1 T2 Information regarding the connection of the first cyber threat to the use of a particular certificate signing authority ("dodgycertauth.com") may be included. T1 Associated threat level is low and / or CTI 300.1 T1 Since there is no information about authentication certificates in the filter rule r002, filter rule r002 may not be configured to cause PSG 110 to check the certificate information of the filtered packets or include the certificate information in the packet logs of packets that match one or more criteria of filter rule r002. However, because those packets are captured, the information can be extracted from those packets and added to the corresponding corresponding packet logs.

[0069] Figure 5D Example composite log data 504 is shown that includes packet logs that may be obtained by system 130 in step 344 and that have been further modified to populate fields in one of the additional columns corresponding to a certificate signing authority based on an inspection of captured packets (e.g., filtered packets and / or packets of a flow that includes filtered packets) that respectively correspond to those packet logs. T2 When the updated criteria of the indicated new NTI is applied to the modified packet log, the system 130 can confirm that the rows that match the updated criteria (e.g., rows c, g, k, and n that include "dodgycertauth.com" in the "CA" field) (and the corresponding filtered packets) are likely to be related to the first network threat. The system 130 can similarly determine that the rows that do not match the updated criteria (e.g., rows that do not include "dodgycertauth.com" in the "CA" field) (and the corresponding filtered packets) are not related to (or are unlikely to be related to) the first network threat, and / or can determine that such rows (and the corresponding filtered packets) can be ignored and / or otherwise designated as less relevant.

[0070] The above examples are only a few of the many ways in which a later CTI for a particular network threat may differ from an earlier CTI for the same threat, and where those differences may be used to process packet filtering output data (e.g., packet logs and / or captured packets) collected based on the earlier CTI. In general, any updated criteria based on the later CTI may be used to narrow down and / or otherwise analyze packet filtering output data collected and / or generated based on the earlier CTI. The updated criteria may include information for matching new NTIs indicated by the later CTI that are not included in the earlier CTI, information for matching changes in the value of the NTI indicated by the later CTI relative to the value of the NTI indicated by the earlier CTI, information for matching omissions of NTIs indicated by the earlier CTI, and / or other information.

[0071] Similarly or alternatively, packet filtering output data collected and / or generated based on criteria based on earlier CTIs may be further analyzed based on new (or changed) criteria based on later CTIs that do not indicate changes and / or additions to NTIs. For example, an earlier CTI for a network threat may indicate several basic NTIs (e.g., one or more source addresses and / or destination addresses), and may further indicate that the network threat is associated with a low threat level, but includes little else. Based on the earlier CTI, a filtering rule may be generated and sent to the PSG 110, which causes the PSG 110 to record the source and destination addresses and source and destination ports of filtered packets that match the criteria of the filtering rule, and to capture packets, but not to record other information about those packets. A later CTI for the network threat may indicate the same threat indicator value, but may increase the threat level of the network threat. Based on the increased threat level, a packet log generated based on the earlier CTI and captured packets may be retrieved, and the captured packets may be examined to obtain information for filling in additional fields in the retrieved packet logs. One or more additional analyses may then be performed on those additional fields that are populated, such as the analyses described below.

[0072] return Figure 3B , at event 346, system 130 may mark and / or otherwise update portions of the stored packet log based on the analysis(s) in step 345 (and / or additional marking / updating may occur during event 346). For example, for each packet communication identified as corresponding to (or possibly corresponding to) a network threat (e.g., at Figure 5A In the first example, the packets corresponding to rows a, j, and o communicate, Figure 5A In the second example of FIG. 1 , the packets corresponding to rows ae, p, and q communicate with each other. Figure 5A In the third example of FIG. 1 , packets corresponding to rows b, f, h, j, k, m, and o are communicated. Figure 5B In the example above, the packets corresponding to rows a, f, h, jm, and o communicate with each other. Figure 5C In the example above, the packets corresponding to rows a, f, g, j, l, and m communicate with each other. Figure 5DIn the example of event 346 (packet communications corresponding to rows c, g, k, and n), based on the packet inspection, the system 130 may replace portions of the previously stored packet logs with modified packet logs corresponding to those communications and having the additional fields completed. Similarly or alternatively, the system 130 may set marks in the modified packet logs (and / or in previously stored versions of those packet logs) to indicate that those packet logs correspond to communications confirmed to be associated with the first network threat. If subsequent CTI is received for the first network threat (e.g., indicating further updated criteria), such marking may, for example, allow for faster and / or more efficient analysis of those log portions. Similarly or alternatively, and as part of the update in event 346, the system 130 may set different marks in packet logs (e.g., previously stored packet logs and / or modified packet logs) that correspond to communications that have been determined not to correspond to the first network threat (e.g., corresponding to communications in FIG. 5A to FIG. 5D Those different markings can be used, for example, to indicate that portions of the stored logs with those different markings can be deleted, or can be retained for a shorter amount of time than portions of the logs that are confirmed to correspond to updates of a cyber threat.

[0073] In event 347, system 130 may further analyze packet logs and / or other data generated by the analysis(s) of event 345. This further analysis may include searching for commonalities in packet logs corresponding to communications confirmed as corresponding to the first network threat. For example, during the analysis of event 345, the fields of the additional columns of those packet logs may have been populated with values ​​based on inspection of captured packets, and some of those additional columns may not correspond to NTIs known to be associated with the first network threat. If a common value appears in a significant portion of the fields of one of those additional columns, the common value may be an NTI that can be used to improve the filtering rules associated with the first network threat. As another example, the time values ​​of the packet logs corresponding to communications confirmed as corresponding to the first network threat may be analyzed. If those time values ​​are confined to a recurring time window, the time window may be used as a new NTI or for narrowing the time range of an existing NTI.

[0074] Similarly or alternatively, the analysis(s) in event 347 may include analyzing other stored packet logs and / or stored packet captures (e.g., logs that do not include Rule_id value r002) that may not have been previously identified as potentially associated with the first network threat. T2New information may be included indicating that the first network threat is associated with malware that follows a particular pattern, the particular pattern including sending a first packet (or series of packets) to an innocuous website (e.g., "www.google.com") to confirm that Internet access is available, sending a second packet to a random address in a particular country to confirm that Internet access to the country is available, and sending a third packet to a command and control server associated with the malware in the particular country. For communications confirmed in event 345 as corresponding to the first network threat, hosts 120 associated with those communications may be determined, and additional packet logs and / or packet captures associated with those hosts 120 may be obtained (e.g., within a time range corresponding to the three steps executed by the malware). If there are additional logs and / or packet captures associated with those hosts 120 that do not include Rule_id r002, and if those log(s) and / or packet capture(s) show activity associated with one of the three steps executed by the malware, additional confirmation of the first network threat and / or additional intelligence about the first network threat may be obtained. But as an additional example of analyzing other stored packet logs and / or stored packet captures that may not have been previously associated with the first network threat, if the packet communication matches the criteria of multiple packet filtering rules, the packet communication may be recorded in multiple ways (e.g., there may be multiple logs for a single packet, each of those logs corresponding to filtering the packet based on a different filtering rule). For example, a first filtering rule may filter based on a source address and a destination address, and a second filtering rule may filter based on a domain name and a time of day. If the packet communication is determined to correspond to a network threat based on a match to the first filtering rule, the stored packet logs may be searched for packet logs corresponding to matches of the packet communication to other filtering rules. For example, the stored packet logs may be searched for other packet communications that occurred at or about the same time and have the same source address and destination address. Based on the packet logs that match the same packet communication to the second filtering rule, additional NTIs and / or other criteria associated with the second filtering rule, and / or other intelligence associated with the second filtering rule may be added to or otherwise combined with the criteria and intelligence associated with the first filtering rule.

[0075] In event 348, system 130 may mark and / or otherwise update portions of the stored packet log based on the analysis(s) in event 347 (and / or additional marking / updating may occur during event 347). The marking and / or updating in event 348 may be similar to the marking and / or updating in event 346, but may further include marking portions of the packet log that were not previously associated with the first network threat as being associated with the first network threat.

[0076] In addition to the output(s) that cause the data in database 131 to be updated and / or marked in one or more of events 346 to 348, system 130 may also (e.g., in event 349) generate and / or cause one or more other types of outputs based on the analysis(s) in event 345 and / or event 347. Such outputs may, for example, include outputting an indication on a display that is associated with a network analyst, system administrator, or other personnel associated with detecting and / or monitoring network threats, preventing and / or reducing harm caused by network threats, and / or remediating network threats. Such indications may, for example, provide details about which packet communications have been identified as (or have been identified as more likely to be) affected by and / or otherwise associated with a particular network threat, details about hosts and / or other devices in network 105 that are associated with a particular threat and / or should be isolated and / or otherwise separated, and / or details about network threats and / or affected hosts or other devices. As shown in events 351 to 354, system 130 may also cause and / or generate outputs based on the analysis(s) in event 345 and / or event 347, which may cause modification and / or creation of filtering rules for subsequent application by PSG 110. For example, in event 351, a filter based on CTI 300.1 may be created. T2 The new or changed criteria and / or the criteria determined based on the analysis(s) in events 345 and / or 347 are added to the filtering rules associated with the first network threat. As another example, CTI 300.1 T2 The new information in and / or from the analysis(s) in events 345 and / or 347 may cause the threat level associated with the first network threat to be upgraded, and event 351 may include an output instruction (e.g., to rules module 203) to change the operator in the filtering rule from "allow" to "block."

[0077] In the above example, the earlier CTI (CTI 300.1 T1 ) is identified as being associated with a network threat (a first network threat) that is associated with a later CTI (CTI 300.1 T2 ) are the same network threats associated with instances of CTI 300.1 ). However, as also indicated above, multiple instances of earlier CTI may be identified as potentially related to network threats that are the same as network threats associated with later instances of CTI. For example, and in addition to CTI 300.1 T1 In addition, the system 130 may also recognize CTI 300.2 received from various other CTIPs (or generated internally by the system 130). Ta 、CTI300.3 Tb ,…,CTI 300.nTn , which is potentially related to the first network threat and is in CTI300.1 T2 Based on identifying those multiple instances of earlier CTI, the later CTI 300.1 can be compared with each instance of the identified earlier CTI. T2 Execute steps 342 to 354. In particular, system 130 may be relative to CTI 300.1 T1 About CTI 300.1 T2 Execute steps 342 to 354 (as described above), relative to CTI 300.2 Ta About CTI 300.1 T2 Execute steps 342 to 354, relative to CTI 300.3 Tb About CTI 300.1 T2 Execute steps 342 to 354, ..., relative to CTI 300.n Tn About CTI 300.1 T2 Execute steps 342 to 354.

[0078] 6A to 6F is a flow chart of an example method for detecting and / or analyzing network threats based on new / updated CTI and / or based on updated criteria associated with the new / updated CTI. 6A to 6F One, some, or all steps of the example method may be performed by the system 130 and / or by a combination of one or more computing devices configured to perform some or all operations and / or functions of the system 130. For convenience, the following describes the system 130 in conjunction with the system 130. 6A to 6F . Similarly or alternatively, 6A to 6F One, some, or all steps of the example methods may be performed by one or more other computing devices. 6A to 6F One or more steps of the example methods may be rearranged (eg, performed in a different order), combined, omitted, and / or otherwise modified, and / or other steps may be added.

[0079] In step 601, the system 130 may determine whether new CTI (e.g., new CTI data) has been received from a CTI provider (e.g., one or more of the CTI providers 135) or another source or generated internally. If not, step 601 may be repeated until new CTI is received. If yes, the system 130 may perform step 602. In step 602, the system 130 may determine whether there are one or more instances of previous CTI that may be related to the network threat to which the new CTI relates. For convenience, the network threat to which the new CTI relates is referred to as a "new CTI network threat" hereinafter. Additional details of step 602 may be incorporated into the description. Fig. 6EIf the system 130 fails to determine at least one instance of a previous CTI in step 602, step 604 may be performed. In step 604, the system 130 may forward the new CTI to the rule module 203 to generate one or more filtering rules (e.g., such as combining Figure 3A The system may repeat step 601 after executing step 604 (indicated by connector AA).

[0080] If the system 130 determines at least one instance of a previous CTI involved in the new CTI network threat in step 602, step 605 may be performed. In step 605, the system 130 may select a previous CTI from one or more instances of the previous CTI determined in step 602. If the system 130 determines multiple instances of the previous CTI in step 602, those determined previous instances (or pointers to those determined previous instances) may be arranged in a queue, and step 605 may include selecting the next instance of the previous CTI in the queue. If only a single previous CTI instance was determined in step 602, step 605 may include selecting the single previous CTI. As part of step 605, the system 130 may also obtain the selected previous CTI (e.g., obtain the NTI and other data indicated by the selected previous CTI). In step 606, the system 130 may determine the difference (if any) between the new CTI and the selected previous CTI. Figure 3B Event 343 of may include an example of step 606. If the system 130 determines in step 607 that no difference is determined in step 606, the system 130 may proceed to step 610. In step 610, the system 130 may determine whether there are additional previous CTI instances that were determined in step 602 but have not yet been selected. If so, the system 130 may return to step 605 (indicated by connector FF). If not, the system 130 may return to step 601 (indicated by connector AA). If the system 130 determines in step 607 that a difference is determined in step 606, the system 130 may proceed to step 608. In step 608, the system 130 may retrieve packet filtering output data (e.g., packet logs and / or captured packets) associated with the selected previous CTI (e.g., packet logs and / or captured packets generated based on packet filtering rules associated with the selected previous CTI). Figure 3B Event 344 of may include an example of step 608. As part of step 608, system 130 may generate composite log data (eg, composite log data 501, 502, 503, or 504 before adding data from captured packets).

[0081] In step 614, system 130 may determine whether the difference determined in step 606 indicates that the packet filtering criteria based on the selected previous CTI should be updated based on the new CTI (e.g., whether one or more values ​​of the NTI should be changed, whether one or more NTIs should be added, whether one or more NTIs are no longer applicable). If not, system 130 may perform step 628 ( Figure 6C ; indicated by connector BB) (described below). If yes, system 130 may perform step 615 ( Figure 6B ; indicated by connector CC). In step 615, system 130 may determine whether all information required to apply the updated criteria is already included in the composite log data generated in step 608. For example, system 130 may determine whether non-null values ​​exist for all corresponding fields of the packet log in the composite log data for all NTIs for which values ​​provided by the new CTI exist. If so, system 130 may perform step 620 (described below). If not (e.g., if there is at least one new or changed NTI that cannot be evaluated based on the information in the composite log data generated in step 608), system 130 may perform step 616. Examples of scenarios corresponding to the "yes" branch from step 615 are described above in conjunction with Figure 5A An example of a scenario corresponding to the "No" branch from step 615 is described above in conjunction with Figure 5B , Figure 5C and Figure 5D Give a description.

[0082] In step 616, the system 130 may determine whether any captured packets were retrieved in step 608. If not (e.g., if the packet filtering rules based on the selected previous CTI do not indicate that the PSG 110 captured packets), the system 130 may perform step 620. If yes, the system 130 may perform step 617. In step 617, the system 130 may examine the retrieved captured packets for values ​​of parameter(s) / characteristic(s) corresponding to the new or changed NTIs associated with the new CTI. In step 618, the system 130 may determine whether any values ​​of parameter(s) / characteristic(s) corresponding to those new or changed NTIs may be extracted from the retrieved captured packets. If not (e.g., if all new or changed NTIs are associated with portions of the retrieved captured packets that are inaccessible due to encryption), the system 130 may perform step 620 (described below). If yes (e.g., if at least one value of at least one parameter / characteristic corresponding to the new or changed NTI is available from the retrieved captured packet), the system 130 may perform step 619. In step 619, the system 130 may extract the value(s) of the parameter(s) / characteristic(s) corresponding to the new and / or changed NTI from the captured packet(s), and may add those value(s) to the composite log data generated in step 608 (e.g., to generate a log file such as FIG. 5A to FIG. 5D Based on step 619 , or based on a “yes” determination in step 615 or a “no” determination in one of steps 616 or 618 , system 130 may perform step 620 .

[0083] In step 620, the system 130 may apply the updated criteria based on the new CTI (e.g., information for matching new and / or changed NTIs) to the previously collected packet log(s) (e.g., the packet log(s) retrieved in step 608) and captured packet(s) (e.g., information from the captured packets retrieved in step 608 and added to the composite log data) by applying the updated criteria based on the new CTI (e.g., information for matching new and / or changed NTIs) to the composite log data. As part of step 620, the system 130 may determine packet communications in the composite log data that match (or do not match) the updated criteria (e.g., matching or not matching new and / or changed NTIs) (e.g., as combined with FIG. 5A to FIG. 5D). If any of the updated criteria correspond to packet log fields for which a value could not be extracted from a captured packet (e.g., if there is a "no" determination in step 618), or if there is no captured packet (e.g., if there is a "no" determination in step 616), then the system 130 may determine that the updated criteria are inconclusive for those packet logs (and corresponding packets) and / or may mark those packet logs accordingly. For example, such marking may indicate that the system 130 has not yet been able to confirm that those logs (and corresponding packets) are associated with a new CTI network threat, or has determined that those logs are not associated with a new CTI network threat.

[0084] In step 621, the system 130 may cause packet logs stored in the database 131 to be updated based on the matches and / or mismatches determined in step 620. Such updates may, for example, include setting flags and / or otherwise marking portions of the packet logs that are determined to be relevant to the new CTI network threat, determined to be irrelevant to the new CTI network threat, and / or for which the analysis was inconclusive, updating the stored packet logs to include additional information added from the captured packets, etc. As part of step 621, the system 130 may also or alternatively cause flags and / or markers to be set for the captured packets based on the matches and / or mismatches determined in step 620. Those flags / markers may indicate captured packets that are determined to be relevant to the new CTI network threat, captured packets that are determined to be irrelevant to the new CTI network threat, and / or captured packets for which the analysis in step 620 was inconclusive.

[0085] In step 622 ( Figure 6C; indicated by connector DD), the system 130 may determine whether the new CTI indicates (and / or whether data generated based on the new CTI indicates) that the threat level associated with the new CTI network threat has increased. If not, the system 130 may perform step 634 (described below). If yes, the system 130 may perform step 623. In step 623, the system 130 may determine whether there are additional parameter(s) / (s) characteristics whose values ​​should be extracted from the captured packets (if possible) and are not already included in the composite log data. For example, if the threat level associated with the network threat reaches a threshold level, it may be appropriate to analyze a set of predetermined parameter(s) / (s) characteristics, regardless of whether any of those parameter(s) / (s) characteristics are associated with a new or changed NTI in the new CTI. The set of predetermined parameter(s) / (s) characteristics may include any one or more of the parameter(s) / (s) characteristics described herein. There may be multiple sets of predetermined parameter(s) / (s) characteristics corresponding to multiple thresholds. For example, a first set of predetermined parameter(s) / characteristic(s) may correspond to a first threshold and a first threat level, a second set of predetermined parameter(s) / characteristic(s) may include all parameter(s) / characteristic(s) of the first set plus additional parameter(s) / characteristic(s) and correspond to a second threshold (higher than the first threshold) and a second threat level (higher than the first threat level), a third set of predetermined parameter(s) / characteristic(s) may include all parameter(s) / characteristic(s) of the second set plus additional parameter(s) / characteristic(s) and correspond to a third threshold (higher than the second threshold) and a third threat level (higher than the second threat level), and so on.

[0086] If the system 130 determines in step 623 that there are no additional parameter(s) / characteristic(s) that should be extracted from the captured packet, the system 130 may perform step 634. If the system 130 determines in step 623 that there are additional threat indicator values ​​that have not been included in the composite log data and therefore should be extracted from the captured packet, the system may perform step 624. In step 624, and similar to step 617, the system 130 may examine the values ​​of the additional parameter(s) / characteristic(s) in the retrieved captured packet. In step 625, and similar to step 618, the system 130 may determine whether values ​​for any of those parameter(s) / characteristic(s) may be extracted from the captured packet. If not (e.g., if all of the additional parameter(s) / characteristic(s) are associated with portions of the captured packet that are inaccessible due to encryption), the system may perform step 634. If yes (e.g., if at least one of the additional parameter(s) / characteristic(s) is associated with the accessible one or more portions of the one or more captured packets), the system 130 may perform step 626. In step 626, and similar to step 619, the system 130 may extract value(s) from the captured packet(s) corresponding to the additional parameter(s) / characteristic(s), and may add those value(s) to the composite log data.

[0087] like Fig. 6A As shown, if the system 130 determines in step 614 that there is no updated standard based on the new CTI, the system 130 may perform step 628, which may be similar to step 622. If the determination in step 628 is no, the system 130 may perform step 634. If the determination in step 628 is yes, the system 130 may perform step 629, which may be similar to step 623. If the determination in step 629 is no, the system 130 may perform step 634. If the determination in step 629 is yes, the system 130 may perform step 630, which may be similar to step 616. If the determination in step 630 is no, the system 130 may perform step 634. If the determination in step 630 is yes, the system 130 may perform step 631, which may be similar to step 617 and / or step 624. Based on step 631, the system 130 may perform step 632, which may be similar to steps 618 and 625. If the determination in step 632 is no, the system 130 may perform step 634. If the determination in step 632 is yes, the system 130 may perform step 633, which may be similar to step 626 and / or step 619.

[0088] Based on step 626 or step 633, or based on a "no" determination in any of steps 622, 623, 625, 628, 629, 630, or 632, system 130 may perform step 634. In step 634, system 130 may further analyze the composite log data. In the analysis of step 634, and as combined with Figure 3B As described in event 347 of , system 130 can search for commonalities in the composite log data. For example, the fields of the additional columns of the composite log data may have been populated (e.g., in step 619 and / or in step 626, or in step 633) with values ​​based on inspection of captured packets, and some of those additional columns may not correspond to NTIs indicated by the selected previous CTI or by the new CTI. If a common value appears in a large portion of the fields of one of those additional columns, the common value can be a new NTI that can be used to improve filtering rules associated with the new CTI network threat. As another example, time values ​​can be analyzed. If at least some of those time values ​​are confined to a recurring time window, the time window can be used as a new NTI or for narrowing the time range of an existing NTI.

[0089] In step 635, system 130 may update database 131 based on step 634. In step 636 ( Fig.6D ; indicated by connector EE), the system 130 may determine additional portions of the stored packet logs and / or additional captured packets that may not have been previously associated with the new CTI network threat. In step 637, the system 130 may analyze those additional stored packet logs and / or additional captured packets. For example, and also in conjunction with Figure 3B As described in event 347 of , additional stored packet log(s) and / or additional captured packet log(s) may be searched for additional packet communications to or from hosts associated with packet communications identified (e.g., based on new CTI) as corresponding to a new CTI network threat and / or packet communications within a time range of those identified communications. As another example, and also as described in conjunction with Figure 3B As described by event 347, additional stored packet log(s) and / or additional captured packets may be searched for additional data indicating that the confirmed communication also matches other packet filtering rules associated with network threats that were previously considered not to be related to the new CTI network threat.

[0090] In step 643, the system 130 may update the database 131 based on step 637. In step 644, the system 130 may send the analysis results of one or more steps 620, 634, and / or 637 and / or a pointer to the analysis results of one or more of steps 621, 635, and / or 643 to the rule module 203 for updating / modifying one or more filter rules associated with the new CTI network threat and / or for generating or modifying one or more additional filter rules. In step 645, the system 130 may generate and / or cause one or more outputs based on the analysis of one or more steps 620, 634, and / or 637. Event 349 and / or one or more of events 351 to 354 may include an example of step 645.

[0091] As can be appreciated from the above description, new CTI for a network threat can be used to obtain updated criteria (e.g., to match a refined set of NTIs), which can be used to confirm that some packet communications filtered based on earlier CTIs are associated with (or more likely to be associated with) the network threat. At the same time, such updated criteria can also be used to determine that other packet communications filtered based on the earlier CTI are not associated with (or less likely to be associated with) the network threat. As also described above, the new CTI can also or alternatively be used to determine additional values ​​of (multiple) parameters / (multiple) characteristics associated with the network threat, which can also be used (e.g., as new NTIs) to determine packet communications that are more likely to be associated with the network threat. In a similar manner, the refined and / or additional NTIs learned from the new CTI can also or alternatively be applied to data from external devices other than PSG 110 (e.g., from devices not managed and / or controlled by system 130).

[0092] For example, and if Figure 1As shown, communications between host 152 of third network 151 and hosts external to third network 151 may pass through firewall 153 without passing through PSG 110. Similarly, communications between host 156 of third network 155 and hosts external to third network 155 may pass through ISP server 157 without passing through PSG 110. Firewall 153 and / or ISP server 157 may be configured to store certain basic data (e.g., the value of a 5-tuple or portions thereof, directionality, timing) for all packets communicated via those devices. The amount of such stored data may be considerable (e.g., much greater than the amount of data associated with filtering performed by PSG 110), and much of the stored data may relate to communications that are not related to any network threat. By applying criteria based on refined and / or additional NTI obtained from new CTI (and / or by applying new CTI to packet logs of PSG 110 and / or packet capture based on earlier CTI) to stored data of packet traffic passing through external devices such as firewall 153 and / or ISP server 157, the data can be classified based on communications that are more likely to be associated with a network threat and / or based on communications that are less likely to be associated with a network threat. External device data determined to be more likely to be associated with a network threat can be retained (and / or retained for a longer period of time), while external device data determined to be less likely to be associated with a network threat can be discarded (and / or retained for a shorter period of time), thereby reducing data storage requirements. In addition, applying criteria based on refined and / or additional NTI obtained from new CTI (and / or by applying updated CTI to packet logs of PSG 110 and / or packet capture based on earlier CTI) to external device data can allow for a determination of whether a host and / or network associated with the external device has been affected by a network threat.

[0093] In step 646, the system 130 may determine whether to analyze the external device data based on the refined and / or additional NTI obtained from (or based on) the new CTI. Those refined and / or additional NTIs may include NTIs from the selected previous CTI that are not changed by the new CTI, new and / or changed NTIs from the new CTI, and / or additional NTIs determined in steps 634 and / or 637. If no, the system 130 may perform step 651, which may be similar to step 610. If yes, the system 130 may obtain data from the external device in step 647. In step 648, the system 130 may determine a first set of packet communications identified by the external device data and matching the criteria based on the refined and / or additional NTI. At the same time, the system 130 may determine a second set of packet communications identified by the external device data and not matching the criteria based on the refined and / or additional NTI. In step 649, the system 130 may mark the first set of packet communications as more likely to be associated with a new CTI network threat, and / or may mark the second set of packet communications as less likely to be associated with a new CTI network threat, and may forward data indicating the marked and unmarked communications to one or more other computing devices for action (e.g., setting a longer retention time for data associated with the first set of packet communications and a shorter retention time for data associated with the second set of packet communications). After step 649, the system 130 may perform step 651.

[0094] If through Fig. 6A , Figure 6B , Figure 6C and Fig.6D It will be appreciated that the example method may be iterative. For example, after updating and / or refining packet filter output data (e.g., (multiple) packet logs and (multiple) captured packets) based on a first CTI of a network threat based on a second and updated CTI of the network threat, and after updating and / or generating (multiple) filtering rules for the network threat based on the second CTI, a third and further updated CTI of the network threat may be received. The third CTI may be applied to the packet filter output data based on the updated filtering rules, and / or to the earlier packet filter output data updated and / or refined based on the second CTI. This may result in further refined and / or further updated packet filter output data, output based on the further refined and / or further updated packet filter output data, new and / or modified filtering rules based on the further refined and / or further updated packet filter output data, etc. The process may then be repeated for any number of additional updates to the CTI of the network threat.

[0095] Fig. 6EAn example of steps that may be performed as part of step 602 is shown. In step 602.1, the system 130 may determine whether the new CTI includes a threat identifier associated with the new CTI network threat (e.g., assigned by a provider of the CTI). If not, the system may proceed to step 602.4 (described below). If yes, the system 130 may perform step 602.2. In step 602.2, the system 130 may determine whether the threat identifier included by the new CTI leads to (e.g., is the same as, has been mapped to, or otherwise points to) a threat identifier associated with one or more previous CTI instances. If yes, the system 130 may mark those one or more previous CTI instances in step 602.3 (e.g., for inclusion in a queue of previous CTI instances from which the previous CTI is selected in step 605). If no, the system 130 may perform step 602.4.

[0096] In step 602.4 (which may also be performed after performing step 602.3), the system 130 may determine whether there is a threshold amount of overlap between the NTI indicated by the new CTI and the NTI indicated by one or more previous CTI instances. The system 130 may determine an overlap if, for example, the NTI indicated by the new CTI is the same value as that indicated by the previous CTI instance or is within a range specified by the previous CTI instance. The threshold amount of overlap may be quantitative. For example, the threshold may require an overlap with respect to at least a specified amount of NTI and / or with respect to a specified percentage of the NTI indicated by the new CTI. Similarly or alternatively, the overlap may be qualitative. For example, the threshold may require an overlap of values ​​of certain defined NTIs (e.g., source address and / or destination address). If the system 130 determines in step 602.4 that there is a threshold amount of overlap between the NTI of the new CTI and the NTI of one or more previous CTI instances, the system 130 may mark those one or more previous CTI instances in step 602.5 (e.g., for inclusion in a queue of previous CTI instances from which the previous CTI is selected in step 605). If the system 130 determines in step 602.4 that there is not a threshold amount of overlap between the NTI of the new CTI and the NTI of one or more previous CTI instances, the system 130 may perform step 602.6.

[0097] In step 602.6 (which may also be performed after performing step 602.5), the system 130 may determine whether there is a term match between one or more fields of the new CTI (e.g., fields that provide a name or description of malware or other description of a network threat) and one or more similar fields of one or more previous CTI instances. If the system 130 determines in step 602.6 that there is a term match between the terms of the new CTI and the terms of the one or more previous CTI instances, the system 130 may mark those one or more previous CTI instances in step 602.7 (e.g., for inclusion in a queue of previous CTI instances from which the previous CTI is selected in step 605). If the system 130 determines in step 602.6 that there is no term match between the terms of the new CTI and the terms of the one or more previous CTI instances, the system 130 may perform step 602.8.

[0098] In step 602.8 (which may also be performed after performing step 602.7), the system 130 may determine whether there are one or more other inputs indicating that the new CTI and one or more previous CTI instances may be related to the same network threat. The input(s) of step 602.8 may be generated by the activities of an operator (e.g., a network analyst) and / or by one or more automated processes (e.g., caused by executing instructions of one or more modules of the system 130). The input(s) of step 602.8 may, for example, include one or more inputs indicating the relationship of the network threats determined by the analysis as described below. If the system 130 determines in step 602.8 that there are one or more other inputs indicating that the new CTI instance and the previous CTI instance may be related to the same network threat, the system 130 may mark those one or more previous CTI instances in step 602.9 (e.g., for inclusion in a queue of previous CTI instances from which the previous CTI is selected in step 605). If the system 130 determines in step 602.8 that there are not one or more other inputs indicating that the new CTI and one or more previous CTI instances may be related to the same cyber threat, the system 130 may perform step 602.10.

[0099] In step 602.10 (which may also be performed after performing step 602.9), the system determines whether at least one previous CTI instance was marked in any of steps 602.3, 602.5, 602.7, or 602.9. If not, the system 130 may proceed to step 604. If yes, the system 130 may proceed to step 605.

[0100] As indicated in the various examples provided above, methods and / or systems according to the present disclosure can be used in various ways to determine whether a subsequent CTI is related to an earlier CTI, determine whether a subsequent CTI updates an earlier CTI, perform one or more analyses based on the updated CTI, and / or take one or more actions based on one or more such analyses. The present disclosure is not limited to those examples. The following is another non-limiting example of how methods and / or systems according to the present disclosure can be used to make such determinations, perform such analyses, and / or take actions based on such analyses.

[0101] (1) Provider P1 (e.g., Provider 135) provides CTI ("CTI1") that notifies system 130 of a threat ("Threat 1"), namely, that a nation-state actor in country C1 is launching a cyberattack against critical infrastructure industries in a particular region of the world, including country C1. The criteria for the filtering rule includes information for matching one or more NTIs based on CTI 1, including all IP address ranges associated with country C1. PSG 110 filters packets based on the rule and forwards logs and captured packets related to traffic to / from country C1 to system 130. System 130 indexes those logs and captured packets and associates them with Threat 1.

[0102] (2) Provider P2 (e.g., another provider 135) provides CTI ("CTI 2") that notifies system 130 of another threat ("Threat 2"), namely, that a global distributed denial of service (DDOS) attack is being actively conducted against a group of ISPs, which may be politically motivated to retaliate against customers of one of the ISPs. The criteria for the filtering rule includes information for matching one or more NTIs based on CTI 2, including the names and server IP addresses of those ISPs (including ISP1 and ISP2), and the source IP address of the attack. PSG 110 inspects packets based on the rule and forwards logs and captured packets to system 130. System 130 indexes those logs and captured packets and associates them with Threat 2.

[0103] (3) Provider P1 provides additional CTI (“CTI 3”) that informs system 130 that additional context has been added about Threat 1, that the targeted critical infrastructure industries may be dispersed across multiple countries including countries C1 and C2, and that ISPs serving countries C1 and C2 (including ISP3 and ISP4) may be conduits for exfiltration attempts. System 130 analyzes the existing context of Threat 1 from the logs and captured packets associated with Threat 1, as mentioned in paragraph (1) above. Based on this analysis, system 130 retroactively indexes those logs and captured packets and associates them with the context of ISP3 and ISP4, and also directs (e.g., by sending new and / or updated filtering rules) PSG 110 to filter packets based on the new / updated filtering rules and collect logs and / or captured packets of traffic to or from country C2 and forwards these logs and / or captured packets to system 130. System 130 receives those logs and captured packets of traffic to or from Nation C2 and associates those logs and captured packets with Threat 1 .

[0104] (4) Provider P3 (e.g., another provider 135) provides CTI ("CTI4") that informs system 130 that a threat ("Threat 3") is an active ransomware campaign being executed via a targeted phishing attack delivered by a compromised website hosted at ISP4. The criteria for the filtering rule includes information for matching one or more NTIs based on CTI 4, including phishing URLs, domains, and IP addresses hosted at ISP4. Based on the rule, PSG 110 begins filtering packets and collecting information about Threat 3, and forwards logs and captured packets related to Threat 3 to system 130. System 130 determines that ISP4 is located in country C1, which is common for Threat 1, and further analyzes logs and packet captures associated with Threat 1 (e.g., the logs and captured packets described in paragraphs (1) and (3)) to extract domains and URLs, and compares those extracted domains and URLs to the NTI of Threat 3, but finds no match and that Threat 1 and Threat 3 appear unrelated.

[0105] (5) Provider P2 provides additional CTI ("CTI 5") that informs system 130 that Threat 2 may be a diversionary attempt by an experienced actor to cover up a more serious attack, and that the DDOS attack is focused on overloading services of ISP 1 in country C1. Based on this additional information, system 130 determines commonalities between Threat 2 and Threat 1 and Threat 3, all of which are associated with country C1. System 130 further analyzes all logs and captured packets associated with Threat 1, Threat 2, and Threat 3 to begin extracting additional information to aid in exfiltration detection.

[0106] (6) Provider P3 provides additional CTI ("CTI 6") that informs system 130 that Threat 3 has a confirmed and validated NTI that is indicative of a Ryuk malware infection when the data transmission in the packet payload matches a specific unique value. System 130 further analyzes the logs and captured packets associated with Threat 1, Threat 2, and Threat 3 for this NTI, and finds a match in the captured packets associated with Threat 1.

[0107] (7) Based on the analysis of paragraph (6) and the preceding paragraphs, system 130 determines that Threat 1, Threat 2, and Threat 3 are related, and associates those threats with a single complex campaign executed in a multi-stage manner. System 130 determines that the actual Ryuk malware penetration occurred when Threat 1 was known, but before Threat 2 and Threat 3 were known. By performing retroactive analysis using updated intelligence, system 130 detects the threat at a later time (associated with the events described in paragraph (6)), which is the earliest time that the identifiable NTI became known.

[0108] The present disclosure encompasses many configurations of the devices and systems described herein, and the operations described herein may be distributed among devices and systems in many ways, and / or may be distributed among other devices. One or more steps, operations, and / or functions described herein may be modified and / or performed in an order other than that explicitly described herein, and / or may be omitted, and / or other steps, operations, and / or functions may be added.

[0109] System 130 can be directly connected to one or more PSGs 110 to proactively direct PSGs 110 to log and / or capture packets via filtering rules and based on threats as information about them is received. PSGs 110 can send logs and / or captured packets to system 130 in real time, near real time, or delayed.

[0110] Likewise or alternatively, the system 130 may be indirectly connected to one or more PSGs 110. The indirect connection may be, for example, via one or more computing devices that act as aggregators of logs and / or packet captures. The aggregator may include one or more computing devices configured to serve as a management platform for the PSG 110. Likewise or alternatively, the aggregator may include one or more computing devices configured to perform security information and event management (SIEM) system functions, wherein the PSG 110 sends logs and / or captured packets to the SIEM system, and the SIEM system sends logs and / or captured packets to the system 130.

[0111] Similarly or alternatively, system 130 may be configured to query and / or retrieve (e.g., rather than always passively receiving) logs and / or captured packets from an external log and / or captured packet storage. Such a query may be based on narrowed query parameters based on evolving CTI. For example, an entity associated with a customer of network 105 may have a 365-day rolling storage of captured packets and / or logs for all traffic, and system 130 may only have captured packets and / or logs for at least some minimal threat context (e.g., based on previously received CTI). System 130 may query the external storage to selectively retrieve additional captured packets and / or logs needed to further apply new CTI.

[0112] Similarly or alternatively, the system 130 can act as a log and / or captured packet filter between the PSG 110 (and / or other non-PSG sources of logs and / or packet capture) and the SIEM system or external storage device. The system 130 can be configured to forward all logs and / or captured packets associated with known threats, and save all logs and / or captured packets whose association with the threat may be unknown. When new CTI is received and historical logs and / or captured packets are further analyzed, the logs and / or captured packets that are retroactively found to be associated with the threat can be forwarded to the SIEM system or external storage device. This deployment model can allow the SIEM system and / or external storage device to save information that is known to be important, and avoid saving information that is known to be unimportant before the system 130 determines the importance.

[0113] Similarly or alternatively, the system 130 can be configured to act as a retention controller for logs and / or captured packets. The system 130 can delete logs and / or captured packets stored by another system (e.g., a SIEM system, an external storage device) more quickly based on a determined lack of importance (e.g., based on an updated CTI, determining that the logs and / or captured packets are irrelevant and / or less likely to be relevant to a network threat, determining that the threat level is reduced, etc.), or store them for a longer period of time based on the determined importance (e.g., based on an updated CTI, determining that the logs and / or captured packets are relevant and / or more likely to be relevant to a network threat, determining that the threat level is increased, etc.). The system 130 can be configured to extend the data retention period applicable to the data as the associated risk (e.g., corresponding to the threat associated with the data and / or the risk that may be associated with the above-mentioned importance) increases. As the risk increases, it is more likely that the data will be needed later. The system 130 can be configured to reduce the data retention period applicable to the data as the associated risk decreases, because reducing the risk can correspond to a lower probability of demand for the data.

[0114] Fig. 6F An example is shown in which the system 130 may act as a retention controller to perform steps as part of the operation. Fig. 6F The step can be used as step 645 ( Fig.6D ), as part of another step, and or as part of FIG. 6A to FIG. 6E The system 130 may perform additional steps separate from the steps already shown in FIG. 644 ( Fig.6D ) and / or after other portions of step 645 (e.g., steps associated with causing other types of outputs and / or actions based on the analysis of one or more of steps 620, 634, and / or step 637). In step 645.1, system 130 may determine, based on the analysis of one or more of steps 620, 634, and / or step 637, whether there has been any increase in the importance of one or more logs and / or one or more captured packets. For example, the importance associated with a particular log or captured packet may increase for one threat, but may decrease for another threat. The increase in importance may include a determination that the log(s) and / or captured packet(s) are associated with a threat, a confirmation that the log(s) and / or captured packet(s) are associated with a threat, a determination that the threat level has increased, and / or other determinations that the importance of the log(s) and / or captured packet(s) has increased. If there is any increase in importance (even if there is also a decrease in importance associated with a different threat), the system 130 may increase the retention period associated with the log(s) and / or captured packet(s) in step 645.2. Step 645.2 may, for example, include sending a message indicating the increase in retention period, updating a data field and / or a flag to indicate the increase in retention period, etc. After step 645.2, the system 130 may perform step 646 ( Fig.6D ) and / or other portions of step 645 (e.g., in conjunction with causing other types of outputs and / or actions based on analysis of one or more of steps 620, 634, and / or step 637). If the importance has not increased, system 130 may perform step 645.3.

[0115] In step 645.3, the system 130 may determine whether the importance of the log(s) and / or one or more captured packets has been reduced based on the analysis of one or more of steps 620, 634, and / or step 637. The reduction in importance may include a determination that the log(s) and / or captured packets are not associated with a threat, a confirmation that the log(s) and / or captured packets are not associated with a threat, a determination that the threat level has been reduced, and / or other determinations that the importance of the log(s) and / or captured packets has been reduced. If the importance has not been reduced, the system 130 may perform step 646 and / or other portions of step 645. If the importance has been reduced, the system 130 may perform step 645.4. In step 645.4, the system 130 may determine whether the retention period of the log(s) and / or captured packets was previously increased (e.g., previously increased relative to the default retention period based on an earlier importance determination). If not, the system 130 may perform step 646 and / or other portions of step 645. If the retention period was previously increased, the system 130 may decrease the retention period associated with the log(s) and / or captured packet(s) in step 645.5. Step 645.5 may, for example, include sending a message indicating the retention period decrease, updating a data field and / or a flag to indicate the retention period decrease, etc. After step 645.5, the system 130 may perform step 646 and / or other portions of step 645.

[0116] As explained above, the system 130 may cause various outputs and / or perform other actions based on determinations resulting from applying new CTI-based criteria to logs and / or captured packets associated with earlier CTIs (e.g., based on analysis of one or more of steps 620, 634, and / or 637). Such outputs and / or actions may also or alternatively include automatically sending alerts (and / or log(s) and / or captured packets) to a SIEM system, an orchestration platform (e.g., a security orchestration, automation, and response (SOAR) platform), and / or other external systems. If the security system 130 directly or indirectly controls PSGs 110 and / or devices, it may send instructions (e.g., new and / or modified rules) to those PSGs 110 and / or other devices to expand or reduce logging and / or packet capture (e.g., as described in the examples of paragraphs (1) to (7) above). Similarly or alternatively, the system 130 may modify (directly or via an intermediate system) settings (e.g., in the PSG 110) that control whether packets are captured. For example, the PSG 110 may be configured to not capture packets for blocked packet communications by default. Based on the updated CTI, the system 130 may determine that packets for subsequently blocked communications should be captured. Such captured packets may, for example, be used by the system 130 for domain extraction (e.g., on non-IP based blocks) and allow for the capture of packets for lateral traffic that matches the NTI and is seen only on spans and / or taps of the PSG 110.

[0117] Figure 7 is a diagram illustrating an example environment 700 for detecting and / or analyzing network threats based on updated network threat intelligence, and will be used to describe several additional examples of filtering, aggregation, and / or retention controls. The example environment 700 may be similar to Figure 1 100. However, to simplify the following explanation of various further examples, system 130 has been divided into a network threat analysis system 730A (system 730A) and a network threat analysis system 730B (system 730B), wherein systems 730A and 730B have respective corresponding storage databases 731A and 731B. Systems 730A and 730B and databases 731A and 731B can communicate with each other via network 701 and with other computing devices (e.g., PSG 110, firewall 153, ISP 157, SIEM system 702, CTIP 135) via network 125. Similarly or alternatively, one or more of systems 730A and 730B or databases 731A and 731B can communicate with each other via network 125.

[0118] System 730A and database 731A may include one or more computing devices (e.g., in conjunction with Figure 2The system 730B and database 731B may include one or more additional computing devices (e.g., in combination with Figure 2 130). Similarly or alternatively, system 730A and database 731A may be configured to perform the operations described herein in conjunction with system 130. Systems 730A and 730B and databases 731A and 731B need not be implemented using separate computing devices (or sets of computing devices). For example, the operations described below in conjunction with system 730A may also or alternatively be performed by a computing device based on the execution of instructions contained in one or more modules stored in a memory of the computing device, and the operations described below in conjunction with system 730B (and / or the operations described herein in conjunction with system 130) may be performed by the same computing device based on the execution of instructions contained in one or more additional modules stored in a memory of the computing device. Similarly, the storage operations described below in conjunction with database 731A may be allocated to one or more first portions of the memory of the database / archive, and the storage operations described below in conjunction with database 731B (and / or the storage operations described herein in conjunction with database 131) may be allocated to one or more second portions of the memory of the same database / archive. In practice, the operations of systems 130, 730A, and 730B and the operations of databases 131, 731A, and 731B may be combined in, or distributed among, any number of separate computing devices.

[0119] Figure 7 Also shown is a SIEM system 702 and a corresponding data archive database 703 used by the SIEM system 702. The SIEM system 702 (with the archive 703) can serve one or more networks, such as network 151 and / or network 155. For example, and as described below, the SIEM system 702 and / or the archive 703 can be configured to store captured packets and / or other data output by firewall 153, ISP 157's servers, agents, and / or any other type of computing device. The SIEM system 702 and the archive 703 can each include one or more computing devices configured to perform operations as described herein.

[0120] Fig. 8A and Figure 8B is a sequence diagram illustrating an example of events associated with filtering, aggregation, and / or retention control based on updated network threat intelligence. In particular, Fig. 8A and Figure 8BAn example of how system 730A may act to collect, filter, and forward (or discard if not forwarding) packets captured by PSG 110 is shown. System 730A may forward some of those captured packets to system 730B for additional processing (e.g., as described above in connection with system 130) if there are subsequent CTIs related to those packets. System 730A may discard other captured packets (e.g., without forwarding to system 730B or other computing devices) if there are no subsequent CTIs related to the other packets. Figure 8B yes Fig. 8A For the purpose of explanation, the Fig. 8A and Figure 8B The example events shown may be varied in number, order, and / or timing, additional events may occur, and / or may be omitted, repeated, or modified. Fig. 8A and Figure 8B One or more of the events shown in . Fig. 8A and Figure 8B Events such as those shown in FIG. 1 (or portions thereof) may be performed alone or in combination with one or more events such as those shown in one or more other figures and / or described herein.

[0121] In event 801, system 730B may receive CTI data 800.1 including data A (e.g., one or more NTIs) associated with a network threat or potential network threat. Based on data A, system 730B may generate one or more rules including filtering criteria based on data A (the criteria based on A, which may include any type of packet filtering criteria described above), one or more operators configured to cause packets matching the criteria based on A to be dropped or allowed to be transmitted, and one or more operators for generating logs for such matching packets (e.g., as combined with Figure 4As used herein, an A-based criterion (where "A" is A or some other letter) may be a single criterion (e.g., a specific value for a single NTI) or may include multiple criteria (e.g., one or more possible values ​​for each of multiple NTIs). One or more rules having an A-based criterion may be forwarded to PSG 110 in events 802 and 803. In event 806, system 730B may receive CTI data 800.2 including data B (e.g., one or more NTIs) associated with a network threat or potential network threat. Based on data B, system 730B may generate one or more rules including a B-based criterion (which may be based on data B and may include any type of packet filtering criteria described above), one or more operators configured to cause packets matching the B-based criterion to be dropped or allowed to be transmitted, and instructions for generating logs for such matching packets. One or more rules having an A-based criterion may be forwarded to PSG 110 in events 807 and 808. CTI data 800.1 and 800.2 and in combination with Fig. 8A and Figure 8B The other CTI data described may be received from CTIP 135, from an internal source (e.g., one or more analysis programs executed by system 730B), and / or from another source.

[0122] In event 811, system 730B may receive CTI data 800.3 including data C (e.g., one or more NTIs). Data C may not include sufficient information to determine and it may not be known whether data C is related to a network threat or a potential network threat. Similarly or alternatively, other information may indicate that data C may not be important. For example, data C may have been received from a source known to provide data of questionable value. As another example, data C may have been identified as being related to extensive efforts to collect information that may be associated with a possible network threat (e.g., collecting data of all packet traffic during a wide range of time around a possible event), and there may not yet be sufficient reason to believe that data C is actually related to a possible network threat. Because there may not yet be information indicating whether data C is important (or will be important), system 730B may determine that analyzing logs of packets that match C-based criteria is currently unlikely to be useful, and / or long-term storage of such logs or packets that match C-based criteria is not currently warranted. However, later information may indicate that data C is important, and to allow time for development and / or receipt of such later information, it may be beneficial to temporarily store packages matching the C-based criteria.

[0123] Thus, in event 812, system 730B may indicate to system 730A that data traffic through PSG 110 should be monitored for packets that match C-based criteria (which may be based on data C and may include any of the types of packet filtering criteria described above), that copies of such packets should be stored for at least a predetermined amount of time (e.g., 30 days, 60 days, 90 days, etc.), and that logs of such packets should be generated with at least some minimal level of detail. For example, system 730B may indicate that PSG 110 should generate a log for packets that match C-based criteria, the log indicating a reference to the C-based criteria, a reference to the PSG that generated the log, the size of the packet that matched the C-based criteria, the time and / or date of the packet that matched the C-based criteria, and / or other basic information (e.g., a 5-tuple). Alternatively, and as described in more detail below, system 730B may indicate that PSG 110 should generate a log with more or less information for each packet that matches the C-based criteria, or that no log should be generated.

[0124] In event 813 , system 730A may update the instruction list to store the instructions received in event 812 . Fig. 9A At least a portion of the stored data of the system 730A and the database 731A after event 813 is shown. The instruction list includes an instruction 901 corresponding to the instruction received in event 812. The instruction 901 indicates that logs should be generated for packets matching the C-based criteria and that such packets should be stored, and further indicates a time associated with the instruction 901. If there are no additional instructions related to the C-based criteria within a predetermined amount of time after the time associated with the instruction 901, the system 730A can be configured to delete the instruction 901 and / or delete any packets and / or logs stored based on the instruction 901. Based on the instruction 901, the system 730A can generate one or more rules, the one or more rules including the C-based criteria, and instruct the PSG 110 to generate logs for packets matching the C-based criteria and capture the packets, and forward those captured packets and logs to the system 730A, but do not instruct the PSG 110 to forward such packets or logs to the system 730B (and / or instruct the PSG 110 not to forward such packets or logs to the system 730B). In events 815 and 816 , system 730A may forward those one or more rules to PSG 110 .

[0125] At event 819, system 730B may receive CTI data 800.4 including data D (e.g., one or more NTIs). Similar to data C, system 730B may determine that data D is not important (or is not yet known to be important), that analysis of logs of packets matching D-based criteria is not currently likely to be useful, and / or that long-term storage of such logs or packets matching D-based criteria is not warranted, but that temporary storage of packets matching D-based criteria may be beneficial. Therefore, system 730B may indicate to system 730A at event 820 (which may be similar to event 812) that data traffic through PSG 110 should be monitored for packets matching D-based criteria (which may be based on data D and may include any type of packet filtering criteria described above), that copies of such packets should be stored for a predetermined amount of time, and that logs of such packets should be generated in at least some minimal level of detail. At event 821 (which may be similar to event 813), system 730A may update a stored list of instructions to include the instructions received at event 820. Fig. 9B At least a portion of the stored data of the system 730A and the database 731A after the event 821 is shown. The stored data includes an instruction 902 for generating a log and storing the packets that match the D-based criteria, and a time associated with the instruction. If there are no additional instructions related to the D-based criteria within a predetermined amount of time after the time associated with the instruction 902, the system 730A can be configured to delete the instruction 902 and / or delete any packets stored based on the instruction 902. Based on the instruction 902, the system 730A can generate one or more rules, the one or more rules including the D-based criteria, and instruct the PSG 110 to generate a log and capture the packets that match the D-based criteria, and forward those captured packets and logs to the system 730A, but do not instruct the PSG 110 to forward such packets or logs to the system 730B (and / or instruct the PSG 110 not to forward such packets or logs to the system 730B). In events 823 and 824 , system 730A may forward those one or more rules to PSG 110 .

[0126] Based on the rules sent in events 802, 803, 807, and 808, PSG 110 may filter packet traffic for packets that match the A-based criteria and the B-based criteria, may log packets that match the A-based criteria and the B-based criteria, and may capture packets that match the B-based criteria. In events 827 and 828, PSG 110 may forward those logs and captured packets (pcaps) to system 730B. Events 827 and 828 may include forwarding those logs and captured packets directly to system 730B. Alternatively, those logs and captured packets may be sent to system 730A, which may forward those logs and packets to system 730B. In event 829, system 730B may store the logs and captured packets from events 827 and 828 in database 731B. Although in Fig. 8A Not shown, but system 730B may also perform additional processing on those logs and / or captured packets (eg, as described in conjunction with system 130).

[0127] Based on the rules sent in events 815, 816, 823, and 824, PSG 110 can filter data traffic for packets that match the C-based criteria or the D-based criteria, and can generate logs of packets that match the C-based criteria or the D-based criteria and capture the packets. In events 832 and 833, PSG 110 can forward those logs and captured packets (pcaps) to system 730A. In event 834, system 730A can store the logs and captured packets from events 832 and 833 in database 731A, and can index those stored logs and captured packets to the criteria, rules, and / or instructions associated with capturing and storing those packets. Fig. 9C At least a portion of the stored data of system 730A and database 731A is shown after event 834. Logs and captured packets (pcaps) are stored in database 731A. Fig. 9C As shown by the "C" and "D" labels in , each of the log and stored packets can be labeled and / or otherwise indicated (e.g., by being stored at a particular memory address) as corresponding to a C-based criterion (and / or corresponding to a rule sent in events 815 and 816 and / or corresponding to instruction 901) or corresponding to a D-based criterion (and / or corresponding to a rule sent in events 823 and 824 and / or corresponding to instruction 902). Fig. 9C As shown in entries "C" and "D" in the "Stored Pcaps" table in FIG. 7 , system 730A may store data indicating that packets indexed to standards based on C and D (and / or corresponding rules and / or instructions) are stored in database 731B. Fig. 9CAs shown by entries "C" and "D" in the "Stored Logs" table in , system 730A may store data indicating that logs of captured packets indexed to criteria based on C and D (and / or corresponding rules and / or instructions) are stored in database 731B. Entries in the stored Pcaps and stored logs tables may also include an indication of a memory address in database 731B at which the log or packet associated with the entry is stored.

[0128] In event 835, system 730A can determine whether any stored instructions indicate that any just stored logs and / or packets should be further processed based on the logs and / or packets stored in database 731A. In the example of event 835, there is no such instruction, and the stored logs or packets are not further processed. Events 832 to 835 can be repeated multiple times. In some repetitions of event 832 and / or event 833, only logs and copies of packets that match the C-based criteria can be received. In some repetitions of event 832 and / or event 833, only logs and copies of packets that match the D-based criteria can be received.

[0129] In Event 838 ( Figure 8B ), system 730B may receive CTI data 800.5 including data E (e.g., one or more NTIs). System 730B may determine (e.g., based on a combination of Fig. 6EOne or more determinations described or otherwise described herein) data E and data C may be related (or potentially related) to the same network threat, and if the captured packets that match the C-based criteria also match the E-based criteria, those packets may be important. Therefore, system 730B can send instructions to system 730A in event 839. In the instructions of event 839, system 730A can be instructed to check the captured packets that match the C-based criteria, and / or check the logs of captured packets that match the C-based criteria to obtain a match with the E-based criteria. In the case where there are one or more packets (or logs of such packets) that match the C-based criteria and also match the E-based criteria, system 730A can be further instructed to perform one or more additional actions associated with those logs and / or packets that are potentially related to the network threat. Such additional actions can include sending an alert to system 730B (and / or to another computing device) indicating the matching of logs and / or packets with the C-based and E-based criteria, indicating the relationship (or potential relationship) of those logs and / or packets to the network threat, and / or indicating one or more other actions, determinations, or other items. Similarly or alternatively, additional actions may include: identifying and / or collecting packets that match the C- and E-based criteria, identifying and / or collecting other packets (e.g., all packets that match the C-based criteria), identifying and / or collecting logs corresponding to packets that match the C- and E-based criteria (and / or logs corresponding to other packets); forwarding any such packets and / or logs so that any such packets and / or logs are stored; and / or other actions. Additional examples of additional actions are provided below. Although in Figure 8B Although not shown in the example of , the instructions of event 839 may also indicate that system 730A should monitor traffic through PSG 110 for packets matching E-based criteria, should store copies of such packets for a predetermined amount of time, and / or should initially generate logs of such packets. If system 730B already includes such additional instructions, system 730A may generate and send rules (e.g., similar to the rules of events 815, 816, 823, and 824) that cause PSG 110 to perform the following operations: monitor for packets matching E-based criteria, generate logs for such packets and capture such packets, and forward the logs and captured packets to system 730A, etc.

[0130] In event 840 , system 730A may update the instruction list to include the instruction received in event 839 . Fig.9DAt least a portion of the stored data of system 730A and database 731A after event 840 is shown. The data includes instruction 903 and an associated time of instruction 903. Instruction 903 may indicate that system 730A should check stored packets captured based on a match to C-based criteria for a match to E-based criteria. Instruction 903 may further indicate that if the stored packet matches both the C-based criteria and the E-based criteria, additional actions should be performed (e.g., an alert should be sent to system 730B, a copy of the packet matching both the C-based criteria and the E-based criteria (and corresponding logs) should be sent to system 730B). Instruction 903 may further include a time associated with instruction 903, and the time may be used to determine whether a predetermined time period has passed (e.g., to determine whether instruction 903 should be deleted if no relevant activity has occurred).

[0131] As part of event 840, system 730A can determine whether there is already a copy of a packet stored in database 731A that matches the C-based criteria. Based on the stored Pcaps and the C entries in the stored log table, system 730A can determine that there are stored packets that match the C-based criteria and corresponding logs for such packets. In event 843, system 730A can cause those stored packets and corresponding logs that match the C-based criteria to be retrieved from database 731A. In event 844, system 730A can update those retrieved logs based on those retrieved packets. For each of those retrieved packets, system 730A can update the corresponding log by reading data from the header fields of the packet, reading time data associated with the packet, and / or otherwise extracting information from the packet (or extracting information about the packet) and adding the information to the corresponding log. Each updated log can, for example, be a combination of Figures 4 to 5D As part of updating each of the corresponding logs, system 730A may extract all information (or substantially all, e.g., all information outside of the payload field) of the packet that is not encrypted or otherwise obfuscated, and may add that information to the corresponding log, or may extract less than substantially all of the extractable information (e.g., system 730A may extract only information for any additional fields required for checking against the E-based criteria). In event 845, system 730A may store the updated logs in database 731B, and may store data indexing those updated logs to the C-based criteria, rules for events 815 and 816, and / or instructions 901. Fig.9EAt least a portion of the stored data of system 730A and database 731A is shown after event 845. A log of updates ("C-updates") may be stored in database 731A and may be marked and / or otherwise indicated (e.g., by being stored at a particular memory address) as corresponding to a C-based standard (and / or corresponding to the rules sent in events 815 and 816 and / or corresponding to instruction 901). Fig.9E As shown in the entry "C-Update" in the "Stored Log" table in FIG. 7 , system 730A may store data indicating that a log of updates indexed to a C-based standard (and / or corresponding rules and / or instructions) is stored in database 731B. An entry in the stored log table may also include an indication of a memory address in database 731B where the log associated with the entry is stored.

[0132] At event 846, system 730A can determine whether any updated logs for packages that match the C-based criteria also match the E-based criteria. Figure 8B 845, but when storing and indexing updated logs in event 845, system 730A can retain a local copy of those updated logs. Alternatively, after storing and indexing updated logs in event 845, system 730A can take a copy of those updated logs as part of (or prior to) event 846. In event 846, system 730A can determine that a portion of the updated log matches the E-based criteria, and therefore determines that the packets corresponding to the portion of the updated log match both the C-based criteria and the E-based criteria. In event 847, system 730A can store data indexing the portion of the updated log and the corresponding stored packets to the C-based criteria and the E-based criteria (and / or instruction 903). Fig.9F At least a portion of the stored data of system 730A and database 731A following event 847 is shown. As indicated by the "C-Update; E" label, a portion of the log of updates to packets that match the C-based criteria have been marked and / or otherwise indicated as also matching the E-based criteria. The marking / indication may further include storing such logs separately (not shown). As indicated by the C, E labels on a portion of the stored packets, packets that match both the C-based criteria and the E-based criteria (and corresponding to logs that match both the C-based and E-based criteria) have also been marked and / or otherwise indicated. Fig.9FAs further shown in the entries "C, E" and "C-update; E" in the stored Pcaps and stored log tables, system 730A can store data indicating that packets indexed to standards based on C and E (and / or instruction 903) and logs of such packets are stored in database 731B. The stored Pcaps and entries in the stored log tables can also include indications of memory addresses at which packets and logs associated with the entries are stored in database 731B.

[0133] In event 848, system 730A may perform additional actions indicated by the instructions sent in event 839 and stored in event 840. For example, system 730A may send an alert to system 730B that captured packets that match the C-based criteria also match the E-based criteria. As part of event 848, system 730A may also send to system 730B copies of captured packets that match the C-based criteria and the E-based criteria, and / or copies of logs corresponding to those captured packets. Similarly or alternatively, system 730A may send all captured packets that match the C-based criteria and / or corresponding logs for all those captured packets. In event 849, system 730B may store the logs and captured packets from event 848 in database 731B. Although in event 848, system 730A may send to system 730B copies of captured packets that match the C-based criteria and the E-based criteria. Figure 8B Not shown, but system 730B may also perform additional processing on those logs and / or captured packets (eg, as described in conjunction with system 130).

[0134] System 730A may continue to receive and store captured packets that match C-based criteria and logs of such captured packets (from one or more of PSGs 110), and may perform operations with respect to such captured packets that are similar to those described above in connection with events 844 through 848 (e.g., updating logs, determining whether updated logs match E-based criteria, etc.). Similarly or alternatively, if system 730B sends additional instructions indicating (e.g., based on additional CTI) additional criteria for which packets matching C-based and / or E-based criteria should be checked, system 730A may continue to perform operations similar to those of events 844 through 848 using the additional criteria. System 730A may continue to perform operations based on instruction 903 and / or other instructions until otherwise directed by system 730B. For example, based on the alerts, logs, and / or captured packets received in step 848, system 730B may determine that PSG 110 should begin generating logs of and / or capturing packets that match C-based criteria and / or E-based criteria, and should send those logs and / or captured packets to system 730B. Based on this determination, system 730B may send rules to PSG 100 (e.g., in events similar to events 802, 803, 807, and 808), and may send one or more instructions to system 730A that cause system 730A to delete instructions 901 and / or 903 and / or to revoke the rules sent in events 815 and 816. Similarly or alternatively, system 730A may continue to store and process captured packets (and corresponding logs) that match C-based criteria until there is no related activity for a predetermined period of time (e.g., packets that match C-based criteria have no further matches to E-based criteria or other criteria, no new instructions related to comparing those packets to other criteria).

[0135] At event 851, system 730A may determine that there is no relevant activity associated with instruction 902 and / or stored packets matching the D-based criteria (or logs of those packets) within a predetermined time period after the time associated with instruction 902. The absence of relevant activity may include no additional instructions to take any action on captured packets matching the D-based criteria (e.g., no instructions to check such packets or corresponding logs for matches with other criteria), packets matching the D-based criteria not matching other criteria indicated by additional instructions (if such additional instructions are received), no access to stored packets matching the D-based criteria (or corresponding logs), etc. Based on the determination of no relevant activity, system 730A may delete instruction 902 at event 852, and may generate and send to PSG 110 (at events 853 and 854) instructions to revoke the rules sent at events 823 and 824. Revocation of the rules sent in events 823 and 824 may, for example, cause PSG 110 to stop capturing and sending packets matching the D-based criteria (and stop generating and sending logs of packets matching the D-based criteria) based on the rules sent in events 823 and 824, but may not affect other rules related to the D-based criteria. Also based on the determination that there is no relevant activity, system 730A may, in event 855, cause deletion of the stored packets (and corresponding logs) that match the D-based criteria and are indexed to instruction 902. Figure 9G At least a portion of the stored data of system 730A and database 731A after event 855 is shown.

[0136] For the purpose of explanation, the Fig. 8A and Figure 8B Examples are given above, and many variations are within the scope of the disclosure. Fig. 8A and Figure 8B Many of the events shown in can occur multiple times (e.g., events 827-829, events 832-835). As additional packets are received that match the C-based and / or D-based criteria, those additional packets can be indexed and stored. As additional logs of such packets are received, those additional logs can be indexed and stored (e.g., by appending later logs of packets that match the C-based criteria to earlier logs of packets that match the C-based criteria, and by appending later logs of packets that match the D-based criteria to earlier logs of packets that match the D-based criteria). Similar to Fig. 8A and Figure 8B The events shown in FIG. 1 but involving other CTI data and related instructions, rules, etc. can also occur multiple times and / or in conjunction with Fig. 8A and Figure 8B. The instructions that cause system 730A to compare previously stored captured packets with additional criteria may be different from instructions 903. For example, such instructions may cause stored packets to be compared with one or more additional criteria, but may not result in sending an alert or sending a log and / or captured packets if they match those one or more additional criteria. Instead, the instruction may simply indicate that packets that match one or more additional criteria should be noted down, and one or more additional instructions may cause those noted packets to be further compared with one or more sets of additional criteria, and / or may cause an alert (and / or log and / or captured packets) to be sent after determining that one or more stored packets have a matching set of criteria. One or more of those later instructions may include data received from system 730B that allows additional portions of the log to be updated. For example, system 730B may send instructions to system 730A that cause system 730A to check stored packets that match D-based criteria for matches with F-based criteria, but indicate that packets that match F-based criteria should be simply noted down (e.g., without sending an alert). System 730B may send subsequent instructions to system 730A that cause system 730A to check packets noted as matching D- and F-based criteria against G-based criteria and send an alert if one or more packets match criteria based on D, F, and G. When sending subsequent instructions related to G-based criteria, system 730B may include data that allows reading of the portion of the packet related to the G-based criteria (e.g., a deobfuscation algorithm).

[0137] As Fig. 8A and Figure 8BAs a further example of a variation of the example of, and as indicated above, system 730A may instruct PSG 110 (e.g., in steps such as events 815, 816, 823, and 824) to generate logs with more or less information for packets that match a standard (e.g., a standard based on C and D). Alternatively, system 730A may not instruct PSG 110 to generate logs for packets that match a standard (e.g., a standard based on C and D), and / or may instruct PSG 110 not to generate such logs. If PSG 110 does not generate such logs, event 844 may be modified to include generating logs from stored packets that match a standard (e.g., a standard based on C and D). If PSG 110 does generate logs for captured packets that match a standard (e.g., a standard based on C and D), those logs and captured packets do not need to be forwarded together. For example, PSG 110 may stream logs to system 730A and forward captured packets at predefined times, or vice versa. Event 844 may include updating and generating a log, and / or generating a log based on a previously generated log. For example, event 844 may include generating a flow log, the flow log including a log of multiple packets associated with the flow and / or otherwise associated, and for which the association may not be identifiable (and / or may not be easily identifiable) until the multiple packets are captured.

[0138] As Fig. 8A and Figure 8B As a further example of a variation of the example of, after determining (e.g., as in event 851 regarding D-based criteria) that there has been no relevant activity for a predetermined period of time, all data (e.g., stored packets and corresponding logs) need not be deleted. For example, event 855 may include deleting stored packets but retaining corresponding logs or data based on those logs. Similarly or alternatively, data indicating how many packets matched the D-based criteria during the period of time that rule 902 was effective may be retained.

[0139] Fig. 10A and Fig. 10B is a sequence diagram illustrating another example of events associated with filtering, aggregation, and / or retention control based on updated network threat intelligence. Fig. 10B yes Fig. 10A The continuation of. Fig. 10A and Fig. 10B An example similar to Fig. 8A and Figure 8B However, in Fig. 10A and Fig. 10B In the example of , system 730A can be used to collect, filter, and forward (or discard without forwarding) packets captured by network edge devices other than PSG 110. Fig. 10A and Fig. 10BIn the example of FIG. 1 , the edge device is the firewall 153 of the network 151. However, the following may be performed for other types of edge devices (e.g., a proxy, a server associated with the ISP 157, etc.). Fig. 10A and Fig. 10B For the purpose of explanation, the events shown in Fig. 10A and Fig. 10B The example events shown may be varied in number, order, and / or timing, additional events may occur, and / or may be omitted, repeated, or modified. Fig. 10A and Fig. 10B One or more of the events shown in . Fig. 10A and Fig. 10B Events such as those shown in FIG. 1 (or portions thereof) may be performed alone or in combination with one or more events such as those shown in one or more other figures and / or described herein.

[0140] In event 1001 (which may be similar to Fig. 8A In event 811), system 730B may receive CTI data 1000.1 including data C. Fig. 8A and Figure 8B In the example of , system 730B may determine that analysis of logs of packets matching C-based criteria is unlikely to be useful, and / or long-term storage of such logs or packets matching C-based criteria is not warranted. However, it may be determined later that data C is important, and therefore temporary storage of packets matching C-based criteria may be beneficial. In event 1002 (which may be similar to event 812), system 730B may indicate to system 730A that data traffic through firewall 153 should be monitored for packets matching C-based criteria, copies of such packets should be stored for at least a predetermined amount of time, and logs of such packets should be generated with at least some minimal level of detail. In event 1003 (which may be similar to event 813), system 730A may update an instruction list to store the instructions received in event 1002. Based on the instructions, system 730A may generate instructions that include C-based criteria and instruct firewall 153 to generate logs for and capture packets matching C-based criteria, and forward those captured packets and logs to system 730A. In event 1004 (which may be similar to events 815 and 816 ), system 730A may forward the generated instructions to firewall 153 .

[0141] At event 1008 (which may be similar to Fig. 8A In event 819), system 730B may receive CTI data 1000.2 including data D. Fig. 8A and Figure 8BIn an example of , system 730B may determine that analysis of logs of packets matching D-based criteria is unlikely to be useful, and / or long-term storage of such logs or packets matching D-based criteria is not warranted, but temporary storage of packets matching D-based criteria may be beneficial. In event 1009 (which may be similar to event 820), system 730B may indicate to system 730A that data traffic through firewall 153 should be monitored for packets matching D-based criteria, copies of such packets should be stored for at least a predetermined amount of time, and logs of such packets should be generated with at least some minimal level of detail. In event 1010 (which may be similar to event 821), system 730A may update an instruction list to store the instructions received in event 1009. Based on the instructions, system 730A may generate instructions that include D-based criteria and instruct firewall 153 to generate logs for and capture packets matching D-based criteria, and forward those captured packets and logs to system 730A. In event 1011 (which may be similar to events 823 and 824 ), system 730A may forward the generated instructions to firewall 153 .

[0142] Firewall 153 can be configured so that all packets sent from hosts outside network 151 to host 152 and all packets sent from host 152 to hosts outside network 151 pass through firewall 153. In event 1015, firewall 153 can send a copy of the packet that passes through firewall 153 and matches the standard based on C or the standard based on D to system 730A and a log of such packet. In event 1016 (which can be similar to event 834), system 730A can store the log and the packet captured from event 1015 in database 731A, and can index those stored packets to the standard and / or instruction that is the basis for capturing and storing those packets and generating corresponding logs. In event 1017 (which can be similar to event 835), system 730A can determine whether any stored instruction indicates that any just stored log and / or packet should be further processed based on the log and / or packet stored in database 731A. In the example of event 1017, there is no such instruction, and the stored log or packet is not further processed. Events 1015 to 1017 may be repeated multiple times. In some repetitions of event 1017, firewall 153 may only send logs and copies of packets that match the C-based criteria. In some repetitions of event 1017, firewall 153 may only send logs and copies of packets that match the D-based criteria.

[0143] In event 1021 (which may be similar to Figure 8BIn event 838 of FIG. 1000 , system 730B may receive CTI data 1000 . 3 including data E (e.g., one or more NTIs). System 730B may determine (e.g., based on a combination of Fig. 6E One or more determinations described or otherwise described herein) data E and data C may be related (or potentially related) to the same network threat, and if captured packets matching the C-based criteria also match the E-based criteria, those packets may be important. In event 1022 (which may be similar to event 839), system 730B may send instructions to system 730A to check captured packets matching the C-based criteria to obtain a match to the E-based criteria. In event 1023 (which may be similar to event 840), system 730A may update the instruction list to include the instructions received in event 1022, and may determine that there are stored packets matching the C-based criteria. In event 1024 (which may be similar to event 843), system 730A may cause those stored packets and corresponding logs that match the C-based criteria to be retrieved from database 731A. In event 1025 (which may be similar to event 844), system 730A may update those retrieved logs based on those retrieved packets. In event 1026 (which may be similar to event 845), system 730A may store updated logs in database 731B and may store data indexing those updated logs to C-based criteria and / or instructions associated with capturing packets based on the C-based criteria.

[0144] In event 1027 ( Fig. 10B) (which may be similar to event 846), system 730A may determine that a portion of the updated log matches the E-based criteria, and therefore determines that packets corresponding to the portion of the updated log match both the C-based criteria and the E-based criteria. In event 1028 (which may be similar to event 847), system 730A may store data indexing the portion of the updated log and the corresponding stored packets to the C-based criteria and the E-based criteria (and / or the instructions stored in event 1023). In event 1029, system 730A may perform additional actions indicated by the instructions stored in event 1023 based on determining that there are packets that match both the C-based and E-based criteria. The additional actions may include sending an alert to SIEM system 702 indicating that captured packets that match the C-based criteria also match the E-based criteria, collecting and / or sending copies of captured packets that match both the C-based criteria and the E-based criteria, and / or collecting and / or sending copies of logs corresponding to those captured packets. Similarly or alternatively, system 730A may collect and / or send all captured packets that match the C-based criteria and / or corresponding logs for all those captured packets to SIEM system 702. In addition to (or as an alternative to) sending alerts, captured packets, and / or logs to SIEM system 702, system 730A may also send alerts, captured packets, and / or logs to one or more other computing devices (e.g., system 730B, a SOAR platform, etc.).

[0145] System 730A may continue to receive and store captured packets that match C-based criteria (from firewall 153) and logs of such captured packets, and may perform operations with respect to such captured packets that are similar to those described above in connection with events 1025 through 1029 (e.g., updating logs, determining whether updated logs match E-based criteria, etc.). System 730A may continue to do so and / or perform other operations (e.g., based on additional instructions with respect to packets that match C-based criteria) until otherwise directed by system 730B or another computing device. Similarly or alternatively, system 730A may continue to store and process captured packets that match C-based criteria (and corresponding logs) until there is no related activity for a predetermined period of time (e.g., packets that match C-based criteria have no further matches with E-based criteria or other criteria, no new instructions with respect to comparing those packets with other criteria).

[0146] Events 1033 and 1034 may be similar to events 851 and 852, respectively. Event 1035 may be similar to event 853 or event 854, except that event 1035 involves sending a revocation instruction to firewall 153. Event 1036 may be similar to event 855.

[0147] For the purpose of explanation, the Fig. 10A and Fig. 10B Examples are given above, and many variations are within the scope of the disclosure. Fig. 10A and Fig. 10B Many of the events shown in can occur multiple times and are similar to Fig. 10A and Fig. 10B The events shown in FIG. 1 but involving other CTI data and related instructions, rules, etc. can also occur multiple times and / or in conjunction with Fig. 10A and Fig. 10B The instructions for causing system 730A to compare previously stored captured packets to the additional criteria may be different from the instructions stored in event 1023. Fig. 8A and Figure 8B The examples of provide non-limiting examples of such different types of instructions. FIG. 10A to FIG. 10B Other variations of the examples may include combining FIG. 8A to FIG. 8B For example, system 730A may instruct firewall 153 (e.g., in events such as events 1004 and 1011) to generate logs with more or less information for packets that match criteria (e.g., criteria based on C and D). Alternatively, system 730A may not instruct firewall 153 to generate logs for packets that match criteria (e.g., criteria based on C and D), and / or may instruct firewall 153 not to generate such logs. If firewall 153 does not generate such logs, event 1025 may be modified to include generating logs from stored packets that match criteria (e.g., criteria based on C and D).

[0148] Fig.11A and Fig. 11B is a sequence diagram illustrating further examples of events associated with filtering, aggregation, and / or retention control based on updated network threat intelligence. Fig. 11B yes Fig.11A The continuation of. Fig.11A and Fig. 11BIn the example of , firewall 153 may be configured (e.g., separately from any instructions received from system 730A or system 730B) to capture some or all packets that pass through firewall 153 (e.g., all packets sent from hosts outside network 151 to host 152, and some or all packets sent from host 152 to hosts outside network 151), generate at least some basic level of logs for all those packets (e.g., a 5-tuple or a portion thereof (e.g., an IP address of host 152 that sent or received the packet, a media access control (MAC) address of a device that sent or received the packet), and forward those captured packets and logs to archive 703. However, due to the amount of data associated with capturing all packets, archive 703 may be configured to store copies of the captured packets and corresponding logs for a relatively short default retention time (e.g., 5 days). If certain packets are associated with a network threat, those packets may be lost (and therefore unavailable for analysis or other activities associated with detecting and / or remediating network threats) if such a relationship is not discovered within the default retention time. In some cases, there may be early information that may be relevant to a network threat but whose importance is not yet known (e.g., data C or data D). If later information (e.g., data E) showing the importance of the early information is not received and processed within the default retention time, important data (e.g., early packets related to the threat) may be lost.

[0149] To increase the retention time of packets that are potentially relevant to a network threat, and as described in more detail below, system 730A can request copies of captured packets based on earlier information, can store local copies of those packets, and / or can notify archive 703 that those packets should be retained longer than the default retention time. System 730A can determine that some or all local copies of packets are more likely to be important based on criteria from later information and send an alert about those packets to SIEM system 703, and / or can cause those packets to be retained. Additional features are described below. Fig.11A and Fig. 11B The number, order, and / or timing of the example events shown in the drawings may be different, additional events may occur, and / or may be omitted, repeated, or modified. Fig.11A and Fig. 11B One or more of the events shown in . Fig.11A and Fig. 11B Events such as those shown in FIG. 1 (or portions thereof) may be performed alone or in combination with one or more events such as those shown in one or more other figures and / or described herein.

[0150] At event 1104 (which may be similar to Fig. 8A In event 811), system 730B may receive CTI data 1100.1 including data C. Fig. 8A and Figure 8B In the example of , system 730B may determine that analysis of logs of packets that match C-based criteria is unlikely to be useful, and / or long-term storage of such logs or packets that match C-based criteria is not yet warranted. However, it may be later determined that data C is important, and therefore temporary storage of packets that match C-based criteria may be beneficial. In event 1105 (which may be similar to event 812), system 730B may indicate to system 730A that packets and / or logs stored by archive 703 should be monitored for packets and / or logs that match C-based criteria, and that copies of such packets and / or logs should be stored for at least a predetermined amount of time. The instructions of event 1105 may further indicate that inference packets (and / or logs of inference packets) should also be stored. Inference packets for packets matching one or more sets of particular criteria may include packets sent to (or received from) a host 152 that sent or received a packet matching the set of criteria and that were sent (or received) within an inference packet time range (e.g., 15 minutes before and 15 minutes after a packet matching the set of criteria was sent or received). For example, if host 152-1 sends a packet matching C-based criteria at 12:00 p.m. on a particular day, the inference packets for that packet sent at 12:00 p.m. may include all packets addressed to and from host 152-1 that passed through firewall 153 between 11:45 a.m. and 12:15 p.m. on the same day. For convenience, inference packets for packets matching particular criteria are hereinafter referred to as "C-based criteria inference packets." For example, an inference packet for a packet matching C-based criteria may be referred to as a "C-based criteria inference packet." The inference packet time range may be different for different criteria used to identify packets. For example, the inference packet time range of a C-based standard inference packet may be 15 minutes before and 15 minutes after the time associated with a packet matching the C-based standard, but the inference packet time range of a D-based standard inference packet may be 30 minutes before and 30 minutes after the time associated with a packet matching the D-based standard.

[0151] In event 1106 , which may be similar to event 813 , system 730A may update the instruction list to store the instructions received in event 1105 . In event 1107, system 730A may forward instructions instructing archive 703 to: (i) send copies of captured packets (and corresponding logs) that match the C-based criteria and are currently stored by archive 703, (ii) send copies of C-based criteria inference packets (and corresponding logs) currently stored by archive 703, (iii) send copies of packets that match the C-based criteria subsequently received by archive 703, (iv) send copies of C-based criteria inference packets subsequently received by archive 703, (v) send copies of subsequently received packets that match the C-based criteria and logs of subsequently received C-based criteria inference packets, and (vi) begin storing packets that match the C-based criteria, logs of packets that match the C-based criteria, C-based criteria inference packets, and logs of C-based criteria inference packets for an increased time period (e.g., 30 days, 60 days, 90 days, etc.) that is longer than the default retention period.

[0152] In event 1110, archive 703 may send a copy of captured packets (and corresponding logs) that match the C-based criteria and are currently stored by archive 703, as well as a copy of C-based criteria inference packets (and corresponding logs) currently stored by archive 703. In event 1111, system 730A may store the packets and logs received in event 1110 in database 731A. As part of event 1111, system 730A may index those stored packets and stored logs to the C-based criteria, the instructions stored in event 1106, and / or the instructions of event 1107. System 730A may use, for example, in conjunction with Fig. 8A , Figure 8B , Fig. 9C , Fig.9E and Fig.9FThe stored packets and logs may be indexed by methods such as those described above. The stored C-based standard inference packets and corresponding logs may be further indexed so that further processing of those packets and logs by system 730A may be omitted, but those packets and logs may be identified and forwarded in appropriate circumstances (e.g., if a packet or log that matches the C-based standard is determined to match one or more additional criteria). In event 1112 (which may be similar to event 835), system 730A may determine whether any stored instructions indicate that any just stored packets should be further processed based on the storage of the packets in database 731A. In the example of event 1112, there is no such instruction, and the stored packets are not further processed. Events 1110 to 1112 may be repeated multiple times (e.g., when archive 703 forwards copies of additional packets that match the C-based standard and additional C-based standard inference packets and corresponding logs subsequently received by archive 703).

[0153] At event 1116 (which may be similar to Fig. 8A In event 819), system 730B may receive CTI data 1100.2 including data D. Fig. 8A and Figure 8B In the example of , system 730B may determine that analysis of logs of packets matching the D-based criteria is unlikely to be useful, and / or that long-term storage of such logs or packets matching the D-based criteria is not yet warranted. However, it may be later determined that data D is important, and therefore temporary storage of packets matching the D-based criteria may be beneficial. In event 1117 (which may be similar to event 820), system 730B may indicate to system 730A that packets stored by archive 703 should be monitored for packets matching the D-based criteria, and that copies of such packets should be stored for at least a predetermined amount of time. The instructions of event 1117 may further indicate that D-based criteria inference packets should also be stored.

[0154] At event 1118 (which may be similar to event 821), system 730A may update the instruction list to store the instructions received at event 1117. At event 1119, system 730A may forward instructions instructing archive 703 to: (i) send copies of captured packets (and corresponding logs) that match the D-based criteria and are currently stored by archive 703, (ii) send copies of D-based criteria inference packets (and corresponding logs) currently stored by archive 703, (iii) send copies of packets subsequently received by archive 703 that match the D-based criteria, (iv) send copies of D-based criteria inference packets subsequently received by archive 703, (v) send copies of subsequently received packets that match the D-based criteria and logs of subsequently received D-based criteria inference packets, and (vi) begin storing packets that match the D-based criteria, logs of packets that match the D-based criteria, D-based criteria inference packets, and logs of D-based criteria inference packets for an increased period of time that is longer than the default retention period.

[0155] In event 1121, archive 703 sends a copy of the captured packets (and corresponding logs) that match the D-based criteria and are currently stored by archive 703, as well as a copy of the D-based criteria inferred packets (and corresponding logs) currently stored by archive 703. In event 1122, system 730A may store the packets and logs received in event 1121 in database 731A. As part of event 1122, system 730A may index those stored packets and stored logs to the D-based criteria, the instructions stored in event 1118, and / or the instructions of event 1119. System 730A may use, for example, in conjunction with Fig. 8A , Figure 8B , Fig. 9C , Fig.9E and Fig.9F The stored packets and logs may be indexed by methods such as those described above. The stored D-based standard inference packets and corresponding logs may be further indexed so that further processing of those packets and logs by system 730A may be omitted, but those packets and logs may be identified and forwarded in appropriate circumstances (e.g., if a packet or log that matches the D-based standard is determined to match one or more additional criteria). In event 1123 (which may be similar to event 835), system 730A may determine whether any stored instructions indicate that any just-stored packets should be further processed based on the storage of the packets in database 731A. In the example of event 1123, there are no such instructions, and the stored packets are not further processed. Events 1121 to 1123 may be repeated multiple times (e.g., when archive 703 forwards copies of additional packets that match the D-based standard and additional D-based standard inference packets and corresponding logs subsequently received by archive 703).

[0156] In event 1127 (which may be similar to Figure 8B In event 838 of FIG. 1 , system 730B may receive CTI data 1100.3 including data E (e.g., one or more NTIs). System 730B may determine (e.g., based on a combination of Fig. 6E One or more determinations described or otherwise described herein) data E and data C may be related (or potentially related) to the same network threat, and if captured packets matching the C-based criteria also match the E-based criteria, those packets may be important. In event 1128 (which may be similar to event 839), system 730B may send instructions to system 730A to check captured packets matching the C-based criteria to obtain a match to the E-based criteria. In event 1129 (which may be similar to event 840), system 730A may update the instruction list to include the instructions received in event 1128, and may determine that there are stored packets matching the C-based criteria. In event 1130 (which may be similar to event 843), system 730A may cause those stored packets matching the C-based criteria and corresponding logs to be retrieved from database 731A. In event 1133 (which may be similar to event 844), system 730A may update the retrieved log for each of those retrieved packets. In event 1134 (which may be similar to event 845), system 730A may store updated logs in database 731B and may store data indexing those updated logs to C-based criteria and / or instructions associated with capturing packets based on the C-based criteria.

[0157] In event 1139 ( Fig. 11B ) (which may be similar to event 846), system 730A may determine that a portion of the stored update log for a packet that matches the C-based criteria also matches the E-based criteria, and therefore determines that the packet corresponding to the portion of the stored update log matches both the C-based criteria and the E-based criteria. In event 1140 (which may be similar to event 847), system 730A may store data indexing the portion of the log and the corresponding stored packet to the C-based criteria and the E-based criteria (and / or the instructions stored in event 1129).

[0158] In event 1141, system 730A may perform additional actions indicated by the instructions stored in event 1129 based on determining that there are packets that match the C-based and E-based criteria. The additional actions may include system 730A sending an alert to SIEM system 702 indicating that captured packets that match the C-based criteria also match the E-based criteria, that packets that match the C-based and E-based criteria (and / or corresponding logs) should continue to be retained (e.g., retained for an additional increased period of time or a longer period of time, and / or until further notice), and / or that C-based and E-based criteria-inferred packets (e.g., inferred packets that match the C-based and E-based criteria) (and / or corresponding logs) should continue to be retained (e.g., retained for an additional increased period of time or a longer period of time, and / or until further notice). Similarly or alternatively, the alert may indicate that all packets that match the C-based criteria (and / or corresponding logs) should continue to be retained, and / or that all C-based criteria-inferred packets (and / or corresponding logs) should continue to be retained. Additional actions (and events 1141) may further include system 730A collecting and / or sending: copies of packets that match the C-based criteria and the E-based criteria, copies of logs corresponding to those packets, copies of packets inferred based on the C- and E-based criteria, copies of logs corresponding to those packets, copies of all packets that match the C-based criteria, copies of logs corresponding to those packets, copies of C-based criteria inferred packets of all packets that match the C-based criteria, and / or copies of logs corresponding to those packets. In addition to (or as an alternative to) sending alerts, captured packets, and / or logs to SIEM system 702, system 730A may also send alerts, captured packets, and / or logs to one or more other computing devices (e.g., system 730B, a SOAR platform, archive 703, etc.).

[0159] System 730A may continue to receive and store packets (and corresponding logs) that match the C-based criteria (from archive 703), may continue to receive and store C-based criteria inference packets (and corresponding logs), and may continue to perform operations with respect to such packets and logs similar to the operations described above in connection with events 1111, 1112, and 1133-1141. System 730A may continue to do so until otherwise directed by system 730B or another computing device. Similarly or alternatively, system 730A may continue to store and process captured packets and corresponding logs that match the C-based criteria (and / or continue to store C-based criteria inference packets and corresponding logs) until there is no relevant activity for a predetermined period of time (e.g., packets that match the C-based criteria have no further matches with the E-based criteria or other criteria, no new instructions related to comparing those packets with other criteria).

[0160] Events 1145 and 1146 may be similar to events 851 and 852, respectively. Event 1147 may be similar to event 853 or event 854, except that event 1147 involves sending a revocation instruction to archive 703. Assuming no other instructions request such an item or request to increase the retention time of such an item, the revocation instruction of event 1147 may cause archive 703 to stop sending captured packets (or corresponding logs) that match the D-based criteria, stop sending captured D-based criteria inference packets (and corresponding logs), and restore the default retention time for such packets and logs. Event 1148 may be similar to event 855, and may include causing the stored packets that match the D-based criteria and are indexed to the rules stored in event 1118, the stored D-based criteria inference packets indexed to the rules stored in event 1118, and the corresponding logs indexed to the rules stored in event 1118 to be deleted from database 731A.

[0161] For the purpose of explanation, the Fig.11A and Fig. 11B Examples are given above, and many variations are within the scope of the disclosure. Fig.11A and Fig. 11B Many of the events shown in can occur multiple times and are similar to Fig.11A and Fig. 11B The events shown in FIG. 1 but involving other CTI data and related instructions, rules, etc. can also occur multiple times and / or in conjunction with Fig.11A and Fig. 11B The instructions for causing system 730A to compare previously stored captured packets to the additional criteria may be different from the instructions stored in event 1129. Fig. 8A and Figure 8B The example of provides a non-limiting example of such different types of instructions. As another variation, system 730A may not initially indicate that archive 703 will store packets that match C-based criteria, inference packets based on C-based criteria, and corresponding logs for an increased period of time (event 1107), and / or may not initially indicate that archive 703 will store packets that match D-based criteria, inference packets based on D-based criteria, and corresponding logs for an increased period of time (event 1119). In the event that such packets and logs are later determined to be important (e.g., based on a match with E-based criteria), a copy may be provided to archive 703 from a copy stored in database 731A. As another variation, and similar to the log of packets that match an earlier criteria, the log of inference packets may be updated and compared to a later criteria (e.g., the log of C-based criteria inference packets may be updated and compared to E-based criteria).

[0162] FIG. 11A to FIG. 11BOther variations of the examples may include combining FIG. 8A to FIG. 8B Examples of variations similar to those discussed in connection with the present disclosure include those described above. For example, firewall 153 may be configured to generate logs with more or less information for packets that match a standard (such as a standard based on C and D) and / or for inferred packets. Alternatively, firewall 153 may not be configured to generate logs for packets that match a standard (such as a standard based on C and D) and / or for inferred packets. If firewall 153 does not generate such logs, event 1133 may be modified to include generating logs from stored packets that match a standard (such as a standard based on C and D) and / or from stored inferred packets.

[0163] Fig. 12A and Fig. 12B is a flow chart illustrating an example method for filtering, aggregating, and / or retaining controls based on updated network threat intelligence. Fig. 12A and Fig. 12B One, some, or all steps of the example method may be performed by the system 730A and / or by a combination of one or more computing devices configured to perform some or all operations and / or functions of the system 730A. For convenience, the following describes the system 730A. Fig. 12A and Fig. 12B . Similarly or alternatively, Fig. 12A and Fig. 12B One, some, or all of the steps of the example method may be performed by one or more other computing devices (eg, system 730B or system 130). Fig. 12A and Fig. 12B One or more steps of the example methods may be rearranged (eg, performed in a different order), combined, omitted, and / or otherwise modified, and / or other steps may be added.

[0164] In step 1201, system 730A may determine whether it has received a new captured packet (e.g., from one or more PSGs 110 as in events 832 and 833, from firewall 153 as in event 1015, from archive 703 as in events 1110 and 1121, or from one or more other computing devices), or whether it has received one or more instructions (e.g., from system 730B as in events 812, 820, 839, 1002, 1009, 1022, 1105, 1117, and 1128, or from one or more other computing devices). If not, step 1201 may be repeated. If a new captured packet has been received, step 1231 may be performed (indicated by connector GG and described below in conjunction with FIG. 1232). Fig. 12B If the instruction has been received, step 1202 may be executed.

[0165] In step 1202, system 730A may review the received instruction(s) and may update the instruction list based on the received instruction(s). The received instructions may indicate that previously stored instructions should be deleted. The received instructions may indicate that one or more new instructions should be stored, such as the examples in events 813, 821, 840, 1003, 1010, 1023, 1106, 1118, and 1129. The new instructions(s) may include instructions for storing captured packets that match one or more criteria, comparing stored packets that match one or more criteria with one or more additional criteria to determine further matches(s), and / or taking additional actions (e.g., sending an alert based on one or more matches to one or more criteria, sending a log and / or a copy of the captured packets based on one or more matches to one or more criteria, and / or performing other actions). The received instructions may include a deobfuscation algorithm and / or other information that may be used to process the stored packets. The received instructions may indicate that previously stored instructions should be modified.

[0166] In step 1203, system 730A may determine whether the instruction(s) updated or added in step 1202 indicate that one or more rules (and / or instruction(s) of other types) should be generated and sent to one or more devices / sources of captured packets (e.g., to Fig. 8A and Figure 8B In the example of PSG 110, sent to Fig. 10A and Fig. 10B In the example of firewall 153, send to Fig.11A and Fig. 11B , and / or sent to one or more other devices / sources). The rules (or instructions) may indicate that packets matching one or more criteria (and / or inferred packets) should be captured and copies forwarded, that copies of already captured packets should be forwarded, that logs of packets should (or should not) be generated and / or forwarded, and / or that other actions should be taken (or not taken). Examples of rules / instructions that may be generated and sent in step 1204 include rules / instructions for events 815, 816, 823, 824, 1004, 1011, 1107, and 1119. The (multiple) rule(s) / (multiple) instructions generated and sent in step 1204 may revoke one or more previous rules / instructions. If the rules / instructions should not be sent, step 1209 may be performed. If the rules / instructions should be sent, the system 730A may generate and send corresponding (multiple) rules / (multiple) instructions in step 1204.

[0167] In step 1209 (which may be performed, for example, as part of events 840, 1023, and 1129), system 730A may determine whether the instruction(s) updated and / or added in step 1202 indicate that one or more previously stored packets should be checked for a match to one or more criteria. If not, step 1225 may be performed. Step 1225 is described below. If yes, step 1210 may be performed. In step 1210, system 730A may determine whether logs of one or more previously stored packets to be checked for a match to one or more criteria have already been generated, and if such logs have already been generated, whether those logs need to be updated (e.g., based on the instruction(s) updated and / or added in step 1202). If not, system 730A may generate those logs (or update existing logs), store those logs (e.g., in database 731A), and / or index those logs (e.g., relative to the instruction(s) updated or added in step 1202 and / or relative to the criteria associated with those instruction(s)) in step 1211. Examples of step 1210 include events 844 and 845, events 1025 and 1026, and events 1133 and 1134. If, for example, the instructions updated and / or added in step 1202 include additional information that allows additional data to be extracted from the captured packets, the previously generated logs may be updated. As another example, if the previously generated logs are logs that include only basic or minimal information received with the captured packets, those logs may be updated.

[0168] After step 1211, or after a "yes" determination in step 1210, the system 730A may retrieve in step 1212 the logs generated (and / or updated), indexed, and stored in step 1211, or the logs determined in step 1210 to have been previously generated, indexed, and stored and do not need to be updated. In step 1217, the system 730A may compare one or more criteria from the instruction(s) updated and / or added in step 1202 to the retrieved logs and determine if there are any matches. Examples of step 1217 include events 846, 1027, and 1139. In step 1218, the system 730A may store data indexing the retrieved logs (or a portion thereof) and / or corresponding stored packages based on any matches determined in step 1217. Examples of step 1218 include events 847, 1028, and 1140. In step 1219, the system 730A may determine whether the (multiple) instructions updated and / or added in step 1202 indicate that any (multiple) additional actions should be performed based on any matches determined in step 1217. The additional actions may include sending an alert (e.g., indicating a match of one or more packets to one or more criteria, indicating a relationship or potential relationship of one or more packets to one or more network threats, indicating that packets and / or logs should be retained, and / or indicating one or more other actions, determinations, or events), causing and / or indicating that packets should be retained (e.g., packets that match one or more criteria, inferred packets), indicating that logs should be retained, collecting and / or sending packets (e.g., packets that match one or more criteria, inferred packets), collecting and / or sending logs, and / or other actions. If no additional actions are indicated, the system 730A may perform step 1225. If one or more additional actions are indicated, the indicated (multiple) additional actions may be performed in step 1220. Examples of step 1220 include events 848, 1029, and 1141.

[0169] In step 1225, system 730A can determine whether any stored instructions, packets, and / or logs should be deleted. For example, system 730A can be configured to cause the stored packets, logs, and / or instructions to be deleted if there is no related activity within a predetermined time period (e.g., no further instructions related to those stored packets are received, the stored packets do not match other criteria, the stored packets or logs are not accessed). Examples of step 1225 include events 851, 1033, and 1145.

[0170] If the system 730A determines in step 1225 that there are stored instructions, packets, and / or logs to be deleted, those stored instructions, packets, and / or logs can be deleted in step 1226. As part of step 1226, the system 730A can generate and send one or more rules / instructions that revoke one or more previous rules / instructions that caused the packet (and / or log) to be forwarded. Examples of step 1226 include, for example, events 852-854, events 1034-1036, and events 1146-1148. After step 1226, or after a "no" determination in step 1225, the system 730A can repeat step 1201.

[0171] If system 730A determines in step 1201 that a new packet has been received, system 730A may execute step 1231 ( Fig. 12B ). In step 1231, system 730A may store the received packets (and corresponding logs, if also received), and may store data indexing the received packets (and logs, if received) to the criteria, instructions, and / or rules that served as the basis for receiving those packets. Examples of step 1231 include events 834, 1016, 1111, and 1122. In step 1232 (examples of which include events 835, 1017, 1112, and 1123), system 730A may determine whether any instructions stored by system 730A indicate that any packets stored in step 1231 should be further processed (e.g., for comparison with additional criteria). If no, system 730A may perform step 1225. If yes, system 730A may perform step 1233. In step 1233, system 730A may generate logs for the packets stored in step 1231. If, for example, events 839 and 840 occurred before event 832, then in step 1233, system 730A may generate logs for the packets stored in step 1231. Fig. 8A and Figure 8B In the example of , step 1233 may have been performed. If logs are received with the packets, step 1233 may include updating those logs to populate additional fields (e.g., based on the read fields of the packet). In step 1234, the system 730A may compare the logs generated / updated in step 1233 with the criteria indicated by one or more stored instructions (e.g., instructions indicating that packets captured based on matching one or more criteria should be compared with one or more additional criteria). In step 1239, the system 730A may store data indexing the one or more logs (generated / updated in step 1233) and the one or more packets (stored in step 1231) based on any matches determined according to the comparison of step 1234.

[0172] In step 1241, system 730A may determine whether any additional actions are indicated (e.g., indicated by stored instructions associated with the comparison of step 1234) based on any matches determined by the comparison of step 1234. If so, system 730A may perform the indicated additional action(s) in step 1242 (which may be similar to step 1220). If not, or after step 1242, system 730A may perform step 1225 (as indicated by connector HH).

[0173] Fig.13A and Fig. 13B is a sequence diagram illustrating additional examples of events associated with filtering, aggregation, and / or retention control based on updated cyber threat intelligence. Fig. 13B yes Fig.13A The continuation of. Fig.13A and Fig. 13B , and similar to Fig.11A and Fig. 11B In an example of , firewall 153 may be configured (e.g., separately from any instructions received from system 730A or system 730B) to capture some or all packets that pass through firewall 153 (e.g., all packets sent from hosts outside network 151 to host 152, and some or all packets sent from host 152 to hosts outside network 151), generate at least some basic level of logs for all those packets, and forward those captured packets and generated logs for storage in archive 703. However, in Fig.13A and Fig. 13B In the example of , those packets and logs are forwarded to system 730A, which forwards those packets and logs to archive 703. Archive 703 may store those forwarded packets and logs for a default retention period or a longer retention period based on instructions received from system 730A. System 730A may determine to store packets and / or logs for a longer retention period based on a comparison with a standard based on CTI data. Fig.11A and Fig. 11B As in the example, Fig.13A and Fig. 13B The example allows for increasing the retention time of packets that are determined to be potentially important based on criteria and / or updated criteria that are potentially relevant to one or more network threats. Fig.13A and Fig. 13B The number, order, and / or timing of the example events shown in the drawings may be different, additional events may occur, and / or may be omitted, repeated, or modified. Fig.13A and Fig. 13B One or more of the events shown in . Fig.13A and Fig. 13BEvents such as those shown in FIG. 1 (or portions thereof) may be performed alone or in combination with one or more events such as those shown in one or more other figures and / or described herein.

[0174] In event 1303 (which may be similar to Fig. 8A In event 811), system 730B may receive CTI data 1300.1 including data C. Fig. 8A and Figure 8B In the example of , system 730B may determine that analysis of logs of packets that match C-based criteria is unlikely to be useful, and / or long-term storage of such logs or packets that match C-based criteria is not yet warranted. However, it may be later determined that data C is important, and therefore temporary storage of packets that match C-based criteria may be beneficial. In event 1304 (which may be similar to event 812), system 730B may indicate to system 730A that packets and / or logs to be stored by archive 703 should be monitored for matches to C-based criteria, and that copies of such packets (and / or corresponding logs) that match C-based criteria should be stored for at least a predetermined amount of time longer than the default retention period. The instructions of event 1304 may further indicate that C-based criteria inference packets (and / or logs of such inference packets) should also be stored for at least a predetermined amount of time. In event 1205 (which may be similar to event 813), system 730A may update the instruction list to store the instructions received in event 1204.

[0175] In event 1309 (which may be similar to Fig. 8A In event 819), system 730B may receive CTI data 1300.2 including data D. Fig. 8A and Figure 8B In the example of , system 730B may determine that analysis of logs of packets matching D-based criteria is unlikely to be useful, and / or that long-term storage of such logs or packets matching D-based criteria is not yet warranted. However, it may be later determined that data D is important, and therefore temporary storage of packets matching D-based criteria may be beneficial. In event 1310 (which may be similar to event 820), system 730B may indicate to system 730A that packets to be stored by archive 703 should be monitored for matches to D-based criteria, and that copies of such packets matching D-based criteria should be stored for at least a predetermined amount of time longer than a default retention period. The instructions of event 1310 may further indicate that D-based criteria inference packets should also be stored for at least a predetermined amount of time. In event 1311 (which may be similar to event 821), system 730A may update the instruction list to store the instructions received in event 1310.

[0176] In event 1315, firewall 153 may forward the captured packets and logs associated with those captured packets to system 730A. In event 1316, system 730A may determine which of the packets and logs received in event 1215 are monitored packets or logs, or are inference packets (or corresponding logs) of monitored packets. In particular, system 730A may determine which of those received packets and logs match the criteria indicating a monitoring packet and indicating the storage of an instruction to store an inference packet. Fig.13A and Fig. 13B In the example of , those stored instructions include instructions stored in events 1305 (indicating that packets and logs matching C-based criteria should be monitored) and 1311 (indicating that packets and logs matching D-based criteria should be monitored). In event 1316, system 730A identifies packets matching C-based criteria (and corresponding logs), packets matching D-based criteria (and corresponding logs), C-based criteria-derived packets (and corresponding logs), and D-based criteria-derived packets (and corresponding logs). In event 1317, system 730A may forward the packets received in event 1315 and identified in event 1316 to archive 703. As part of event 1317, system 730A may also indicate to archive 703 that the packets and logs identified in event 1316 should be stored for an increased period of time. In event 1318, system 730A may store the packets and logs identified in event 1316 in database 731A. As part of event 1318, system 730A may index any of those stored packets (and corresponding logs) that match the C-based criteria and the C-based criteria inference packets (and corresponding logs) to the C-based criteria and / or instructions stored in event 1305. System 730A may use, for example, Fig. 8A , Figure 8B , Fig. 9C , Fig.9E and Fig.9FThe method described above can be used to index those stored packets and logs. The C-based criteria inference packets and corresponding logs can be further indexed so that further processing of those packets and logs by system 730A can be omitted, but those packets and logs can be identified and forwarded in appropriate circumstances (e.g., if the packets or logs that match the C-based criteria are determined to match one or more additional criteria). Similarly, and also as part of event 318, system 730A can index any of those stored packets (and corresponding logs) that match the D-based criteria and the D-based criteria inference packets (and corresponding logs) to the D-based criteria and / or instructions stored in event 1311. The D-based criteria inference packets and corresponding logs can be further indexed so that further processing of those packets and logs by system 730A can be omitted, but those packets and logs can be identified and forwarded in appropriate circumstances (e.g., if the packets or logs that match the D-based criteria are determined to match one or more additional criteria). In event 1319 (which may be similar to event 835), system 730A may determine whether any stored instructions indicate that any just stored packets should be further processed based on just storing the packets in database 731A. In the example of event 1319, there is no such instruction, and the stored packets are not further processed.

[0177] Events 1315 to 1319 may be repeated multiple times. In some repetitions of event 1315, there may not be a packet that matches the C-based standard. In this case, events 1316 to 1319 may be changed to omit actions related to packets that match the C-based standard or packets inferred based on the C standard. In some repetitions of event 1315, there may not be a packet that matches the D-based standard. In this case, events 1316 to 1319 may be changed to omit actions related to packets that match the D-based standard or packets inferred based on the D standard. In some repetitions of event 1315, there may not be a packet that matches the C-based or D-based standard. In this case, event 1317 may be changed to omit actions related to packets that match the C-based standard, packets inferred based on the C standard, packets that match the D-based standard, or packets inferred based on the D standard, and events 1318 and 1319 may not occur.

[0178] In event 1323 (which may be similar to Figure 8B In event 838 of FIG. 1 , system 730B may receive CTI data 1100.3 including data E (e.g., one or more NTIs). System 730B may determine (e.g., based on a combination of Fig. 6EOne or more determinations described or otherwise described herein) data E and data C may be related (or potentially related) to the same network threat, and if captured packets matching the C-based criteria also match the E-based criteria, those packets may be important. In event 1324 (which may be similar to event 839), system 730B may send instructions to system 730A to check captured packets matching the C-based criteria to obtain a match to the E-based criteria. In event 1325 (which may be similar to event 840), system 730A may update the instruction list to include the instructions received in event 1324, and may determine that there are stored packets matching the C-based criteria. In event 1326 (which may be similar to event 843), system 730A may cause those stored packets matching the C-based criteria and corresponding logs to be retrieved from database 731A. In event 1334 (which may be similar to event 844), system 730A may update the retrieved log for each of those retrieved packets. In event 1335 , which may be similar to event 845 , system 730A may store a log of updates in database 731B and may store data indexing the log of those updates to the C-based criteria and / or instructions stored in event 1305 .

[0179] In event 1339 ( Fig. 13B ) (which may be similar to event 846), system 730A may determine that a portion of the stored update log for a packet that matches the C-based criteria also matches the E-based criteria, and therefore determines that the packet corresponding to the portion of the stored update log matches both the C-based criteria and the E-based criteria. In event 1340 (which may be similar to event 847), system 730A may store data indexing the portion of the log and the corresponding stored packet to the C-based criteria and the E-based criteria (and / or the instructions stored in event 1325).

[0180] In event 1341, system 730A may perform additional actions indicated by the instructions stored in event 1325 based on determining that there are packets that match the C-based and E-based criteria. The additional actions may include system 730A sending an alert to SIEM system 702 indicating that captured packets that match the C-based criteria also match the E-based criteria, that packets that match the C-based and E-based criteria (and / or corresponding logs) should continue to be retained (e.g., retained for an additional increased period of time or a longer period of time, and / or until further notice), and / or that packets inferred based on the C-based and E-based criteria (and / or corresponding logs) should continue to be retained (e.g., retained for an additional increased period of time or a longer period of time, and / or until further notice). Similarly or alternatively, the alert may indicate that all packets that match the C-based criteria (and / or corresponding logs) should continue to be retained, and / or that all C-based criteria inferred packets (and / or corresponding logs) should continue to be retained. Additional actions (and events 1341) may further include system 730A collecting and / or sending: copies of packets that match the C-based criteria and the E-based criteria, copies of logs corresponding to those packets, copies of packets inferred based on the C- and E-based criteria, copies of logs corresponding to those packets, copies of all packets that match the C-based criteria, copies of logs corresponding to those packets, copies of C-based criteria inferred packets of all packets that match the C-based criteria, and / or copies of logs corresponding to those packets. In addition to (or as an alternative to) sending alerts, packets, and / or logs to SIEM system 702, system 730A may also send alerts, packets, and / or logs to one or more other computing devices (e.g., system 730B, a SOAR platform, archive 703, etc.).

[0181] System 730A may continue to receive and store packets (and corresponding logs) that match the C-based criteria (from firewall 153), may continue to receive and store C-based criteria inference packets (and corresponding logs), and may perform operations with respect to such packets and logs similar to the operations described above in connection with events 1318, 1319, and 1334 to 1341. System 730A may continue to do so until otherwise directed by system 730B or another computing device. Similarly or alternatively, system 730A may continue to store and process captured packets and corresponding logs that match the C-based criteria (and / or continue to store C-based criteria inference packets and corresponding logs) until there is no relevant activity for a predetermined period of time (e.g., packets that match the C-based criteria have no further matches with the E-based criteria or other criteria, no new instructions related to comparing those packets with other criteria).

[0182] Events 1345 and 1346 may be similar to events 851 and 852, respectively. Event 1347 may be similar to event 853 or event 854, except that event 1347 involves sending a revocation instruction to archive 703. The revocation instruction of event 1347 may cause archive 703 to restore the default retention time for packages that match D-based criteria (and corresponding logs) and D-based criteria inference packages (and corresponding logs), assuming that no other instructions request an increase in the retention time of such items. Event 1348 may be similar to event 855, and may include causing the stored packages that match D-based criteria and are indexed to the rules stored in event 1311, the stored D-based criteria inference packages indexed to the rules stored in event 1311, and the corresponding logs indexed to the rules stored in event 1311 to be deleted from database 731A.

[0183] For the purpose of explanation, the Fig.13A and Fig. 13B Examples are given above, and many variations are within the scope of the disclosure. Fig.13A and Fig. 13B Many of the events shown in can occur multiple times and are similar to Fig.13A and Fig. 13B The events shown in FIG. 1 but involving other CTI data and related instructions, rules, etc. can also occur multiple times and / or in conjunction with Fig.13A and Fig. 13B The instructions for causing system 730A to compare previously stored captured packets to the additional criteria may be different from the instructions stored in event 1325. Fig. 8A and Figure 8B The example of provides a non-limiting example of such different types of instructions. As another variation, system 730A may not initially indicate that archive 703 will store packets that match C-based criteria, inference packets based on C-based criteria, and a corresponding time period for log storage increase (event 1107), and / or may not initially indicate that archive 703 will store packets that match D-based criteria, inference packets based on D-based criteria, and a corresponding time period for log storage increase (event 1317). In the event that such packets and logs are later determined to be important (e.g., based on a match with E-based criteria), a copy may be provided to archive 703 from a copy stored in database 731A. As another variation, and similar to the log of packets that match an earlier criteria, the log of inference packets may be updated and compared to a later criteria (e.g., the log of C-based criteria inference packets may be updated and compared to E-based criteria).

[0184] FIG. 13A to FIG. 13B Other variations of the examples may include combining FIG. 8A to FIG. 8BExamples of variations similar to those discussed in connection with the present disclosure include those described above. For example, firewall 153 may be configured to generate logs with more or less information for packets that match a standard (such as a standard based on C and D) and / or for inferred packets. Alternatively, firewall 153 may not be configured to generate logs for packets that match a standard (such as a standard based on C and D) and / or for inferred packets. If firewall 153 does not generate such logs, event 1334 may be modified to include generating logs from stored packets that match a standard (such as a standard based on C and D) and / or from stored inferred packets.

[0185] Fig.14A and Fig. 14B is a flow chart illustrating an example method for filtering, aggregating, and / or retaining controls based on updated network threat intelligence. Fig.14A and Fig. 14B One, some, or all steps of the example method may be performed by the system 730A and / or by a combination of one or more computing devices configured to perform some or all operations and / or functions of the system 730A. For convenience, the following describes the system 730A. Fig.14A and Fig. 14B . Similarly or alternatively, Fig.14A and Fig. 14B One, some, or all of the steps of the example method may be performed by one or more other computing devices (eg, system 730B or system 130). Fig.14A and Fig. 14B One or more steps of the example methods may be rearranged (eg, performed in a different order), combined, omitted, and / or otherwise modified, and / or other steps may be added.

[0186] In step 1401, system 730A may determine whether it has received a new captured packet (e.g., from firewall 153 as in event 1315, or from one or more other computing devices), or whether it has received one or more instructions (e.g., from system 730B as in events 1304, 1310, and 1324, or from one or more other computing devices). If not, step 1401 may be repeated. If a new captured packet has been received, step 1431 may be performed (indicated by connector II and described below in conjunction with FIG. 1432). Fig. 14B If the instruction has been received, step 1402 may be executed.

[0187] In step 1402, the system 730A may review the received instruction(s) and may update the instruction list based on the received instruction(s). The received instructions may indicate that previously stored instructions should be deleted. The received instructions may indicate that one or more new instructions should be stored, such as the examples in events 1305, 1311, and 1325. The new instruction(s) may include instructions for storing captured packets that match one or more criteria, comparing stored packets that match one or more criteria with one or more additional criteria to determine further matches, taking additional actions (e.g., sending an alert based on one or more matches to one or more criteria, sending a log and / or a copy of the captured packet based on one or more matches to one or more criteria, and / or performing other actions). The received instructions may include a deobfuscation algorithm and / or other information that may be used to process the stored packets. The received instructions may indicate that previously stored instructions should be modified.

[0188] In step 1409 (which may be performed, for example, as part of event 1325), system 730A may determine whether the instruction(s) updated and / or added in step 1402 indicate that one or more previously stored packets should be checked for a match to one or more criteria. If not, step 1425 may be performed. Step 1425 is described below. If yes, step 1410 may be performed. In step 1410, system 730A may determine whether logs of one or more previously stored packets to be checked for a match to one or more criteria have already been generated, and if such logs have already been generated, whether those logs need to be updated (e.g., based on the instruction(s) updated and / or added in step 1402). If not, system 730A may generate those logs (or update existing logs), store those logs (e.g., in database 731A), and / or index those logs (e.g., relative to the instruction(s) updated or added in step 1402 and / or relative to the criteria associated with those instruction(s)) in step 1411. Examples of step 1411 include events 1334 and 1335. If, for example, the updated and / or added instructions in step 1402 include additional information that allows additional data to be extracted from the captured packets, the previously generated logs may be updated. As another example, if the previously generated logs were logs that included only basic or minimal information received with the captured packets, those logs may be updated.

[0189] After step 1411, or after a "yes" determination in step 1410, system 730A may retrieve, in step 1412, the logs generated (and / or updated), indexed, and stored in step 1411, or the logs determined in step 1410 to have been previously generated, indexed, and stored and do not need to be updated. In step 1417, system 730A may compare one or more criteria from the instruction(s) updated and / or added in step 1402 to the retrieved logs and determine if there are any matches. Examples of step 1417 include event 1339. In step 1418, system 730A may store data indexing the retrieved logs (or a portion thereof) and / or corresponding stored captured packets based on any matches determined in step 1417. Examples of step 1418 include event 1340. In step 1419, the system 730A may determine whether the (multiple) instructions updated and / or added in step 1402 indicate that any (multiple) additional actions should be performed based on any matches determined in step 1417. The additional actions may include sending an alert (e.g., indicating a match of one or more packets to one or more criteria, indicating a relationship or potential relationship of one or more packets to one or more network threats, indicating that packets and / or logs should be retained, and / or indicating one or more other actions, determinations, or events), causing and / or indicating that packets should be retained (e.g., packets that match one or more criteria, inferred packets), indicating that logs should be retained, collecting and / or sending packets (e.g., packets that match one or more criteria, inferred packets), collecting and / or sending logs, and / or other actions. If no additional actions are indicated, the system 730A may perform step 1225. If one or more additional actions are indicated, the indicated (multiple) additional actions may be performed in step 1420. An example of step 1420 includes event 1341.

[0190] In step 1425, system 730A can determine whether any stored instructions, packets, and / or logs should be deleted. For example, system 730A can be configured to cause the stored packets, logs, and / or instructions to be deleted if there is no related activity within a predetermined time period (e.g., no further instructions related to those stored packets are received, the stored packets do not match other criteria, the stored packets or logs are not accessed). An example of step 1425 includes event 1345.

[0191] If the system 730A determines in step 1425 that there are stored instructions, captured packets, and / or logs to be deleted, then those stored instructions, captured packets, and / or logs can be deleted in step 1426. As part of step 1426, the system 730A can generate and send one or more instructions that revoke one or more previous instructions that caused the packets (and / or logs) to be forwarded. Examples of step 1426 include events 1346-1348. After step 1426, or after a "no" determination in step 1425, the system 730A can repeat step 1401.

[0192] If system 730A determines in step 1401 that a new packet has been received, system 730A may perform step 1431 ( Fig. 14B ). In step 1431, system 730A may determine whether the received packet is a packet that system 730A is monitoring (e.g., whether the received packet corresponds to a stored instruction indicating a packet that should be monitored). An example of step 1431 is event 1316. If not, system 730A may forward the received packet (and corresponding log, if received) to archive 703 in step 1432 (e.g., without any instruction to increase the retention time of any of those packets). After step 1432, system 730A may perform step 1425 (indicated by connector JJ). If the system determines in step 1431 that the received packet includes a packet that system 730A is monitoring, system 730A may perform step 1433. In step 1433, system 730A may forward the received packets (and corresponding logs, if received) to archive 703, but may include one or more instructions indicating the packets and / or logs for which the retention period should be increased (e.g., the monitored packets determined in step 1431, the inferred packets of the monitored packets, the corresponding logs). An example of step 1433 includes event 1317. In step 1438, system 730A may store the monitored packets determined in step 1431, as well as the inferred packets and corresponding logs. As part of step 1438, system 730A may store data indexing the received packets to the criteria and / or instructions that were the basis for receiving those packets. An example of step 1438 includes event 1318.

[0193] In step 1439 (examples of which include event 1319), system 730A may determine whether any instructions stored by system 730A indicate that any packets stored in step 1338 should be further processed (e.g., to be compared to additional criteria). If not, system 730A may perform step 1425. If yes, system 730A may perform step 1441. In step 1441, system 730A may generate (and / or update) logs of the packets stored in step 1438. If logs were received with the packets, step 1441 may include updating those logs to populate additional fields (e.g., based on the read fields of the packet).

[0194] In step 1442, the system 730A may compare the logs generated / updated in step 1441 with the criteria indicated by one or more stored instructions (e.g., instructions indicating that packets captured based on matching one or more criteria should be compared with one or more additional criteria). In step 1445, the system 730A may store data indexing the one or more logs (generated / updated in step 1441) and the one or more packets (stored in step 1438) based on any matches determined according to the comparison of step 1442. In step 1446, the system 730A may determine whether any additional actions are indicated (e.g., indicated by stored instructions associated with the comparison of step 1442) based on any matches determined by the comparison of step 1442. If yes, the system 730A may perform the indicated additional action(s) in step 1447 (which may be similar to step 1420). If no, the system 730A performs step 1425 (as indicated by connector JJ).

[0195] As previously described herein, an earlier CTI may indicate that the threat level associated with a threat is lower, and a new CTI for the threat may indicate a higher threat level. The opposite may also occur. For example, an earlier CTI may indicate that the threat level associated with a threat is higher, and a new CTI may indicate that the threat level associated with the threat is lower. Determining that an initially high threat level should be lower (e.g., by comparing a criterion based on an updated CTI with a log and / or captured packets associated with an earlier CTI) may be as valuable as determining that an initially low threat level should be higher. Threats may have a life cycle. An NTI associated with a threat may, for example, start with a low risk, may be raised to a high risk, may then be reduced to a low risk, may return to a high risk, and so on. As a further example, a legitimate website may be hacked and serve malware. The hacked website may be quickly remedied and stop serving the malware. The system 130 may use the life cycle of the NTI to block access to the hacked website until the threat associated with the hacked website is reduced, and / or take other steps until the threat is reduced. Such other steps may, for example, include setting a high risk profile for filtering rules (e.g., requiring additional logging and / or requiring packet capture), enforcing the use of the latest Transport Layer Security (TLS) protocol, limiting encrypted sessions, and / or using a man-in-the-middle (MITM) decryption proxy to maintain awareness of malicious packet content.

[0196] As explained above, CTI may be received from a provider 135 that may be external to the system 130. Similarly or alternatively, the system 130 may generate its own CTI based on analysis such as that described herein. For example, when analyzing existing logs and / or captured packets, the system 130 may discover additional NTI that may be used to further analyze the existing logs and / or captured packets, to refine filtering rules, and / or in any manner that may use CTI from an external provider. The system 130 may iteratively perform multiple cycles of generating CTI, applying criteria based on the generated CTI to logs and / or packet captures, generating additional CTI, and the like.

[0197] As indicated above, the new CTI can be used to analyze logs associated with an earlier CTI. Such analysis can be performed based on information obtained from analysis of captured packets associated with the earlier CTI. However, such analysis can also be performed without analyzing captured packets. For example, valuable information (e.g., affected hosts, threat treatment) can be obtained by applying information from the new CTI to packet logs that may not have corresponding captured packets or do not require analysis of corresponding captured packets.

[0198] One or more features described herein may be embodied in computer-usable or readable data and / or computer-executable instructions, such as embodied in one or more program modules executed by one or more computers or other devices as described herein. Program modules may include routines, programs, objects, components, data structures, etc., which perform specific tasks or implement specific abstract data types when executed by a processor in a computer or other device. Modules may be written in a source code programming language that is subsequently compiled and executed, or may be written in a scripting language such as (but not limited to) HTML or XML. Computer-executable instructions may be stored on non-transient computer-readable media such as hard disks, optical disks, removable storage media, solid-state memory, RAM, etc. The functions of program modules may be combined or distributed as needed. In addition, the functions may be embodied in firmware or hardware equivalents, such as integrated circuits, field programmable gate arrays (FPGAs), etc. Specific data structures may be used to more effectively implement one or more features discussed herein, and such data structures are contemplated within the scope of computer-executable instructions and computer-usable data described herein. The various features described herein may be embodied as methods, computing devices, systems, and / or computer program products.

[0199] For the avoidance of doubt, and without limiting the breadth of the disclosure above or in the accompanying drawings, this application further includes the subject matter described in the following numbered clauses:

[0200] 1. A method comprising: storing one or more first packets that match one or more first criteria; and based on at least a portion of the one or more first packets matching one or more third criteria, causing an additional action associated with the at least a portion of the one or more first packets to be potentially related to a network threat.

[0201] 2. The method as described in clause 1 further includes: storing one or more second packages that match one or more second criteria; and deleting the stored one or more second packages based on the absence of activities associated with the stored one or more second packages.

[0202] 3. A method as described in any of clauses 1 or 2, wherein causing the deletion of the stored one or more second packages includes causing the deletion to be performed without causing another action associated with the one or more second packages to be performed.

[0203] 4. The method of any one of clauses 1 to 3, wherein causing deletion of the stored one or more second packages comprises causing the deletion based on a lack of activity for at least a predetermined period of time.

[0204] 5. The method of any of clauses 1 to 4, wherein the absence of activity comprises a failure to determine a match of the one or more second packages to any criteria other than the one or more second criteria.

[0205] 6. The method of any of clauses 1 to 5, wherein the absence of activity comprises an absence of instructions for inspecting the one or more second packets for a match to any criteria other than the one or more second criteria.

[0206] 7. The method of any one of clauses 1 to 6, wherein the absence of activity comprises an absence of attempts to access the stored one or more second packages.

[0207] 8. The method of any of clauses 1 to 7, wherein the one or more second criteria are not known to correspond to a cyber threat.

[0208] 9. The method of any of clauses 1 to 8, wherein prior to receiving the one or more third criteria, it is not known that the one or more first criteria correspond to a network threat.

[0209] 10. A method as described in any of clauses 1 to 9, wherein each of the one or more first criteria, the one or more second criteria, and the one or more third criteria includes data configured to match one or more network threat indicators.

[0210] 11. The method of any one of clauses 1 to 10, further comprising one or more of the following: receiving the one or more first packets without a log of the one or more first packets; or receiving the one or more second packets without a log of the one or more second packets.

[0211] 12. The method of any one of clauses 1 to 11, further comprising: determining that the at least a portion of the one or more first packets matches the one or more third criteria.

[0212] 13. A method as described in clause 12, wherein determining that at least a portion of the one or more first packets matches the one or more third criteria includes: generating and / or updating one or more logs of the one or more first packets; comparing the one or more third criteria with the one or more logs; and determining the at least a portion based on a match between the one or more third criteria and at least a portion of the one or more logs corresponding to the at least a portion of the one or more first packets.

[0213] 14. The method of any one of clauses 12 or 13, further comprising: determining that the at least a portion of the one or more first packages matches one or more additional criteria before determining that the at least a portion of the one or more first packages matches the one or more third criteria.

[0214] 15. A method as described in clause 14, wherein causing the additional action associated with the at least a portion of the one or more first packets to be performed includes causing the additional action to be performed further based on determining that the at least a portion of the one or more first packets matches the one or more additional criteria.

[0215] 16. A method as described in any of clauses 14 or 15, wherein determining that at least a portion of the one or more first packets matches the one or more additional criteria includes making this determination without alerting other computing devices that the one or more first packets match the one or more additional criteria.

[0216] 17. A method as described in any of clauses 1 to 16, wherein the additional action associated with the at least a portion of the one or more first packets includes alerting one or more computing devices of one or more of: a match between the at least a portion of the one or more first packets and the one or more third criteria, a relationship between the at least a portion of the one or more first packets and a network threat, or a potential relationship between the at least a portion of the one or more first packets and a network threat.

[0217] 18. A method as described in any of clauses 1 to 17, wherein the further action associated with the at least part of the one or more first packets includes causing the at least part of the one or more first packets to be stored.

[0218] 19. A method as described in any of clauses 1 to 18, wherein the further action associated with the at least part of the one or more first packets includes causing the at least part of the one or more first packets to be stored for at least an additional period of time.

[0219] 20. A method as described in any of clauses 1 to 19, wherein the further action associated with the at least a portion of the one or more first packets includes causing one or more logs associated with the at least a portion of the one or more first packets to be stored.

[0220] 21. A method as described in any of clauses 1 to 20, wherein the further action associated with the at least a portion of the one or more first packets includes causing one or more of the following to be stored: the one or more first packets or one or more logs associated with the one or more first packets.

[0221] 22. A method as described in any of clauses 1 to 21, wherein the additional action associated with the at least a portion of the one or more first packets includes one or more of the following: collecting logs corresponding to the at least a portion of the one or more first packets, or collecting logs corresponding to the one or more first packets.

[0222] 23. A method as described in any of clauses 1 to 22, wherein the additional action associated with the at least a portion of the one or more first packets includes one or more of the following: sending a log corresponding to the at least a portion of the one or more first packets to one or more computing devices; or sending a log corresponding to the one or more first packets to one or more computing devices.

[0223] 24. The method as described in any one of clauses 1 to 23 further includes: receiving the one or more first packets and / or the one or more second packets from one or more packet security gateways, and the one or more packet security gateways are configured to: filter packet traffic based on one or more criteria, record packets, allow packets matching one or more criteria to pass, block packets matching one or more criteria from passing, and capture packets matching one or more criteria.

[0224] 25. The method of clause 24, further comprising: instructing the one or more packet security gateways to forward a copy of the one or more first packets and / or the one or more second packets to a computing device executing the method.

[0225] 26. A method as described in clause 25, wherein instructing the one or more packet security gateways to forward copies of the one or more first packets and / or the one or more second packets to the computing device executing the method includes instructing the one or more packet security gateways to forward copies of the one or more first packets and / or the one or more second packets to the computing device, and not forwarding copies of the one or more first packets and / or the one or more second packets to one or more other computing devices to which packet logs and / or packet copies are forwarded.

[0226] 27. A method as described in any of clauses 25 or 26, wherein instructing the one or more packet security gateways to forward a copy of the one or more first packets and / or the one or more second packets includes instructing the one or more packet security gateways not to record the one or more first packets and / or instructing the one or more packet security gateways not to record the one or more second packets.

[0227] 28. The method as described in any one of clauses 1 to 27 further includes: receiving the one or more first packets and / or the one or more second packets from one or more computing devices, the one or more computing devices including one or more of a firewall, a computing device associated with an Internet service provider, an archival computing device, or a computing device at a network boundary.

[0228] 29. The method of clause 28, further comprising: instructing the one or more computing devices to forward a copy of the one or more first packets and / or the one or more second packets.

[0229] 30. The method of any one of clauses 1 to 29, further comprising: receiving the one or more first packages and / or the one or more second packages from an archive configured to store packages for a default retention period, and wherein the further action associated with at least a portion of the one or more first packages comprises instructing the archive to store the one or more first packages for an increased time period longer than the default retention period.

[0230] 31. The method of any one of clauses 1 to 30, further comprising one or more of: receiving an inference package associated with the one or more first packages; or receiving an inference package associated with the one or more second packages.

[0231] 32. The method of any one of clauses 1 to 31, further comprising one or more of: requesting an inference package associated with the one or more first packages; or requesting an inference package associated with the one or more second packages.

[0232] 33. A method as described in any of clauses 1 to 32, wherein the additional action associated with at least a portion of the one or more first packets includes one or more of the following: forwarding an inference packet associated with at least a portion of the one or more first packets; or forwarding an inference packet associated with the one or more first packets.

[0233] 34. The method as described in any one of clauses 1 to 33 further includes: receiving a copy of a packet captured from packet traffic passing through a network device; determining that the copy of the packet captured from the packet traffic includes the one or more first packets and / or the one or more second packets; forwarding the received copy of the packet captured from the packet traffic; and indicating that the forwarded copy of the one or more first packets and / or the one or more second packets should be retained.

[0234] 35. A method as described in clause 34, wherein indicating that a copy of the forwarded one or more first packets and / or the one or more second packets should be retained includes indicating that a copy of the forwarded one or more first packets and / or the one or more second packets should be retained for an increased retention period longer than a default retention period.

[0235] 36. The method as described in any one of clauses 34 or 35, further comprising: not indicating that other packets should be retained, wherein the other packets include packets other than the one or more first packets or the one or more second packets from a copy of packets captured from packet traffic via the network device.

[0236] 37. The method of clause 36, wherein not indicating that the other packets should be retained comprises not indicating that the other packets should be retained for an increased retention period longer than a default retention period.

[0237] 38. A method as described in any of clauses 1 to 37, wherein the method includes a method for filtering, aggregating and / or retaining control based on updated network threat intelligence.

[0238] 39. A system comprising one or more computing devices, wherein the system is configured to perform the method of any one of clauses 1 to 38.

[0239] 40. One or more non-transitory computer-readable media comprising stored instructions that, when executed by one or more processors of one or more computing devices of a system, cause the system to perform a method as described in any of clauses 1 to 38.

[0240] 41. A method comprising: receiving data, the data including packet logs, the packet logs corresponding to packets filtered by one or more computing devices, the data also including captured packets, the captured packets including a copy of at least a portion of the filtered packets; receiving second network threat intelligence data; determining that the second network threat intelligence data and the first network threat intelligence data are potentially associated with common network threats; identifying a subset of the captured packets and a subset of the packet logs associated with the first network threat intelligence data; and using criteria based on the second network threat intelligence data, using a subset of the packet logs and / or using a subset of the captured packets to perform one or more actions.

[0241] 42. A method as described in clause 41, wherein the one or more actions include: updating one or more packet logs in the subset of packet logs by applying the standard to the subset of packet logs or at least one of the subset of captured packets; and outputting one or more indications associated with the common network threats based on the updated one or more packet logs.

[0242] 43. A method as described in any of clauses 41 or 42, wherein the one or more actions include: determining that one or more packet logs in the subset of packet logs are not associated with the common network threat by applying the standard to the subset of captured packets; and outputting one or more indications associated with the common network threat based on determining that the one or more packet logs are not associated with the common network threat.

[0243] 44. A system comprising one or more computing devices, wherein the system is configured to perform the method of any of clauses 41 to 43.

[0244] 45. One or more non-transitory computer-readable media comprising stored instructions that, when executed by one or more processors of one or more computing devices of a system, cause the system to perform a method as described in any of clauses 41 to 43.

[0245] 46. ​​A method comprising: receiving data including packet logs corresponding to packets filtered by one or more computing devices; receiving second network threat intelligence data; determining that the second network threat intelligence data and the first network threat intelligence data are potentially associated with a common network threat; identifying a subset of the packet logs associated with the first network threat intelligence data; and using criteria based on the second network threat intelligence data, using the subset of the packet logs to perform one or more actions.

[0246] 47. A method as described in clause 46, wherein the one or more actions include: determining that one or more packet logs in a subset of the packet logs are not associated with the common network threat by applying the standard to data received from the one or more computing devices; and outputting one or more indications associated with the common network threat based on determining that the one or more packet logs are not associated with the common network threat.

[0247] 48. A method as described in any of clauses 46 or 47, wherein the one or more actions include: confirming that one or more packet logs in a subset of the packet logs are associated with the common network threat by applying the standard to the data received from the one or more computing devices; and outputting one or more indications associated with the common network threat based on confirming that the one or more packet logs are associated with the common network threat.

[0248] 49. A system comprising one or more computing devices, wherein the system is configured to perform the method of any of clauses 46 to 48.

[0249] 50. One or more non-transitory computer-readable media comprising stored instructions that, when executed by one or more processors of one or more computing devices of a system, cause the system to perform the method of any of clauses 46 to 48.

[0250] 51. A method comprising: receiving data including captured packets, the captured packets including copies of packets filtered by one or more computing devices; receiving second network threat intelligence data; determining that the second network threat intelligence data and the first network threat intelligence data are potentially associated with common network threats; identifying a subset of the captured packets associated with the first network threat intelligence data; and using criteria based on the second network threat intelligence data, using the subset of the captured packets to perform one or more actions.

[0251] 52. A method as described in clause 51, wherein the one or more actions include: confirming that one or more captured packets in the subset of captured packets are not associated with the common network threat by applying the standard to data received from the one or more computing devices; and outputting one or more indications associated with the common network threat based on determining that the one or more captured packets are not associated with the common network threat.

[0252] 53. A method as described in any of clauses 51 or 52, wherein the one or more actions include: confirming that one or more captured packets in the subset of captured packets are associated with the common network threat by applying the standard to data received from the one or more computing devices; and outputting one or more indications associated with the common network threat based on confirming that the one or more captured packets are associated with the common network threat.

[0253] 54. A system comprising one or more computing devices, wherein the system is configured to perform the method of any of clauses 51 to 53.

[0254] 55. One or more non-transitory computer-readable media comprising stored instructions that, when executed by one or more processors of one or more computing devices of a system, cause the system to perform a method as described in any of clauses 51 to 53.

[0255] 56. A method for use with data received from one or more packet security gateways, the one or more packet security gateways being configured to apply packet matching criteria of packet filtering rules to network traffic passing through the one or more packet security gateways while in transit between a protected network and an unprotected network, the method comprising: receiving, by a network threat analysis system comprising one or more servers, network threat intelligence data indicating a plurality of network threats, wherein the received network threat intelligence data comprises first network threat intelligence data indicating a first network threat among the plurality of network threats; receiving, by the network threat analysis system and from the one or more packet security gateways, data comprising packet logs corresponding to packets filtered by the one or more packet security gateways based on the packet filtering rules, wherein the packet logs correspond to filtered packets and comprise network threat indicators that match the criteria of the packet filtering rules, and wherein the The criteria of the packet filtering rule are based on the network threat intelligence data, and the data also includes captured packets, the captured packets including a copy of at least a portion of the filtered packets; the network threat analysis system receives second network threat intelligence data; the network threat analysis system determines updated criteria based on the second network threat intelligence data potentially corresponding to the first network threat; the network threat analysis system identifies a subset of the packet logs associated with the first network threat and a subset of the captured packets associated with the first network threat; the network threat analysis system generates an updated packet log set associated with the first network threat by applying the updated criteria to at least one of the subset of the packet logs or the subset of the captured packets; and the network threat analysis system outputs one or more indications associated with the first network threat based on the updated packet log set.

[0256] 57. A method as described in clause 56, wherein the filtered packets corresponding to the packet log include packets from network traffic passing through the one or more packet security gateways during a first time period, wherein the first network threat intelligence data is generated at a time before the start of the first time period, and wherein the second network threat intelligence data is generated at a time after the start of the first time period.

[0257] 58. A method as described in any of clauses 56 or 57, wherein the filtered packets corresponding to the packet log include packets from network traffic passing through the one or more packet security gateways during a first time period, wherein the receiving of the network threat intelligence data includes receiving the first network threat intelligence data before the start of the first time period, and wherein the receiving of the second network threat intelligence data includes receiving the second network threat intelligence data after the start of the first time period.

[0258] 59. A method as described in any of clauses 56 to 58, wherein the identifying a subset of the packet logs and a subset of the captured packets is performed based on determining that both the first network threat intelligence data and the second network threat intelligence data are associated with the first network threat.

[0259] 60. A method as described in any of clauses 56 to 59, wherein the identifying of the subset of the packet logs and the subset of the captured packets is performed based on determining that the second network threat intelligence data includes one or more of the following: a change in the value of a network threat indicator identified by the first network threat intelligence data, or a change in the value of a network threat indicator not identified by the first network threat intelligence data.

[0260] 61. A method as described in any of clauses 56 to 60, wherein the generating includes generating the updated packet log set to include network threat indicators from the identified subset of the captured packets that are not identified by the first network threat intelligence data.

[0261] 62. A method as described in any of clauses 56 to 61, wherein the updated packet log set includes network threat indicators from an identified subset of the captured packets, and the network threat indicators include one or more of the following: source address, destination address, source port, destination port, protocol, L3 header field value, L4 header field value, L2 header field value, protocol version, host name, domain name, part of a domain name, Universal Resource Identifier (URI), Universal Resource Locator (URL), authentication certificate, certificate authority, size of a packet, size of a part of a packet, specific contents of at least a part of a data payload, HTTP request method type, time associated with a packet, or a relationship of a packet to one or more other packets.

[0262] 63. A method as described in any of clauses 56 to 62, wherein the criteria include one or more first criteria based on one or more first network threat indicators from the first network threat intelligence data and associated with the first network threat, wherein the updated criteria are based on one or more second network threat indicators from the second network threat intelligence data and associated with the first network threat, wherein the one or more second network threat indicators are different from the one or more first network threat indicators, and wherein generating the updated packet log set further includes one or more of the following: confirming the association with the first network threat based on the presence of the one or more second network threat indicators in one or more packet logs in a subset of packet logs, or determining that there is no association with the first network threat based on the absence of the one or more second network threat indicators in one or more packet logs in the subset of packet logs.

[0263] 64. The method of any of clauses 56 to 63, further comprising determining one or more commonalities associated with network threat indicators of the updated set of packet logs.

[0264] 65. The method of any of clauses 56 to 64, further comprising determining, based on the updated set of packet logs, that one or more packet logs of the packet logs not identified as part of the subset of packet logs are associated with the first network threat.

[0265] 66. The method of any of clauses 56 to 65, wherein the identifying is further based on determining that the second cyber threat intelligence data increases the threat level associated with the first cyber threat.

[0266] 67. The method as described in any one of clauses 56 to 66 further includes: generating a further updated packet log set associated with the first network threat by the network threat analysis system and based on third network threat intelligence data associated with the first network threat and updating the second network threat intelligence data; and outputting one or more indications associated with the first network threat by the network threat analysis system and based on the further updated packet log set.

[0267] 68. A method as described in any of clauses 56 to 67, wherein the output includes one or more of the following: outputting an indication on a display; modifying a packet filtering rule to add one or more packet matching criteria; modifying a packet filtering rule to block a packet; or changing a storage time associated with one or more packet logs in the packet log.

[0268] 69. A network threat analysis system, comprising one or more servers, wherein the one or more servers are configured to perform the method as described in any one of clauses 56 to 68.

[0269] 70. One or more non-transitory computer-readable media comprising stored instructions that, when executed by one or more processors of a network threat analysis system, cause the network threat analysis system to perform the method of any of clauses 56 to 68.

[0270] Although the present disclosure has been described according to various examples, it will be apparent to those skilled in the art that many additional modifications and variations will be apparent in view of the present disclosure. In particular, any of the various processes described above may be performed in an alternative order and / or in parallel (on different computing devices) to achieve similar results in a manner more suitable for the requirements of a particular application. Therefore, it should be understood that the present disclosure may be practiced in a manner different from that specifically described without departing from the scope and spirit of the present disclosure. Although examples are described above, the features and / or steps of those examples may be combined, divided, omitted, rearranged, modified and / or amplified in any desired manner. Therefore, the present disclosure should be considered illustrative and not restrictive in all respects. Therefore, the scope of the present disclosure should not be determined by examples, but by the appended claims and their equivalents.

Claims

1. A method for use with data received from one or more packet security gateways, the one or more packet security gateways being configured to apply packet matching criteria of packet filtering rules to network traffic passing through the one or more packet security gateways while in transit between a protected network and an unprotected network, the method comprising: Receiving, by a network threat analysis system including one or more servers, network threat intelligence data indicating a plurality of network threats, wherein the received network threat intelligence data includes first network threat intelligence data indicating a first network threat among the plurality of network threats; The network threat analysis system receives data from the one or more packet security gateways, the data comprising: a packet log corresponding to packets filtered by the one or more packet security gateways based on the packet filtering rule, wherein the packet log corresponds to the filtered packets and includes network threat indicators that match criteria of the packet filtering rule, and wherein the criteria of the packet filtering rule is based on the network threat intelligence data, and a captured packet, the captured packet comprising a copy of at least a portion of the filtered packet; The network threat analysis system receives second network threat intelligence data; Determining, by the network threat analysis system, updated criteria based on the second network threat intelligence data potentially corresponding to the first network threat; identifying, by the network threat analysis system, a subset of the packet logs associated with the first network threat and a subset of the captured packets associated with the first network threat; generating, by the network threat analysis system, an updated set of packet logs associated with the first network threat by applying the updated criteria to at least one of the subset of the packet logs or the subset of the captured packets; and One or more indicators associated with the first network threat are outputted by the network threat analysis system based on the updated set of packet logs.

2. The method of claim 1, wherein: The filtered packets corresponding to the packet log include packets from network traffic passing through the one or more packet security gateways during a first time period, wherein the first network threat intelligence data is generated at a time before the start of the first time period, and wherein the second network threat intelligence data is generated at a time after the start of the first time period.

3. The method of claim 1, wherein: The filtered packets corresponding to the packet log include packets from network traffic passing through the one or more packet security gateways during a first time period, wherein receiving the network threat intelligence data includes receiving the first network threat intelligence data before the start of the first time period, and wherein receiving the second network threat intelligence data includes receiving the second network threat intelligence data after the start of the first time period.

4. The method of claim 1, wherein: The identifying the subset of the packet logs and the subset of the captured packets is performed based on determining that both the first network threat intelligence data and the second network threat intelligence data are associated with the first network threat.

5. The method of claim 4, wherein: The identifying the subset of the packet logs and the subset of the captured packets is performed based on determining that the second cyber threat intelligence data includes one or more of: a change in the value of a cyber threat indicator identified by the first cyber threat intelligence data, or Values ​​of cyber threat indicators not identified by the first cyber threat intelligence data.

6. The method of claim 1, wherein: The generating includes generating the updated packet log set to include network threat indicators from the identified subset of the captured packets that are not identified by the first network threat intelligence data.

7. The method of claim 1, wherein: The updated packet log collection includes network threat indicators from the identified subset of the captured packets, the network threat indicators including one or more of the following: source address, destination address, source port, destination port, protocol, L3 header field value, L4 header field value, L2 header field value, protocol version, host name, domain name, portion of a domain name, Universal Resource Identifier (URI), Universal Resource Locator (URL), authentication certificate, certificate authority, size of a packet, size of a portion of a packet, specific contents of at least a portion of a data payload, HTTP request method type, time associated with a packet, or a relationship of the packet to one or more other packets.

8. The method of claim 1, wherein: The criteria include one or more first criteria, the one or more first criteria are based on one or more first network threat indicators from the first network threat intelligence data and associated with the first network threat, wherein the updated criteria are based on one or more second network threat indicators from the second network threat intelligence data and associated with the first network threat, wherein the one or more second network threat indicators are different from the one or more first network threat indicators, and wherein generating the updated packet log set further includes one or more of the following: confirming an association with the first cyber threat based on the presence of the one or more second cyber threat indicators in one or more packet logs in the subset of packet logs, or The absence of an association with the first network threat is determined based on an absence of the one or more second network threat indicators in one or more packet logs in the subset of packet logs.

9. The method of claim 1, further comprising: One or more commonalities associated with network threat indicators of the updated set of packet logs are determined.

10. The method of claim 1, further comprising: It is determined based on the updated set of packet logs that one or more of the packet logs not identified as part of the subset of the packet logs are associated with the first network threat.

11. The method of claim 1, wherein: The identifying is further based on determining that the second cyber threat intelligence data increases a threat level associated with the first cyber threat.

12. The method of claim 1, further comprising: generating, by the network threat analysis system, a further updated set of packet logs associated with the first network threat based on third network threat intelligence data, wherein the third network intelligence data is associated with the first network threat and updates the second network threat intelligence data; and One or more indicators associated with the first network threat are outputted by the network threat analysis system based on the further updated packet log set.

13. The method of claim 1, wherein: The output includes one or more of the following: outputting an indication on a display; Modify a packet filter rule to add one or more packet matching criteria; Modify the packet filtering rules to block the packets; or A storage time associated with one or more of the packet logs is changed.

14. A network threat analysis system, comprising one or more servers, wherein: The one or more servers are configured to: Receiving network threat intelligence data indicating a plurality of network threats, wherein the received network threat intelligence data includes first network threat intelligence data indicating a first network threat among the plurality of network threats; receiving data from one or more packet security gateways configured to apply packet matching criteria of packet filtering rules to network traffic passing through the one or more packet security gateways while in transit between a protected network and an unprotected network, the data comprising: a packet log corresponding to packets filtered by the one or more packet security gateways based on the packet filtering rule, wherein the packet log corresponds to the filtered packets and includes network threat indicators that match criteria of the packet filtering rule, and wherein the criteria of the packet filtering rule is based on the network threat intelligence data, and a captured packet, the captured packet comprising a copy of at least a portion of the filtered packet; receiving second network threat intelligence data; determining updated criteria based on the second cyber threat intelligence data potentially corresponding to the first cyber threat; identifying a subset of the packet logs associated with the first network threat and a subset of the captured packets associated with the first network threat; generating an updated set of packet logs associated with the first network threat by applying the updated criteria to at least one of the subset of the packet logs or the subset of the captured packets; and One or more indicators associated with the first network threat are outputted by the network threat analysis system based on the updated set of packet logs.

15. The network threat analysis system according to claim 14, wherein: The filtered packets corresponding to the packet log include packets from network traffic passing through the one or more packet security gateways during a first time period, wherein the first network threat intelligence data is generated at a time before the start of the first time period, and wherein the second network threat intelligence data is generated at a time after the start of the first time period.

16. The network threat analysis system according to claim 14, wherein: The one or more servers are configured to identify the subset of the packet logs and the subset of the captured packets based on determining that both the first network threat intelligence data and the second network threat intelligence data are associated with the first network threat.

17. The network threat analysis system according to claim 14, wherein: The criteria include one or more first criteria, the one or more first criteria are based on one or more first network threat indicators from the first network threat intelligence data and associated with the first network threat, wherein the updated criteria are based on one or more second network threat indicators from the second network threat intelligence data and associated with the first network threat, wherein the one or more second network threat indicators are different from the one or more first network threat indicators, and wherein the one or more servers are configured to generate the updated set of packet logs by one or more of: confirming an association with the first cyber threat based on the presence of the one or more second cyber threat indicators in one or more packet logs in the subset of packet logs, or The absence of an association with the first network threat is determined based on an absence of the one or more second network threat indicators in one or more packet logs in the subset of packet logs.

18. One or more non-transitory computer-readable media comprising stored instructions that, when executed by one or more processors of a network threat analysis system, cause the network threat analysis system to: receiving cyber threat intelligence data indicative of a plurality of cyber threats, wherein: The received network threat intelligence data includes first network threat intelligence data, the first network threat intelligence data indicating a first network threat among the plurality of network threats; receiving data from one or more packet security gateways configured to apply packet matching criteria of packet filtering rules to network traffic passing through the one or more packet security gateways while in transit between a protected network and an unprotected network, the data comprising: a packet log corresponding to packets filtered by the one or more packet security gateways based on the packet filtering rule, wherein the packet log corresponds to the filtered packets and includes network threat indicators that match criteria of the packet filtering rule, and wherein the criteria of the packet filtering rule is based on the network threat intelligence data, and a captured packet, the captured packet comprising a copy of at least a portion of the filtered packet; receiving second network threat intelligence data; determining updated criteria based on the second cyber threat intelligence data potentially corresponding to the first cyber threat; identifying a subset of the packet logs associated with the first network threat and a subset of the captured packets associated with the first network threat; generating an updated set of packet logs associated with the first network threat by applying the updated criteria to at least one of the subset of the packet logs or the subset of the captured packets; and One or more indicators associated with the first network threat are outputted by the network threat analysis system based on the updated set of packet logs.

19. One or more non-transitory computer readable media as recited in claim 18, wherein: The filtered packets corresponding to the packet log include packets from network traffic passing through the one or more packet security gateways during a first time period, wherein the first network threat intelligence data is generated at a time before the start of the first time period, and wherein the second network threat intelligence data is generated at a time after the start of the first time period.

20. The one or more non-transitory computer readable media of claim 18, wherein: The instructions, when executed by the one or more processors of the network threat analysis system, cause the network threat analysis system to identify the subset of the packet logs and the subset of the captured packets based on determining that both the first network threat intelligence data and the second network threat intelligence data are associated with the first network threat.

Images