Patent Publication Number: US-8528077-B1

Title: Comparing events from multiple network security devices

Description:
FIELD OF THE INVENTION 
     The present invention relates to a computer-based system for capturing security events from heterogeneous and homogenous sources, and comparing such events to generate a meta-event. 
     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, intrusion detection systems (IDS) have been developed to help uncover attempts by unauthorized persons and/or devices to gain access to computer networks and the information stored therein. In addition, network devices such as routers and firewalls maintain activity logs that can be used to examine such attempts. 
     Intrusion detection may be regarded as the art of detecting inappropriate, incorrect or anomalous activity within or concerning a computer network or system. The most common approaches to intrusion detection are statistical anomaly detection and pattern-matching detection. IDS that operate on a host to detect malicious activity on that host are called host-based IDS (HIDS), which may exist in the form of host wrappers/personal firewalls or agent-based software, and those that operate on network data flows are called network-based IDS (NIDS). Host-based intrusion detection involves loading software on the system (the host) to be monitored and using log files and/or the host&#39;s auditing agents as sources of data. In contrast, a network-based intrusion detection system monitors the traffic on its network segment and uses that traffic as a data source. Packets captured by the network interface cards are considered to be of interest if they match a signature. 
     Regardless of the data source, there are two complementary approaches to detecting intrusions: knowledge-based approaches and behavior-based approaches. Almost all IDS tools in use today are knowledge-based. Knowledge-based intrusion detection techniques involve comparing the captured data to information regarding known techniques to exploit vulnerabilities. When a match is detected, an alarm is triggered. Behavior-based intrusion detection techniques, on the other hand, attempt to spot intrusions by observing deviations from normal or expected behaviors of the system or the users (models of which are extracted from reference information collected by various means). When a suspected deviation is observed, an alarm is generated. 
     Advantages of the knowledge-based approaches are that they have the potential for very low false alarm rates, and the contextual analysis proposed by the intrusion detection system is detailed, making it easier for a security officer using such an intrusion detection system to take preventive or corrective action. Drawbacks include the difficulty in gathering the required information on the known attacks and keeping it up to date with new vulnerabilities and environments. 
     Advantages of behavior-based approaches are that they can detect attempts to exploit new and unforeseen vulnerabilities. They are also less dependent on system specifics. However, the high false alarm rate is generally cited as a significant drawback of these techniques and because behaviors can change over time, the incidence of such false alarms can increase. 
     Regardless of whether a host-based or a network-based implementation is adopted and whether that implementation is knowledge-based or behavior-based, an intrusion detection system is only as useful as its ability to discriminate between normal system usage and true intrusions (accompanied by appropriate alerts). If intrusions can be detected and the appropriate personnel notified in a prompt fashion, measures can be taken to avoid compromises to the protected system. Otherwise such safeguarding cannot be provided. Accordingly, what is needed is a system that can provide accurate and timely intrusion detection and alert generation so as to effectively combat attempts to compromise a computer network or system. 
     SUMMARY OF THE INVENTION 
     In an embodiment of the present invention, events are received from a plurality of security devices (which may be similar or different devices, e.g., intrusion detection systems configured to monitor network traffic) and divided into a plurality of event flows. Comparing the event flows (e.g., using statistical correlation methods) then generates one or more meta-events. The received events may be divided into different event flows on the basis of the security device that generated the events. The meta-events may be generated by evaluating a perimeter defense device through comparison of the different event flows. In some cases, various ones of the security devices may be inside or outside a perimeter defined by the perimeter defense device. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       The present invention is illustrated by way of example, and not limitation, in the figures of the accompanying drawings in which: 
         FIG. 1  is a block diagram of a network security system according to one embodiment of the present invention; 
         FIG. 2  is a block diagram of a manager of a network security system according to one embodiment of the present invention; 
         FIG. 3  is a flow chart illustrating a process for generating meta-events through a comparison of event streams according to one embodiment of the present invention; 
         FIG. 4  is a flow chart illustrating a process for using security event processing to evaluate a perimeter defense device according to one embodiment of the present invention; and 
         FIG. 5  is a flow chart illustrating a process for detecting tampering according to one embodiment of the present invention. 
     
    
    
     DETAILED DESCRIPTION 
     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 consoles, 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. Also, examples of the messages that may be passed to and from the components of the system and the data schemas that may be used by components of the system are given in an attempt to further describe the present invention, but are not meant to be all-inclusive examples and should not be regarded as such. 
     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 computer-based network security system  10  architected in accordance with an embodiment of the present invention is illustrated. System  10  includes agents  12 , one or more managers  14  and one or more consoles  16  (which may include browser-based versions thereof). In some embodiments, agents, managers and/or consoles may be combined in a single platform or distributed in two, three or more platforms (such as in the illustrated example). The use of this multi-tier architecture supports scalability as a computer network or system grows. 
     Agents  12  are software programs that provide efficient, real-time (or near real-time) local event data capture and filtering from a variety of network security devices and/or applications. The primary sources of security events are common network security devices, such as firewalls, intrusion detection systems and operating system logs. Agents  12  can collect events from any source that produces event logs or messages and can operate at the native device, at consolidation points within the network, and/or through simple network management protocol (SNMP) traps. 
     Agents  12  are configurable through both manual and automated processes and via associated configuration files. Each agent  12  may include one or more software modules including a normalizing component, a time correction component, an aggregation component, a batching component, a resolver component, a transport component, and/or additional components. These components may be activated and/or deactivated through appropriate commands in the configuration file. 
     Managers  14  may be server-based components that further consolidate, filter and cross-correlate events received from the agents, employing a rules engine  18  and a centralized event database  20 . One role of manager  14  is to capture and store all of the real-time and historic event data to construct (via database manager  22 ) a complete, enterprise-wide picture of security activity. The manager  14  also provides centralized administration, notification (through one or more notifiers  24 ), and reporting, as well as a knowledge base  28  and case management workflow. The manager  14  may be deployed on any computer hardware platform and one embodiment utilizes a relational database management system such as an Oracle™ database to implement the event data store component. Communications between manager  14  and agents  12  may be bi-directional (e.g., to allow manager  14  to transmit commands to the platforms hosting agents  12 ) and encrypted. In some installations, managers  14  may act as concentrators for multiple agents  12  and can forward information to other managers (e.g., deployed at a corporate headquarters). 
     Consoles  16  are computer- (e.g., workstation-) based applications that allow security professionals to perform day-to-day administrative and operation tasks such as event monitoring, rules authoring, incident investigation and reporting. Access control lists allow multiple security professionals to use the same system and event database, with each having their own views, correlation rules, alerts, reports and knowledge base appropriate to their responsibilities. A single manager  14  can support multiple consoles  16 . 
     In some embodiments, a browser-based version of the console  16  may be used to provide access to security events, knowledge base articles, reports, notifications and cases. That is, the manager  14  may include a web server component accessible via a web browser hosted on a personal or handheld computer (which takes the place of console  16 ) to provide some or all of the functionality of a console  16 . Browser access is particularly useful for security professionals that are away from the consoles  16  and for part-time users. Communication between consoles  16  and manager  14  is bi-directional and may be encrypted. 
     Through the above-described architecture the present invention can support a centralized or decentralized environment. This is useful because an organization may want to implement a single instance of system  10  and use an access control list to partition users. Alternatively, the organization may choose to deploy separate systems  10  for each of a number of groups and consolidate the results at a “master” level. Such a deployment can also achieve a “follow-the-sun” arrangement where geographically dispersed peer groups collaborate with each other by passing primary oversight responsibility to the group currently working standard business hours. Systems  10  can also be deployed in a corporate hierarchy where business divisions work separately and support a rollup to a centralized management function. 
     The exemplary network security system illustrated in  FIG. 1  is described in further detail in U.S. application Ser. No. 10/308,415, entitled “Real Time Monitoring and Analysis of Events from Multiple Security Devices”, filed Dec. 2, 2001, which is hereby incorporated fully by reference. 
       FIG. 2  illustrates another aspect of one embodiment of the manager  14  shown in  FIG. 1 . In one embodiment, manager  14  includes a reconciliation monitor  30  that compares event sub-flows to generate meta-events. The reconciliation monitor  30  is just one specific type of data monitor that can be implemented by the manager  14 . In general, a data monitor is a module or component that listens to the event flow from the various security devices and analyzes the data contained in the events. The names “data monitor” and “reconciliation monitor” are purely descriptive, similar or identical functionality may be provided under many different names, e.g., “flow monitor,” and “device comparator,” respectively. The names of the various components do not limit the embodiment of the present invention. 
     Referring to  FIG. 2 , the manager  14  receives events from the various security devices (IDSs, Firewalls, etc.) as discussed above. These events constitute an event flow  32 , referring to the aggregate stream of events received by the manager  14 . In one embodiment, the event flow  32  is provided to the reconciliation monitor  30  for analysis. The reconciliation monitor  30  may receive the event flow  32  from the agent manager  26 , and may operate in sequence (before or after) the rules engine  18  or in parallel. 
     In one embodiment, the reconciliation monitor  30  divides the event flow  32  into two or more event sub-flows  34 . As shown in  FIG. 2 , the reconciliation monitor  30  may use a filter  36  (e.g., a Boolean filter or multiple Boolean filters) to divide the event flow  32  into event sub-flow  34   a  and event sub-flow  34   b . Using non-Boolean filters or a plurality of filters, the event flow  32  can be divided into more than two event sub-flows, as indicated in  FIG. 2  by the ellipsis between event sub-flows  34   a  and  34   b . More typically, each sub-flow may be associated with a unique Boolean filter that identifies events associated with, or that are part of, that sub-flow. As used herein, the term flow is meant to describe “an ordered set of event processing components” and the term stream (or event stream) is meant to describe “an ordered set of events”. 
     The event sub-flows  34  may include all events in the event flow  32 , but in most cases they will not. For example, if the filter  36  is configured to produce two sub-flows  34  corresponding with two specific security devices, then events from other security devices will not be in either sub-flow  34 . Specific operation of the filter  36  is described further below. 
     In one embodiment, the event sub-flows  34  are provided to a comparison engine  38 , which generates a meta-event  40  by comparing the event sub-flows  34  to one another. Specific operation of the comparison engine  38  and some examples of meta-events  40  are described further below. One embodiment of the security event processing described above is also illustrated by a flow-chart in  FIG. 3 . Referring to  FIG. 3 , in block  42  the security events are received, in block  44  they are divided into a plurality of flows (i.e., two or more sub-flows), and in block  46  the meta-event is generated based on comparing the two or more flows. 
     In one embodiment, a user may supply a set of event fields (e.g., SourceIP Address or AgentID, etc.). If the values from the fields from several events (one event per sub-stream) are comparable, (ordinarily they would need to be identical but in some cases a tolerance range may be given, for example when comparing event times, etc., and the two values may thus be considered identical if they fall within 15 seconds or so (or some other time tolerance) of one another) then those events are considered to be reconciled. If an event cannot be reconciled with comparable events from other streams then it is considered to be unreconciled. Meta-events may be generated whenever reconciled or unreconciled events are identified. In some cases, mathematical correlations may be computed (e.g., 1.0 if the event counts on all streams vary in synch; −1.0 if they vary in the inverse; and some value in between these endpoints (approaching 0) as the streams vary at random). 
     Referring again to  FIG. 2 , in one embodiment, the meta-event  40  is provided to the manager  14  for further processing  48 . Such further processing may include providing the meta-event  40  to the notifier  24  to generate an alarm to one or more consoles  16 . 
     In one embodiment, the operation of the filter  36  and the comparison engine  38  is determined based on configuration input  50 . The configuration input may be provided by a user through a console/browser interface  16  (e.g., by the user selecting from a list of possible functionalities), it may be preconfigured, or the user may program it. 
     In one embodiment, the filter  36  is configured to divide the event flow  32  into two sub-flows  34 . The first sub-flow  34   a  is filtered to contain security events from a first security device situated outside of a perimeter defense device. The second sub-flow  34   b  is filtered to contain security events from a second security device that is identical to the first security device, except that it is situated on the inside of the perimeter defense device. 
     For example, the perimeter defense device may be a Firewall set up to protect a LAN. One IDS is set up outside of the Firewall, and an identical (e.g., same make and model) IDS is set up inside the Firewall. Event sub-flow  34   a  contains events reported by the outside IDS while event sub-flow  34   b  contains events reported by the inside IDS. 
     In such an embodiment, the comparison engine  38  can be configured to evaluate the perimeter defense device by comparing the two event sub-flows  34 . Since the two security devices are identical, an event can be determined to be stopped by the perimeter defense device, passed by the perimeter defense device, or introduced by the perimeter defense device. For example, using the IDS example above, if an event is seen by the outside IDS, but not by the inside IDS, the event was stopped by the Firewall. Events seen at both IDSs are passed by the Firewall, and events seen only by the inside IDS are introduced by the Firewall. 
     Using this information, the effectiveness of the Firewall—or other perimeter defense device—can be evaluated by the comparison engine. In such an embodiment, the meta-event  40  represents such an evaluation. For example, the meta-event  40  can indicate. The meta-events may be Reconciled Events or Unreconciled Events. A report of all Reconciled Events would inform the operator that these sorts of attacks are not being blocked by the firewall. A report regarding the Unreconciled Events would inform the operator which attacks are being blocked by the firewall. 
     One embodiment of using the security event processing to evaluate a perimeter defense device is also illustrated by a flow-chart in  FIG. 4 . Referring to  FIG. 4  in block  52  the first security device is configured outside of the monitoring perimeter, while in block  54  the second security device is configured on the inside. In block  56 , security events received from the two security devices, respectively, are compared, and in block  58 , the perimeter defense device is evaluated based on the comparison. In the example above, the filter  36  divided the event flow  32  into only two event sub-flows  34 . However, in other embodiment, any other number of sub-flows higher than two can be used. 
     In another embodiment, referring again to  FIG. 2 , the filter  36  is also configured to divide the event flow  32  into two sub-flows  34 . In this embodiment, the first sub-flow  34   a  is filtered to contain security events from a first security device. The second sub-flow  34   b  is filtered to contain security events from a second security device that is identical to the first security device. Thus, the event sub-flows  34  contain events from two identical security devices. 
     For example, the two identical security devices may be two identical IDSs by the same manufacturer set up to monitor the same network traffic. Thus, the two event sub-flows  34  are expected to be identical. In such an embodiment, the comparison engine  38  can be configured to detect whether one of the security devices has been tampered with by comparing the two event sub-flows  34 . Since the two security devices are identical, any discrepancy in the two event sub-flows  34  may indicate tampering with one of the devices. 
     For example, if one of the IDS fails to report an event seen by the other IDS monitoring the same traffic, the comparison engine  38  can generate a meta-event  40  indicating suspected tampering with the IDS. In such an embodiment, the meta-event  40  represents such a tampering detection. In general, the meta-events may be Reconciled Events or Unreconciled Events and an operator may establish rules for handling same. For example, the operator may establish a rule that indicates in the event any Unreconciled Events are generated by the data monitor then one of the monitored devices has been compromised. Upon inspection of that meta-event, the operator could determine which of the monitored devices did not generate the expected event—indicating the device that has been tampered with. Alternatively, this inspection could be performed automatically (e.g., rule-based inspection) and a further Tampering Detected meta-event generated. 
     In the example above, the filter  36  divided the event flow  32  into only two event sub-flows  34 . However, in other embodiment, any other number of sub-flows higher than two can be used. For example, if an attacker could have the ability to tamper with two IDSs simultaneously, then using three identical IDSs—and comparing three event sub-flows  34  respectively—would again provide tamper detection ability. 
     Tampering detection, according to one embodiment of the present invention, is also illustrated by a flow-chart in  FIG. 5 . Referring to  FIG. 5 , in block  60  two identical security devices are configured in series to listen to the same network traffic. In block  62 , the security events from the two security devices are compared, and in block  64 , tampering with one of the devices is detected based on the comparison. 
     In another embodiment, referring again to  FIG. 2 , the filter  36  is configured to divide the event flow  32  into two sub-flows  34 . The first sub-flow  34   a  is filtered to contain security events from a first security device. The second sub-flow  34   b  is filtered to contain security events from a second security device that is not identical to the first security device. In other words, the two event sub-flows  34  are from two heterogeneous security devices. 
     The two devices can be heterogeneous in numerous ways. For example, they can be two devices of the same type from different vendors, e.g., an IDS from Cisco Systems and another from ISS. In one embodiment, they are two devices of similar types, but different scope, e.g., a HIDS and a NIDS. Alternatively, they may be completely dissimilar devices, such as a firewall and a router, for example. 
     In such an embodiment, the comparison engine  38  can be configured to evaluate the effectiveness of the two security devices by comparing the two event sub-flows  34 . In one embodiment, by observing the events missed by one security device but seen by the other, and vice versa, an inference can be made about the effectiveness of the two security devices working together. 
     In one embodiment, the events contained in the event flow  32  are normalized, thus facilitating comparison of the two sub-flows  34  from two disparate security devices. In one embodiment, an event category as opposed to the event name form the basis of comparison. 
     In one embodiment, inferring the effectiveness and accuracy of the two security devices operating as a system can be done by a Kappa-enabled data monitor. In such an embodiment, the meta-event  40  represents such an evaluation. For example, a Kappa-enabled data monitor may generate Device Coverage meta-events that would include a percentage expressing the relation between attacks detected by the monitored devices and the universe of all attacks both known and unknown. 
     In the example above, the filter  36  divided the event flow  32  into only two event sub-flows  34 . However, in other embodiment, any other number of sub-flows higher than two can be used. Furthermore, each sub-flow  34  can contain security events from more than just one security device. For example, all IDS events can be filtered into one sub-flow  34   a  and all Firewall events can be filtered into another sub-flow  34   b . Furthermore, another sub-flow  34  can contain all router events. That is, the number of sub-flows  34  is not limited to two, and each sub-flow  34  can have events from numerous security devices depending on the configuration of the filter  36 . 
     In one embodiment, the filter  36  is configured to divide the event flow  32  into two sub-flows  34  according to some classification, such as two different security devices. The comparison engine  38  can then be configured to statistically correlate the two event sub-flows  34  by comparing them to each other. Statistical correlation indicates how much one thing is related to another, ranging from completely like, to unrelated, to completely unlike. 
     In one embodiment, the two sub-flows  34  being compared for statistical correlation contain normalized security events. Using information about the statistical correlation between two event flows, an operator may watch for correlated variations in the traffic directed at, for example, particular ports. If the traffic directed at all ports associated with an SQLServer, for instance, suddenly spike together then one might strongly suspect that there is a virus spreading across mySQLServer installations. If the traffic on one port suddenly spikes while another suddenly falls, the operator might suspect a denial of service attack has suddenly cut the demand for the second port by tying up the first. Event Stream Correlation events may be generated periodically and a field of such meta-events may include a correlation value between 1 and −1. 
     In the example above, the filter  36  divided the event flow  32  into only two event sub-flows  34 . However, in other embodiment, any other number of sub-flows higher than two can be used. Then, the sub-flows  34  may be correlated in pairs, or a group correlation may be calculated for all the event sub-flows  34 . 
     Thus, a network security system has been described. In the forgoing description, various specific values and data structures were given names, such as “security event” and “event sub-flow,” and various specific modules, such as the “reconciliation monitor” and “comparison engine” 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 manager  14 , the filter  36 , and the comparison engine  38  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 either in software or in hardware, whether described above or not.