Patent Application
20080168549
1. Field of the Invention
The present disclosure relates generally to network security, and more specifically to a method and apparatus for implementing security applications efficiently in a network environment containing several gateway systems.
2. Related Art
A networked environment generally contains several systems (from which users access various resources or at which resources are available for access) connected by a network. A network in turn contains various switches connecting the systems by appropriate communication paths, as is well known in the relevant arts.
Security applications are often implemented in networked environments, generally to protect systems from undesirable packets. In general, a security application examines the content (typically header as well as payload) of various packets and determines whether to forward or block the packets. The packets are often scanned for determining various threats such as DOS attacks and viruses, and packets may be blocked depending on the level of security threat detected.
Security applications are often implemented on several security devices (often termed as security gateways) provided along with the network. The security devices may include gateways which provide other utilities such as switching (in which case the switch is often referred to as a gateway), and special purpose devices dedicated for security related applications alone.
It is generally desirable that the security application(s) be implemented efficiently so that resource requirements such as processing power and/or memory are reduced.
The present invention will be described with reference to the accompanying drawings, which are described below briefly. In the drawings, like reference numbers generally indicate identical, functionally similar, and/or structurally similar elements. The drawing in which an element first appears is indicated by the leftmost digit(s) in the corresponding reference number.
Figure (FIG.) 1 is a block diagram illustrating an example environment in which several aspects of the present invention can be implemented.
In one embodiment, security devices communicate to determine the respective roles within a community designed for a security application, and then operate according to the determined role. For example, a first device in the community may be determined as a primary player and other devices may be determined as secondary players. The primary player may then operate with more stringent security policies (e.g., larger set of signatures in case of a anti-virus application) and the secondary players may operate with less stringent security policies.
Assuming the primary player would cover any deficiencies in the security operation of the secondary player and both the players are in the path to the (user/server) systems sought to be protected, a desired high security level may be attained by a combination of operation of the two players. At the same time, the computational requirements in the secondary players are reduced.
According to another aspect of the present invention, a secondary player checks the operational status of the (original) primary player, and may revert to operation as a primary player if the original primary player is determined not to be operational. The operational devices may communicate again to determine the respective roles to determine if such a role change is required.
Several aspects of the invention are described below with reference to examples for illustration. It should be understood that numerous specific details, relationships, and methods are set forth to provide a full understanding of the invention. One skilled in the relevant art, however, will readily recognize that the invention can be practiced without one or more of the specific details, or with other methods, etc. In other instances, well-known structures or operations are not shown in detail to avoid obscuring the features of the invention.
For illustration, it is assumed that location 101 corresponds to a corporate office having various communication facilities as a hub and locations 102-104 correspond to branch offices. It may be observed that locations 102 and 103 are connected directly to location 101 and location 104 is connected via location 103. Each block of
User systems 111A-111X represent devices, which can be used to access various data and services (e.g., on server system 161) using LAN 131. LAN 131 may also be implemented using IP (and Ethernet), and provide communication between user systems 111A-111X, as well as with external systems (e.g., server system 164). Server system 161 represents a system from which data and services can be accessed from user systems 111A-111X.
Switching device 151 forwards packets from one interface to other (operating as a router), and also implements various services (e.g., firewall, intrusion detection system). In embodiment(s) described below, switching device 151 is assumed to operate consistent with Internet Protocol (IP) and thus the interface on which the packet is forwarded, depends on the destination IP address of the packet.
Switching device 151 is shown connected to switching devices 152 and 153 by corresponding communication links. Switching device 153 is in turn shown connected to switching device 154. Each of the switching devices 101 -104 may also operate as a security device (and thus interchangeably referred to as a switching device of security device), which selectively forwards some of the packets by implementing the corresponding security applications. The manner in which the security applications may be implemented efficiently in various switches is described below in further detail.
In step 210, switching device 151 receives configuration data indicating a community identifier and a relative level within the community. The configuration data may be received from a non-volatile memory provided within switching device 151 or from an external device on a network.
The community identifier uniquely identifies the community to which the device belongs, and the relative level is used to determine the role to be played by the device when implementing a security application. A community represents a group of devices which operate cooperatively in implementing a security application. An administrator may configure the identifier and level to control the members of a community and a role to be played by the security device.
In step 220, switching device 151 identifies the role to be played in that community based on the relative level. The device may communicate with other devices in identifying the role. In an embodiment described below, only one of the members of a community operates as a primary device and the others operate as secondary devices. The device configured with the highest relative level may assume the role of the primary device, while the remaining devices assume the role of secondary devices.
In step 230, switching device 151 determines a set of security policies to be applied by the security application according to the identified role. In one embodiment, each security application operates using a set of security policies, which determine the specific packets to be discarded or forwarded. Multiple sets of security policies may be stored, with each set corresponding to one of the corresponding roles. For illustration, an exhaustive set of security policies (IDS signatures) may be used associated with a primary role, and a less stringent set of roles may be associated with a secondary role.
In step 240, switching device 151 receives packets for forwarding. In step 250, switching device checks whether the identified set of security policies permits the packets to be forwarded or blocked according to the security application. The header and/or payload of potentially multiple packets may be examined according to the security policies in determining whether to forward or block packets.
From step 250 control passes to step 260 if the packets are to be discarded and to step 270 otherwise. In step 260, switching device 151 discards (or blocks) the packets. Control then passes to step 240 to process more packets.
In step 270, switching device 151 forwards the data packets to the recipient specified by the destination (IP) address of the packet. Accordingly, the forwarding may be caused by operation of switching device 151 as a IP routing device. Control then passes to step 240.
It should be appreciated that the flowchart of
Thus, the packets are processed according to the security policies determined by the role. While the flowchart is described assuming that a security device operates with the same role, it should be appreciated that the role can change, as described below with an example.
In step 285, security device 152 checks whether primary security device 151 is operational. The checking may be implemented through well known heart-beat/Keep-Alive ‘message’ type mechanisms. Missing responses to more than 3 consecutive keep-alive messages may lead to the conclusion that primary security device 151 is not operational. The number of Keep-Alive messages to determine the state change is administratively configurable. Control passes to step 285 if primary security device 151 is operational and to step 290 otherwise. The loop around 285 indicates that the status is checked periodically.
In step 290, security device 152 determines the new role to be played in view of the non-operational status of security application on primary security device 151. In step 295, security device 152 identifies the set of security policies to be applied by the security application based on the new role.
In step 296, security device 152 checks whether it is operating as a primary security device temporarily (due to the non-operational status of switching device 151). Control transfers to step 285 if security device 152 is operating as a secondary security device. Otherwise, control passes to step 297.
In step 297, security device 152 monitors the status of other security devices to determine whether any device configured with higher priority has become operational. Control remains in step 297 until such a condition is detected. Control transfers to step 290 when primary security device 151 is determined to be operational.
Thus, a device configured with lower priority may operate as a primary security device only so long as higher priority devices are non-operational. It should be further appreciated that each security device can be configured to be a part of multiple communities as described below in further detail.
security device 151
configuration community=comm-A level=25
configuration community=comm-C level=25
security device 152
configuration community=comm-C level=50
security device 153
configuration community=comm-A level=50
configuration community=comm-B level=25
security device 154
configuration community=comm-B level=50
Thus, it may be appreciated that security devices 151 and 153 are configured to be members of multiple communities. Though the configuration data above is shown without reference to specific security application, it should be appreciated that the approach of above can be used to specify potentially different communities and levels for different security applications.
It is further assumed that each device can take on only one of two possible roles (primary and secondary), with the lower value indicating a more stringent (primary) role. Thus, security device 151 would operate with a primary role in both communities A and C. However, if it is desirable to limit the processing (related to security application) in the root nodes (i.e., 151), the lower level devices (152 and 153) may be configured with lower level values to cause them to operate with primary roles.
As noted above with respect to
Thus, it may be appreciated that communication can be used to determine the roles of the devices in each community. Various approaches (distributed, centralized, etc.) can be used in determining the roles. In an embodiment, the BGP protocol is extended to provide for the communication (in a distributed manner). In general, the communication needs to contain data to indicate the necessary information and can be included by extending any protocol (for example as specified in Assigned Numbers RFC 1700), as will be apparent to one skilled in the relevant arts.
It should be appreciated that the features described above may be implemented in various combinations of hardware, software and firmware, depending on the corresponding requirements. The description is continued with respect to some example embodiments.
Inbound interface 410 and outbound interface 490 provide electrical and protocol interfaces to respectively receive and send internet protocol (IP) packets on an appropriate medium. Inbound interface 410 (packets received from one of LAN or communication path shown by a bidirectional line to external switching device) forwards the received packets to parser 420. Outbound interface 490 forwards packets received from forwarding block 470 to LAN 131 or the communication path as specified by forwarding block 470. Inbound interface 410 and outbound interface 490 may be implemented in a known way.
Parser 420 examines each IP packet received from inbound interface 410 to determine whether to forward packets to role block 425, security block 430 or routing block 460. In general, packets related to determination of roles (e.g., according to steps 220, 285 and 290) are forwarded to role block 425, packets related to routing updates (e.g., according to protocols such as RIP, OSPF, well known in the relevant arts) are forwarded to routing block 460, and packets which need to be switched/routed are forwarded to security block 430.
Routing block 460 receives packets representing routing updates (links up/down, congestion metrics, etc.) and translates the updates into (and stores as) entries in forwarding table 480. Each entry of forwarding table 480 may indicate the specific path/physical port (which specifies the communication path) on which packets with matching destination IP addresses are to be forwarded (permitting packet switching at layer-3/IP level).
Nonvolatile memory 415 stores the different sets of security policies which can used by security block 430 in implementing a security application. Configuration data indicating the community identifiers and the relative levels within the community may also be stored in non-volatile memory 415.
Role block 425 identifies the corresponding role played by the switching device 151 for each of the security applications implemented by security block 430. Role block 425 may send any necessary packets to other security devices using outbound interface 490 and receive packets from other security devices via parser 420 in identifying the roles.
Role block 425 retrieves the policy set corresponding to the identified role and stores the policy set in policy data 440. Policy data 440 may be implemented in a random access memory (RAM), and a suitable mechanism (well known in the relevant arts) may be provided to cause security block 430 to switch to a new policy set if role block 425 determines to change the role according to
Security block 430 executes each security application of relevance, for example, based on the packets and policy rules applicable to the device. With respect to applications operating according to rules, security block 430 may execute the security applications according to the policies in policy data 440 to determine whether to discard the packets received. The packets determined not to be discarded, are forwarded to NAT processing block 450.
NAT processing block 450 performs any required network address translation operation on various addresses (port numbers or IP addresses, typically) in the packet headers (according to TCP/UDP/IP). The packets with such translated addresses are provided to forwarding block 470.
Forwarding block 470 may forward the packets (using outbound interface 490) based on the entries in forwarding table 480, usually based on the destination address present in the header. In general, the specific interface (path/physical port) on which to forward the packet is determined based on the destination address.
Thus, due to the operation of role block 425, different set of security policies may be applied by security applications depending on the assumed role. As the resource requirements (processing power, memory requirements, etc.) differ based on the set of security policies used, a network administrator may conveniently configure different security devices to operate with different resource requirements in implementing security applications.
While the operation of role block 425 is described with respect to changing sets of security policies to control the role played by the specific switching device, it should be appreciated that other approaches can be employed to change the roles, as suitable for the specific security application. For example, anomaly based detection systems can employ different set of heuristics depending on the specific role being played.
The description is continued with respect to an embodiment in which some of such features are operative upon execution of the corresponding software instructions.
Input interface 590 (e.g., interface with a key-board and/or mouse, not shown) enables a user/administrator to provide any necessary inputs to system 500. Output interface 560 provides output signals (e.g., display signals to a display unit, not shown), and the two interfaces together can form the basis for a suitable user interface for an administrator to interact with system 500. The administrator may provide various configuration data noted above using such an interface.
Network interface 580 may enable system 500 to send/receive data packets to/from other systems on corresponding paths using protocols such as internet protocol (IP). Network interface 580, output interface 560 and input interface 590 can be implemented in a known way.
RAM 520, secondary memory 530, and packet memory 570 may together be referred to as a memory. RAM 520 receives instructions and data on path 550 (which may represent several buses) from secondary memory 530, and provides the instructions to central processing unit 510 for execution. RAM 520 may be used to store the various tables (e.g., routing table and policies data) described above.
In general the various memories noted above (whether read only or random access, removal or not, etc.) represent example computer/machine readable medium from which instructions can be retrieved and executed by various processors.
Packet memory 570 stores (queues) packets waiting to be forwarded (or otherwise processed) on different ports/interfaces. Secondary memory 530 may contain units such as hard drive 535 and removable storage drive 537.
Some or all of the data and instructions may be provided on removable storage unit 540 (or from a network using protocols such as Internet Protocol), and the data and instructions may be read and provided by removable storage drive 537 to central processing unit 510. Floppy drive, magnetic tape drive, CD-ROM drive, DVD Drive, Flash memory, removable memory chip (PCMCIA Card, EPROM) are examples of such removable storage drive 537.
Central processing unit 510 may contain one or more processors. Some of the processors can be general purpose processors which execute instructions provided from RAM 520. Some can be special purpose processors adapted for specific tasks (e.g., for memory/queue management). The special purpose processors may also be provided instructions from RAM 520. In general, central processing unit 510 reads sequences of instructions from various types of memory medium (including RAM 520, storage 530 and removable storage unit 540), and executes the instructions to provide various features of the present invention described above.
While various embodiments of the present invention have been described above, it should be understood that they have been presented by way of example only, and not limitation. Thus, the breadth and scope of the present invention should not be limited by any of the above-described embodiments, but should be defined only in accordance with the following claims and their equivalents.
