Network damage activity monitoring system and activity analyzer thereof, computer-implemented method, and non-transitory computer-readable medium

Abstract

A network compromise activity monitoring system and a network device compromise activity analyzer used therein, a computer-implemented method for monitoring network device compromise activity, and a non-transitory computer-readable medium thereof. The network compromise activity monitoring system includes a network connector, a compromise activity analyzer, and a compromise preventer. The network connector has a public network port, at least one private network port, and a corresponding network connector traffic log regarding network connector data packet traffic. The compromise activity analyzer is capable of accessing suspicious target metadata, egress traffic metadata, and network device metadata, and is capable of determining a compromise activity level for one or more devices coupled to the at least one private network port. The compromise preventer responds to the determined compromise activity level for the one or more devices and is capable of performing at least one action including blocking, alerting, and notifying based on at least one rule.

Description

Technical Field

[0001] The present invention relates to network security technology, and more particularly to a network damage activity monitoring system and a network device damage activity analyzer used therein, a computer-implemented method for monitoring network device damage activities, and a non-transitory computer-readable medium thereof. Background Art

[0002] Computers and computer networks are under increasingly sophisticated attacks from entities (often referred to as "hackers") who gain unauthorized access to computers and / or network devices. More specifically, hackers gain unauthorized access to devices such as computers, smartphones, tablets, and network equipment, typically to cause damage, compromise systems, steal data, hold data ransomed, or otherwise restrict access to these devices by authorized users. Hackers' tools, tactics, techniques, and procedures are rapidly proliferating, enabling activities ranging from initial intrusion, command and control, persistence, and data exfiltration to proceed unnoticed by network security and IT teams and the traditional tools they use. Hackers are adept at creating attack vectors to trick employees and individual users into opening malicious attachments or links and voluntarily providing sensitive personal or corporate data or user credentials. Attack vectors include sharing malware and viruses, malicious email attachments and web links, phishing attacks, pop-ups, text messages, and instant messaging.

[0003] Malware is software intentionally designed to cause damage to a computer, server, client, or computer network; to disclose private information; to gain unauthorized access to information or systems; to deprive users of access to information; or to otherwise interfere with the security and privacy of a user's computer. Types of malware include computer viruses, parasites, Trojan horses, ransomware, spyware, adware, rogue software, wipers, and keyloggers.

[0004] Traditional defense strategies against hackers and malware include network firewalls, endpoint agents that detect malware and viruses, and the collection and aggregation of log data into tools such as Security Information and Event Management (SIEM). Antivirus and anti-malware software attempt to identify viruses or malware, typically through known hash tags or signatures, designed to detect behavior associated with hacker activity. However, these software rely on maintaining and constantly updating databases of detection capabilities. The increasing sophistication of malware has limited their use, as hackers can use the same tools to test their malicious code to determine whether it can evade detection. In contrast, a firewall is a security system that monitors and controls inbound and outbound network traffic based on predetermined security rules. Some firewalls also have the ability to analyze network traffic to identify malicious files or unauthorized user activity. However, these methods typically require a well-trained security team to review and address alerts to distinguish between real attacks and false positives. Firewalls create a security barrier between trusted (private) devices or device networks and untrusted (public) networks, such as the internet. However, as hackers increasingly use encrypted channels that cannot be analyzed without more advanced traffic inspection capabilities, firewalls cannot stop all would-be hackers.

[0005] There are various network monitoring tools used to collect and analyze network activity data, including "Syslog" and "NetFlow." While these tools serve similar purposes, there are some key differences between them. Syslog is a standard protocol for forwarding system log information from one device to another. It is primarily used to collect log data from various network devices (such as routers, switches, and servers). Syslog information contains information about events that occurred on the device, including security alerts, system errors, and other information. The data is stored in text files and can be analyzed using a variety of tools.

[0006] NetFlow, on the other hand, is a network protocol developed by Cisco for usage analysis and network monitoring. It collects and records information about network traffic flows, including source and destination addresses, traffic type, and the amount of data transferred. NetFlow is used to identify network usage patterns, monitor network performance, and detect security threats.

[0007] In terms of similarities, both Syslog and NetFlow are used to collect and analyze data about network activity, and both are widely used in network monitoring and management. They provide valuable insights into network performance, security, and usage patterns. However, the main difference between the two is that Syslog focuses on collecting and logging data, while NetFlow focuses on network usage analysis. Both Syslog and NetFlow are important tools for network monitoring and management, but they have different uses. Syslog is used to collect and log data from network devices, while NetFlow is used to analyze network traffic flows.

[0008] For network monitoring and management, there are many alternatives to Syslog and NetFlow, each with its own advantages and disadvantages. These include sFlow, Simple Network Management Protocol (SNMP), the ELK Stack, Graylog, and Wireshark. The tool of choice will depend on the organization's specific needs, the type of network being monitored, and the level of detail required for analysis.

[0009] The term "initial access" refers to when a hacker (also known as an intruder, threat actor, etc.) bypasses network defenses and gains access to a computer network or computer system. Initial access can also be achieved by implanting malware into a computer (for example, via a thumb drive or pen drive). Some tools have been developed that attempt to detect, prevent and / or block access based on network activity (including intrusion detection tools and firewalls (IDS), intrusion prevention tools and firewalls (IPS), malware defenses (such as anti-malware, anti-virus), endpoint detection and response (EDR), management detection and response (MDR), etc.). These protections are typically focused on the network or perimeter end and may not be sufficient to detect, prevent or handle initial access. Hackers who successfully achieve initial access to a computer network and / or computer system are considered intruders or threat actors. A growing number of industry organizations and experts believe that the protection measures of existing technical tools (network or perimeter measures, etc.) are insufficient to ensure the security of private networks.

[0010] The U.S. Department of Defense (DOD) approved a document for release on November 7, 2022, regarding its "Zero Trust Strategy," which assumes that "threat actors" may have already gained access to network systems, computers, or devices. The DOD Zero Trust Strategy, approved on October 21, 2022, and publicly released on November 7, 2022, establishes the Office of Prepublication and Security Review, indicating the need for a comprehensive new solution system to understand and respond to intruders.

