Patent Grant
7954160
1. Field of the Invention
The present invention relates to intrusion detection systems. More particularly, the invention concerns an intrusion detection system that operates in a remote, on-demand computing service environment.
2. Description of the Prior Art
By way of background, many institutional entities purchase or lease computing resources and deploy them physically within their facilities. Users of these data processing systems will typically connect thereto over an institutional network or, to a limited degree, the institution may allow trusted individuals some type of VPN (Virtual Private Network) remote access over a public network, such as the Internet. In either case, the type of access to the data processing system (and by whom) is known.
Remote, on-demand computing is a more recent innovation in the data processing field. According to this model, a customer obtains computing services from a remote computer system that is not under the customer's physical custody and control. Instead, the remote system is typically owned by another entity that maintains the system at its own premises. In some cases, the system owner's equipment used to provide remote, on-demand service may be spread over plural geographic locations, as where the remote on-demand system comprises a computer grid network with plural interlinked data processing hosts. A disadvantage of remote, on-demand computing is that it is difficult for the remote user to know whether or not their applications and data are being accessed by others who may also have access to the same computer equipment, such as a system administrator associated with the on-demand service provider. On-demand users are generally provided with firewall protection implemented on the data processing hosts assigned to provide the on-demand services. However, firewalls only block network-originating intrusions, and only based on a fixed set of specific rules. Events such as a login by an on-premises administrator via a local console are typically not blocked, or even reported.
An intrusion detection system can detect unusual events and provide a record of suspected activity, regardless of its point of origin. However, as far as known, intrusion detection has not been offered to remote on-demand users so that they can monitor intrusion activity on the remote data processing hosts to which they are assigned. This may cause customers to be reluctant to take advantage of remote, on-demand services. For example, consider a hardware vendor who wishes to encourage a proprietary software vendor to test the software vendor's software on the hardware vendor's computing platform. Given the option of either running the software under a remote, on-demand service model or simply borrowing or renting the hardware and setting it up at their own facility, a security conscious software vendor may well insist on the latter arrangement. This is undesirable from the hardware vendor's perspective due to the high capital costs of equipment loaner and leasing programs.
Accordingly, an intrusion detection system is needed that can provide remote on-demand computing service users with the security assurances they require before utilizing such services. What would be particularly desirable is an intrusion detection system for use in a remote, on-demand computing service environment wherein users are provided with a view of the remote data processing resources as though such resources where physically “in house,” and wherein the users are fully informed whenever security has been violated. Preferably, remote, on-demand service users should have the ability to fully define each type of security event they desire to have monitored and to specify how such events are to be handled.
The foregoing problems are solved and an advance in the art is obtained by an intrusion detection system, and a related method and computer program product, for implementing intrusion detection in a remote, on-demand computing service environment in which one or more data processing hosts are made available to a remote on-demand user that does not have physical custody and control over the host(s). Intrusion detection performed by the intrusion detection system entails monitoring one or more resources defined by the on-demand user for intrusion events that are also defined by the on-demand user, and implementing responses according to event-action rules that are further defined by the on-demand user. Alternatively, the resources, events and responses can be defined by a third party entity, such as a security provider, authorized to act on behalf of the on-demand user.
According to exemplary implementations of the invention, the intrusion detection system includes an intrusion detection system (IDS) agent associated with each data processing host. The IDS agent(s) is/are adapted to monitor the user-defined events and report intrusion activity. If there are plural IDS agents, they can be individually programmed to monitor agent-specific sets of user-defined intrusion events. The intrusion detection system further includes an intrusion detection system (IDS) controller associated with one of the data processing hosts. The IDS controller is adapted to manage and monitor the IDS agent(s), process agent reports of intrusion activity, and communicate intrusion-related information to the on-demand user or other authorized entity. User-defined responses to intrusion events can be implemented by the IDS controller in combination with the IDS agent(s), or by any such entity alone.
The foregoing and other features and advantages of the invention will be apparent from the following more particular description of exemplary embodiments of the invention, as illustrated in the accompanying Drawings, in which:
Turning now to the drawing figures, wherein like reference numerals indicate like elements in all of the several views,
Additional equipment, such as data storage systems 141 and 142, may be provided as part of the system 4 to support the data processing operations required by the on-demand user system 8. All of these entities may be interconnected by way of a network 16 or other communication interface operating according to a conventional protocol, such as TCP/IP. It should be further understood that the data processing hosts of the system 4 need not all be situated at the premises 10. As shown in
Although
Turning now to
The intrusion detection system 30 is adapted to allow an on-demand user to monitor activity on data processing hosts 61, 62, 63 . . . 6n of the system 4, regardless of its point of origin. Moreover, the on-demand user can act as if it were the owner of the data processing hosts 61, 62, 63 . . . 6n and the system 4 was physically located at the on-demand user premises 12. These advantages are obtained by allowing the on-demand user to customize and control all major aspects of intrusion detection system operation even though the on-demand user does not have physical custody and control over the data processing hosts 61, 62, 63 . . . 6n. In particular, even though another entity may own and operate the data processing hosts 61, 62, 63 . . . 6n, the intrusion detection system 30 allows the on-demand user to monitor resources thereon that are defined by the on-demand user for intrusion events that are likewise defined by the on-demand user, and to implement responses according to event-action rules that are further defined by the on-demand user.
The resources that the intrusion detection system 30 can be programmed by the on-demand user to monitor for signs that the system 4 may be compromised are many and varied. By way of example only, detection capabilities that may be selectively specified by the on-demand user could include:
By examining these and other resources, the intrusion detection system 30 can be customized by the on-demand user to track any relevant intrusion event occurring in the system 4, including hardware events, operating system events, system access events and network access events. Activity that does not correspond to a tracked intrusion event for a monitored resource will be allowed to proceed. Activity that corresponds to a tracked event for a resource being monitored will be handled by way of responses or response sequences according to the event-action rules defined by the on-demand user. Such event-action rules can be written using any suitable policy definition language (such as a conventional “if-then-else” policy language of the type used for policy-based network management).
The actions taken in response to intrusion events will typically include logging the events and reporting them to the on-demand user via the on-demand user system 8. Depending on the requirements of the on-demand user, the reporting of response actions could be triggered by a single intrusion event as well as complex event sequences, such as repeated access attempts from a single potentially hostile source. In all cases, the intrusion detection system 30 will maintain a record of unusual activity in the system 4 (as defined by the on-demand user) so that the on-demand user can review any accesses that took place and validate them. In addition to the reporting of intrusion events, the actions taken in response to intrusion events may include remedial actions or action sequences, such as blocking incoming packets at a network port, denying access to a file, etc. To provide additional flexibility, the intrusion detection system 30 may be programmed to allow event context information to be specified as part of event-action rules, such as the time when an event occurs. With this capability, the on-demand user could specify complex rules, such as rules for taking different actions in response to events at different times of day.
As an example of the manner in which the intrusion detection system 30 can handle intrusion events based on event-action rules specified by the on-demand user, consider a scenario where an unauthorized root user, possibly an administrator associated with the on-demand service provider that owns the system 4, logs in and attempts to alter the permissions of a non-root user file. Assuming the intrusion detection system 30 is programmed by the on-demand user to track login and user file permission alteration events, an event-action rule could be triggered that causes a report to be sent to the on-demand user that the login has occurred, and that the user file has had its permissions changed. The on-demand user could then take action on its own to rectify the situation, such as to place a telephone call the on-demand service provider. Alternatively, the on-demand user could specify an event-action rule that causes a remedial action to be performed by the intrusion detection system 30. For example, the on-demand user could specify that a message be sent to the administrator advising that the file permission change is unauthorized and requesting that the person contact the on-demand user to provide an explanation.
A further illustration of the manner in which the intrusion detection system 30 can handle intrusion events would be a scenario where a firewall on one of the data processing hosts 61, 62, 63 . . . 6n (with public network connectivity) reports unusual intrusion-related activity (e.g. a denial of service attack). In that case, an event-action rule specified by the on-demand user could provide for an intrusion detection system agent (described in more detail below) to call an API (Application Programming Interface) of a software application running on behalf of the on-demand user. Depending on the application, the API call could be used to modify the application's operational mode, protect its data, or even perform an application shutdown depending on the perceived threat level.
To help facilitate the on-demand user's specification of event-action rules, the intrusion detection system 30 can be configured with a default set of intrusion criteria based on the system's hardware, operating system, system configuration, system access and network configuration. Using a web-browser or other interface supported by the intrusion detection system 30, the on-demand user can then modify these criteria as desired. As described in more detail below, the intrusion detection system 30 will store the criteria defined by the on-demand user (which may be the default set of intrusion criteria if no changes are made) in appropriate configuration files. The intrusion detection system 30 will then generate and store the programs needed to detect intrusion events and the programs needed to implement user-defined actions when necessary. Recovery sequences for recovering the intrusion detection system 30 from an error condition can also be configured by the on-demand user, and a default set of criteria may again be provided by the on-demand service provider to assist the on-demand user in this regard.
Note that for purposes of the present invention, a default set of security-related criteria is considered to be on-demand user-defined so long as the on-demand user is given the opportunity to either approve or disapprove of at least some portion thereof, even if the default criteria remain unmodified. Nor does the invention require that the on-demand user interact with the intrusion detection system 30 for the purpose of specifying intrusion criteria. A non-technically savvy on-demand user may not wish to be bothered with such a task and may instead specify its security needs to personnel associated with the on-demand service provider, who will then edit the necessary files. Alternatively, the on-demand user may simply accept a default security policy that is made available by the on-demand security provider. For example, a service scenario could be implemented wherein the on-demand user is allowed to select one of several security packages offered by the on-demand service provider.
A further scenario falling within the scope of the invention would be where an authorized third party security provider (e.g., a security specialist) configures the on-demand user's security preferences by dealing with the on-demand service provider on behalf of the on-demand user, so that the on-demand user does not have to perform this function. This scenario is illustrated in
In the exemplary implementation of
The IDS controller 32 is the main control center of the intrusion detection system 30. It is adapted to manage and monitor the IDS agents 341, 342, 343 . . . 34n, interpret agent reports of intrusion event activity, and communicate intrusion-related information to the on-demand user system 8 (or other location authorized by the on-demand user). If configured to do so by (or on behalf of) the on-demand user, the IDS controller 32 will also instruct the IDS agents 341, 342, 343 . . . 34n to implement user-defined remedial actions in response to reported intrusion events. Alternatively, the IDS controller 32 could directly implement user-defined remedial actions without using the IDS agents 341, 342, 343 . . . 34n. Moreover, as described in more detail below, the IDS agents 341, 342, 343 . . . 34n could implement user-defined remedial actions without involvement of the IDS controller 32.
With regard to the management and monitoring of the IDS agents 341, 342, 343 . . . 34n, the IDS controller 32 is responsible for spawning each such software entity as each of the various data processing hosts 61, 62, 63 . . . 6n come online following system startup. The IDS controller 32 thereafter monitors agent operational status and takes corrective action (e.g., a restart sequence) in the event that an IDS agent 341, 342, 343 . . . 34n malfunctions or becomes non-responsive.
With regard to the receipt and interpretation of reports of intrusion activity provided by the IDS agents 341, 342, 343 . . . 34n, the IDS controller 32 can be implemented to provide a service interface (e.g., a TCP/IP network port) that the IDS agents access to report intrusion events. As each intrusion report is received at the IDS controller 32, can be processed according to event-action rules specified in a rule set file 38 maintained on the data processing host (e.g., 63) that hosts the IDS controller 32. This rule set file 38 contains the event-action rules defined by (or on behalf of) the on-demand user, but as indicated above, a default rule set may be provided to establish a starting point for user customization. When a specific rule requires that a response action be taken following receipt of an intrusion event report, the IDS controller 32 will orchestrate that action following the lookup in the rule set file 38 (either alone or with assistance from the IDS agents 341, 342, 343 . . . 34n). It will be appreciated that different event-action rules may be specified for each data processing host 61, 62, 63 . . . 6n.
Although a single rule set file 38 is shown for use by the IDS controller 32 on the data processing host 63, an alternative arrangement could be implemented wherein some or all of the event-action rules specified by (or on behalf of) the on-demand user are maintained in plural rule set files distributed across the data processing hosts 61, 62, 63 . . . 6n (see reference numerals 381, 382 . . . 38n in
With regard to response actions involving the communication of intrusion-related information to the on-demand user system 8 (or other location authorized by the on-demand user), the IDS controller 32 can be programmed to log all intrusion activity and periodically report the log information to the on-demand user (or other entity authorized by the on-demand user). The frequency of such reports is programmable by (or on behalf of) the on-demand user, and may be based on perceived threat level and other factors.
The intrusion detection system 30 may further comprise a standby IDS controller 40 that can run on the same data processing host (e.g., 63) as the IDS controller 32, or on a different data processing host of the system 4. The standby IDS controller 40 is adapted to assume IDS controller functions in the event that the IDS controller 32 fails or is otherwise incapable of performing such functions. It will be appreciated that the combination of an IDS controller 32, one or more IDS agents 341, 342, 343 . . . 34n controlled by the IDS controller, and a standby IDS controller 40 provides an intrusion detection system 30 in which there is no single point of failure, and in which every data processing host 61, 62, 63 . . . 6n runs independent intrusion detection system services monitored by a highly available IDS controller pair.
It will be seen in
Turning now to
In step 52, the IDS controller 32 spawns the standby controller 40. For security reasons, the standby controller 40 is spawned on the same node that runs the IDS controller 32 (e.g., the data processing host 63). Alternatively, system robustness could be improved by hosting the standby controller 40 on a separate node. In that case, the standby controller 40 would remain operational even if the data processing host 63 went down. However, the security level of the intrusion detection system 30 could be affected because the IDS controller 32 and the standby controller 40 would be required to communicate with each other using a network protocol (such as TCP/IP) instead of the interprocess communication that can be used when these entities run on the same node.
In step 54, the IDS controller 32 spawns one of the IDS agents 341, 342, 343 . . . 34n on each node of the system 4 (e.g., data processing host 61, 62, 63 . . . 6n in
In step 56, the IDS controller 32 begins monitoring for intrusion events reported by the IDS agents 341, 342, 343 . . . 34n. When an intrusion report is received in step 57, the IDS controller 32 responds in step 58 by implementing actions specified in the rule set 38. As indicated, this will typically include the logging and reporting of intrusion events to the on-demand user system 8 (or other location authorized by the on-demand user), and may also include the implementation of user-defined remedial actions. As indicated above, such remedial actions could be implemented directly by the IDS controller 32, or by submitting action requests to the IDS agents 341, 342, 343 . . . 34n. On the other hand, if the IDS agents 341, 342, 343 . . . 34n perform their own event-action processing using local rule sets (381, 382 . . . 38n in
Turning now to
Accordingly, an intrusion detection system for use in a remote, on-demand computing service environment has been disclosed. It will be appreciated that the inventive concepts may be variously embodied in any of a data processing system, a machine implemented method, and a computer program product in which programming means are recorded on media for controlling a computer system to perform the required functions. Exemplary data storage media for storing such programming means are shown by reference numeral 100 in
Although various embodiments of the invention have been described, it should be apparent that many variations and alternative embodiments could be implemented in accordance with the invention. It is understood, therefore, that the invention is not to be in any way limited except in accordance with the spirit of the appended claims and their equivalents.
This application is a continuation under 35 U.S.C. 120 of application Ser. No. 11/079,380, filed Mar. 14, 2005, entitled “Computer Security Intrusion Detection System For Remote, On-Demand Users.”
| Number | Name | Date | Kind |
|---|---|---|---|
| 6986161 | Billhartz | Jan 2006 | B2 |
| 20020069369 | Tremain | Jun 2002 | A1 |
| 20020087882 | Schneier et al. | Jul 2002 | A1 |
| 20020112185 | Hodges | Aug 2002 | A1 |
| 20020162026 | Neuman et al. | Oct 2002 | A1 |
| 20030172145 | Nguyen | Sep 2003 | A1 |
| 20030188189 | Desai et al. | Oct 2003 | A1 |
| 20030220940 | Futoransky et al. | Nov 2003 | A1 |
| 20030229559 | Panttaja et al. | Dec 2003 | A1 |
| 20040073800 | Shah et al. | Apr 2004 | A1 |
| 20040123141 | Yadav | Jun 2004 | A1 |
| 20040143749 | Tajalli | Jul 2004 | A1 |
| 20040260945 | Raikar et al. | Dec 2004 | A1 |
| Number | Date | Country |
|---|---|---|
| WO0137511 | May 2001 | WO |
| Number | Date | Country | |
|---|---|---|---|
| 20100011440 A1 | Jan 2010 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 11079380 | Mar 2005 | US |
| Child | 12560811 | US |
