Abstract:
A network security system having a hierarchical configuration is provided. In one embodiment the present invention includes a plurality of subsystems, where each subsystem includes a plurality of distributed software agents configured to collect base security events from monitor devices, and a local manager module coupled to the plurality of distributed software agents to generate correlated events by correlating the base security events. Each subsystem can also include a filter coupled to the manager module to select which base security events are to be processed further. The selected base security events are passed to a global manager module coupled to the plurality of subsystems that generates global correlated events by correlating the base security events selected for further processing by each filter of each subsystem.

Description:
FIELD OF THE INVENTION 
     The present invention relates to a network security system, and, in particular, to a network security system having a hierarchical architecture. 
     BACKGROUND 
     Computer networks and systems have become indispensable tools for modern business. Today terabits of information on virtually every subject imaginable are stored in and accessed across such networks by users throughout the world. Much of this information is, to some degree, confidential and its protection is required. Not surprisingly then, various network security monitor devices have been developed to help uncover attempts by unauthorized persons and/or devices to gain access to computer networks and the information stored therein. 
     Network security products largely include Intrusion Detection Systems (IDS&#39;s), which can be Network or Host based (NIDS and HIDS respectively). Other network security products include firewalls, router logs, and various other event reporting devices. Due to the size of their networks, many enterprises deploy hundreds, or thousands of these products thoughts their networks. Thus, network security personnel are bombarded alarms representing possible security threats. Most enterprises do not have the resources or the qualified personnel to individually attend to all of the received alarms. 
     Furthermore, many large organizations deploy these devices locally at each of their sites to distribute computational resources and to limit bandwidth use. Since security events generally concern local attacks, such division is generally helpful. However, localizing network security can have disadvantages, since not all available and relevant information is used during the threat analysis and decision making. 
     SUMMARY OF THE INVENTION 
     A network security system having a hierarchical configuration is provided. In one embodiment the present invention includes a plurality of subsystem&#39;s, where each subsystem includes a plurality of distributed software agents configured to collect base security events from monitor devices, and a local manager module coupled to the plurality of distributed software agents to generate correlated events by correlating the base security events. Each subsystem can also include a filter coupled to the manager module to select which base security events are to be processed further. The selected base security events are passed to a global manager module coupled to the plurality of subsystems that generates global correlated events by correlating the base security events selected for further processing by each filter of each subsystem. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       The present invention is illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings in which like reference numerals refer to similar elements and in which: 
         FIG. 1  is a block diagram illustrating a standard configuration for implementing a network security system; 
         FIG. 2  is a block diagram illustrating a hierarchical configuration for implementing a network security system according to one embodiment of the present invention; 
         FIG. 3  is a block diagram illustrating an example environment in which one embodiment of the present invention may be implemented; 
         FIG. 4  is a block diagram illustrating additional detail of one embodiment of a subsystem according to the present invention; 
         FIG. 5  is a block diagram illustrating additional detail of another embodiment of a subsystem according to the present invention; and 
         FIG. 6  is a block diagram illustrating another example environment in which one embodiment of the present invention may be implemented. 
     
    
    
     DETAILED DESCRIPTION 
     Described herein is a network security system having a hierarchical configuration. 
     Although the present system will be discussed with reference to various illustrated examples, these examples should not be read to limit the broader spirit and scope of the present invention. For example, the examples presented herein describe distributed agents, managers and various network devices, which are but one embodiment of the present invention. The general concepts and reach of the present invention are much broader and may extend to any computer-based or network-based security system. 
     Some portions of the detailed description that follows are presented in terms of algorithms and symbolic representations of operations on data within a computer memory. These algorithmic descriptions and representations are the means used by those skilled in the computer science arts to most effectively convey the substance of their work to others skilled in the art. An algorithm is here, and generally, conceived to be a self-consistent sequence of steps leading to a desired result. The steps are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared and otherwise manipulated. It has proven convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers or the like. It should be borne in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise, it will be appreciated that throughout the description of the present invention, use of terms such as “processing”, “computing”, “calculating”, “determining”, “displaying” or the like, refer to the action and processes of a computer system, or similar electronic computing device, that manipulates and transforms data represented as physical (electronic) quantities within the computer system&#39;s registers and memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage, transmission or display devices. 
     As indicated above, one embodiment of the present invention is instantiated in computer software, that is, computer readable instructions, which, when executed by one or more computer processors/systems, instruct the processors/systems to perform the designated actions. Such computer software may be resident in one or more computer readable media, such as hard drives, CD-ROMs, DVD-ROMs, read-only memory, read-write memory and so on. Such software may be distributed on one or more of these media, or may be made available for download across one or more computer networks (e.g., the Internet). Regardless of the format, the computer programming, rendering and processing techniques discussed herein are simply examples of the types of programming, rendering and processing techniques that may be used to implement aspects of the present invention. These examples should in no way limit the present invention, which is best understood with reference to the claims that follow this description. 
     Referring now to  FIG. 1 , an example of a manager module  100  of a network security system that is not hierarchically configured is illustrated. The manager  100  receives base events  102  (also referred to as “security events” or “events”) from various sources. For example, the manager  100  can receive a base event  102  from a distributed software agent  104  associated with an IDS, or from the agent  104  associated with a firewall. In one embodiment, the IDS&#39;s alarms are normalized by the software agent  104  before being reported as an event  102  to the manager  100 . 
     In formal security terminology, an “event” is an actual physical occurrence—such as a packet traversing the network, or a file being deleted—and an “alarm” is a representation of the “event.” As used in this application, however, a security event  102  (or just “event”) refers to a representation of a physical phenomenon, thus being an “alarm” according to strict formal terminology. In this application, alarms are produced by a network security device associated with an agent  104 —such as an HIDS, a NIDS, or a firewall—and a base event  102  refers to the output of the agent  104  after the agent  104  processed, e.g. aggregated, batched, or normalized, the alarms. Furthermore, an unprocessed alarm directly from a sensor device is also considered to be a “base event” for the purposes of this application. 
     A base event  102  can have various fields that contain information about the event  102 . Several example events are described, for example, in the co-pending application entitled “Real Time Monitoring and Analysis of Events from Multiple Network Security Devices”, filed on Dec. 2, 2002, application Ser. No. 10/308,415 for inventors Hugh S. Njemanze and Pravin S. Kothari, and in the co-pending application entitled “Threat Dection in a Network Security System”, filed on Sep. 3, 2003, application Ser. No. 10/655,062, for inventors Kenny Tidwell, Kumar Saurabh, Depurate Dash, Hugh S. Njemanze and Pravin S. Kothari, both applications incorporated herein fully by reference. The base events are then processed by the manager module  100 . Such processing can include prioritisation performed by an event prioritizer module  106 . Event prioritisation is described in more detail in the co-pending application entitled “Thread Detection in a Network Secutiry system, ”incorporated by reference above. 
     Furthermore, event processing can include event correlation performed by an event correlator module  108  using various rules. Event correlation is described in detail in application Ser. No. 10/308,415. The output of the event correlator  108  is correlated events. A correlated event is a conclusion drawn from several base events based on the rules. For example, twenty failed logins followed by a successful login and twenty-one base events that can translate to one correlated event, namely “successful brute-force dictionary attack.” The manager module  100  can also include a notifier module  110  to send alert information to the system administrators. The notifier is also described in application Ser. No. 10/308,415. 
     The correlation rules that operate on the events evaluate threats and attacks according to selected criteria (e.g., degree of threat, level of success, vulnerability of target and value of target) and generate alerts according to a security intelligence taxonomy that focuses attention on the most dangerous and potentially most damaging attacks. For example, threats to network assets that are deemed not to have succeeded or that are not likely to succeed may be coded green, while those that have succeeded or have a high probability of success might be coded red. The value of the security information taxonomy lies in its ability to eliminate false positives while clearly identifying real threats to vulnerable and valuable assets. 
     In general, the rules may be designed to capture threats and attacks that are typical in large, diverse networks and may be organized to provide multiple lines of defense by detecting specific activities and grouping them according to level of threat such as:
         Reconnaissance zone transfer, port scan, protocol, scanning, etc.   Suspicious illegal outgoing traffic, unusual levels of alerts from the same host, etc.   Attack overflow, IDS evasion, virus, denial of service, etc.   Successful compromise of a backdoor, root compromise, covert channel exploit, etc.
 
Similar events and signatures may be grouped into rule categories that can be utilized by the rules to insulate the rule from changes in vendor-specific event details. For example, event names may change between product releases or new devices may be added to the network infrastructure with a new set of nomenclature. Since the rule categories map similar signatures into a single name that is used by the rules engine, if an individual network device changes taxonomy, only the mapping is changed, not the rule definition. Therefore, despite changes in individual devices, the investment in custom defined rules is preserved.
       

     Referring now to  FIG. 2 , an example of a hierarchically configured network security system according to one embodiment of the present invention is illustrated. The manager module  100  of  FIG. 1  is renamed local manager  100  for  FIG. 2  to indicate that other managers exist in the system. 
     Thus, agents  104  and local manager  100  are identical to their counterparts described with reference to  FIG. 1  above. However, in  FIG. 2 , the agents  104  collect events only from a subsystem  202  of the network security system, and the local manager  100  processes only these base events. For example, subsystem  202  can be the local security system at a company site or location. 
     As described above, one output of the local manager is correlated events. In one embodiment described with reference to  FIG. 2 , these correlated events are not only used locally, but are provided to a global manager module  200  that receives similar inputs from other sites, such as subsystem  204  and subsystem  206 . In one embodiment, the correlated events are first passed through a filter  208  to a manager agent  210 . 
     The manager agent  210  can be implemented similarly or identically to agents  104 . The tasks performed by the manager agent can also be similar or identical to agents  104 , such as normalization, aggregation, batching, and other tasks described above and in the incorporated applications. 
     The filter  208  can be implemented using Boolean expressions. Its purpose is to select the correlated events to be delivered to the global manager module  200 . For example, the filter  208  can be set to block out correlated events deemed only to have local significance. In other embodiments, bandwidth constraints between the global manager  200  and subsystem  202  may allow for only a relatively few correlated events to be sent, hence allowing only specifically requested types of correlated event through the filter. 
     For example, the global manager  200 , through back-link  212 , can program the filter  208  to provide all correlated events relating to some IP address of interest. In similar fashion, the global manager  200  can configure what it receives from each subsystem to anything the filters  208  can be programmed to, using back-links  212  to each subsystem. In other embodiments, the filter  208  can be programmed and configured locally at subsystem  202 . In other embodiments in which all correlated events are provided to the global manager  200 , the filter  208  can be omitted. 
     In one embodiment, the global manager  200 , through back-channel  214 , can request information from the local manager  100 . For example, the global manager  200  may send a request to the local manager  100  for all base events that were correlated to produce a particular correlated event previously sent to the global manager  200 . 
     Subsystem  204  and subsystem  206  can be similar or identical to subsystem  202  described above. Any number of subsystems can be similarly configured to feed correlated events to the global manager  200 . In one embodiment, these base events are retrieved from local storage by the local manager  100 , and are sent to the global manager  200  through back-channel  214  to avoid re-correlation of these base events. 
     The global manager module  200  receives the correlated events from the various subsystems. These correlated events can be referred to as local correlated events, since they are local to a specific subsystem. In one embodiment, the global manager  200  functions in a manner similar to the local managers  100 , treating the local correlated events as base events. Thus, the global manager  200  can perform a correlation of the local correlated events to generate global correlated events. 
     An example is given with reference to  FIG. 3 .  FIG. 3  shows a number of military vehicles  300 . Each vehicle  300  has an on-board network  302  consisting of various meters, radars, communication equipment, global positioning equipment, processors, data storage, and other network components. Each network  302  is monitored by a local network security system  304 . The local network security system can be similar to subsystem  202  in  FIG. 2 . 
     In this example, each local security network picked up an attempted unauthorized network access. This conclusion is a local correlated event  306  that may be based on various base events. When these local correlated events  306  are reported wirelessly to a command centre  308  housing the global manager module  200 , the global manager  200  can correlate these local correlated events to determine the location of a hacker. This would be a global correlated event, since it uses correlated events from various local security networks. 
     In this example, finding the hacker would be difficult for a single vehicle with a local network security system, since each vehicle experiences many attacks. However, if all vehicles experience an attack on the same street corner, broader conclusions about the location of a specific attacker can be drawn. 
     Referring now to  FIG. 4 , data flow according to one embodiment of the present invention is reiterated.  FIG. 4  shows a closer look at subsystem  202  of  FIG. 2 . As explained above, base events  402  collected by the distributed software agents are correlated by the local manager module  100  to generate local correlated events  404 . The correlated events are provided to the filter  208  on their way to the global manager module  200 . 
     Another embodiment of the present invention is now described with reference to  FIG. 5 .  FIG. 5  shows another close-up of subsystem  202 . In this embodiment, however, the local correlated events  404  generated from the base events  402  are used locally. Furthermore, the base events  402  are provided to the filter  208 . Those base events  404  that are selected for pass-through by the filter  208  are then provided to the global manager  200 , according to the description referencing  FIG. 2 . 
     An example is given with reference to  FIG. 6 .  FIG. 6  shows three satellite offices—a Phoenix  602 , a Dallas  604 , and a Frankfurt office  606 —and the Boston headquarters  600  of an enterprise. Each satellite office has a computer network, such as network  608  of the Phoenix office  602 . Each network is monitored by a network security subsystem, such as subsystem  610 . These subsystems can be implemented as described with reference to  FIG. 2  and  FIG. 5 . 
     As described with reference to  FIG. 5 , each local manager of the network security subsystems is configured to pass base events through. In this example, the filter  208  is programmed by the global manager  200  to only select high-priority base events to be provided to the global manager  200 . The global manager module  200  thus receives high-priority base events from all connected satellite offices, and from the local Boston subsystem  612 . 
     The global manager  200  can thus correlate all high-priority base events, not just the local ones. In this manner, the global correlation performed by the global manager  200  results in global correlated events that can concern a global attack. For example, an attacker trying to bring down the Phoenix. network  608  may not be catastrophic, the same attacker trying to bring down multiple networks may be. 
     In another example, an attacker may have been detected by subsystem  610  to have performed reconnaissance—such as scanning for populated addresses and open ports—on the Phoenix network  608 . If this attacker now attacks the Dallas network, the Dallas subsystem  610  is unaware of the heightened security risk. However, the global manager  200  will be able to inform the Dallas office  604  that an attack they thought to be low priority is being perpetrated by an attacker using information from a previous reconnaissance. 
     In other embodiments, each subsystem can be configured as a combination of  FIGS. 4 and 5 , with both base events  402  and local correlated events  404  being provided to the filter  208 , which can select among them according to its configuration. The filter  208  can be user programmed at each site, or automatically and remotely programmed by the global manager  200  according its perceived needs. For example, if the global manager  200  thinks that an attacker with a certain IP address is trying to perform a global attack, it may set the filters  208  of all subsystems to let base and correlated events relating to that IP address through. 
     Thus, a hierarchically configured network security system, and event processing in such a system has been described. In the foregoing description, various specific intermediary values were given names, such as “local correlated events,” and various specific modules, such as the “manager agent,” have been described. However, these names are merely to describe and illustrate various aspects of the present invention, and in no way limit the scope of the present invention. Furthermore, various modules, such as the local manager module  100  and the global manager module  200  in  FIG. 2 , can be implemented as software or hardware modules, or without dividing their functionalities into modules at all. The present invention is not limited to any modular architecture, whether described above or not. 
     In the foregoing description, the various examples and embodiments were meant to be illustrative of the present invention and not restrictive in terms of their scope. Accordingly, the invention should be measured only in terms of the claims, which follow.