[0011] Over the years, many organizations, including the IBM / Ponemon Institute, have conducted research on data breaches. In a July 2022 report titled "The Cost of a Data Breach 2022," the IBM / Ponemon Institute stated that the average time to detect a data breach is 207 days. They noted that the duration of a breach must also be considered when assessing the damage caused. Unfortunately, effective solutions for early detection of data breaches or other network system compromises remain elusive with existing technologies.

[0012] Other limitations of these prior art techniques will become apparent to one skilled in the art upon review of the following description and examination of the several drawings. Summary of the Invention

[0013] A network damage activity monitoring system includes a network connector, a damage activity analyzer, and a damage preventer. The network connector has a public network port, at least one private network port, and network connector traffic records related to network connector data packet traffic, wherein data packets flowing to the at least one private network port and data packets flowing out of the public network port are egress traffic, and data packets flowing to the public network port and data packets flowing out of the at least one private network port are ingress traffic. The damage activity analyzer has access to suspicious target metadata, egress traffic metadata, and network device metadata, and is capable of determining a damage activity level of one or more devices coupled to the at least one private network port based at least in part on the suspicious target metadata, egress traffic metadata, and network device metadata. The damage preventer responds to the damage activity level determined for the one or more devices and is capable of performing at least one action based on at least one rule, wherein the action includes blocking, alerting, and notifying.

[0014] A network device compromise activity analyzer includes: a processor; and a memory coupled to the processor, the memory having code segments executable on the processor, configured to: (a) extract firewall traffic metadata, including traffic metadata including at least an originating Internet Protocol (IP) address and a destination IP address of firewall egress traffic; (b) match the originating IP address of the egress traffic metadata with network device metadata to identify a source device of at least one egress data packet; (c) match the destination IP address of the egress traffic metadata with suspicious target metadata to identify a suspicious target of the egress data packet; (d) determine a compromise activity level associated with at least one source device based on the egress traffic metadata, the network device metadata, and the suspicious target metadata; and (e) operate on the determined compromise activity level according to at least one rule.

[0015] A computer-implemented method for monitoring network device compromise activity includes: providing firewall traffic metadata to a compromise activity analyzer including a digital processor and a memory, wherein the firewall traffic metadata includes at least an originating Internet Protocol (IP) address of firewall egress traffic and a destination IP address of the firewall egress traffic; matching the originating IP address of the firewall egress traffic metadata with network device metadata to identify a source device of at least one firewall egress data packet; matching the destination IP address of the firewall egress traffic metadata with suspicious target metadata; determining a compromise activity level of at least one source device based on the firewall egress traffic metadata, the network device metadata, and the suspicious target metadata; and operating on the determined compromise activity level based on at least one rule.

[0016] A non-transitory computer-readable medium (media) includes code segments executable on a digital processor for monitoring compromised activity of a network device, wherein the code segments include: a code segment for providing firewall traffic metadata, the firewall traffic metadata comprising at least an originating Internet Protocol (IP) address of firewall egress traffic and a destination IP address of the firewall egress traffic; a code segment for matching the originating IP address of the firewall egress traffic metadata with network device metadata to identify a source device of at least one firewall egress data packet; a code segment for determining a compromised activity level of at least one source device based on the firewall egress traffic metadata and the network device metadata; and a code segment for operating on the determined compromised activity level according to at least one rule.

[0017] The advantage of the embodiment of this case is that by inspecting the traffic transmitted through the network connector (firewall is an example), damage to network devices (such as servers and computers) can be detected in a timely manner.

[0018] These and other embodiments, features and advantages will become more apparent to those skilled in the art upon reading the following description and examining the several figures of the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] Several embodiments will now be described with reference to the accompanying drawings, wherein similar components are numbered similarly. These embodiments are intended to illustrate, but not to limit, the present invention. The drawings include the following figures:

[0020] Figure 1 is a block diagram of a first example public / private network system having a network damage activity analysis system;

[0021] Figure 2 is a block diagram of an example computer platform of a network damage activity analysis system;

[0022] Figure 3 is a block diagram of a second example public / private network system including a plurality of network compromise activity analysis systems;

[0023] Figure 4 is an example block diagram of an example cloud-based network damage activity analysis system;

[0024] Figure 5 yes Figure 4 Block diagram of an example damage defender in [1].

[0025] Figure 6 is a flow chart of an example process implemented by the Compromise Activity Analyzer;

[0026] Figure 7 is a flow chart of an example process for providing firewall traffic metadata;

[0027] Figure 8 is an accompanying diagram of an example firewall traffic record file and a firewall traffic metadata table;

[0028] Figure 9 is a flow chart of an example process for matching originating IP addresses of egress traffic metadata with network device metadata;

[0029] Figure 10 is an accompanying diagram of an example network device metadata table;

[0030] Figure 11 is a flow chart of an example process for matching target IP addresses with suspicious target metadata;

[0031] Figure 12 is an accompanying diagram of an example suspicious target list and a suspicious target metadata table;

[0032] Figure 13is an accompanying diagram illustrating an example method for determining the level of damaging activity;

[0033] Figure 14 is an attached diagram of a network port metadata table;

[0034] Figure 15 is a tabular graph with the Fibonacci sequence and associated count and volume adjustments; and

[0035] Figure 16 is a flow chart of an example process for operating on a determined level of compromised activity according to at least one rule.

[0036]

Explanation of symbols

