U.S. patent application number 14/753210 was filed with the patent office on 2015-10-22 for network zone identification in a network security system.
The applicant listed for this patent is HEWLETT-PACKARD DEVELOPMENT COMPANY, L.P.. Invention is credited to Christian Beedgen, Kenny Tidwell.
Application Number | 20150304333 14/753210 |
Document ID | / |
Family ID | 53719098 |
Filed Date | 2015-10-22 |
United States Patent
Application |
20150304333 |
Kind Code |
A1 |
Tidwell; Kenny ; et
al. |
October 22, 2015 |
Network Zone Identification In A Network Security System
Abstract
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.
Inventors: |
Tidwell; Kenny; (Los Altos,
CA) ; Beedgen; Christian; (San Jose, CA) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
HEWLETT-PACKARD DEVELOPMENT COMPANY, L.P. |
Houston |
TX |
US |
|
|
Family ID: |
53719098 |
Appl. No.: |
14/753210 |
Filed: |
June 29, 2015 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
10974105 |
Oct 27, 2004 |
9100422 |
|
|
14753210 |
|
|
|
|
Current U.S.
Class: |
726/1 ;
726/12 |
Current CPC
Class: |
H04L 63/10 20130101;
H04L 63/02 20130101; H04L 63/1408 20130101; H04L 63/101 20130101;
H04L 63/20 20130101 |
International
Class: |
H04L 29/06 20060101
H04L029/06 |
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.
Description
FIELD OF THE INVENTION
[0001] 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.
BACKGROUND
[0002] 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.
[0003] 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.
[0004] 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.
[0005] 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.
[0006] 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.
[0007] 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
[0008] 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.
BRIEF DESCRIPTION OF THE DRAWINGS
[0009] The present invention is illustrated by way of example, and
not limitation, in the figures of the accompanying drawings in
which:
[0010] FIG. 1 is a block diagram of a network security system
according to one embodiment of the present invention;
[0011] FIG. 2 is a block diagram a distributed network security
system according to one embodiment of the present invention;
[0012] FIG. 3 is a block diagram of a software agent according to
one embodiment of the present invention; and
[0013] FIG. 4 is a flow diagram illustrating zone mapping according
to one embodiment of the present invention.
DETAILED DESCRIPTION
[0014] 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.
[0015] 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.
[0016] 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.
[0017] 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.
[0018] 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.
[0019] 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.
[0020] 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.TM. 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).
[0021] 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.
[0022] 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.
[0023] 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.
[0024] 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, 2002, which is
hereby incorporated fully by reference.
[0025] 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.
[0026] Another configuration of the network security system 10 is
illustrated by a simplified diagram in FIG. 2. FIG. 2 shows a
configuration in which agents 12 are distributed at multiple remote
sites that are connected to the Internet 54. Agent 12(d) collects
events from monitor device 42, which monitors the Denver LAN 30.
Similarly Agent 12(e) collects events from monitor device 44, which
monitors the Austin LAN 32. The manager 14 collecting the security
events from the agents 12 can be located at a third site, e.g., the
Los Angeles headquarters, or at either site shown in FIG. 2.
[0027] 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.
[0028] 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.
[0029] 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.
[0030] 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."
[0031] 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.
[0032] 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.
[0033] 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.
[0034] One embodiment of an agent 12 configured to perform zone
identification is now described with reference to FIG. 3. In one
embodiment, unprocessed security events from the monitor device
(e.g. IDS) associated with the agent 12 are collected by the agent
12 in an input buffer 60. This information is then used by the
agent normalize module 62, which is configured to map the data
contained in the unprocessed security events to a normalized event
schema. In one embodiment, the event fields included in the event
schema include various zone fields. In one embodiment, these
include a zone associated with an event source, a zone associated
with an event destination, a zone associated with the monitor
device, and a zone associated with the agent.
[0035] 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-US-00001 TABLE 1 IP Address Range Zone Name
9.0.0.0-9.255.255.255 Public Address Space: IBM
56.0.0.0-56.255.255.255 Public Address Space: US Postal Service
191.0.0.0-192.0.1.255 Public Address Space 192.168.0.0-192.168.0.64
Denver: Engineering 192.168.0.64-192.168.0.128 Denver: Marketing
192.168.0.128-192.168.0.255 Denver: DMZ
192.168.0.255-192.168.255.255 Private Address Space
197.0.0.0-197.255.255.255 Dark Address Space
[0036] 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."
[0037] 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.
[0038] One embodiment of zone identification is now described with
reference to FIG. 4. In block 102, the agent receives the raw
unprocessed security event from the monitor device, such as a
firewall, router, or IDS. In block 104, the agent determines the
zone to which the source of the security event belongs.
[0039] 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.
[0040] 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.
[0041] 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.
[0042] 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.
[0043] 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.
[0044] 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.
[0045] 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 FIG. 1, 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.
* * * * *