Network Zone Identification In A Network Security System
Different network segments can have overlapping address spaces. In one embodiment, the present invention includes a distributed agent of a security system receiving a security event from a network device monitored by the agent. In one embodiment, the agent normalizes the security event into an event schema including one or more zone fields. In one embodiment, the agent also determines one or more zones associated with the received security event, the one or more zones each describing a part of a network, and populates the one or more zone fields using the determined one or more zones.
The present invention relates to a computer-based system for capturing security events from heterogeneous and homogenous sources, and specifically to correlating a number of security events.
BACKGROUNDComputer 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'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 INVENTIONDifferent network segments can have overlapping address spaces. In one embodiment, the present invention includes a distributed agent of a security system receiving a security event from a network device monitored by the agent. In one embodiment, the agent normalizes the security event into an event schema including one or more zone fields. In one embodiment, the agent also determines one or more zones associated with the received security event, the one or more zones each describing a part of a network, and populates the one or more zone fields using the determined one or more zones.
The present invention is illustrated by way of example, and not limitation, in the figures of the accompanying drawings in which:
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'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
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 12 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
The agents 12 described above are configured, in one embodiment, to perform various pre-correlation processing on the security events they observe at their respective monitor devices. An agent 12, for example, can normalize observed events (i.e., map events to some universal schema used by the network security system 10), aggregate events to save memory and bandwidth, and batch events for efficient transmission. Such agent 12 functionalities, and others, are described in further detail in U.S. application Ser. No. 10/308,584, entitled “Method for Aggregating Events to be Reported by software agent”, filed Dec. 2, 2002, which is hereby incorporated fully by reference.
Another configuration of the network security system 10 is illustrated by a simplified diagram in
In one embodiment, the Denver LAN 30 shares an address space with the Austin LAN 32. Since IP addresses are scarce and/or expensive, many companies reuse the same address range in two or more network segments. Using network address translation (“NAT” also referred to as “nattting”) implemented for example in routers 34 and 46, packets can be routed off the local network segments without confusion. However, the Manager 14 may have difficulty distinguishing IP addresses contained in security event fields.
For example, agent 12(d) may collect an attack by machine 38 targeted at fax 36, while agent 12(e) may collect an attack by machine 52 targeted at machine 50. If machine 52 has the same IP address as machine 38, then the source IP of both security events representing the attacks will be the same. This may cause confusion and possible faulty correlation at the manager 14.
Various issues related to address translation are overcome in one embodiment of the present invention using zone labeling. In one embodiment, a zone describes a part of the network, such as “Denver LAN.” Zones may be on a smaller scale as well, or sub-zones can be further defined, such as “Denver: Engineering.” Any range of IP addresses, or any collection of non-consecutive IP addresses can be designated as a zone.
In one embodiment, zone labeling is performed by the agents 12. In one embodiment, zone labeling can be a part of the normalization process, but it may be performed at any time during event processing. In one embodiment, each security event has one zone field to be populated by a label of the zone that the monitor device and the agent 12 monitor. For example, agent 12(e) would label each event as “Austin Zone.”
In another embodiment, multiple zone fields can identify various zones associated with the security event. In one embodiment, a security event includes the zones of the source of the event, the destination of the event, the monitor device that is responsible for the original event, and the agent 12 that generated the normalized event. These zones can be used to populate event fields having some descriptive name, such as “Device Zone,” “Source Zone,” “Destination Zone,” “Agent Zone,” and other similar names.
In one embodiment, the zone field contains a zone reference identifier that can be used to address into a table containing additional zone attributes, such as zone name, the zone's external identifier, and various other values or identifiers associated with the zone. In another embodiment, the zone field may contain any of these attributes directly. In yet another embodiment, each event can have several zone fields for each zone identified, such as “Agent Zone ID,” “Agent Zone Name,” and so on.
Such labeling is even more useful when zones are on a smaller scale than entire facility networks. For example, the attacker machine 38 may be in zone “Denver: Engineering,” the target router 34 may be in zone “Denver: DMZ,” the monitor device may be in zone “Denver: IT,” and the agent 12(d) may be in yet another zone, or also in the “Denver: IT” zone. Various other entities and their zones may be included in other embodiments of security events.
One embodiment of an agent 12 configured to perform zone identification is now described with reference to
In one embodiment, these fields are populated by a zone mapper 66. The zone mapper accesses a zone table 64. In one embodiment, the zone table associates ranges of IP addresses with zones. An example zone table is shown in Table 1 below:
Table 1 above is only a simplified example. A real world zone table 64 may specify one hundred or more zones, and cover the entire range of possible IP addresses. The zone mapper 66 thus uses the zone table 64 to map certain IP addresses to zones according to the associations provided by the zone table 64. For example, in the source IP of an event is 192.168.0.55, then the zone mapper 66 would populate the “Source Zone” filed with “Denver: Engineering.”
In one embodiment, the zone table 64 shown in Table 1 would be resident on agent 12(d) on the Denver LAN 30. In one embodiment, the zone table 64 of agent 12(e) describes the zones of the Austin LAN 32 instead of the Denver LAN 30 in the same IP address range.
One embodiment of zone identification is now described with reference to
In block 106, the agent determines the zone to which the destination of the security event belongs. If the destination is not on the local network monitored by the device associated with the agent, then the zone of the destination may not be accurately determined, since the destination IP address may be translated before delivery at a remote site.
In block 108, the agent determines the zone to which the monitor device that generated the security event belongs. Since the monitor device will generally not shift zones on a regular basis, the device zone may be fixed at agent configuration. In one embodiment, the device IP address is mapped to a zone for each security event.
In block 110, the agent determines the zone to which the agent itself belongs. Since the agent will generally not shift zones on a regular basis, the agent zone may be fixed at agent configuration. In one embodiment, the agent's IP address is mapped to a zone for each security event.
In block 112, the agent generates a normalized security event. In one embodiment, this includes populating the various zone fields with the appropriate zones determined in blocks 104, 106, 108, and 110. The normalized event may undergo additional processing before being sent on to a manager.
In other embodiments, zones other than the four zones discussed above can also be determined and used to further identify the security event, such as a target and attacker zones, where there are different from source and destination. In yet other embodiments, less than four zones may be used. In one embodiment, only one of the four zones discussed above is used, e.g., the monitor device zone. Other embodiments can use any two or any three of the zones discussed above.
The manager 14 can use the zone fields of the normalized security events in any number of ways. In one embodiment, it can use it to keep track of events from various network segments with overlapping address spaces. Correlation rules can also be created that respond to the observation of certain zones, such as prohibited zones. Furthermore, by distributing the zone identification to the agents, the manager 14 is spared this computational task.
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 “zone table,” and various specific modules, such as “agents” and “agent normalize module” 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, and the agents 12 in
Claims
1. A method performed by a distributed software agent of a network security system, the method comprising:
- receiving a security event from a network device monitored by the agent;
- normalizing the security event into an event schema including one or more zone fields;
- determining one or more zones associated with the received security event, the one or more zones each describing a part of a network; and
- populating the one or more zone fields using the determined one or more zones.
2. The method of claim 1, wherein determining one or more zones comprises determining a zone associated with a source of the received security event.
3. The method of claim 2, wherein determining the zone associated with the source of the received security event comprises mapping a source Internet protocol (“IP”) address to the zone associated with the source of the received security event, the zone comprising a range of IP addresses.
4. The method of claim 3, further comprising mapping the determined zone associated with the source of the received security event to a zone name, and populating a zone name field of the normalized security event.
5. The method of claim 1, wherein determining one or more zones comprises determining a zone associated with the network device monitored by the agent.
6. The method of claim 5, wherein determining the zone associated with the network device monitored by the agent comprises mapping a network device Internet protocol (“IP”) address to the zone associated with the network device responsible for generating the received security event, the zone comprising a range of IP addresses.
7. The method of claim 1, wherein determining one or more zones comprises determining a zone associated with the agent.
8. The method of claim 7, wherein determining the zone associated with agent comprises mapping an Internet protocol (“IP”) address of the agent to the zone associated with the agent, the zone comprising a range of IP addresses.
9. The method of claim 1, wherein determining one or more zones comprises determining a zone associated with a destination of the received security event.
10. The method of claim 9, wherein determining the zone associated with the destination of the received security event comprises mapping a destination Internet protocol (“IP”) address to the zone associated with the destination of the received security event, the zone comprising a range of IP addresses.
11. The method of claim 1, wherein determining one or more zones associated with the received security event comprises mapping an Internet protocol (“IP”) address to a zone, wherein the zone comprises a range of IP addresses.
12. The method of claim 11, wherein mapping the IP address to a zone comprises mapping the IP address to a zone and a sub-zone, wherein the sub-zone comprises a range of IP addresses within the range of the zone.
13. A distributed agent of a network security system, the agent comprising:
- an input buffer to receive a security event from a network device monitored by the agent;
- a zone table configured to provide a mapping between internet protocol (“IP”) addresses and zones;
- a zone mapper to determine one or more zones associated with the received security event using the zone table; and
- an agent normalize module to generate a normalized security event based on the received security event, the normalized security event including the determined one or more zones.
14. The agent of claim 13, wherein the one or more zones include a zone associated with a source of the received security event.
15. The agent claim 13, wherein the one or more zones include a zone associated with a destination of the received security event.
16. The agent of claim 13, wherein the one or more zones include a zone associated with the network device that generated the received security event.
17. The agent of claim 13, wherein the one or more zones include a zone associated with the agent.
18. A method preformed by a manager of a network security system monitoring a network, the method comprising:
- receiving a first security event from a first distributed agent of the network security system, the first distributed agent configured to receive security events from a first network device monitoring a first portion of the network, the security event including an identifier of the first portion of the network; and
- receiving a second security event from a second distributed agent of the network security system, the second distributed agent configured to receive security events from a second network device monitoring a second portion of the network, the second security event including an identifier of the second portion of the network.
19. The method of claim 18, wherein the first portion of the network at least partially shares an address space with the second portion of the network.
20. The method of claim 19, wherein the address space comprises a range of Internet protocol (“IP”) addresses.
21. The method of claim 18, further comprising correlating the first and the second security events using a rules engine.
22. The method of claim 18, wherein the identifier of the first portion of the network comprises an identifier of a portion of the network where a source of the first security event resides.
23. The method of claim 18, wherein the identifier of the first portion of the network comprises an identifier of a portion of the network where the first distributed agent resides.
24. The method of claim 18, wherein the identifier of the first portion of the network comprises an identifier of a portion of the network where the first network device resides.
25. A manager of a network security system, the manager comprising:
- an agent manager to receive a first security event from a first distributed agent of the network security system, the first distributed agent configured to receive security events from a first network device monitoring a first portion of the network, the security event including an identifier of the first portion of the network, wherein the agent manager is also to receive a second security event from a second distributed agent of the network security system, the second distributed agent configured to receive security events from a second network device monitoring a second portion of the network, the second security event including an identifier of the second portion of the network; and
- a rules engine to correlate the first and second security events using the identifier of the first portion of the network and the identifier of the second portion of the network.
26. The manager of claim 25, wherein the first portion of the network at least partially shares an address space with the second portion of the network.
27. The manager of claim 26, wherein the address space comprises a range of Internet protocol (“IP”) addresses.
28. A normalized event schema for a security event comprising:
- an agent zone field to identify a zone to which a distributed agent of a network security system belongs.
29. The event schema of claim 28 further comprising:
- a device zone field to identify a zone to which a monitor device that generated the security event belongs;
- a source zone field to identify a zone to which a source of the security event belongs; and
- a destination zone field to identify a zone to which a destination of the security event belongs.
30. A machine-readable medium having stored thereon data representing instructions that, when executed by a processor, cause the processor to perform operations comprising:
- receiving a security event from a network device monitored by the agent;
- normalizing the security event into an event schema including one or more zone fields;
- determining one or more zones associated with the received security event, the one or more zones each describing a part of a network; and
- populating the one or more zone fields using the determined one or more zones.
Type: Application
Filed: Jun 29, 2015
Publication Date: Oct 22, 2015
Inventors: Kenny Tidwell (Los Altos, CA), Christian Beedgen (San Jose, CA)
Application Number: 14/753,210