[0037] 10 ~ Network System; 12 ~ Private Network; 14 ~ Public Network; 16 ~ Network Damage Analysis System; 18 ~ Firewall; 20 ~ Damage Analyzer; 22 ~ Router; 24 ~ Hub Switch; 26 ~ Printer; 28A-28N ~ Server; 30 ~ Switch: 32A-32N ~ Workstation; 34 ~ WiFi Router; 36 ~ Computer; 38 ~ Tablet; 40 ~ Cell Phone; 42 ~ Public Network Port; 44 ~ Private Network Port; 46 ~ Local Bus; 48 ~ Central Processing Unit; 50 ~ High-Speed ​​SRAM Cache; 52 ~ DRAM Main Memory; 53 ~ Content-Addressable Memory; 54 ~ Basic Input / Output System; 56 ~ Power-On Reset; 58 ~ Non-Volatile Memory; 6 0 ~ Network Interface; 62 ~ Input / Output; 10' ~ Network System; 64A, 64B ~ Private Network; 66 ~ Service Provider Network; 68A ~ Network Connector; 69A ~ Private Network Port; 69B ~ Public Network Port; 70 ~ Damage Analyzer; 71A ~ Private Network Port; 71B ~ Public Network Port; 76 ~ Damage Analyzer; 77A ~ Private Network Port; 77B ~ Public Network Port; 78 ~ Virtual Network Connector; 79 ~ Mobile Device; 16' ~ Network Damage Activity Analysis System; 74B ~ Connector; 82 ~ Egress Traffic Data; 84 ~ Damage Translation Table (CTT) (Device Metadata) Module; 86 ~ External Data and Pointer Module; 88 ~ Internal Automated Analysis Module for Heuristic and Statistical Analysis Module; 90 ~ Machine Learning Module; 92 ~ Damage Prevention Module; 94 ~ Automatic and Manual Integration Module; 96 ~ Target System Relationship Module; 98 ~ Traffic Analysis Module; 100 ~ Metadata Extraction Module; 102 ~ Severity Impact Determination Module; 104 ~ Damage Risk Rating Developing Module; 106 ~ Action Determination Module; 108 ~ Potential Threat Behavior Identification Module; 110 ~ Abnormal Activity Identification Module; 112 ~ Damage Probability Determination Module; 114 ~ Damage Prevention Engine Module; 116 ~ CTT Module Update Determination Module; 118 ~ Other Automatic and Manual Integration Interaction Modules; 120 ~ Alert and Notification Engine Module; 122 ~ Execution Notification Module; 124 ~ Maintaining and Updating Alert Modules Block; 126 ~ Create / Update Report Module; 128 ~ Distribute Report Module; 130 ~ Block Engine Module; 132 ~ Isolate Endpoint Module; 134 ~ Report to Law Enforcement Module; 136 ~ Automatic Forensic Data Analysis Module; 138 ~ Mitigation Engine; 140 ~ Monitor Active Damage Module; 142 ~ Patching Endpoint Module; 144 ~ Trigger Forensic Data Collection Module; 146-158 ~ Process; 150', 160-176 ~ Process; 178 ~ Firewall Traffic Log File; 180 ~ List; 182 ~ Firewall Traffic Metadata File; 184 ~ Table; 186-192 ~ Process; 194 ~ Network Device Metadata File Structure; 154', 196-202 ~ Process; 204 ~ Suspicious Target File;206 - List of Suspicious IP Addresses; 208 - Suspicious Target Metadata File; 210 - Table; 212 - Host Sensitivity Multiplier Table; 214 - Target Host Score Factor Table; 216 - Port Importance Factor Table; 218 - Communication of Interest Table; 220 - Factor / Value / Result Table; 222 - Example Score Parameters; 224 - Adjusted Damage Concern Calculation; 226 - Network Port Metadata File; 228 - Table of Metadata for Private Network Ports; 230 - List with Fibonacci Sequence and Related Count Adjustments and Data Volume Adjustments; and, 158', 232-238 - Process. DETAILED DESCRIPTION

[0038] exist Figure 1 In the example network system 10, a private network 12, a public network 14, and a network damage activity analysis system 16 are shown. In this example, the private network 12 is a local area network (LAN), such as that of a private enterprise, and the public network 14 is a wide area network (WAN), such as the Internet. The public network 14 can provide a variety of cloud services, such as cloud firewalls, virtual private networks (VPNs), cloud computing, software as a service (SaaS), cloud data storage, etc. The network damage activity analysis system 16 in this example also includes a firewall 18, a damage activity analyzer 20, and an integrated damage prevention module (CDM). In other embodiments, the CDM can be separate from the damage activity analyzer 20, for example, provided as software as a service (SaaS) on the Internet 14.

[0039] Communications between devices in network system 10 consist of digital data packets with a header (and sometimes a trailer and / or footer) that provides information about the data packet's contents, origin, and destination. For example, an Internet Protocol (IP) packet has a header that contains information about where the packet came from (its originating IP address), where the packet is going (its destination IP address), how large the packet is, and how long network routers should continue forwarding the packet before discarding it. It can also indicate whether the packet can be fragmented and contain information about reassembling fragmented packets.

[0040] In this non-limiting example, a private network (LAN) 12 includes a plurality of devices, including a router 22, a hub switch 24, a printer 26, a plurality of servers 28A-28N, a switch 30, a plurality of workstations 32A-32N, a WiFi router 34, and three exemplary WiFi-enabled devices, such as a computer 36, a tablet 38, and a cell phone 40. Each device on the private network 12 is assigned an Internet Protocol (IP) address, some of which may be static and some of which may be dynamic. For example, devices connected to the WiFi router 34 (such as the computer 36, tablet 38, and cell phone 40) may be assigned a dynamic IP address upon connecting to the WiFi router 34, while the servers 28A-28N may be assigned static IP addresses. The various devices on the private network 12 can generally communicate freely within the private network and can communicate with the public network 14 through the firewall 18.

[0041] In this example, firewall 18 is a commercial hardware firewall from multiple manufacturers, including Cisco Systems, WatchGuard, Fortinet, and Barracuda Networks. In alternative embodiments, firewall 18 may be implemented in software running on a server, computer, or in the cloud (e.g., in a cloud-based firewall on Internet 14). Firewall 18 includes multiple modules, including a packet blocking (PB) module for blocking certain data packets; a firewall logic (FL) module for controlling the PB module; a firewall rules (FR) module used by the FL module; a masking (MA) module for masking the IP addresses of devices connected to private LAN 12; and a firewall flow logging (FT) module. In other examples, the firewall may include any hardware or virtual network device having a public network port and at least one private network port.

[0042] An important purpose of the firewall 18 is to prevent the transmission of malicious code or unauthorized data between the private LAN 12 and the public WAN 14. They do this in a number of ways. First, the MA module can mask the IP addresses of the devices on the LAN 12 from being visible to the public network, typically using a process called Network Address Translation (NAT), which causes devices on the LAN to be assigned private IP addresses rather than publicly addressable IP addresses. This often poses a challenge to security analysis tools because the same private IP address may be used by millions of devices around the world. Additionally, the FL module examines the origin and destination IP addresses, port numbers, type, etc. of the data packets and, using a set of rules from the FR module, blocks certain data packets from being transmitted from the WAN to the LAN, and possibly vice versa, via the PB module.

