Patent Application
20110209215
Embodiments of the present invention relate in general to the field of network security and, more specifically, to intrusion prevention systems and the deployment of traffic scanning resources.
Electronic communication networks based on the Internet Protocol (IP) have become ubiquitous. Although the primary focus of the information technology (IT) industry over the last two decades has been to achieve “anytime, anywhere” IP network connectivity, that problem has, to a large extent, been solved. Individuals can now use a wide variety of devices connected to a combination of public and private networks to communicate with each other and use applications within and between private enterprises, government agencies, public spaces (such as coffee shops and airports), and even private residences. A corporate executive can now reliably send an email message wirelessly using a handheld device at a restaurant to a schoolteacher using a desktop computer connected to the Internet by a wired telephone line halfway around the world.
In other words, virtually any IP-enabled device today can communicate with any other IP-enabled device at any time. Advances in the resiliency, reliability, and speed of IP connections have been made possible by improvements to the traditional routers and switches that form the “IP connectivity” of IP networks. Such “IP connectivity” networks have propelled business productivity enormously the world over.
Concurrently, the sophistication of internal and external network attacks in the form of viruses, Trojan horses, worms and malware of all sorts has increased dramatically. Just as dramatic is the accelerated increase of network speeds and a corresponding drop in their cost, thereby driving their rapid adoption. These factors and others have necessitated the development of innovative and more advanced network security mechanisms. Enterprise executives understand this reality. From a technical perspective, CIOs know that the current connectivity network cannot resolve security and application performance issues. In turn, from a financial perspective, CFOs are concerned that it will be too expensive to solve these problems by performing full IPS coverage on each network link. Finally, from an overall business perspective, CEOs cannot tolerate network security downtime risk, and are demanding predictable, stable application performance.
Consider some of the problems of conventional connectivity networks in more detail. One solution to this problem has been to use firewalls to establish a network “perimeter” defining which users and devices are “inside”—and therefore authorized to access the network—and which users and devices are “outside”—and therefore prohibited from accessing the network. The concept of a clear network perimeter made sense when all users accessed the network from fixed devices (such as desktop computers) that were physically located within and wired to the network. Now, however, users access the network from a variety of devices—including laptops, cell phones, and PDAs—using both wired and wireless connections, and from a variety of locations inside and outside the physical plant of the enterprise. As a result, the perimeter has blurred, thereby limiting the utility of firewalls and other systems which are premised on a clear inside-outside distinction.
The typical cost of a successful attack is higher today than in the past because of the increased value of information stored on modern networks. The use of networks to connect a larger number and wider variety of devices is both causing problems for traditional access control mechanisms and leading to the use of the network to store increasingly high-value information. Although one way to protect information stored on the network would be to use intrusion prevention systems (IPSs) to perform deep packet inspection on each link, or along the entire network perimeter, the cost of doing so at the high speeds required by modern networks is prohibitively expensive. Therefore, there is a need to provide a low-cost mechanism for preventing high-cost network security breaches.
Embodiments of the present invention provide a low-cost mechanism for preventing high-cost network security breaches. In one embodiment of the present invention, a meta-policy is created and utilized to determine the present trust level of traffic associated with a source. The dynamic meta-policy may only associate one or more actions with an input, and thereby differ from a static policy. In particular, the meta-policy may be a series of input-to-action associations, where each association is valid during a particular state of the meta-policy. The meta-policy may also include state transition descriptions that transition the meta-policy from one state to another state.
For example, in one embodiment of the present invention, an electronic communication network includes connectivity devices. A connectivity system, upon receiving network traffic, determines a source of the traffic, sends a present trust level request to a present trust level system, receives a present trust level response, and, based on that response, either forwards the traffic directly or directs the traffic to security traffic inspection resources.
For example, one embodiment of the present invention is directed to a method and/or system comprising: (A) at a network traffic receiving subsystem: (A)(1) receiving first network traffic; (A)(2) identifying a first source of the first network traffic; (A)(3) requesting a first present trust level of the first source from a present trust subsystem; (A)(4) receiving the first present trust level of the first source from the present trust subsystem; (A)(5) determining whether to provide the first network traffic to an intrusion prevention subsystem based on the first present trust level of the first source; and (A)(6) providing the first network traffic to the intrusion prevention subsystem if it is determined that the first network traffic should be provided to the intrusion prevention subsystem.
Another embodiment of the present invention is directed to a method and/or system comprising: (A) receiving, from a network traffic receiving subsystem, a first request for a first present trust level of a first source of first network traffic; (B) determining the first present trust level of the first source based on an identifier of the first source and a first policy associated with the first source; and (C) sending, to the network traffic receiving subsystem, a response specifying the first present trust level of the first network source.
Yet another embodiment of the present invention is directed to a method and/or system comprising: (A) receiving, from a network traffic receiving subsystem, a first request for a first present trust level of a first source of first network traffic; (B) determining the first present trust level of the first source based on an identifier of the first source and at least one of: other network traffic received from the first source; a location of a network connection of the first source; and an application associated with the first source; and (C) sending, to the network traffic receiving subsystem, a response specifying the first present trust level of the first network source.
Other features and advantages of various aspects and embodiments of the present invention will become apparent from the following description and from the claims.
Referring to
End nodes 131a and 131b send packets that are received by switches 110 and 112. The switches 110 and 112 request a present trust level of the source of the received packet. The “present” trust level of the source refers to a trust level of the source at or around the time at which the packet was received by one of the switches 110 and 112. As a result, the present trust level of the source may change over time. For example, the source may have a first present trust level at a first time and a second present trust level, which may be the same as or differ from the first present trust level, at a second time. When an endnode is running a virtual environment the switch function may be implemented in the endnode network adapter (not shown in
The Present Trust Engine 140 receives the request, identifies the present trust level of the source, and sends to the switch a response which indicates the identified present trust level of the source. The Present Trust Engine 140 may identify the present trust level of the source by, for example, reading: (1) a data object that contains dynamic meta-policy information (data and logic), and (2) (optionally) other network information. The other network information may, for example, include network traffic history and/or network device capabilities of a specified network location.
The Present Trust Engine 140 responds to the requesting switch with the present trust level of the network source. The Present Trust Engine 140 may also pass traffic redirect instructions back to the requesting switch. The switch uses the response to decide whether to forward the packet without utilizing IPS resources or to redirect the packet to an IPS resource for scanning (i.e., deep packet inspection). If the switch redirects the packet to an IPS resource, the switch may pass security scanning parameters to the IPS resource, in which case the IPS resource may use the security scanning parameters to focus the packet scanning operation. The traffic redirect instructions passed back to the switch, if any, may include, for example, information about which IPS resource to use and information about the endnode's traffic that may be used by the IPS resource to focus its traffic inspection actions. Information about the endnode's traffic may include, for example, information about the applications which transmitted the traffic, the hardware platform of the endnode, and the endnode's security track record.
Referring to
The Present Policy Manager 230 therefore uses the network Source ID 204 to identify the part(s) of the Meta-Policy data object 210 which is/are relevant to the particular network source. Assume, for example, that the Source ID 204 identifies the part of the Meta-Policy data object 210 containing elements 212a, 214a, and 216a. In this case, the Present Trust Level 212a may represent the most-recently determined present trust level of the particular network source, the Recent History 214a may represent network traffic sent by the particular network source, and the Present Policy Logic 216a may contain logic which may be used to determine a new present trust level of the particular network source.
The Present Policy Manager 230 may read the Present Trust Level 212a, the Recent History 214a, and the Present Policy Logic 216a associated with the particular network source. This data 212a, 214a, and 216a may each have its own time stamp. The Present Policy Manager 230, therefore, may compare the time stamps of the data 212a, 214a, and 216a to the Present Time 206 to determine how recent the data 212a, 214a, and 216a is.
As described in more detail below, the Present Policy Manager 230 may use the Present Policy Logic 216a associated with the particular network source to determine a new present trust level of the particular network source. The Present Policy Manager 230 may then update the dynamic Meta-Policy data object 210 to reflect this new present trust level. Furthermore, the Present Policy Manager 230 may update the dynamic Meta-Policy data object 210 to reflect the new recent history of the particular network source, and to reflect new present policy logic associated with the particular network source. For example, as shown in
In the particular example shown in
Updating the Meta-Policy data object 210 with new present policy logic makes the Meta-Policy data object 210 a dynamic data object. This enables the present trust level of the network source to change over time, either building (increasing) or losing (decreasing) trust based upon factors such as network or end node history and end node network locations. An example of a trust calculation state machine which may be used to enable such changes in trust level over time is further described below in connection with
Referring to
In the embodiment illustrated in
In the embodiment illustrated in
Referring to
Prior art security systems analyze only traffic sent from or to the endnode to determine the potential threat posed by an endnode. Some prior art systems may also do an initial “posture check” of the endnode to assure it has the required software and software versions. In embodiments of the present invention, the Present Trust Engine 140 may both analyze traffic and perform a posture check to determine the potential threat posed by an endnode. More specifically, as shown in
Referring to
If the source passes this baseline check (step 402), then the source is transitioned into the Low Trust state 414 (step 403), represented by transition 491 of the state machine 410 in
Referring to
Referring to
If, however, suspicion has been built by observing the traffic from this source, and/or other Endnode Factors 482 during the second monitoring check of step 421, then the source is transitioned (demoted) to the No Trust state 412 (step 408). The Endnode Factors 482 may include, for example, suspicious traffic sent by the source, a change of the source's network connection location, a change of applications running on the source, or other factor associated with the source. If trust has not been built to merit promotion to the High Trust state 418, then the source is kept at the Medium Trust state 416 (step 425) to again be monitored for a policy-specified period of time. Some sources may not be allowed to enter the High Trust state 418 due to variety of factors such as one or more of the following: a lack of any activity (even if no suspicious activity has been observed); connection of the source to the network at a location deemed risky; and execution of a high-risk application on the source.
If the source does not pass the second monitoring period check of step 422, then a determination is made about the severity of the failure to pass the second monitoring period check (step 426). If the failure was severe enough (e.g., if the severity exceeds some predetermined threshold value) then the source is demoted to No Trust state 412 (step 427), represented by transition 494 of the state machine 410 in
Referring to
If it is determined that the source should not stay in the High Trust state 418, then the severity of the concern is measured. If the severity is high (e.g., exceeds some predetermined threshold value), such as if traffic from the source is suspicious, or if a location change of the source indicates that another source is masquerading as this source, then the source is demoted to the No Trust state 412 (step 435), represented by transition 496 of the state machine 410 in
Referring to
Referring to
Also for each network area the capabilities of the IPS resources are saved in Network Capabilities 213x. Each IPS resource has a description stored. This description may contain, for example: hardware capabilities that indicate the performance to the IPS packet scanning; software capabilities that indicate the performance and types of scanning of the IPS resource; the current assigned load; and queue depths. The Network Capabilities 213x is used by the Present Trust Engine 140 to help direct the switch to the IPS resource that will provide the best performance for that endnode at that point in time.
The techniques described above may be implemented, for example, in hardware, software, firmware, or any combination thereof. The techniques described above may be implemented in one or more computer programs executing on a programmable computer including a processor, a storage medium readable by the processor (including, for example, volatile and non-volatile memory and/or storage elements), at least one input device, and at least one output device. Program code may be applied to input entered using the input device to perform the functions described and to generate output. The output may be provided to one or more output devices.
Each computer program within the scope of the claims below may be implemented in any programming language, such as assembly language, machine language, a high-level procedural programming language, or an object-oriented programming language. The programming language may, for example, be a compiled or interpreted programming language.
Each such computer program may be implemented in a computer program product tangibly embodied in a machine-readable storage device for execution by a computer processor. Method steps of the invention may be performed by a computer processor executing a program tangibly embodied on a computer-readable medium to perform functions of the invention by operating on input and generating output. Suitable processors include, by way of example, both general and special purpose microprocessors. Generally, the processor receives instructions and data from a read-only memory and/or a random access memory. Storage devices suitable for tangibly embodying computer program instructions include, for example, all forms of non-volatile memory, such as semiconductor memory devices, including EPROM, EEPROM, and flash memory devices; magnetic disks such as internal hard disks and removable disks; magneto-optical disks; and CD-ROMs. Any of the foregoing may be supplemented by, or incorporated in, specially-designed ASICs (application-specific integrated circuits) or FPGAs (Field-Programmable Gate Arrays). A computer can generally also receive programs and data from a storage medium such as an internal disk (not shown) or a removable disk. These elements will also be found in a conventional desktop or workstation computer as well as other computers suitable for executing computer programs implementing the methods described herein, which may be used in conjunction with any digital print engine or marking engine, display monitor, or other raster output device capable of producing color or gray scale pixels on paper, film, display screen, or other output medium.
