Patent Application
20060075093
1. Field of the Invention
The present invention relates to methods and systems for detecting and mitigating the effects of flow anomalies in a network communication system. More particularly, the present invention relates to methods and systems for defining and monitoring flow conditions, analyzing the conditions, and reacting in ways to improve network security, usefulness and efficiency. As an example, the system would discard or dampen excess packet flows to minimize the impact of denial of service attacks and to prevent or minimize their effects on data networks. These methods and system functions are expected to be used within a one or more network infrastructure device and also coordinated across many diverse network system devices.
2. Description of the Prior Art
Interconnected computing systems having some sort of commonality form the basis of a network. A network permits communication or signal exchange among computing systems of a common group in some selectable way. The interconnection of those computing systems, as well as the devices that regulate and facilitate the exchange among the systems, represent a network. Further, networks may be interconnected together to establish internetworks. For purposes of the description of the present invention, the devices and functions that establish the interconnection represent the network infrastructure. The users, computing devices and the like that use that network infrastructure to communicate are referred to herein as attached functions and will be further defined. The combination of the attached functions and the network infrastructure will be referred to as a network system.
Presently, access to applications, files, databases, programs, and other capabilities associated with the entirety of a discrete network is restricted primarily based on the identity of the user and/or the network attached function. For the purpose of the description of the present invention, a “user” is a human being who interfaces via a computing device with the services associated with a network. For further purposes of clarity, a “network attached function” or an “attached function” may be a user connected to the network through a computing device and a network interface device, an attached device connected to the network, a function using the services of or providing services to the network, or an application associated with an attached device. Upon authentication of the offered attached function's identity, that attached function may access network services at the level permitted for that identification. For purposes of the present description, “network services” include, but are not limited to, access, Quality of Service (QoS), bandwidth, priority, computer programs, applications, databases, files, and network and server control systems that attached functions may use or manipulate for the purpose of conducting the business of the enterprise employing the network or might otherwise provide or use data or information transfer. The basis upon which the network administrator grants particular permissions to particular attached functions in combination with the permissions is an established network usage policy. For example, one policy may be that any user (one type of attached function) with an employee identification number is granted access to the enterprise's electronic mail system at a specified bandwidth and QoS level.
Events and activities do occur that may be harmful to the network system. For purposes of this description, harm to the network system includes, for example, denying access to the network, denying access to the services of the network, unauthorized access to the services of the network, intentionally tying up network computing or data relay resources, intentionally forcing bandwidth availability reduction, and restricting, denying or modifying network-related information. There are currently two generally available forms of network protection designed to minimize such types of network harm: firewalls and an Intrusion Detection Systems (IDS). Firewalls monitor, analyze and enforce all in one, and are designed to prevent the passage of packets to the network based on certain limited specific conditions associated with the packets. Firewalls do not permit packet passage for the purpose of further analysis nor do they enable assigned policy modifications.
IDSs typically only monitor traffic. They do not analyze nor do they enforce. They are generally more effective at monitoring/detecting potentially harmful traffic than are firewalls. They are designed to observe the packets, the state of the packets, and patterns of usage of the packets entering or within the network infrastructure for harmful behavior. However, until recently with the availability of the Distributed Intrusion Response System by Enterasys Networks of Andover, Mass., common owner of the invention described herein, the available IDSs do not prevent packet entry to the network infrastructure. Further, for the most part, they only alert a network administrator to the existence of potentially harmful behavior but do not provide an automated response to the detected occurrence. There is some limited capability to respond automatically to a detected intrusion. However, that capability is static in nature in that the response capability is ordinarily restricted to limited devices of the network infrastructure and the response is pre-defined and generated by the network administrator for implementation on specified network infrastructure devices.
For the most part, existing IDSs, whether network-based (NIDS), host-based (HIDS) or a combination of the two (NIDS/HIDS), report possible intrusions to a centralized application for further analysis. That is, all detected potentially harmful occurrences are transferred to a central processing function for analysis and, if applicable, alarm reporting. The detection functionality may reside in one or more appliances associated with one or more network devices. Each appliance provides its own report to the central processing function with respect only to those packets passing through it. The central processing function then conducts the analysis and the alarm reporting. Network administrators often restrict the intrusion detection functionality to certain parts of the network system rather than to the entirety of the system. That is, for example, all packets entering a network infrastructure from an attached function may be forced to enter through one or more select entry functions. Those select entry locations form a choke point or bottleneck arrangement in the network. IDS and their placements are typically chosen for throughput capacity and to simplify manual policy changes that may be required based upon an alarm occurrence.
Upon receipt of an alarm, the network administrator can either do nothing, or implement a response function through adjustment of the operation of one or more network infrastructure devices. The implementation of a response function may take a relatively significant amount of time, with the response delay, or latency, potentially allowing greater harm to, or at least reduced effectiveness of, the network system prior to the implementation of a response to address the triggering activity or event. In a network system in which only a select few network infrastructure devices have intrusion response functionality, the implemented response may result in more widespread restriction of network usage than may be warranted by the triggering activity or event. The response may also be excessive if a greater number of network infrastructure devices are configured to respond to an attack than the scope of the intrusion warrants. It would be preferable to have a response capability that is implementable as quickly as possible in a manner that substantially ensures repulsion/neutralization of a triggering activity or events, such as an attack, while the system goes through the process of establishing a revised set of policies to specifically address the activity or events only, and in a manner targeted at only the source of the attack.
As indicated, other than the Enterasys Distributed Intrusion Response System, the presently available IDSs only report the existence of potentially harmful activities, events or occurrences, and do not enable responsive policy modification. Any adjustment to the state of permitted attached function network usage typically occurs manually after detection and evaluation on an ad hoc basis. Therefore, what is needed is a network function arranged to produce a rapid response to a detected flow condition or event through changes in the operational features or policies of one or more network infrastructure devices. The one or more network infrastructure devices for which a change is effected may or may not be directly associated with the detected condition or detection location.
Importantly, the ability to respond in an organized manner to distributed attacks is currently very limited. For purposes of this discussion, a distributed attack is one in which a plurality of network system devices are included in the activity. A network system having network intrusion detection “protection” may nevertheless be harmed by a distributed attack. That is, individual network infrastructure devices may not be compromised in their operation, but a plurality of network system devices may be used in combination to compromise a specific network system device or affect the system bandwidth available for use. An example of a distributed attack is the SQL Slammer. By the time the network administrator recognizes the nature of the distributed attack, it may be too late to implement policy changes on the individual network system devices associated with the distributed attack. Therefore, what is needed is a response system capable of effective detection and response to distributed attacks.
A detrimental effect of a DOS attack is the consumption of a substantial portion of available bandwidth in the network. In some instances, the network devices may have adequately protected control functions that are not impacted by a DOS attack. The problem occurs in the fact that such devices will not degrade or fail but that they will instead continue to forward the harmful traffic, in effect facilitating the infection of other network or infrastructure devices and attached functions of the network system. That, in turn, causes a greater consumption of network bandwidth until enough signal forwarding devices are involved and generate enough data network traffic in total such that valid traffic may no longer be forwarded effectively on the network links.
Another intentional activity harmful to network system operation is the port scan. Port scans are computer programs configured by hackers to learn about the interior of a data communication network as well as vulnerabilities in a data communication system. A port scan uses valid network protocol mechanisms where one data communication system establishes communication with another system. Attempted communications by opening both Transport Control Protocol (TCP) and Uniform Datagram Protocol (UDP) “ports” from 1 to 65000 is a typical approach used in a port scan. In this process, it is the intent of the hacker that the communication system being probed will respond to the probing station each time port is opened, indicating the presence of that port. It is by learning which ports are present that a hacker can potentially determine the device type and the system's vulnerability to attack. In addition, these scans and responses may consume a fair amount of bandwidth.
A firewall or IDS function may be useful in detecting such events. The information that they provide must be analyzed by a central processor and a response implemented through one or more signal forwarding functions. That process takes time and may consume more network system resources than may be required to respond to the distributed scanning event. It would be preferable to take advantage of the existing functionality of signal and packet forwarding devices to detect and/or respond to this type of scanning process and other triggering events.
Therefore, what is needed is a method and related system to detect, notify, and/or respond to, triggering events quickly and effectively. Further, what is needed is such a method and related system that provides for such capability through existing network signal forwarding devices capable of making normal forwarding and traffic classification decisions. The method and related system preferably operate within the confines of the existing network infrastructure in a localized manner so as to minimize the impact on the remainder of the network that may not be affected by the triggering conditions or events. Further, the system and methods are preferably scalable to operate across multiple devices to provide efficient DOS and other event detection and prevention.
The present invention is a method and related system to detect, notify, analyze and/or respond to, triggering flow metric conditions or events quickly and effectively. The invention preferably operates within the confines of the existing network infrastructure in a localized manner so as to minimize the impact on the remainder of the network that may not be affected by the triggering conditions or events. The invention takes advantage of many of the existing classification and flow metrics instrumentation capabilities of network infrastructure routing/switching devices. The invention also takes advantage of the existing capability of network devices and systems that track signal exchanges in the form of flows (a logical representation of communication between or among attached functions) to identify the presence of a threat (potentially harmful activity) to the communication system. The method and related system of the present invention provides several response mechanisms to mitigate the threat and to alarm network administrators of the presence of detected conditions, activities, and events. For purposes of describing the present invention, it is to be understood that flows in a data network can be thought of as the signal or packet flows or logical “conversations” between devices of the network system, functions attached to the network system, or combinations thereof. Flows may be further defined at many levels such as, for example, all traffic between any two MAC addresses, or all traffic from a single IP server based on its IP (layer 3) address. Flows may be unidirectional or bi-directional, they may use any fields or data in the data packets to determine or help determine flow definition. Further, flow metrics are the status, timing and history based data, and derived information about any specified flow or flows. Flow metrics may include information about only a specific flow, or may use information from multiple flows and other data available or derived from the flows, or network's status or events and other information. A flow metric event is the occurrence of a condition determined by a set of parameters, including flow metrics, defined to be of interest or to be monitored by the network system. While always including flow related information, these flow metric events might include any other network data, status or related or relevant information. As an example, a flow metric event could be defined to be triggered if the aggregate flows egressing a single backbone port “M” exceed value “X” between 8:00 AM and 5:00 PM, and value “Y” all other times except if redundant port “N” is in use. It is easily understood that there is a wide variety of ways to define specific signal or data flows, and a very wide variety of parameters and status and conditions which could aid in defining a vast set of flow metric events. Of particular interest, is the use of those flow metric events that are indicative of network harm and the ability of the analysis and response function to generate mitigating changes in network access and use.
The present invention employs existing forwarding device knowledge and control and management functions to detect changes in the flow metrics which may indicate harmful or potentially harmful activity. The communication of this flow metric event information, coupled with an analysis function, enables a policy change by a centralized system, a localized response by the reporting device(s), and/or distributed response by other forwarding devices.
In one example of the method of the present invention, anomalies in the flow metrics are detected in a network system by monitoring the rate of data flow creation, flow counts and analyzing the traffic patterns in the flows. Many network infrastructure devices forward traffic based on a flow definition, or they monitor network level conversations with flow-based tracking. The invention is configured to detect conditions or events, such as excessive flow creation rates, based on attached-function-to-attached-function exchange protocols at any of the layers of the OSI model. The invention then provides for adjustment of network device operation through defined remediation policies based on where the events were detected and/or other status and/or network data.
The system of the present invention includes three primary functions. The first is a Detection Function. The Detection Function preferably includes a set of sub-functions used to monitor flow metrics for critical triggering events as indications of network system threats. When a threat pattern is detected, the Detection Function triggers notification of the event to an Analysis Function. Outputs from the Analysis Function are typically implemented or “enforced” by a Response Function. The Response Function preferably includes a set of sub-functions to generate various network operation outcomes responsive to the signals or packets indicative of harmful or potentially harmful activity. These Response Functions may be enabled on a per device, per channel, per port, per set of channels, per set of ports, or per set of devices arrangement. Further, the functions may be operable in a format compatible with IEEE 802.1 Q Virtual LAN service, IEEE 802.11 Wireless LAN service, and WAN/MAN switch routers with channelized interfaces. In a generalized network wide model, the Response Function may provide enforcement through a Policy Management driven distribution and rule based enforcement model.
The method of the present invention involves the following steps, all or a portion of which may be used to establish an attack monitoring and response functionality. The steps include monitoring the network system for flow metrics events, analyzing the monitored flow metric events and other information, and generating a response deemed responsive to any analyzed flow metric events and other information determined to require a response. In another aspect of the method of the present invention, steps include: 1) establishing a flow definition for each monitored flow, 2) monitoring one or more flows associated with the operation of the network system, 3) associating each flow definition with a flow counter, wherein the flow counter generates count information for the flow definition, 4) defining particular count information or other events as a triggering condition (or conditions), 5) upon determining that a triggering condition exists, generating a notification to the analysis function, 6) analyzing the flow event(s) and potentially other information, and 7) generating a response by changing one or more policies associated with one or more network infrastructure devices, one or more attached functions, or both.
The related system for implementing the present invention includes a Detection Function for monitoring defined flows associated with the network system, and detecting defined triggering conditions, and a Response Function for responding to triggering conditions defined to require a response and implementing a change of condition of the network system. The system may also further include an Analysis Function. In another aspect of the invention, the system includes: 1) a monitor sub-function for monitoring flows associated with the network system, 2) a flow definition sub-function for defining activity types to be monitored, 3) a monitor counter sub-function for counting the defined activity types, 4) a notification sub-function for initiating a notification in the network system to a monitored flow based on a count or other metrics of a defined activity type, 5) analysis of the notification(s) and 6) a response function for responding to the response function by triggering a change of condition of the network system including not only what is monitored but what is forwarded or none or both.
In an aspect of the invention, there is an article of manufacture comprising a machine-readable medium that stores executable instruction signals that cause a machine to perform the method described above and related methods described herein.
The details of one or more examples related to the invention are set forth in the accompanying drawings and the description below. Other features, objects, and advantages of the invention will be apparent from the description and drawings, and from the appended claims.
The present invention is a system and related method to detect through one or more network infrastructure forwarding devices potentially or actually harmful activity in network system packet or signal traffic. The detected information is analyzed and reported to a centralized or distributed policy management and enforcement function, acted upon by the detecting device or devices, or a combination of the two. Generally, the system provides a method for using flow metrics to determine whether operation of a portion or all of a network system should be adjusted, such as through dynamic policy changes, based on a triggering condition. Referring to
With reference to
The process 200 includes the step of monitoring the network system for the flow metrics that have been established (step 202). The monitored flow metrics information is preferably recorded and, if desired, correlated with other flow metric and/or network system information (step 203). The system determines whether one or more flow metric triggering conditions or events have been detected by the monitoring step (step 204). If not, the monitoring continues without further activity. If a triggering flow metric condition has been detected, an Analysis Function analyzes the condition and, optionally, other events or network system information, for the purpose of determining the form of a response to be initiated, if any (step 205). The process 200 further includes the step of generating and distributing to one or more devices of the network system one or more policy changes based upon the analysis (step 206). The analysis, policy change decision, the triggering condition, and any outcomes may be logged (step 207). If it is deemed necessary or useful, the established flow metrics, responses, or combinations thereof, may be modified (step 208) and the process continued. Although the process 200 may be performed sporadically or periodically, it is preferably performed substantially continuously. Further the steps may be implemented in multiple devices and configured to provide communications among the steps running in parallel, serial or altered order but so as to implement the general process.
Referring again to
One or more of the devices of the infrastructure 101 may include one or both of a Detection Function module 108 and a Response Function module 109. For purposes of illustration, network infrastructure devices 105a, 105b, 106, and 160 each includes the Detection Function module 108 and the Response Function module 109, while server 103 includes the Response Function module 109. It is to be understood that any of the forwarding devices of the network infrastructure 101 may include either or both of modules 108 and 109. Additionally, server 103 may also include both but preferably includes Response Function module 109. Further, it is to be noted that either or both functions may be configured on a per device or per port/channel basis. It may include one or more of the detection sub-functions to be described herein, as well as command and communication functions of the type generally associated with network operation servers. It is to be understood that in a comprehensive network infrastructure, not all signal transferring devices may include the functionality embodied in the two modules. Any network infrastructure device including the module 108 will be referred to herein as a network detection device and any network infrastructure device including the module 109 will be referred to herein as a network response device. Further the Analysis Function (110) preferably implemented in a server (such as 103) may also be located in either detection or response devices, in whole or in a limited form. These functions are capable of communicating with all other functions in all devices. The communication capability may take many forms with SNMP to be used in a preferred embodiment.
The Detection Function may configured on network infrastructure devices through any of a number of well known means. Preferably, a detection function template is created and employed to configure all defined parameters for each sub function described herein. Similarly, the Response Function is configured on selected devices using a response function template. The two templates are interactive in that one or more defined pointers of one point to conditions to be activated in the other. Module 108 includes one or more of the four sub-functions. The four sub-functions are: a) a monitor sub-function; b) a flow definition sub-function, c) a monitor counter sub-function and d) a notification sub-function. The monitor sub-function associates new traffic flows with the address of a particular network infrastructure device. The flow definition sub-function defines the traffic flow for the associated network infrastructure device. The monitor counter sub-function establishes flow creations and counts active exchanges associated with identified flows. The notification sub-function initiates communication to the analysis function or response function based upon flow metric triggering events. The Analysis Function, which performs the function of analyzing the flow event information, such as flow metrics, including count information, determines whether a response, such as a filter or dynamic policy change, is to be implemented. The Analysis Function is particularly useful where harmful network activity such as DOS attacks can typically be determine only by analyzing data and events from more than one device or detection function. Any of the functions may exist or be implemented on one or more devices of the network system. They may be located in central devices, network entry devices or servers. Any one or more of the functions may be centralized or distributed or implemented in a redundant manner.
The monitor sub-function associates the flow metrics for attached functions with one or more specific network infrastructure devices of the network system 100 whether, the attached functions monitored are directly or indirectly attached to the particular network infrastructure device used for the association. For example, as illustrated in
The monitor sub-function of the Detection Function establishes the basis for determining the characteristics of a particular flow under monitor for potentially harmful activity. The present invention is directed to evaluating network traffic for potentially harmful activity by monitoring for unusual flow events. Such events may be generated by a particular attached function, they may be directed to a particular attached function, or they may relate to an exchange between two or more attached functions. The events may also involve a particular network infrastructure device. For these reasons, the monitor sub-function may be associated with the source address or destination address of an attached function or a network infrastructure device involved in a flow under monitor. It may also be associated with a bilateral address pair involved in a flow under monitor; that is, a source address/destination address pair. Further, it may be associated with the ingress and/or egress ports of a network infrastructure device, as well as system aggregate flows, port group ingress aggregates, channel group ingress aggregates, port group egress aggregates, channel group egress aggregates, port-to-port flows, and channel-to-channel flows. A few will be described herein; however, it is to be understood that the system administrator may set up to monitor any sort of flow to be examined for triggering events or conditions.
The source address monitor sub-function is a monitor function that examines only the flows in the network system generated by a particular attached function. The source address monitor sub-function may be enabled to monitor communications traffic on a port by port basis, or from a system wide point of view. When implemented on a system wide basis, the data flows are monitored for all ports in the system simultaneously. In certain situations, such as when the ingress port on a network infrastructure device where the monitor sub-function is to be enacted is a link aggregated port (IEEE 802.3AD interface), the network system must correlate events across multiple ports into a single match result when received packets match a source address monitor definition.
To illustrate the flow types associated with the source address monitor sub-function with reference to
There are multiple uses of a source address monitor sub-function, in data communication networks utilizing Internet Protocol version 4 (IPv4). The source address monitor sub-function may be used to detect port scans, virus-initiated attacks (such as SQL-Slammer) or network ICMP spray attacks. The source address monitor sub-function also enables the network administrator to gauge the amount of network connections a particular source address is generating. If anomalous, the network infrastructure device port to which the particular attached function associated with that source address is connected to the network system may be assigned a changed policy restricting input in response to the anomaly.
The destination address monitor sub-function is a monitor function that examines only the flows through the network system sent from a network system device to a specific attached function. The flow types associated with the destination address monitor sub-function with reference to
There are multiple uses of a destination address monitor sub-function in a network system using IPv4. The destination address monitor sub-function may be used to detect port scans of a specified system, virus initiated attacks (such as SQL-Slammer), network ICMP spray attacks or distributed DOS attacks targeting the attached function specified by the destination address.
The bilateral address pair monitor sub-function examines flows based exchanges between two attached functions attached to the network infrastructure. To illustrate the flow types associated with the bilateral address pair monitor sub-function with reference to
The ingress port monitor sub-function and the egress port monitor sub-function are similar to one another but are independent of source/destination relationships. In particular, each examines flows exchanged through a network infrastructure device based on port activity, whether ingressing or egressing the network infrastructure device. To illustrate the flow types associated with the ingress or egress port monitor sub-function with reference to
For each type of flow monitoring sub-function selected, the system of the present invention is further configured to define the monitored flow. In particular, the flow definition sub-function provides a mechanism for identifying the attributes of each flow monitored as part of the detection and mitigation capability. The information associated with the flows monitored may be of considerable detail or of relatively little detail, dependent upon the detection and mitigation needs, as well as the level of capability of the network infrastructure device or devices employed to perform the Detection Function. That is, there are many possible definitions for a flow and different hardware types and packet look up/forward mechanisms may provide monitor flow information with varying degrees of granularity. For instance, a simple OSI Layer 2 based network infrastructure device may be aware of and therefore only able to provide Media Access Control (MAC) addresses and packet types. Alternatively, a basic IPv4 switch/router network infrastructure device may have the ability to classify flows based on IP source/destination address pairs, Class of Service (CoS) value, and IP packet type. An advanced IPv4 switch/router network infrastructure device may have the ability to examine packets based on IP source/destination address pairs, CoS value, IP packet type, and Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and/or Stream Control Transmission Control Protocol source/destination address ports. Moreover, it is contemplated that higher level network infrastructure devices will examine flows based on individual TCP sessions.
While there may be a great many flow definitions possible, in general, it appears that several may be of use to cover most flow cases of interest. Table 1 below sets out examples of suitable flow definitions; however, it is to be understood that other flow definitions may include more or less of the information associated with these preferred ones.
The flow definition sub-function allows the network administrator to define the logical constructs or patterns that constitute the flows to be monitored. Further, multiple flow definitions may be used for each flow under monitor and each flow definition may encompass multiple flows under monitor. As an example, the network administrator may be interested in tracking both IPv4 and IPv6 flows at the ingress port of a network infrastructure device. As another example, the administrator may establish a flow definition to be tracked on a per port, per source address, destination address of bi-lateral address pair. Flow definitions may be structured to allow the network administrator to match packets with high or low granularity. An example of a high granularity (much detail) monitor sub-function/flow definition sub-function set would involve tracking flows based on ingress port, egress port, source address, destination address or bilateral address pair. An example of a low granularity (less detail) monitor sub-function/flow definition sub-function set would involve tracking of all new IPv4 flows from an attached function to any destination IPv4 address with any IPv4 packet type, with any ToS value, to and from any source/destination port. Further, the network administrator may set fine grain flow definitions to be matched against particular monitor sub-functions. As an example the administrator might only monitoring traffic to a destination IPv4 address only for Hyper Text Transfer Protocol (HTTP) (destination port 80).
The monitor counter sub-function of the system of the present invention provides a mechanism for gathering information to be acted upon through the Response Function related to the flows under monitor as defined. The monitor counter sub-function is configured to record the occurrences of flow creation as well as the number of active flows for a specific flow definition. The network administrator may establish information collection parameters of interest for each flow definition. The monitor counter sub-function may be a simple counter mechanism that increments with each new flow creation or a group of counters that includes details on active flows, peak and average flow creation rates as well as historical data. The network administrator may select what counters are implemented on a per flow-monitoring basis. The information may be retained locally or remotely, persistently or temporarily.
While there may be a great many counter formats of use, in general, it appears that several may be of use to cover most flow metric cases of interest. Table 2 below sets out examples of suitable flow metrics and counters; however, it is to be understood that other flow metrics and counters may include more or less of the information associated with these preferred ones.
It is further contemplated that in network systems including available information processing resources, the network administrator may further gather information referred to as Time stamp of last new flow creation value, corresponding to a time stamp associated with the creation of the last new flow as defined by the monitor sub-function/flow definition sub-function pair. Additionally, Unique flow statistics may be gathered, preferably including: a) average packets per defined time interval counter; b) peak packets per define time interval counter; c) average bytes per time interval counter; d) peak bytes per time interval counter; and e) time since last packet received counter. These statistics may be maintained for each unique flow. The default time interval is one second, although an operator can define other values. Further, the administrator may configure the system to generate System-wide aggregate instantaneous, average and peak counters over defined time intervals, corresponding to the system-wide aggregate total for active flows, attempted and failed new flow establishments over the operator define time interval.
The information acquired through the various counters provided by the monitor counter sub-function may be compared to known, expected or threshold information. That comparison forms the basis for determining whether an anomaly or flow metric event has been detected in the network system.
The Analysis Function executes based on information parameters established by the network administrator. A response is triggered by matching predefined or dynamically derived values that can be compared values instrumented by the monitor counter sub-function. The Analysis Function compares statistics from multiple monitor counter sub-functions and uses mathematical and logical operations to produce test values. When test criteria have been validated, a response may be initiated. Evaluated statistics may be monitored from local or remote storage or a combination of the two. In general then, the event detection capabilities of the system of the present invention are derived comparing values and the Analysis Function may correlate multiple events.
In the preferred embodiment of the present invention there are two classes of responses; basic and advanced. Basic responses are provided by the DRS and provide a simple method to react to conditions in the data communications device or system and are based on administrator-defined values. Basic triggers can be defined based on the following two mechanisms:
1.) Threshold Exceed over a defined time interval trigger function:
2.) High Water Mark/Low Water Mark Trigger Function
Advanced triggers are derived from the basic trigger mechanism, but add the ability to compare current multiple observed values, any type of mathematical operation and the ability to utilize logs history and correlation functions based on history, other devices and comparison files of expected operation. They may include other network status or events not related to those of the Detection Function. As previously indicated, examples of these types of triggers are disclosed in the referenced pending application of John Roese et al.
The Response Function of the present invention defines the policies or actions that may be enabled or changed in reaction to a trigger. When an observed activity count falls below a specified triggering value, the action may be disabled or the policy may revert back to its original state. Nevertheless, in some instances the network administrator may wish to override default low water mark conditions to effect a policy change or a modifying action, or to prevent such a change. For that reason, the present invention contemplates permitting the network administrator to remotely disable an action via any of the systems available to configure network infrastructure devices including, but not limited to, Simple Network Management Protocol (SNMP), remote console, terminal session, Web interface, etc.
It is to be understood that there may be an unlimited number of actions or steps that may be enabled in response to a flow metric trigger event. Some examples of particular actions implemented directly, or through policy driven mechanisms, available to the network administrator include:
11. System History Table Update Action:
The present invention supports both local and distributed modes of operation. In its simplest form, the Detection and Response Functions operate on a single communications device with a minimal analysis function. In a distribute mode, there is a communication function that can be utilized by or associated with all sub-functions and functions to distribute various functions, actions and storage beyond the single system. For example, the Response Function may be centralized on another server system.
Other triggering condition detection methods may also be employed in the context of the system and method of the present invention. Multiple Response Functions can be enacted by a single flow metric trigger. It is expected that network administrators will at least enable Logging and SNMP Traps with one or more of the Response Functions. The Response Functions may further include the implementation of static and/or dynamic policy changes as described in the referenced pending application of John Roese et al.
The following is a list of a few possible devices (but not limited to only those devices) that may contain any one or more of the functions described herein: network switches, data switches, WAN and MAN data relay devices, routers, firewalls, gateways, computing devices such as network file servers or dedicated usage servers, management stations, network connected voice over IP/voice over data systems such as hybrid PBXs and VoIP call managers, network layer address configuration/system configuration servers such as enhanced DHCP servers, enhanced Bootstrap Protocol (bootp) servers, IPv6 address auto-discovery enabled routers, and network based authentication servers providing services such as RADIUS, extensible authentication protocol/IEEE 802.1X or others.
As indicated above, in order to distribute templates changes to network infrastructure devices, network system 100 may employ SNMP. The network administrator provisions the policy information of the terminus of a network cable associated with the attached function in the SNMP ifDescr variable (e.g., the ifDescr is a read only attribute, but many systems allow a network operator to “name” a port, which then will be displayed in this field). The module 109 of a network infrastructure device or associated with a network infrastructure device reads the terminus information via the SNMP. In another example MIB parameters may be established or used to obtain and configure the table of information, the intrusion triggers, and the policying options. MIBs may also be employed to populate the table of dynamic and static historical information for storage and/or caching. Telnet with console access or other communications protocols may be employed to configure the detection function template(s) and/or the response function template(s) to one or more network infrastructure devices.
Other variations of the above examples can be implemented. One example variation is that the illustrated processes may include additional steps. Further, the order of the steps illustrated as part of processes is not limited to the order illustrated in their figures, as the steps may be performed in other orders, and one or more steps may be performed in series or in parallel to one or more other steps, or parts thereof.
Additionally, the processes, steps thereof and various examples and variations of these processes and steps, individually or in combination, may be implemented as a computer program product tangibly as computer-readable signals on a computer-readable medium, for example, a non-volatile recording medium, an integrated circuit memory element, or a combination thereof. Such computer program product may include computer-readable signals tangibly embodied on the computer-readable medium, where such signals define instructions, for example, as part of one or more programs that, as a result of being executed by a computer, instruct the computer to perform one or more processes or acts described herein, and/or various examples, variations and combinations thereof. Such instructions may be written in any of a plurality of programming languages, for example, Java, Visual Basic, C, or C++, Fortran, Pascal, Eiffel, Basic, COBOL, and the like, or any of a variety of combinations thereof. The computer-readable medium on which such instructions are stored may reside on one or more of the components of system 100 described above and may be distributed across one or more such components.
A number of examples to help illustrate the invention have been described. Nevertheless, it will be understood that various modifications may be made without departing from the spirit and scope of the invention. Accordingly, other embodiments are within the scope of the claims appended hereto.