[0043] Figure 1 The example firewall 18 in FIG. 1 is shown with a public network port 42 connected to the WAN 14 and a private network port 44 connected to the LAN 12. Public network port 42 and private network port 44 are typically input / output (I / O) ports compliant with the IEEE 802.3 standard, commonly referred to as Ethernet ports. Other firewalls have different configurations of I / O ports. For example, many hardware firewalls have multiple private network ports to supplement or replace the need for router 22. As mentioned, not every data packet sent from the WAN 14 to public network port 42 is allowed through the firewall 18 to reach the LAN 12. Furthermore, in some cases, not every data packet sent from the LAN 12 to network port 44 is allowed through the firewall 18 to reach the WAN 14. The FR module typically includes a rule table that specifies the conditions under which data packets are allowed to pass through the firewall and which packets should be blocked.

[0044] As described above, the firewall 18 includes a FT module that at least temporarily stores recorded data about data packet traffic, referred to herein as "firewall traffic" or "FT," i.e., Figure 1 As shown, to facilitate continuous exchange between LAN 12 devices and WAN 14 devices. Data packets leaving port 42 bound for WAN 14 are referred to herein as "egress data packets" or similar names and are Figure 1 The data packets marked with an "E" on the left and heading for LAN 12 are referred to herein as "ingress packets" or similar names and are Figure 1 An egress packet will have a masked version of the IP address of the LAN device where the packet originated, and the IP address of the device on WAN 14 to which it is being transmitted. Conversely, an ingress packet will have the IP address of the device on WAN 14 as its origin, and a masked version of the IP address of the LAN device to which it is being transmitted.

[0045] The damage activity analyzer 20 is a digital logic system comprising, in this example, a processor and memory, a Firewall Traffic Metadata (FTM) module, a Network Device Metadata (NDM) module, a Damage Activity Analysis (CAA) module, a Damage Prevention Module (CDM) module, and a Suspicious Target Metadata (SDM) module. The FTM module obtains its data from the FT module of the firewall 18, either through direct communication with the firewall 18 (e.g., via a Ethernet connection) or indirect communication (e.g., via WAN 14), as indicated by the dashed line. The NDM module can optionally store network device metadata in a content-addressable format, such as content-addressable memory (CAM), so that the device metadata can be retrieved by its IP address. The CAA module uses metadata from the FTM and NDM modules to assign device damage indices (DCI) to various servers, computers, and other devices on the private network 12. The CDM module uses the DCI of network devices to take appropriate actions to address system threats. While the CDM module forms part of the damage activity analyzer 20 in this embodiment, it can also be a separate module that communicates with the damage activity analyzer. The SDM module includes the IP address of the suspicious target, as well as metadata including threat level, threat type, etc. The SDM metadata can be supplemented from a variety of sources, including databases provided in the public network 14 .

[0046] It is important to note that the compromise activity analyzer 20 utilizes metadata from multiple sources, including egress traffic metadata, network device metadata, and suspicious target metadata. As known to those skilled in the art, metadata is data that describes other forms of data, such as the origin, structure, and characteristics of data packets, devices, network endpoints, and the like. The form of metadata can vary, though it is typically in the form of a file, array, table, or list of lists. For example, egress traffic metadata can be obtained from the packet header of egress traffic, such as source IP address, destination IP address, packet importance, packet size, port number, etc. Network device data is conveniently created as a table, sometimes referred to herein as a Compromise Translation Table (CTT), which includes fields such as IP address, MAC address, private port number, device name, function, vulnerability, user, group, and the like. Suspicious target metadata can also be configured as a table that includes the IP addresses of known bad actors, the threat type associated with the IP address, the severity of the threat, and the like. Various metadata structures can be conveniently stored in content-addressable memory (CAM), various metadata structures can be conveniently stored in content-addressable memory (CAM), such as Figure 2CAM 53 in. For example, by storing suspicious target metadata in the CAM, each destination address of the egress traffic can quickly search the suspicious target metadata (which may include thousands of IP addresses) for a match. Other search and metadata structures are well known to those skilled in the art.

[0047] exist Figure 2 In another embodiment of the compromise activity analyzer 20, by way of example only and not limitation, includes a local bus 46 and a central processing unit (CPU) 48 connected to the local bus 46 by a high-speed static random access memory (SRAM) cache 50. Dynamic random access memory (DRAM) main or "main" memory 52 is connected to the cache 50 and the bus 46. In some embodiments, a content-addressable memory (CAM) 53 or other searchable data storage may also be provided. A basic input / output system (BIOS) 54 is connected to the bus 46 and can be reset via a power-on reset 56. The compromise activity analyzer 20 also includes non-volatile memory 58, such as flash memory or a hard drive, a network interface 60, and other input / output (I / O) interfaces 62. It should be noted that this is only one suitable architecture for the compromise activity analyzer. For example, the compromise activity analyzer 20 may be integrated into the firewall 18, implemented on a server, or provided via cloud computing on the Internet 14.

[0048] Figure 3 An example network system 10' is shown that includes multiple private networks 64A, 64B, and 66, and a public network (e.g., the Internet) 14. In this example, private networks 64A and 64B are corporate intranets or similar networks, while network 66 is a service provider network that provides software as a service (SaaS) to customers. For example, service provider network 66 can provide network monitoring for compromised activity for a company (i.e., a customer) associated with corporate network 64B and a private virtual network on public network 14.

[0049] In this example, networks are connected to each other via network connectors, or simply "connectors." A network connector's defining characteristics are that it has one or more private network ports, one public network port, and the ability to provide Connector Traffic Log (CTL) data. For example, a network connector can provide Syslog (a logging protocol) information collected in a Syslog data structure. Netflow data can also be used.

[0050] There are many types of connectors that are suitable for use with the network system 10'. The firewall described above is an example of a network connector, where firewall (connector) traffic log information is stored in Syslog, Netflow, or other data structures to provide a basis for firewall (connector) traffic metadata. Another example of a connector is a network router having a public network port and one or more private network ports, with router traffic metadata collection capabilities. Therefore, as used herein, a "network connector" or simply "connector" is defined as a network device having a public network port, one or more private network ports, and capable of providing connector traffic information or logs (CTLs).

