Streaming Method and System for Processing Network Metadata

• US 20170013001A1
• Filed: 07/09/2016
• Published: 01/12/2017
• Est. Priority Date: 11/07/2011
• Status: Active Grant

• Current Assignee: NetFlow Logic Corporation
• Original Assignee: NetFlow Logic Corporation
• Inventors: Friedman, William G., Velednitsky, Alexander
• Granted Patent: US 10,079,843 B2
• Time in Patent Office: Days
• US Class Current: 1/1
• CPC Class Codes: H04L 43/16 Threshold monitoring
• CPC Class Codes: H04L 47/20 Traffic policing
• CPC Class Codes: H04L 61/4511 using domain name system [DNS]
• CPC Class Codes: H04L 63/102 Entity profiles
• CPC Class Codes: H04L 63/1416 Event detection, e.g. attack signature detection
• CPC Class Codes: H04L 63/1425 Traffic logging, e.g. anomaly detection
• CPC Class Codes: H04L 63/20 for managing network security; network security policies in general filtering policies H04L63/0227

Abstract

A method and system for processing network metadata is described. Network metadata may be processed by dynamically instantiated executable software modules which make policy-based decisions about the character of the network metadata and about presentation of the network metadata to consumers of the information carried by the network metadata. The network metadata may be type classified and each subclass within a type may be mapped to a definition by a unique fingerprint value. The fingerprint value may be used for matching the network metadata subclasses against relevant policies and transformation rules. For template-based network metadata such as NetFlow v9, an embodiment of the invention can constantly monitor network traffic for unknown templates, capture template definitions, and informs administrators about templates for which custom policies and conversion rules do not exist. Conversion modules can efficiently convert selected types and/or subclasses of network metadata into alternative metadata formats.

Claims

1. A method of processing network metadata generated on a network transmitting network traffic using one or more network protocols, the network including devices at least some of which receive network traffic through an ingress interface and transmit network traffic through an egress interface, the method comprising the steps of:

receiving network metadata from a plurality of sources in a data processing system, in at least one data format;

determining the type or character of said network metadata;

processing said network metadata to extract useful information therefrom; and

converting at least a portion of said network metadata into one or more different data formats that are used in said data processing system for other system metadata, in response, at least in part, to the results of said determining step.

2. The method as set forth in claim 1, wherein said processing step is performed while said network metadata is in transition on said network between a network device that generated said network metadata and a device that is able to store said network metadata.

3. The method as set forth in claim 2, wherein said processing step is achieved by applying at least one policy governing network metadata processing.

4. The method as set forth in claim 3, wherein said at least one policy is applied for the purpose of detecting traffic on said network indicative of a potential security threat.

5. The method as set forth in claim 4, wherein said at least one policy includes the steps of:

comparing the source of incoming network traffic to a predefined list of monitored off-limit devices on said network;

if the destination IP address is on a predefined list of off-limit devices, storing the source IP/port, as well as the destination IP/port in a potential alert list, along with the number of bytes and packets reported in the ingress NetFlow record;

examining output records to determine if the source IP/port and the destination IP/port match an entry in the potential alert list;

if a match is found, treating such match as an indication that an internal host replied to an outside peer request; and

generating an alert message in a timely manner to inform of a potential botnet infection.

6. The method as set forth in claim 4, wherein said at least one policy includes the steps of:

collecting information about internal network devices communicating with external network devices;

said information comprising a list of communicating devices'"'"' IP addresses and protocols;

applying a streaming cluster analysis method to determine patterns in communications between the communicating devices;

identifying abnormal instances of communications between the communicating devices by the presence of small disjoint patterns in the set of all computed patterns;

generating an alert message in a timely manner to inform of a potential botnet infection if at least one abnormal communication pattern is identified.

7. The method as set forth in claim 3, wherein said at least one policy is applied for the purpose of identifying traffic spikes on said network.

8. The method as set forth in claim 7, wherein said at least one policy includes the steps of:

comparing the source of incoming network traffic to a predefined list of monitored devices on said network;

if the source IP address is on a predefined list of devices, storing the source IP in an in-memory database along with the number of bytes and packets reported in the ingress NetFlow record;

at predefined intervals examining the in-memory database and identifying devices which exceeded a threshold set forth by a network manager;

generating an alert message in a timely manner to inform of a traffic spike.

9. The method as set forth in claim 3, wherein said at least one policy is applied for the purpose of improving the reliability of capturing NetFlow traffic on said network.

10. The method as set forth in claim 9, wherein said at least one policy includes the steps of:

receiving one or a plurality of NetFlow messages over an unreliable network transport protocol;

optionally converting said received NetFlow messages into one or a plurality of formats other than NetFlow, different flavor of NetFlow or same format as the received NetFlow;

forwarding said received or converted messages to a plurality of end points over an unreliable network transport protocol, to at least one end point over a reliable network transport protocol, or to at least one end point over an unreliable network transport protocol and to at least one end point over a reliable network transport protocol.

11. The method as set forth in claim 3, wherein said at least one policy is applied for the purpose of reducing the number of NetFlow messages that arrives at the device that stores said network metadata on said network.

12. The method as set forth in claim 11, wherein said at least one policy includes the steps of:

receiving a plurality of NetFlow messages;

identifying similarities in said received NetFlow messages;

consolidating information in the received NetFlow messages identified as similar into one or a plurality of NetFlow messages;

discarding NetFlow messages for which information was consolidated; and

forwarding consolidated NetFlow messages to the device that stores network metadata on said network.

13. The method as set forth in claim 12, wherein said step of forwarding consolidated NetFlow messages is performed after the passage of a configurable time period.

14. The method as set forth in claim 3, wherein said at least one policy is applied for the purpose of detecting when a network interface on said network becomes inoperable.

15. The method as set forth in claim 14, wherein said at least one policy includes the steps of:

establishing a threshold time period during which the absence of an interface identifier in the incoming network metadata signifies said network interface'"'"'s inoperable state, said established threshold time period being variable depending on the time and geographic criteria;

monitoring network metadata related to said network interface;

generating an alert message in a timely manner to inform of an inoperable state of said network interface if network metadata related to said network interface fails to be detected for a period in excess of said threshold time period.

16. The method as set forth in claim 3, wherein said at least one policy is applied for the purpose of measuring network latency using network metadata on said network.

17. The method as set forth in claim 16, wherein said at least one policy includes the steps of:

establishing a threshold time period during which a network device which requested services of a Domain Name Server (DNS) must receive a response from said DNS service;

monitoring network metadata describing communications between network devices and DNS services;

computing time elapsed between said network device request for a DNS service and receiving a response from that DNS service;

comparing said elapsed time with said threshold time period; and

generating an alert message to inform of excessive network latency.

18. The method as set forth in claim 3, wherein said at least one policy is applied for the purpose of providing real time network visibility per application type across a plurality of devices on said network.

19. The method as set forth in claim 3, wherein said at least one policy is applied for the purpose of producing a list of most active hosts over a specified time period on said network.

20. The method as set forth in claim 19, wherein said at least one policy includes the steps of:

receiving a plurality of network metadata messages;

identifying network metadata related to individual network hosts;

aggregating network metadata for each identified network host;

selecting a configurable size list of the network hosts which produced most network connections; and

reporting said list of the network hosts which produced most network connections.