[0051] In this example, private network 64A includes a network connector 68A (including a CTL module) having one or more private network ports 69A connected to devices on network 64A and a public network port 69B connected to damage analyzer 70 and public network 14. This configuration is similar to Figure 1 , where impairment analyzer 70 (including the CTM module) may be physically located near or within network connector 68A, or may be remotely located, for example, as a physical or virtual device on public network 14.

[0052] Similarly, in this example, private network 64B includes a network connector 68B (including a CTL module) having one or more private network ports 71A connected to devices on private network 64B, and a public network port 71B connected to impairment analyzer 76 (including a CTM module) on public network 14 and service provider network 66. Similarly, connected to impairment analyzer 78 is public network port 77B of virtual network connector 78 (including a CTL module), which has private network port 77A. In this non-limiting example, private network port 77A is connected to mobile device 79, which can be monitored by impairment analyzer 76.

[0053] The example network compromise monitoring system described here offers the advantage of detecting compromised activity before an actual intrusion into a private network system can occur. A key source of information is egress traffic metadata, typically reflected at Layer 3, or the network layer, of internet data packets. Specifically, Layer 3 is responsible for all packet forwarding between intermediate routers. While egress traffic metadata alone can reveal very useful information about compromised activity, combining it with network device metadata (e.g., the CTT table mentioned previously) and suspicious target metadata can significantly enhance the detection process.

[0054] Detection and analysis of compromised activity monitors for potential indicators of compromise, including:

[0055] -New communication mode

[0056] -Communications with known threat hosts

[0057] - Beaconing or call-back type activities

[0058] - Abnormal data inflow or outflow to the system

[0059] -Communication on non-standard ports

[0060] -Interaction with new SaaS or application servers

[0061] - Command and control activities

[0062] -Interaction with new or unusual storage on data upload / storage hosts

[0063] -Communications with external servers used to download malware or download more malware (bootstrapping malware) (sometimes called "call-home systems")

[0064] Communications with threat actors conducting surveillance to identify network and system infrastructure while looking for sensitive content (sometimes referred to as communications with “command and control” systems (servers or people using laptops or desktops))

[0065] -Injecting code or malware that could provide persistent surveillance activities (keyloggers, Remote Access Trojans (RATs), etc.)

[0066] -Destruction of data, encryption of data, theft or infiltration of data.

[0067] Hackers have a variety of motivations, ranging from relatively harmless (self-gratification, curiosity) to more nefarious ones. Early detection of hacker activity by detecting patterns of damaging activity can help prevent business-damaging activities, such as:

[0068] - Potential ransomware activity

[0069] - Potential data compromise: In some cases used in conjunction with ransomware

[0070] - Potential data loss: such as sensitive business data or sensitive government data (classified, CUI, FCI), which in some cases is used in conjunction with ransomware

[0071] - Potential data encryption: used in conjunction with ransomware in some cases

[0072] - Potential data or system destruction (“hacktivist” or nation-state attacks on defense or critical infrastructure systems).

[0073] For example, changes from "normal" can be detected by detecting unusual communications over a period of time. For example, a device may exhibit a new communication pattern or a sudden increase in the number of communications. Large data volumes can be detected when the amount of communication with an external host suddenly increases. For example, when communications deviate from the past norm (such as when damage is detected by a two-standard deviation). Monitoring suspicious private network ports, such as port 3389 used for remote desktop control, can provide useful information about damage activity. Beaconing refers to regular routine communications between internal and external hosts and is sometimes considered a sign of damage activity.

[0074] Figure 4 FIG2 is a block diagram of an example cloud-based network compromise activity analysis system 16′, including a connector 74B and a compromise activity analyzer 76. In this example, egress traffic data 82 from connector 74B is input into compromise activity analyzer 76 and processed to determine the level of compromise activity on one or more devices on a customer's private network. To accomplish this task, compromise activity analyzer 76 is connected to multiple modules, including a compromise translation table (CTT) module 84 containing network device metadata, an external data and pointer module 86 containing suspicious target metadata, an internal automated analysis module 88 containing heuristic and statistical analysis, and a machine learning module 90 containing expert system and / or neural network analysis. Figure 4 Also shown is a damage prevention module (CDM) 92 connected to the damage activity analyzer 76 and connector 74B. The CDM 92 is also connected to an automatic and manual integration module 94. The CDM 92 is separate from the damage activity analyzer 76 in this embodiment.

[0075] Continue to refer Figure 4The example compromise activity analyzer 76 includes a target system lookup module 96, a traffic analysis module 98, and a metadata extraction module 100. These three modules analyze egress traffic 82 from connector 74B and generate egress traffic metadata for further analysis. The example compromise activity analyzer 76 also includes a severity impact determination module 102, a compromise risk rating development module 104, and a determination whether to take action module 106. Based at least in part on device metadata from the CTT module 84, these three modules analyze potential compromise activity, estimate the risk of the compromise activity, and determine whether any containment measures are warranted based on predetermined heuristics. As will be explained in greater detail below, if module 106 determines that action is warranted, the compromise prevention module 92 may be brought into play. Finally, the example compromise activity analyzer 76 also includes a potential threat behavior identification module 108, an anomalous activity identification module 110, and a compromise probability determination module 112. These modules communicate with modules 86-90 and provide input to module 104 to develop a compromise risk rating.

[0076] Figure 5 yes Figure 4FIGURE 9 illustrates a block diagram of an example damage prevention module (CDM) 92. As previously mentioned, the damage prevention module 92 interfaces with connector 74B, the damage activity analyzer 76, and the automatic and manual integration module 94. In this example, the damage prevention module 92 includes a damage prevention engine module 114, a module 116 that determines whether updates to the CTT module are required, and a module 118 that interacts with other automatic and manual integrations. These three modules work together to coordinate responses to detected damage activity and update device metadata (CTT) when necessary. The damage prevention engine module 114 can also optionally launch an alert and notification engine module 120, which can optionally launch an execution notification module 122, which can optionally launch a maintenance and update alert module 124. These three modules provide alerts and notifications to system administrators, device administrators, information technology (IT), and other departments. The damage prevention engine module 114 can also optionally launch a create / update report module 126, which can optionally launch a distribute report module 128. The damage prevention engine module 114 can also optionally launch the prevention engine module 130, which can optionally launch the quarantine endpoint module 132, which can optionally launch the report to law enforcement module 134, which can optionally launch the automatic forensics data analysis module 136. These modules respond to serious compromises of network devices (endpoints), for example, by isolating the endpoint from the attack. Depending on the sensitivity of the compromised endpoint (e.g., a server containing confidential information), the compromise may be automatically reported to law enforcement. The damage prevention engine module 114 can also optionally launch the mitigation engine 138, which can optionally launch the monitor active compromise module 140, which can optionally launch the patch endpoint module 142 and the trigger forensics data collection module 144, which can optionally launch the automatic forensics data analysis module 136. In this case, the network device (endpoint) threatened by suspected compromise activity can be "remediated" by, for example, being reassigned a new IP address to mitigate the problem.

[0077] Figure 6 is generated by running e.g. Figure 2An example process 146 implemented by a code segment on a compromise activity analyzer 20 is shown. Process 146 begins at step 148. In operation 150, the compromise activity analyzer 20 receives traffic metadata including at least the originating Internet Protocol (IP) address and the destination IP address of firewall egress traffic. The firewall traffic metadata may be received from the firewall, by inspecting the firewall's egress traffic, or by any other suitable method. Next, in operation 152, the compromise activity analyzer 20 matches the originating IP address of the egress traffic metadata with network device metadata to identify the source device of at least one egress data packet. The network device metadata may be derived through automated network mapping or in a tabular form provided by a network administrator. In operation 154, the compromise activity analyzer 20 matches the destination IP address of the egress traffic metadata with suspicious target metadata to identify the suspicious target of the egress data packet. The suspicious target metadata may evolve over time or may be obtained from a third-party organization. Next, in operation 156, the compromise activity analyzer 20 determines a compromise activity level associated with the at least one source device based on the egress traffic metadata, the network device metadata, and the suspicious target metadata. The level of damage activity can be scaled, for example, on a scale of 1-10, or can be labeled as low, medium, and high. Finally, in operation 158, the damage activity analyzer 20 takes action based on at least one rule regarding the determined level of damage activity. For example, a low level of damage activity can be ignored, a medium level of damage activity can be reported to an administrator of the network device, and a high level of activity can result in an automated response to a real-time threat. Various example actions may include blocking, alerting, and notifying.

[0078] Figure 7 Is to receive including at least Figure 6 Flowchart of an example process 150' for firewall traffic metadata. In this example, process 150' begins at 160. At operation 162, a determination is made as to whether a current firewall traffic metadata file exists. If so, the firewall traffic metadata file is retrieved at operation 164. If not, a new firewall traffic metadata file is created at operation 166. Next, operation 168 determines whether new firewall traffic record data exists. If so, the firewall traffic metadata file is updated at operation 170. If not, or after operation 170, the process continues at operation 172, which determines whether the firewall traffic metadata includes egress traffic metadata. If not, process control returns to operation 168 to await new firewall traffic record data. If so, operation 174 provides the firewall traffic metadata, and process 150' ends at 176.

[0079] Figure 81 is an illustration of an example firewall traffic log file 178, including a list 180 and an example firewall traffic metadata file 182, and the firewall traffic metadata file 182 includes a table 184. In this non-limiting example, the firewall traffic log list 180 can be obtained from a system logging protocol (Syslog) message generated by the firewall. The Syslog message includes a timestamp, a severity rating, a device ID (including an IP address), and information about the specific event. Syslog messages are typically sent over User Datagram Protocol (UDP) port 514. UDP is considered a connectionless protocol in which messages are not acknowledged or guaranteed to arrive. Syslog messages are typically presented in a human-readable format, but need not be. In its header, each Syslog message has a priority level, which is a combination of the code of the process of the device that created the message and the severity level.

[0080] Continue to refer to Figure 8 , the example firewall traffic metadata file extracts metadata from the large amount of Syslog data stored in the firewall traffic records 180. For example, the rows of table 184 can represent communications between devices on the public network (having public IP addresses) and devices on the private network (having private IP addresses). The columns of table 184 can include source and destination IP addresses, port information for private network devices, port information for public network devices, timestamps, flags for egress traffic and ingress traffic, and other relevant factors in this non-limiting example. It should be noted that the egress traffic metadata and ingress traffic metadata can be subsets of the firewall traffic metadata file 182. Alternatively, the egress traffic metadata and ingress traffic metadata can include their own data structures.

[0081] Figure 9 This shows matching the source IP address of the egress traffic metadata with the network device metadata. Figure 6 Example flow chart 152' of operation 152. Example process 152' begins at 186. At operation 188, the source IP address of the egress traffic from the firewall is extracted from the firewall traffic metadata. Next, at operation 190, the extracted source IP address is matched with the network device metadata to identify the originating device. Process 152' then ends at 192.

[0082] Figure 101 is an example network device metadata file structure 194, hereinafter referred to as a damage translation table (CTT) 194. In this non-limiting example, the CTT 194 is a table having rows for various private network devices and columns for various attributes of these private network devices. Examples of private network devices include servers, computers, routers, peripheral devices, etc. In this example, the attributes of the network devices provided by the columns of the CTT include IP addresses, media access control (MAC) addresses, human-readable names, functions, vulnerabilities, users, groups, and other attributes of the network devices. The CTT 194 can be partially populated automatically, for example, using a network imaging tool; but is preferably manually populated by a system administrator of the private network through an appropriate user interface.

[0083] Figure 11 Yes Display Figure 6 A flowchart 154' of an example process 154 for identifying suspicious destinations of egress data packets by matching the destination IP address in egress traffic metadata with suspicious destination metadata is provided. The example process 154' begins at 196, and at operation 198, the destination IP address of the egress traffic is extracted from the firewall traffic metadata. Next, at operation 200, the extracted destination IP address is matched with the suspicious destination metadata to identify the suspicious destination of the egress data packet. The process 154' then ends at 202.

[0084] Figure 12 FIG2 is a diagram of an example suspicious target file 204, including a list 206 of suspicious IP addresses, and an example suspicious target metadata file 208, wherein the file 208 includes a table 210. The list 206 of the suspicious target file can be static or dynamic, and can be generated by commercially available manual methods or heuristic methods. In this non-limiting example, the table 210 of the suspicious target metadata file 208 can be generated at least in part from the suspicious target list 206, and supplemented with additional metadata including IP ranges, threat types, severity, etc.

[0085] Figure 13 yes Figure 6Figure 156 of an example method 156' for determining a level of compromise activity. Method 156' includes a host sensitivity multiplier table 212, a target host score factor table 214, a port importance factor table 216, a communications of concern table 218, a factor / value / result table 220, an example score parameter 222, and an example adjusted compromise concern calculation 224. In this example, the example score parameter has a minimum score of 23.75 and a maximum score of 123.75, which are then normalized to a scale of 1 to 100. The adjusted compromise concern calculation 224 uses two scales based on the Fibonacci sequence to determine adjustments for communication count and data volume. The maximum of the count adjustment and the data volume adjustment is then used with a weighted average to calculate a compromise concern value (CCV) between 1 and 100. One or more rules may also be used to derive a compromise activity level (CAL) from the CCV. For example, CAL may be assigned the value LOW for 1 ≤ CCV < 20, MEDIUM for 20 ≤ CCV < 80, and HIGH for 80 ≤ CCV ≤ 100.

[0086] Figure 14 is a network port metadata file 226 that includes a table 228 containing metadata about one or more private network ports of the firewall. Figure 13 The method includes a port importance factor 216. Outbound traffic to suspicious targets originating from private network ports 3389, 1433, 1521, 1531, 1541, 3306, etc., will affect the level of concern for compromised activity. For example, private network port 3389 is used for remote access such as Windows RDP, among other things. Therefore, as can be seen in this example, the network port metadata file 226 has a port table 228 that includes items such as port number, common port usage (e.g., remote access, database access, etc.), and importance.

[0087] Figure 15 230 is a table with Fibonacci numbers and associated count adjustments and data size adjustments. In this non-limiting example, for each number in the Fibonacci sequence, the count adjustment increases by 5 and the data size adjustment increases by 2. At the 6,765th number in the Fibonacci sequence, the count adjustment is fixed at 100, and at the 12,586,269,025th number in the Fibonacci sequence, the data size adjustment is fixed at 100.

[0088] Further references Figure 13-15 , the general method for determining the damage concern score is as follows:

[0089] 1. Take 50 as the default score source point.

[0090] 2. Use the host sensitivity multiplier to adjust the score by 25% or 50%.

[0091] 3. Use the target host threat score to adjust the number up or down by 50%.

[0092] 4. Apply a factor based on the criticality of the port.

[0093] 5. In this example, this will result in a number between 23.75 and 123.75. Normalize the number to the range 1 to 100.

[0094] 6. Use the communication count and communication volume to adjust the weighted average of the score as follows:

[0095] a. Use the Fibonacci sequence to weight the weighted count and data volume, such as Figure 15 As shown, for this series, the count adjustment increases by 5 and the data amount adjustment increases by 2;

[0096] b. Using the maximum of these scores, calculate the Compromise Concern Score (CCS) by taking a 2× weighted average of the normalized scores.

[0097] Figure 16 yes Figure 6 Example flow chart 158' of process 158 for operating on a confirmed level of compromised activity according to at least one rule. Process 158' idles in process 232 until a compromise concern score (CCS) is received. If the CCS is LOW, process 234 reports one or more potential system compromises before returning to process 232. Since the CCS is LOW, the report can be a regular, scheduled report, such as to a system administrator. If the CCS is MEDIUM, process 236 sends one or more alerts. These alerts have a higher urgency and can be sent immediately to one or more system managers, such as a database server manager or a group manager. Flow control can then proceed to operation 234 for more extensive reporting or return directly to idle process 232. If the CCS is HIGH, process 238 can automatically block the compromised activity, such as blocking a malicious device on a public network or isolating a device infected with malware on a private network at a firewall. Flow control can then proceed to process 236 to send one or more alerts and process 234 to send one or more reports, or return directly to idle process 232. It will be appreciated that the action taken is subject to one or more rules, such as always notify, sometimes alert, or only block under extreme threat conditions.

[0098] Although specific terms and devices are used to describe various embodiments, this description is for illustrative purposes only. The vocabulary used is descriptive and not restrictive. It should be understood that changes and variations can be made by one of ordinary skill in the art without departing from the true spirit or scope of the supported invention. Furthermore, it should be understood that various aspects of the various other embodiments may be interchanged in whole or in part. Therefore, the claims of the present invention should be interpreted in accordance with the true spirit and scope of the invention, and not to be limited or prohibited.

Claims

1. A network damage activity monitoring system, characterized in that: include: A hardware or virtual network connector comprising a digital processor, the network connector having a public network port, at least one private network port, and an associated network connector flow record regarding packet traffic on the network connector, the flow record comprising at least egress traffic metadata, the egress traffic metadata comprising an originating IP address of the egress traffic, wherein packets flowing to the at least one private network port and outgoing from the public network port are egress traffic, and packets flowing to the public network port and outgoing from the at least one private network port are ingress traffic; a digital logic damage activity analyzer comprising a processor and a memory, the digital logic damage activity analyzer receiving the egress traffic metadata of the network connector traffic record and accessing suspicious target metadata and network device metadata including a damage translation table (CTT); the digital logic damage activity analyzer determining a damage activity level of one or more devices coupled to the at least one private network port based at least in part on the suspicious target metadata, the egress traffic metadata, and the network device metadata, including extracting the originating IP address from the egress traffic metadata and matching the extracted originating IP address with the CTT to identify at least a portion of the originating network device, thereby determining the damage activity level of the one or more devices coupled to the at least one private network port; as well as A digital logic damage prevention module includes a processor and memory, and performs one of blocking, alerting, and notifying in response to the determined damage activity level of the one or more devices according to at least one rule.

2. The network damage activity monitoring system according to claim 1, characterized in that: The digital logic compromise activity analyzer may also be capable of accessing ingress traffic metadata, whereby at least a portion of the ingress traffic metadata is used to determine the compromise activity level of the one or more devices.

3. The network damage activity monitoring system according to claim 2, characterized in that: The egress traffic metadata and the ingress traffic metadata are derived from the network connector traffic record.

4. The network damage activity monitoring system according to claim 3, characterized in that: The digital logic compromise activity analyzer may also be capable of accessing private network port metadata associated with the at least one private network port, whereby at least a portion of the private network port metadata is used to determine the compromise activity level of at least one of the devices.

5. The network damage activity monitoring system according to claim 3, characterized in that: The damage prevention module is a part of the digital logic damage activity analyzer.

6. The network damage activity monitoring system according to claim 5, characterized in that: The digital logic damage activity analyzer is a part of the network connector.

7. The network damage activity monitoring system according to claim 3, characterized in that: The above network connector is a firewall or a router.

8. A network device damage activity analyzer, characterized in that: include: a processor; A memory coupled to the processor, comprising a code segment executable on the processor, configured to: (a) extracting firewall traffic metadata, including at least the source IP address and destination IP address of the firewall's egress traffic metadata; (b) matching the originating IP address of the egress traffic metadata with network device metadata, the network device metadata including a damage translation table (CTT) to identify at least one originating device of the egress data packet; (c) matching the destination IP address of the egress traffic metadata with the suspicious target metadata to identify the suspicious target of the egress data packet; (d) determining a level of compromise activity associated with the at least one originating device based on the egress traffic metadata, the network device metadata, and the suspicious target metadata; and (e) take action, in accordance with at least one rule, based on the level of harmful activity determined above.

9. The network device damage activity analyzer according to claim 8, characterized in that: A damage activity level is further determined based on the private network port metadata.

10. The network device damage activity analyzer according to claim 9, characterized in that: The private network port metadata is associated with one or more private ports of the firewall.

11. The network device damage activity analyzer according to claim 8, characterized in that: According to at least one rule, taking action based on the determined level of harmful activity includes at least one of blocking, alerting, and notifying.

12. The network device damage activity analyzer according to claim 8, characterized in that: For each device, the network device metadata includes an IP address and a device type.

13. The network device damage activity analyzer according to claim 12, characterized in that: The network device metadata further includes one or more of a MAC address, a technology name, an organization name, and a department name.

14. The network device damage activity analyzer according to claim 8, characterized in that: Matching the originating IP address of the egress traffic metadata with network device metadata to identify at least one originating device of the egress data packet includes: Creating a list of one or more originating IP addresses of the egress traffic metadata; and The CTT is searched using the above list of one or more origin IP addresses.

15. The network device damage activity analyzer according to claim 8, characterized in that: The suspicious target metadata is stored in a content-searchable format.

16. The network device damage activity analyzer according to claim 8, characterized in that: Matching the destination IP address of the egress traffic metadata with the suspicious target metadata to identify the suspicious target of the egress data packet includes: Creating a list of one or more destination IP addresses of the egress traffic metadata; and Using the above list of one or more target IP addresses, the above suspicious target metadata is challenged as suspicious threat metadata.

17. The network device damage activity analyzer according to claim 8, characterized in that: The egress traffic metadata is analyzed to determine a data rate of the egress traffic to a destination IP address.

18. The network device damage activity analyzer according to claim 8, characterized in that: The egress traffic metadata is analyzed to determine contact or call-back activity to a device IP address via a target IP address.

19. The network device damage activity analyzer according to claim 18, characterized in that: The above-mentioned egress traffic metadata is analyzed to determine contact or call-back activities to multiple device IP addresses through a target IP address.

20. A computer-implemented method for monitoring network equipment for damaging activity, characterized in that: The following steps are involved: Providing firewall traffic metadata to a compromise activity analyzer comprising a digital processor and a memory, wherein the firewall traffic metadata comprises at least egress traffic metadata including a source IP address and a destination IP address of the firewall egress traffic; matching the originating IP address of the egress traffic metadata with network device metadata including a damage translation table (CTT) to identify at least one originating device of the egress data packet; Match the destination IP address of the above egress traffic metadata with the suspicious target metadata; determining a damage activity level of the at least one originating device based on the egress traffic metadata, the network device metadata, and the suspicious target metadata; as well as According to at least one rule, an action is taken based on the determined level of harmful activity.

21. The computer-implemented method for monitoring network device compromise activity according to claim 20, wherein: This includes analyzing the egress traffic metadata to determine a data rate above a predetermined threshold.

22. The computer-implemented method for monitoring network device compromise activity according to claim 20, wherein: The egress traffic metadata is analyzed to determine at least one of a frequency of the egress traffic and a pattern of the egress traffic.

23. The computer-implemented method for monitoring network device compromise activity according to claim 20, wherein: The above network device metadata is analyzed to determine the importance of the device.

24. The computer-implemented method for monitoring network device compromise activity according to claim 20, wherein: Analyze the above suspicious target metadata to determine the severity of the threat.

25. A non-transitory computer-readable medium comprising executable code segments on a digital processor for monitoring a network device for compromised activity, comprising: A code segment for providing firewall traffic metadata, wherein the firewall traffic metadata includes at least egress traffic metadata having a source IP address and a destination IP address of egress traffic from a firewall; a code segment for matching the originating IP address of the egress traffic metadata with network device metadata including a damage translation table (CTT) to identify at least one originating device of the egress data packet; a code segment for determining a damage activity level of at least one originating device based on the egress traffic metadata and the network device metadata; as well as A code segment for taking action based on the determined level of harmful activity according to at least one rule.

26. The non-transitory computer readable medium comprising executable code segments on a digital processor for monitoring network devices for compromised activity according to claim 25, wherein: The egress traffic metadata is analyzed to determine a data rate above a predetermined threshold.

27. The non-transitory computer readable medium comprising executable code segments on a digital processor for monitoring network devices for compromised activity according to claim 25, wherein: The egress traffic metadata is analyzed to determine one of a frequency of the egress traffic and a pattern of the egress traffic.

28. The non-transitory computer readable medium comprising executable code segments on a digital processor for monitoring network devices for compromised activity according to claim 25, wherein: The above network device metadata is analyzed to determine the importance of the device.

29. The non-transitory computer readable medium comprising executable code segments on a digital processor for monitoring network equipment for compromised activity according to claim 25, wherein: Analyze suspicious target metadata to determine the severity of the threat.

Images