Title of Invention	A SYSTEM AND A METHOD FOR THE SURVIVABILITY OF INTRUSION DETECTION ENTITIES
Abstract	The present invention provides a system and method by means of which irrespective of the architecture, identified controls messages modules are triggered to achieve a cohesive 2-way communication among the cooperating entities of an Intrusion Detection System (IDS). The system and the method of the present invention allows the defining and execution of control messages for various possible survivable scenarios, this is done by defining the generic and optimal format for these control messages. The present system and method also implements and initiate these control messages among the cooperating components of the IDS system so that they exist cohesively. The applications of control messages are information sharing, issuing commands & directives and handling exceptions to achieve the goal of making the IDS components and the IDS system survivable. The other issues handled by the system and method of the present invention are initiation of backup, communication of availability of alternate resource, delegation of responsibility, isolation during crisis situation, switching among various modes of operations and revelation of the status information about the IDS components etc.

Title of Invention

A SYSTEM AND A METHOD FOR THE SURVIVABILITY OF INTRUSION DETECTION ENTITIES

Abstract

The present invention provides a system and method by means of which irrespective of the architecture, identified controls messages modules are triggered to achieve a cohesive 2-way communication among the cooperating entities of an Intrusion Detection System (IDS). The system and the method of the present invention allows the defining and execution of control messages for various possible survivable scenarios, this is done by defining the generic and optimal format for these control messages. The present system and method also implements and initiate these control messages among the cooperating components of the IDS system so that they exist cohesively. The applications of control messages are information sharing, issuing commands & directives and handling exceptions to achieve the goal of making the IDS components and the IDS system survivable. The other issues handled by the system and method of the present invention are initiation of backup, communication of availability of alternate resource, delegation of responsibility, isolation during crisis situation, switching among various modes of operations and revelation of the status information about the IDS components etc.

Full Text	A SYSTEM AND A METHOD FOR THE SURVIVABILITY OF INTRUSION DETECTION ENTITIES Technical Field The present invention relates to a system for survivability and synchronization of intrusion detection entities (IDEs) in a computer network by means of a cohesive 2-way control message communication among the intrusion detection entities. The present invention also provides a method for the survivability and synchronisation of intrusion detection entities (IDEs) in computer network by way of control message communication. Background and prior art An "Intrusion Detection System (IDS)" is a system for detecting intrusions and suspicious activity that may be occurring on the systems and networks. IDS attempt to detect such hatch plots and hibernated activity. The system accomplishes it by collecting information from various network and host sources (mainly system & network logs, messages and reports) and then analysing them for suspicious activity. Usually the information is collected through various sensors placed in hosts at various locations of the network. IDS entity is a process, a module or a system having mechanism and intelligence in-built to detect and/or respond to intrusions, deployed on a host at either a network periphery or system level. The major focus of intrusion detection systems is detection of vulnerabilities, intrusions and abnormalities in the network or system. Practical requirements and experiences in the area of network and system security have manoeuvred the IDS vendors to incorporate a holistic security solution. Steps in this direction include viewing the problem at a complete network and system perspective and incorporating solutions deeper at design and implementation level. Research and development endeavours have also brought the intrusion detection methodologies to a significant level. Currently most IDS are capable of detecting intrusions based on the signature detection methodology where all the packets are analysed against the set of signatures. Recent IDS have the capability of detecting the anomalies in the network and systems also. Network IDS sits in a network segment and perform the detection whereas the Host IDS sits in a host and performs detection only with respect to that host. Hybrid IDS provides the detection, both at network and host level and they correlate the detections. Current day interest surrounding IDS is related to enable IDS become more proactive such that it transforms into an Intrusion Prevention System (IPS). IDS currently have various detection components like signature detection, anomaly detection and there is the necessity for some of the detection to be done at the network segment level and some at the host level. Hence the IDS components are spread in a network at various host and they communicate amongst themselves to infer the intrusion. Survivability is an ability of a system to tolerate intentional attacks or accidental failures or errors, is becoming increasingly important with extended use of computer systems in society. Techniques, such as cryptographic methods, intrusion detection, and traditional fault-tolerance are being developed to improve the survivability of such systems. Intrusion detection System (IDS) being a security solution, the main challenge is to protect itself from any damage or mishap. Hence, the survivability of the individual IDS components and the requirement for it to be survivable as a system as a whole is of immense importance. If an attacker can compromise any of the IDS components, it will lead to serious problems. Considering the recent developments in the direction, such compromises will not only affect the IDS but will totally collapse the peripheral security policies, which will lead to the collapse of the network. Hence, the need for IDS is to evolve into survivable and a dependable system. Within the purview of survivability there are lots of issues that are required to be analysed and addressed. Currently there exist solutions at Infrastructural design level where by alternate infrastructure is required to address the issue of survivability. The current IDS system has the following significant limitations with respect to survivability of IDS system, which the present invention overcomes, there is no generic control message exchange mechanism among IDS entities, there is an absence of any cohesive 2-way communication among the IDS entities enabling synchronisation, and information propagation, absence of delegation of the responsibilities of IDS entities to alternate resource under abnormal conditions, the IDS system does not provide isolation of IDS entities during crisis situation, there is no control of logging measures and backup of data and state of the IDS entities, absence of any system to effectively control the operational status of various IDS entities, absence of active control of the IDS entities which might include modification, regulation of their functionality and the prior art IDS system does not provide result notifications of the actions and control which include exception and success updates. US Patent 6487666 describes 'Intrusion detection signature analysis using a regular expressions and logical operators. This invention depicts a method of describing intrusion signatures, which are used by an intrusion detection system to detect attacks on a local network. The signatures are described using a "high level" syntax having features in common with regular expression and logical expression methodology. These high level signatures may then be compiled, or otherwise analyzed, to provide a process executable by a sensor or other processor-based signature detector. US Patent No. 6370648 ' Computer network intrusion detection' describes an invention for detecting harmful or illegal intrusions into a computer network or into restricted portions of a computer network uses statistical analysis to match user commands and program names with a template sequence. Discrete correlation matching and permutation matching are used to match sequences. The result of the match is input to a feature builder and then a modeller to produce a score. The score indicates possible intrusion. A sequence of user commands and program names and a template sequence of known harmful commands and program names from a set of such templates are retrieved. A closeness factor indicative of the similarity between the user command sequence and a template sequence is derived from comparing the two sequences. The user command sequence is compared to each template sequence in the set of templates thereby creating multiple closeness or similarity measurements. These measurements are examined to determine which sequence template is most similar to the user command sequence. A frequency feature associated with the user command sequence and the most similar template sequence is calculated. It is determined whether the user command sequence is a potential intrusion into restricted portions of the computer network by examining output from a modeller using the frequency feature as one input. There are many components that exist which need to work in a cohesive manner and any failure of any one of them will lead to the total failure of the IDS system. Also, not all the mentioned components needs exist in one computer system; it can be distributed in a network bringing out the vital requirement of survivability. The present invention addresses survivability irrespective of the placement of the IDS components in any architectural fashion. The aim of making them work cohesively is achieved through various identified control messages that when initiated will address wide range of survivability issues. Various scenarios are possible under which the devised mechanism will initiate appropriate control messages to trigger respective action. The devising of the mechanism includes defining the control messages for various possible survivable scenarios, defining the generic and optimal format for these control messages, implementing the same and finally to initiate these control messages between the cooperating components of the IDS system so that they exist cohesively. Objects of the invention The primary object of the present invention is to provide a system for survivability and synchronization of intrusion detection entities in intrusion detection networks by initiating a cohesive 2-way control message communication among the intrusion detection enfities. Another object of the present invention is to provide a system to initiate control message communication for information sharing, issuing commands and directives and handling exceptions among the IDS entities in a network. Yet another object of the present invention is to provide a system catering to the survivability and synchronization of intrusion detection entities (IDEs) irrespective of the network architecture. Further object of the present invention is to provide a method for the survivability and synchronisation of intrusion detection entities (IDEs) in computer network by way of control message communication. Summary of the invention The present invention provides a system by means of which irrespective of the architecture, identified controls messages modules are triggered to achieve a cohesive 2-way communication among the cooperating entities of an Intrusion Detection System (IDS). The system comprises a plurality of control message generating members in the form of an instruction builder, an operation executor, an announcer, an exception handler and success component. The present system implements and initiates these control messages among the cooperating components of the IDS system so that they communicate cohesively. The Control messages are generated for information sharing, issuing commands and directives and handling exceptions to achieve the goal of making the IDS components and the IDS survivable. The system of the present invention also provides survivability of IDEs, by way of initiating backup, communicating the availability of alternate resource, delegating the responsibility, isolating in crisis situation, switching among various modes of operations and revealing the status information about the IDS entity. Brief Description of the diagrams Fig 1 depicts the placement of IDS entities (Agent, Independent Agent and Manager) of the present invention in a typical network architectural scenario. Fig 2 shows the IDS entity of the present invention in the form an Agent and a Manager and the communication channel between these entities. Fig 3 shows the IDS entity components available for the present invention typically for the Independent Agent and a Manager. It also shows the communication channel between these components. Fig 4 depicts the components of the Survivability manager of the present invention Fig 5 represents the Control Message module and the control messages of the present invention. Fig 6 shows a typical scenario under which the control messages of the present invention are used amongst the IDS entities. The present invention is applicable, but not restricted to the scenario depicted in the Fig 6 Fig 7 shows the relationship of the Control Messages with IDMEF (lETF's draft on communication message format for IDS Entities). The present invention is applicable, but not restricted to the scenario depicted in the figure 7 Detailed Description of the invention Accordingly, the present invention provides a system survivability and synchronization of intrusion detection entities (IDEs) in a computer network by means of a cohesive 2- way control message communication among the intrusion detection entities. Initially, the subject matter of the invention is explained by referring to Fig 1 of the accompanied diagrams, wherein the relationship of master IDS entity vis-a-vis other entities in a network is explained is illustrated. The IDS entities of the present invention are disposed to reside in the same computer or different computers, in any number. Further, all the entities in the network are equipped to understand the control messages. In the present scenario an Intrusion Detection Entity can act either as Manager, Agent or an Independent Agent. Agents Al & A2 are the main sensors that detect intrusions. One agent can employ one or multiple techniques of intrusion detection. Essentially these agents are dumb and are not aware of other agents residing and working elsewhere. They are controlled by the manager(s) Ml and send the intrusion alerts to the Manager(s). Manager Ml is a controller entity that can control one or more of subordinate agents, remotely. The Manager Ml normally has extensive information regarding the agents like its logical network location, the modules running. The manager is also a location where the agents send the alerts generated due to intrusions. Being the know all entity, its in a position to respond appropriately to the reported alerts. A manager Ml may not have the capability to control the Independent agents lAl & IA2, but might know about their presence. Independent agents work independently and do not need Managers to control them. They are intelligent than the simple Agents, and are not dependant on the managers. They are capable of taking decisions related to survivability. Unlike the managers, Independent agents are unaware of other agents; meaning, they don't store any information about other agents. All in all Independent Agents can be looked upon as Agent and Manager clubbed together in one single independent entity. Accordingly the present invention provides a system for survivability and synchronization of intrusion detection entities (IDEs) in a computer network by means of a cohesive 2-way control message communication among the intrusion detection entities. Fig 1 of the accompanied diagrams, depicts a typical deployment of IDS entities in a commonly available network set-up connected to Internet 1 or any public network. A user is generally connected to Internet 1 by means of a boundary gateway, which is a Router 2. The Router 2 acts as a first layer of security to the network. This security is generally enhanced, by incorporating one more layer of defence by introducing a Firewall 4 between the network of organization and the Router 2. Typically an organization's network would comprise internal network 5 and a De-Militarised Zone (DMZ) 6. The servers (Email server 9, web server 10 and DNS server 11) are exposed to the outside to be accessed through the internet 1. This publicly exposed network is referred to as DMZ (Demilitarized Zone) 6. In view of the exposure of the servers to Internet 1, the servers are vulnerable to external attack. It is often a practice to have an IDS to monitor the traffic for these servers. In the Fig 1, Al represents the IDS that works in the DMZ 6. Considering that the internal network located beyond the firewall 4 is assumed to be safe from the external world as the firewall 4 incorporates many filtering rules to block unwanted traffic. In spite of the firewall 4, any user within the organization may still victimize the internal network 5. An IDS sitting beyond firewall 4 within the internal network 5 can monitor the traffic that is internal to the networK as well as the traffic that enters the internal network 5 through the firewall 4. In the Fig 1, 1A2 and A2 represent the IDS that resides in the internal network 5. Also, due to the introduction of a firewall 4, some traffic containing attack attempts might get blocked at firewall 4. An Intrusion Detection System (IDS) between the Firewall 4 and the Router 2 can monitor this blocked traffic. The network tap 3 enables the independent IDS Agent lAl, to capture packets passing through the router 2, but blocked by the firewall 4. The system architecture also comprises Manager Ml to control the IDS agent Al residing in the DMZ 6. The embodiments of the present invention are now explained initially referring to Fig 2 of the accompanied diagrams. Fig 2 is a functional representation of an Intrusion detection system of the present invention depicting IDS entities of which one is an agent Al and the other is a Manager Ml. The Al further comprises Data collector 15, and Protocol Decoder 16, and detection modules 17, 18 and 19. One or more detection modules such as signature based detection (SD), Protocol Anomaly Detection (PAD) module or Statistical Analysis module (STAT) can also be used. In Fig 2,17 represents the signature based detection (SD), 18 represents Protocol Anomaly Detection (PAD) module and 19 represents Statistical Analysis module (STAT). The data collector 15 is a sniffer component capable of capturing the network traffic from a network device such as Ethernet device. This captured traffic forms as the input to the Al system. This captured traffic, which is in the form of packets, is passed on to the protocol decoder 16 to understand the type of packet. The protocol decoder 16 extracts protocol information from the packet, which is input to the Detection modules SD 17, PAD 18 and STAT 19. The Detection modules SD 17, PAD 18 and STAT 19 check for intrusions in these packets. The detection module 17 does the signature based detection on the packets, and detection module 18 evaluates the packet for any protocol anomalies and similarly the detection module 19 carries out statistical analysis on the incoming packet. Al contains the Event Handler (EH) 20E that performs the required tasks such as executing instructions, indicate success, handle exceptions and announce status on receiving Control Messages from Manager Ml. The Agent Communication Interface (ACI) 21 is the Communicafion Interface for Agent Al. ACI 21 is responsible for a secure and guaranteed communication to other IDS entities. Manager Ml is responsible for controlling the Agents like Al and A2. Manager Ml comprises of Manager communication Interface (MCI) 23, Survivability Manager (SM) 25S, Event Handler(EH) 25E and Management console(MC) 24. Manager Ml contains an event handler 25E, which is responsible for handling the messages that are received by Manager Ml. Although Manager Ml communicates with more IDS Entities(IE) 47 compared to Al, EH 25E is similar to EH 20E, because the Control Messages that Ml receives are of the same category as Al receives. 25S is the survivability manager (SM) responsible for the survival of Ml as well as the survival of all the agents that report to Ml. Agent Al does not contain a Survivability Manager. The responsibility of survival of Al lies with Manager Ml. SM 25S is responsible for survival of Ml, Al and A2. The MCI 23 is the Communication Interface for Manager Ml. MCI 23 is responsible for a secure and guaranteed communication to other IDS entities. The Management Console 24 is the user interface for Manager Ml. The Communication Channel (CC), 22 in Fig 2 and CC 33 in Fig 3, is the physical network channel that the IDS entities use for communication. In a typical enterprise network environment CC 22 would be a LAN 5. Fig 3 is a functional representation of an Intrusion detection system of the present invention depicting IDS entities of which one is an Independent agent lAl and the other is a Manager Ml. The lAl further comprises Data collector 26, and Protocol Decoder 27, and detection modules 28, 29 and 30. One or more detection modules such as signature based detection (SD), Protocol Anomaly Detection (PAD) module or Statistical Analysis module (STAT). In Fig 3, 28 represents the signature based detection (SD), 29 represents Protocol Anomaly Detection (PAD) module and 30 represents Statistical Analysis module (STAT). lAl contains the Event Handler (EH) 31E that performs the required operations such as executing instructions, indicate success, handle exceptions and announce status on receiving Control Messages from Manager Ml. The Independent Agent Communication Interface (lACl) 32 is the Communication Interface for Independent Agent lAl. lACI 32 is responsible for a secure and guaranteed communication to other IDS entities. Manager Ml in Fig 3 is the same as in Fig 2. In the present dispensation 31S acts as a Survivability Manager (SM) for the Independent Agent lAl and is responsible for the survival of lAl in adverse situations. The Survivability Managers, 31S and 258 are aware of each other's presence and can depend on the capabilities of either of the IDS entities. But 25S has more responsibilities compared to 31S and is thus aware of the capabilities of Al and A2 too. 25S can decide to relieve Al of some responsibility (eg. Al is overloaded) such as stop SO 28 and command A2 to take it up - provided A2 is capable of taking it up. Referring to Fig 4, an Event Handler (EH) 44 is responsible for appropriately handling the received control messages. An EH 44 is present in all the IDS entities. It is the EH 44 that decides and performs the tasks to be performed on receiving a Control Message. The Survivability Manager 34 is software responsible for helping the system survive in adverse situations. Here, System refers to any of the IDS Entities that the Survivability Manager 34 resides in. It could be either a Manager Ml or an Independent Agent lAl orIA2. The heart of the Survivability Manager 34 is the /iDA/(Analyzer cum Decision Maker) 37, which is responsible for making decisions crucial in the survival of the system. The Survivability Manager 34 also contains an AD (Anomaly Detector) 36 that is responsible for detecting anomalous behaviour of the system. The AD 36 can detect if the system has started consuming too much of memory, beyond the acceptable limits. It might also be in a position to detect what part of the system is causing the overload. The ADM 37 reads this data from the AD 36 and makes a decision that is in best interests of the survivability of the system. Some of these decisions have been elaborated in the scenarios explained in Example 1-3. The decisions are not limited to these examples. The ADM 37 decides the message to send based on the situation. The ADM 37 can select any of the five control message modules (CMM) 43. The CMM 43 has all the formatting information to prepare a valid control message. The ADM 37 uses this information and fills appropriate fields of the required message and generates the required message using the CMM 43. The message is then handed over to the MCP 45(Message Compiler) that compiles the messages and finally dispatches the Messages via the Communication Interface CI 46. The MCP 45 might implement the IDMEF (Intrusion Detection Message Exchange Format), which is the upcoming and the only IETF standard (in draft stage) for communication between IDS entities. Apart from taking inputs from the AD 36 and the IDS Entity information 35, the ADM 37 also handles message received by the system. The Event Handler (EH) 44 is responsible for appropriately handling the received control messages. When placed along with a Survivability Manager 34, the EH 44 interprets the received messages and hands them over to the ADM 37. The IDS Entity Information (IDSEI) 35 is the information about all the IDS entities that the system can interact with. The information includes the address, location - physical as well as logical, deployed Detection Modules 17, 18, 19, 28, 29 and 30 and the capabilities of the IDS Entity. The capabilities of an IDS Entity include the ability to survive in adverse situations. For the same reason, IDSEI 35 maintains data related to the IDS entities containing the SM 34. The CI 46 is responsible for a secure and guaranteed communication to other IDS entities (IE) 47 outside the system. Generally, CI 46 contains encryption facilities to avoid eavesdropping of the message. In Fig 4, IE 47, represents only those IDS entities that are considered outside the system. Referring Fig 5 the system of the present invention comprises a executable control message member 48 with executable modules, said control message member residing in the IDS entities of a computer network to handle various survivability issues such as initiation of backup, communicate availability of alternate resource, delegation of responsibility, isolation during crisis situation, switching among various modes of operations and revealing various status information about the IDS components etc. An instruction builder 49, which is an executable module of the control message member 48, disposed to trigger instructions in the form of control messages to other cooperating IDS entities of a network system in the event of attack or an action. The instruction builder 49, residing in any IDS entities, induces specific actions in the receiving entities by means of which a cohesive work environment is realized. The specific actions induced by instruction builder 49 includes the IDS entities that have control on other entities within the system, to instigate active measures like isolating entities under crisis, synchronizing the data repositories (containing, but not limited to configurations necessary for detection methodologies of entities). The instruction builder 49 helps in keeping all the participating entities in synchronization in terms of data repository. The IDS entities with instruction builder 49 induce other entities to take active measures during disastrous conditions to keep the system healthy. The instructional builder 49 further comprises a plurality of functionally connected internal executable members to execute the pre-designated tasks. An isolate member 54, which is functionally connected to the instructional builder 49 on activation, directs the receiving entities to get isolated logically or physically from the network in an event such as a Denial of Service attack on the system. An executable contact member 55 of the instructional builder 49, to issue contact messages to other entities of the network, in the event of said IDS entity getting overloaded or being shutdown. The contact member 55 is functionally disposed on any IDS entity to delegate the functions of one entity to another in the event of attack or the overloading of the system. In other words, the contact member is disposed to direct dynamically an entity to pursue communication with another specified entity for the specific purpose. When an entity has to contact another entity as a sync or source of some information or for any other purpose this message can be sent to that entity with the target entity's details and the purpose. A log signal member 56 of said instructional builder 49 to communicate directives to other IDS entities to manage functionalities related to logs generated and handled by the ID entities. Logs have to be handled and managed under different scenarios and abnormal conditions. The log signal member 56 is executed in scenarios such as when the controlling entity requires initiating logging activity with respect to the parameters specified, such as the generated logs may be required to be saved at the entity generating the logs, the generated logs may be required to be transferred to another entity. Once the Logging activity is initiated, generated logs are saved to the logging entity, logs are being transferred to the controlling entity, and required logs are being flushed by the controlled entity. In the system of the present invention, important information like alerts, network traffic etc is logged by IDS entities, for future use to analyse, the logs are saved, are transferred or are flushed upon receiving the different control messages. A synchronize member 57 residing on any IDS entity, especially on an entity controlling another entity, executes synchronisation activities dynamically, on controlled entities, with regard to data, updates, resources and patches. Synchronise member 57, is executed to prevent the redundancy of any controlled entity. Therefore, a cohesive 2-way communication environment is maintained and the status information propagated. The synchronised entity is directed to become updated which helps in detection from latest vulnerabilities and attacks. A fall back scenario would exist, as at least there would exist an entity that would have thwarted the attack. A send-info member 58, disposed on IDS entity, said send-info member in functional connectivity with the instruction builder 49, directs the receiving entity to send the desired information to the sending entity. The send-info member is activated to secure an update on module data, attack knowledge etc., by seeking from an entity in a network in possession of the information. In another embodiment of the present invention an operation executor 50 in functional connectivity with control message member 48, disposed to provide a control of various entities of the ID system. The operation executor 50, executes directives including communicate initiation or stopping of detection functionality, and change working technique of the IDS entities in order to implement 2-way cohesive communication between the entities. The operation executor is also disposed to provide pausing or resuming any operation within an IDS entity in handling exceptional conditions. The operation executor 50 further disposed to handle the change in the working mode of the ID entities. In another embodiment of the present invention, the operational executor 50 further comprises a start member 59, to enable the entity to execute an action. The actions include delegation of a job performed by one entity to another entity, execution of a message by a controlling entity to the controlled entity to perform a pre-selected action, which is hitherto performed by other entity in the network. The Start member 59 with control capability can order an entity to initiate a function being performed by another entity, when such an entity is not able to perform its function. Accordingly, the start member 59 disposed to delegate the functions, when the functional entity controlling other entities is unable to perform the designated functions, for instance when one entity (with control on other entities) is going down it can delegate its functions to other entities by sending the start request to those entities with the specifying the action to be taken. A stop member 60 disposed to execute stopping of a selected function of a selected entity, by undoing the initialisation performed during the starting of said function. The stop member 60 is disposed on any controlling entity to stop a pre-selected function in any another entity either in order to delegate the function to another entity or just to stop the function running in that entity. In another embodiment of the present invention, a pause member 61 disposed on any IDS entity to pause a running function so as to resume at a pre-determined time. The pause member 61 is disposed on an entity when one entity desires to pause a running function in another entity in order to delegate that to some other entity or to reduce the load on that entity temporarily. In another embodiment of the present invention, a resume member 62, disposed on any entity to resume the functions of any entity which have been stopped by pause member 61. In yet another embodiment of the present invention, a change mode member 63, disposed on any controlling entity to effect a change in a running mode of an entity to start, stop or paused. In further embodiment of the present invention, an announcer 51 in functional connectivity with control message member 48, disposed on an IDS entity to facilitate an IDS entity to inform about its current operational status to the other entities in the system. The announcer 51 disposed to execute informative messages that are required to be communicated among all the entities. The messages under this category are passive i.e. they won't initiate any action in the received nodes except for the updating their status in the neighbourhood knowledge base of the received node. The announcer 51 is further disposed to create a cohesive operational environment among IDS entities, which is achieved by IDS entities announcing their status periodically through the informative messages. In yet another embodiment of the present invention, the announcer 51 further comprises a shutdown member 65, which is disposed on an IDS entity, to enable the entity to sign off by announcing the same to other entities of the network. A normal member 64, which is a functional component of announcer 51, disposed to communicate with other entities in a network the normal working of the entities to indicate the healthy state of the network system. The normal member 61 is disposed to get triggered on any of the events such as during reboot of the machine, restart of the service, periodically as a heartbeat or after coming back to normalcy from some overloaded state. An overload member 66 disposed in functional connectivity with announcer 51 to communicate with other entities whenever an entity is overloaded or there is a shortage of a resource, this message can be used to convey that information to neighbours. In yet another embodiment of the present invention, an exception handler 52 and success component 53, in functional connectivity with control message member 48 to handle success/failure of actions taken in response to other control messages. The exception handler 52 further comprises exception message component 68. The success component 53 further comprises success message component 69. The exception message 68 and success message components 69 together are disposed to handle success and exception scenarios in the network. Fig 7 represents the application of our invention in IDMEF (Intrusion Detection Message Exchange Format), but not restricted to IDMEF. IDMEF is lETF's draft on communication message format for IDS Entities. Presently the IDMEF-Message 78 facilitates communication of either the Alert 79 or Heartbeat 80 category. By addition of Control Message Module 48 of the present invention enables control communication amongst IDS entities in the form of Instruction Builder 49, Operation Executor 50, Announcer 51, Exception Handler 52 and Success Indicator 53. The present invention also provides a method for the survivability and synchronisation of intrusion detection entities (IDEs) in computer network by way of control message communication, said method comprising the steps of detecting anomaly by an anomaly detector in an IDS entity of the computer network and initiating communication, receiving and analysing the anomaly by analyser cum decision maker, identifying the desired control message with inherent tasks for said anomaly, executing and performing the inherent task of said control message in the intrusion detection entity, and indicating success or failure of the selected task. In the method of the present invention, the executing and performing of the inherent task further comprising the steps of, isolating an intrusion detection entity, delegating tasks of an intrusion detection entity to another, performing local logging or flushing logs, and synchronizing IDS entities by providing detection data, configuration and patches, and passing data from IDS entity to another. The functional aspects of the flow of activities performed by the intrusion detection entity (sending entity) in a process of sending a control message are provided in the following flow chart. I The functional aspects of the flow of activities performed by the intrusion detection entity (receiving entity) in a process of sending a control message are provided in the The present invention is further exempHfied in the form of following examples. However, the following examples should not be construed as limiting the scope of the invention. Example 1 By Referring to Fig 1 if the Manager Ml intends to shutdown for some maintenance reasons. In absence of control messages, the manager Ml would have shut down, without notifying the agents, and would have resulted in following: 1. The agents Al & A2 try to send alerts to the manager and find that manager is dead, 2. The alerts get delayed or worst still lost. 3. This could happen for every alert generated. 4. No proper reaction/response could be taken for the alerts generated. But in presence of control message modules, the manager Ml makes an attempt to save the situation using the control messages. It tries to get a surrogate alert handler and finds it in the form of IA2. It then asks Al and A2 to report to it. Finally when the manager Ml is ready to resume normal operations, it demands logs of all the responses taken by 1A2. Referring to Fig. 6, which shows time on the Y-Axis and the entities on the X-axis, shows the flow of messages passed between IDS entities involved in the Results obtained using the control messages include no alerts went unnoticed, lAl could respond to alerts and Manager could demand a storage/log of all the happenings during its absence. The scenario above shows that the manager made decisions and made appropriate use of the control messages to save the system. The manager had no information about the configuration of other Independent agents; as to what modules they were capable of running. Example 2 Now again referring to Fig 1 wherein if one of the agents Al & A2 feels short of processing power because of overload. In absence of control messages, the agent could at best take measures like shutting down one of its detection module. This could result in following: Detection is hampered, either because it is stopped or because its constrained, the agent is not able to handle the overload and finally dies and nobody would perhaps know about this failure. In the presence of control messages, the manager gets notified of the overload. This enables the manager to find out of some other agent can take up the responsibility. In an attempt to relieve Al with some detection technique, Ml asks A2, lAl and IA2 to take up PAD (Protocol Anomaly Detection) technique so that Al could be asked to stop. But nobody have the expertise of this detection methodology. Manager is aware that Al has signature detection running. So the manager again asks help from A2, lAl and IA2. Fortunately IA2 offers help. Manager asks IA2 to update its signature database to that with Al and asks it to start the SD module. Finally, Al is asked to stop SD (Signature Detecfion) module and some problem in the detection system, and get the detection module be nin at some other system. Therefore, the manager could handle a situation that would have been impossible without control messages. After the message 11, manager could very well restart the signature detection module back at Al. This would eventually restore the old system status. In this scenario, IA2 understands the calamity and helps survive the system. Example 3 One of the most feared situations is a DOS attack: a Denial of Service (DOS) attack. (In such an attack, the attacker floods the server that provides some service. This causes the server to overloaded and eventually stop serving the legitimate clients. Such attacks can only be detected correctly with complicated statistical techniques involving analysis of data from many sources). Survivability is of utmost importance when the system itself is under attack. In case of a DOS attack on an agent, the agent gets overloaded. One of the agents feels short of memory because of overload. In absence of control messages, the detection is hampered, either because its stopped or because its constrained. If it's stopped, to save from overload, the attack becomes successful. Further, the agent is not able to handle the overload and finally dies and there would be a non-disclosure of failure. In the presence of control messages, the manager gets notified of the overload. In such a case, the manager could very well take up the technique as mentioned in the earlier case (Example 2), but using the control messages, it tries to understand the situation by demanding logs of the recent happenings from all the agents. Since DOS attacks can be detected only with complex techniques, with inputs from multiple sources, the manager is in much better position to detect it. When the manager gets a hint of a DOS on one of its agent, it asks the agent to go underground. It achieves this by asking the agent to logically relocate itself on the network. Presence of control messages, helped in achieving the following: The manager becomes aware of some problem in the detection system and further the DOS attack on the agent is detected and finally the agent is saved from the attack. Inference: The manager was in the best position to detect the ongoing attack. However since the agents have detecting software, it could be possible to at least get a hint of the attack. In absence of control messages, there is nothing that the agent could do than to change to logging mode. Moreover changing to logging mode doesn't save the agent from the attack. If at all the agent decides to relocate itself, the manager cannot be notified, and it would end up denying service to the manager, as the manager could no longer contact the agent. This would again be a successful DOS attack as for an agent the manager is a legitimate client. The system and the executable modules of present invention are implemented using an object oriented language C++ on Fedora core Linux platform. Hardware Pentium III CPU 1.3 Ghz Memory 512 MB Hard Disk 40 GB Ethernet Interface: 10/100/1000Mbps Software Operating System Fedora Core Linux Language: C"^\ Java The implementation of the subject matter of the present invention is not constrained to a specific hardware or software requirements. It is within the scope of the present invention to use any suitable hardware/software can for implementing the subject matter of the present invention. Advantages 1. Irrespective of the architecture of the IDS (standalone solution, Distributed etc) the present invention provides means to create a two-way communication environment for the internal and external components of IDS to work cohesively facilitating survivability. 2. The aim of functioning of various components cohesively is achieved through various identified control messages. 3. The control messages when initiated, addresses a wide range of survivability issues. We claim: 1. A system for the survivability and synchronization of Intrusion Detection System (IDS) Entities in a computer network, said system comprising; an anomaly detector means to detect an anomaly in an IDS entity of the computer network and initiate communication, an analyser cum decision maker to take strategic decisions for survivability of one or more IDS Entities, an instruction builder to generate control messages, said control messages with inherent tasks, an operation executor to execute the tasks, an announcer to announce the status of an IDS entity, a success indicator to indicate the completed inherent tasks, and an exception handler to handle the unsuccessful tasks. 2. The system as claimed in claim 1, wherein the instructional builder consisting of an isolate member to generate control message for isolating an intrusion detection entity, a contact member to generate control message for delegating tasks of an intrusion detection entity to another, a log signal member to generate control message for performing logging events, a synchronize member to generate control message for synchronising intrusion detection entities, and a send-info member to generate control message for passing data from IDS entity to another. 3. The system as claimed in claim 1, wherein the operation executor consisting of a start, stop, pause and resume action members along with a switch mode member to execute the corresponding action in an IDS entity. 4. The system as claimed in claim 1, wherein the announcer consisting of normal, shutdown, and overload members to announce the on, off and overload status respectively of an entity, 5. The system as claimed in claim 1, wherein the exception handler consisting of exception message component to handle errors of any IDS entity. 6. The system as claimed in claim 1, wherein the success indicator consisting of success message component to indicate the affirmative result of any operation by the IDS entity. 7. The system as claimed in claim 1, wherein the control message of data of the send-info member consists of logs, alerts and configurations of an entity. 8. A method of surviving and synchronizing of Intrusion Detection System Entities (IDS) in a computer network, said method comprising the steps of: (a) detecting anomaly by an anomaly detector in an IDS entity of the computer network and initiating communication, receiving and analysing the anomaly by analyser cum decision maker, identifying the desired control message with inherent tasks for said anomaly, executing and performing the inherent task of said control message in the intrusion detection entity, and indicating success or failure of the selected task. 9. The method as claimed in claim 8, wherein the executing and performing of the inherent task further comprising the steps of, (a) isolating an intrusion detection entity, delegating tasks of an intrusion detection entity to another, performing local logging or flushing logs, and synchronizing IDS entities by providing detection data, configuration and patches, and passing data from IDS entity to another.

Full Text

A SYSTEM AND A METHOD FOR THE SURVIVABILITY OF INTRUSION DETECTION ENTITIES
Technical Field
The present invention relates to a system for survivability and synchronization of intrusion detection entities (IDEs) in a computer network by means of a cohesive 2-way control message communication among the intrusion detection entities. The present invention also provides a method for the survivability and synchronisation of intrusion detection entities (IDEs) in computer network by way of control message communication. Background and prior art
An "Intrusion Detection System (IDS)" is a system for detecting intrusions and suspicious activity that may be occurring on the systems and networks. IDS attempt to detect such hatch plots and hibernated activity. The system accomplishes it by collecting information from various network and host sources (mainly system & network logs, messages and reports) and then analysing them for suspicious activity. Usually the information is collected through various sensors placed in hosts at various locations of the network. IDS entity is a process, a module or a system having mechanism and intelligence in-built to detect and/or respond to intrusions, deployed on a host at either a network periphery or system level.
The major focus of intrusion detection systems is detection of vulnerabilities, intrusions and abnormalities in the network or system. Practical requirements and experiences in the area of network and system security have manoeuvred the IDS vendors to incorporate a holistic security solution. Steps in this direction include viewing the problem at a complete network and system perspective and incorporating solutions deeper at design and implementation level. Research and development endeavours have also brought the intrusion detection methodologies to a significant level. Currently most IDS are capable of detecting intrusions based on the signature detection methodology where all the packets are analysed against the set of signatures. Recent IDS have the capability of detecting the anomalies in the network and systems also. Network IDS sits in a network segment and perform the detection whereas the Host IDS sits in a host and performs detection only with respect to that host. Hybrid IDS provides the detection, both at network and host level and they correlate the detections.

Current day interest surrounding IDS is related to enable IDS become more proactive such that it transforms into an Intrusion Prevention System (IPS). IDS currently have various detection components like signature detection, anomaly detection and there is the necessity for some of the detection to be done at the network segment level and some at the host level. Hence the IDS components are spread in a network at various host and they communicate amongst themselves to infer the intrusion.
Survivability is an ability of a system to tolerate intentional attacks or accidental failures or errors, is becoming increasingly important with extended use of computer systems in society. Techniques, such as cryptographic methods, intrusion detection, and traditional fault-tolerance are being developed to improve the survivability of such systems.
Intrusion detection System (IDS) being a security solution, the main challenge is to protect itself from any damage or mishap. Hence, the survivability of the individual IDS components and the requirement for it to be survivable as a system as a whole is of immense importance. If an attacker can compromise any of the IDS components, it will lead to serious problems. Considering the recent developments in the direction, such compromises will not only affect the IDS but will totally collapse the peripheral security policies, which will lead to the collapse of the network. Hence, the need for IDS is to evolve into survivable and a dependable system. Within the purview of survivability there are lots of issues that are required to be analysed and addressed. Currently there exist solutions at Infrastructural design level where by alternate infrastructure is required to address the issue of survivability. The current IDS system has the following significant limitations with respect to survivability of IDS system, which the present invention overcomes, there is no generic control message exchange mechanism among IDS entities, there is an absence of any cohesive 2-way communication among the IDS entities enabling synchronisation, and information propagation, absence of delegation of the responsibilities of IDS entities to alternate resource under abnormal conditions, the IDS system does not provide isolation of IDS entities during crisis situation, there is no control of logging measures and backup of data and state of the IDS entities, absence of any system to effectively control the operational status of various IDS entities, absence of active control of the IDS entities which might include modification, regulation of their functionality and the

prior art IDS system does not provide result notifications of the actions and control which include exception and success updates.
US Patent 6487666 describes 'Intrusion detection signature analysis using a regular expressions and logical operators. This invention depicts a method of describing intrusion signatures, which are used by an intrusion detection system to detect attacks on a local network. The signatures are described using a "high level" syntax having features in common with regular expression and logical expression methodology. These high level signatures may then be compiled, or otherwise analyzed, to provide a process executable by a sensor or other processor-based signature detector. US Patent No. 6370648 ' Computer network intrusion detection' describes an invention for detecting harmful or illegal intrusions into a computer network or into restricted portions of a computer network uses statistical analysis to match user commands and program names with a template sequence. Discrete correlation matching and permutation matching are used to match sequences. The result of the match is input to a feature builder and then a modeller to produce a score. The score indicates possible intrusion. A sequence of user commands and program names and a template sequence of known harmful commands and program names from a set of such templates are retrieved. A closeness factor indicative of the similarity between the user command sequence and a template sequence is derived from comparing the two sequences. The user command sequence is compared to each template sequence in the set of templates thereby creating multiple closeness or similarity measurements. These measurements are examined to determine which sequence template is most similar to the user command sequence. A frequency feature associated with the user command sequence and the most similar template sequence is calculated. It is determined whether the user command sequence is a potential intrusion into restricted portions of the computer network by examining output from a modeller using the frequency feature as one input. There are many components that exist which need to work in a cohesive manner and any failure of any one of them will lead to the total failure of the IDS system. Also, not all the mentioned components needs exist in one computer system; it can be distributed in a network bringing out the vital requirement of survivability.
The present invention addresses survivability irrespective of the placement of the IDS components in any architectural fashion. The aim of making them work cohesively is achieved through various identified control messages that when initiated will address

wide range of survivability issues. Various scenarios are possible under which the devised mechanism will initiate appropriate control messages to trigger respective action. The devising of the mechanism includes defining the control messages for various possible survivable scenarios, defining the generic and optimal format for these control messages, implementing the same and finally to initiate these control messages between the cooperating components of the IDS system so that they exist cohesively. Objects of the invention
The primary object of the present invention is to provide a system for survivability and synchronization of intrusion detection entities in intrusion detection networks by initiating a cohesive 2-way control message communication among the intrusion detection enfities.
Another object of the present invention is to provide a system to initiate control message communication for information sharing, issuing commands and directives and handling exceptions among the IDS entities in a network.
Yet another object of the present invention is to provide a system catering to the survivability and synchronization of intrusion detection entities (IDEs) irrespective of the network architecture.
Further object of the present invention is to provide a method for the survivability and synchronisation of intrusion detection entities (IDEs) in computer network by way of control message communication. Summary of the invention
The present invention provides a system by means of which irrespective of the architecture, identified controls messages modules are triggered to achieve a cohesive 2-way communication among the cooperating entities of an Intrusion Detection System (IDS). The system comprises a plurality of control message generating members in the form of an instruction builder, an operation executor, an announcer, an exception handler and success component. The present system implements and initiates these control messages among the cooperating components of the IDS system so that they communicate cohesively. The Control messages are generated for information sharing, issuing commands and directives and handling exceptions to achieve the goal of making the IDS components and the IDS survivable. The system of the present invention also provides survivability of IDEs, by way of initiating backup, communicating the availability of alternate resource, delegating the responsibility,

isolating in crisis situation, switching among various modes of operations and revealing
the status information about the IDS entity.
Brief Description of the diagrams
Fig 1 depicts the placement of IDS entities (Agent, Independent Agent and Manager)
of the present invention in a typical network architectural scenario.
Fig 2 shows the IDS entity of the present invention in the form an Agent and a
Manager and the communication channel between these entities.
Fig 3 shows the IDS entity components available for the present invention typically for
the Independent Agent and a Manager. It also shows the communication channel
between these components.
Fig 4 depicts the components of the Survivability manager of the present invention
Fig 5 represents the Control Message module and the control messages of the present
invention.
Fig 6 shows a typical scenario under which the control messages of the present
invention are used amongst the IDS entities. The present invention is applicable, but
not restricted to the scenario depicted in the Fig 6
Fig 7 shows the relationship of the Control Messages with IDMEF (lETF's draft on
communication message format for IDS Entities). The present invention is applicable,
but not restricted to the scenario depicted in the figure 7
Detailed Description of the invention
Accordingly, the present invention provides a system survivability and synchronization
of intrusion detection entities (IDEs) in a computer network by means of a cohesive 2-
way control message communication among the intrusion detection entities. Initially,
the subject matter of the invention is explained by referring to Fig 1 of the
accompanied diagrams, wherein the relationship of master IDS entity vis-a-vis other
entities in a network is explained is illustrated. The IDS entities of the present invention
are disposed to reside in the same computer or different computers, in any number.
Further, all the entities in the network are equipped to understand the control messages.
In the present scenario an Intrusion Detection Entity can act either as Manager, Agent
or an Independent Agent. Agents Al & A2 are the main sensors that detect intrusions.
One agent can employ one or multiple techniques of intrusion detection. Essentially
these agents are dumb and are not aware of other agents residing and working
elsewhere. They are controlled by the manager(s) Ml and send the intrusion alerts to

the Manager(s). Manager Ml is a controller entity that can control one or more of subordinate agents, remotely. The Manager Ml normally has extensive information regarding the agents like its logical network location, the modules running. The manager is also a location where the agents send the alerts generated due to intrusions. Being the know all entity, its in a position to respond appropriately to the reported alerts. A manager Ml may not have the capability to control the Independent agents lAl & IA2, but might know about their presence. Independent agents work independently and do not need Managers to control them. They are intelligent than the simple Agents, and are not dependant on the managers. They are capable of taking decisions related to survivability. Unlike the managers, Independent agents are unaware of other agents; meaning, they don't store any information about other agents. All in all Independent Agents can be looked upon as Agent and Manager clubbed together in one single independent entity.
Accordingly the present invention provides a system for survivability and synchronization of intrusion detection entities (IDEs) in a computer network by means of a cohesive 2-way control message communication among the intrusion detection entities. Fig 1 of the accompanied diagrams, depicts a typical deployment of IDS entities in a commonly available network set-up connected to Internet 1 or any public network. A user is generally connected to Internet 1 by means of a boundary gateway, which is a Router 2. The Router 2 acts as a first layer of security to the network. This security is generally enhanced, by incorporating one more layer of defence by introducing a Firewall 4 between the network of organization and the Router 2. Typically an organization's network would comprise internal network 5 and a De-Militarised Zone (DMZ) 6.
The servers (Email server 9, web server 10 and DNS server 11) are exposed to the outside to be accessed through the internet 1. This publicly exposed network is referred to as DMZ (Demilitarized Zone) 6. In view of the exposure of the servers to Internet 1, the servers are vulnerable to external attack. It is often a practice to have an IDS to monitor the traffic for these servers. In the Fig 1, Al represents the IDS that works in the DMZ 6. Considering that the internal network located beyond the firewall 4 is assumed to be safe from the external world as the firewall 4 incorporates many filtering rules to block unwanted traffic. In spite of the firewall 4, any user within the organization may still victimize the internal network 5. An IDS sitting beyond firewall

4 within the internal network 5 can monitor the traffic that is internal to the networK as well as the traffic that enters the internal network 5 through the firewall 4. In the Fig 1, 1A2 and A2 represent the IDS that resides in the internal network 5. Also, due to the introduction of a firewall 4, some traffic containing attack attempts might get blocked at firewall 4. An Intrusion Detection System (IDS) between the Firewall 4 and the Router 2 can monitor this blocked traffic. The network tap 3 enables the independent IDS Agent lAl, to capture packets passing through the router 2, but blocked by the firewall 4. The system architecture also comprises Manager Ml to control the IDS agent Al residing in the DMZ 6.
The embodiments of the present invention are now explained initially referring to Fig 2 of the accompanied diagrams.
Fig 2 is a functional representation of an Intrusion detection system of the present invention depicting IDS entities of which one is an agent Al and the other is a Manager Ml. The Al further comprises Data collector 15, and Protocol Decoder 16, and detection modules 17, 18 and 19. One or more detection modules such as signature based detection (SD), Protocol Anomaly Detection (PAD) module or Statistical Analysis module (STAT) can also be used. In Fig 2,17 represents the signature based detection (SD), 18 represents Protocol Anomaly Detection (PAD) module and 19 represents Statistical Analysis module (STAT).
The data collector 15 is a sniffer component capable of capturing the network traffic from a network device such as Ethernet device. This captured traffic forms as the input to the Al system. This captured traffic, which is in the form of packets, is passed on to the protocol decoder 16 to understand the type of packet. The protocol decoder 16 extracts protocol information from the packet, which is input to the Detection modules SD 17, PAD 18 and STAT 19. The Detection modules SD 17, PAD 18 and STAT 19 check for intrusions in these packets. The detection module 17 does the signature based detection on the packets, and detection module 18 evaluates the packet for any protocol anomalies and similarly the detection module 19 carries out statistical analysis on the incoming packet. Al contains the Event Handler (EH) 20E that performs the required tasks such as executing instructions, indicate success, handle exceptions and announce status on receiving Control Messages from Manager Ml. The Agent Communication Interface (ACI) 21 is the Communicafion Interface for Agent Al. ACI 21 is responsible for a secure and guaranteed communication to other IDS entities.

Manager Ml is responsible for controlling the Agents like Al and A2. Manager Ml comprises of Manager communication Interface (MCI) 23, Survivability Manager (SM) 25S, Event Handler(EH) 25E and Management console(MC) 24. Manager Ml contains an event handler 25E, which is responsible for handling the messages that are received by Manager Ml. Although Manager Ml communicates with more IDS Entities(IE) 47 compared to Al, EH 25E is similar to EH 20E, because the Control Messages that Ml receives are of the same category as Al receives. 25S is the survivability manager (SM) responsible for the survival of Ml as well as the survival of all the agents that report to Ml. Agent Al does not contain a Survivability Manager. The responsibility of survival of Al lies with Manager Ml. SM 25S is responsible for survival of Ml, Al and A2. The MCI 23 is the Communication Interface for Manager Ml. MCI 23 is responsible for a secure and guaranteed communication to other IDS entities. The Management Console 24 is the user interface for Manager Ml.
The Communication Channel (CC), 22 in Fig 2 and CC 33 in Fig 3, is the physical network channel that the IDS entities use for communication. In a typical enterprise network environment CC 22 would be a LAN 5.
Fig 3 is a functional representation of an Intrusion detection system of the present invention depicting IDS entities of which one is an Independent agent lAl and the other is a Manager Ml. The lAl further comprises Data collector 26, and Protocol Decoder 27, and detection modules 28, 29 and 30. One or more detection modules such as signature based detection (SD), Protocol Anomaly Detection (PAD) module or Statistical Analysis module (STAT). In Fig 3, 28 represents the signature based detection (SD), 29 represents Protocol Anomaly Detection (PAD) module and 30 represents Statistical Analysis module (STAT).
lAl contains the Event Handler (EH) 31E that performs the required operations such as executing instructions, indicate success, handle exceptions and announce status on receiving Control Messages from Manager Ml. The Independent Agent Communication Interface (lACl) 32 is the Communication Interface for Independent Agent lAl. lACI 32 is responsible for a secure and guaranteed communication to other IDS entities. Manager Ml in Fig 3 is the same as in Fig 2.
In the present dispensation 31S acts as a Survivability Manager (SM) for the Independent Agent lAl and is responsible for the survival of lAl in adverse situations. The Survivability Managers, 31S and 258 are aware of each other's presence and can

depend on the capabilities of either of the IDS entities. But 25S has more responsibilities compared to 31S and is thus aware of the capabilities of Al and A2 too. 25S can decide to relieve Al of some responsibility (eg. Al is overloaded) such as stop SO 28 and command A2 to take it up - provided A2 is capable of taking it up. Referring to Fig 4, an Event Handler (EH) 44 is responsible for appropriately handling the received control messages. An EH 44 is present in all the IDS entities. It is the EH 44 that decides and performs the tasks to be performed on receiving a Control Message. The Survivability Manager 34 is software responsible for helping the system survive in adverse situations. Here, System refers to any of the IDS Entities that the Survivability Manager 34 resides in. It could be either a Manager Ml or an Independent Agent lAl orIA2.
The heart of the Survivability Manager 34 is the /iDA/(Analyzer cum Decision Maker) 37, which is responsible for making decisions crucial in the survival of the system. The Survivability Manager 34 also contains an AD (Anomaly Detector) 36 that is responsible for detecting anomalous behaviour of the system.
The AD 36 can detect if the system has started consuming too much of memory, beyond the acceptable limits. It might also be in a position to detect what part of the system is causing the overload.
The ADM 37 reads this data from the AD 36 and makes a decision that is in best interests of the survivability of the system. Some of these decisions have been elaborated in the scenarios explained in Example 1-3. The decisions are not limited to these examples. The ADM 37 decides the message to send based on the situation. The ADM 37 can select any of the five control message modules (CMM) 43. The CMM 43 has all the formatting information to prepare a valid control message. The ADM 37 uses this information and fills appropriate fields of the required message and generates the required message using the CMM 43. The message is then handed over to the MCP 45(Message Compiler) that compiles the messages and finally dispatches the Messages via the Communication Interface CI 46. The MCP 45 might implement the IDMEF (Intrusion Detection Message Exchange Format), which is the upcoming and the only IETF standard (in draft stage) for communication between IDS entities.
Apart from taking inputs from the AD 36 and the IDS Entity information 35, the ADM 37 also handles message received by the system. The Event Handler (EH) 44 is

responsible for appropriately handling the received control messages. When placed along with a Survivability Manager 34, the EH 44 interprets the received messages and hands them over to the ADM 37.
The IDS Entity Information (IDSEI) 35 is the information about all the IDS entities that the system can interact with. The information includes the address, location - physical as well as logical, deployed Detection Modules 17, 18, 19, 28, 29 and 30 and the capabilities of the IDS Entity. The capabilities of an IDS Entity include the ability to survive in adverse situations. For the same reason, IDSEI 35 maintains data related to the IDS entities containing the SM 34.
The CI 46 is responsible for a secure and guaranteed communication to other IDS entities (IE) 47 outside the system. Generally, CI 46 contains encryption facilities to avoid eavesdropping of the message. In Fig 4, IE 47, represents only those IDS entities that are considered outside the system.
Referring Fig 5 the system of the present invention comprises a executable control message member 48 with executable modules, said control message member residing in the IDS entities of a computer network to handle various survivability issues such as initiation of backup, communicate availability of alternate resource, delegation of responsibility, isolation during crisis situation, switching among various modes of operations and revealing various status information about the IDS components etc. An instruction builder 49, which is an executable module of the control message member 48, disposed to trigger instructions in the form of control messages to other cooperating IDS entities of a network system in the event of attack or an action. The instruction builder 49, residing in any IDS entities, induces specific actions in the receiving entities by means of which a cohesive work environment is realized. The specific actions induced by instruction builder 49 includes the IDS entities that have control on other entities within the system, to instigate active measures like isolating entities under crisis, synchronizing the data repositories (containing, but not limited to configurations necessary for detection methodologies of entities). The instruction builder 49 helps in keeping all the participating entities in synchronization in terms of data repository. The IDS entities with instruction builder 49 induce other entities to take active measures during disastrous conditions to keep the system healthy. The instructional builder 49 further comprises a plurality of functionally connected internal executable members to execute the pre-designated tasks. An isolate member 54, which is functionally

connected to the instructional builder 49 on activation, directs the receiving entities to get isolated logically or physically from the network in an event such as a Denial of Service attack on the system. An executable contact member 55 of the instructional builder 49, to issue contact messages to other entities of the network, in the event of said IDS entity getting overloaded or being shutdown. The contact member 55 is functionally disposed on any IDS entity to delegate the functions of one entity to another in the event of attack or the overloading of the system. In other words, the contact member is disposed to direct dynamically an entity to pursue communication with another specified entity for the specific purpose. When an entity has to contact another entity as a sync or source of some information or for any other purpose this message can be sent to that entity with the target entity's details and the purpose. A log signal member 56 of said instructional builder 49 to communicate directives to other IDS entities to manage functionalities related to logs generated and handled by the ID entities. Logs have to be handled and managed under different scenarios and abnormal conditions. The log signal member 56 is executed in scenarios such as when the controlling entity requires initiating logging activity with respect to the parameters specified, such as the generated logs may be required to be saved at the entity generating the logs, the generated logs may be required to be transferred to another entity. Once the Logging activity is initiated, generated logs are saved to the logging entity, logs are being transferred to the controlling entity, and required logs are being flushed by the controlled entity. In the system of the present invention, important information like alerts, network traffic etc is logged by IDS entities, for future use to analyse, the logs are saved, are transferred or are flushed upon receiving the different control messages.
A synchronize member 57 residing on any IDS entity, especially on an entity controlling another entity, executes synchronisation activities dynamically, on controlled entities, with regard to data, updates, resources and patches. Synchronise member 57, is executed to prevent the redundancy of any controlled entity. Therefore, a cohesive 2-way communication environment is maintained and the status information propagated. The synchronised entity is directed to become updated which helps in detection from latest vulnerabilities and attacks. A fall back scenario would exist, as at least there would exist an entity that would have thwarted the attack.

A send-info member 58, disposed on IDS entity, said send-info member in functional connectivity with the instruction builder 49, directs the receiving entity to send the desired information to the sending entity. The send-info member is activated to secure an update on module data, attack knowledge etc., by seeking from an entity in a network in possession of the information.
In another embodiment of the present invention an operation executor 50 in functional connectivity with control message member 48, disposed to provide a control of various entities of the ID system. The operation executor 50, executes directives including communicate initiation or stopping of detection functionality, and change working technique of the IDS entities in order to implement 2-way cohesive communication between the entities. The operation executor is also disposed to provide pausing or resuming any operation within an IDS entity in handling exceptional conditions. The operation executor 50 further disposed to handle the change in the working mode of the ID entities.
In another embodiment of the present invention, the operational executor 50 further comprises a start member 59, to enable the entity to execute an action. The actions include delegation of a job performed by one entity to another entity, execution of a message by a controlling entity to the controlled entity to perform a pre-selected action, which is hitherto performed by other entity in the network. The Start member 59 with control capability can order an entity to initiate a function being performed by another entity, when such an entity is not able to perform its function. Accordingly, the start member 59 disposed to delegate the functions, when the functional entity controlling other entities is unable to perform the designated functions, for instance when one entity (with control on other entities) is going down it can delegate its functions to other entities by sending the start request to those entities with the specifying the action to be taken.
A stop member 60 disposed to execute stopping of a selected function of a selected entity, by undoing the initialisation performed during the starting of said function. The stop member 60 is disposed on any controlling entity to stop a pre-selected function in any another entity either in order to delegate the function to another entity or just to stop the function running in that entity.
In another embodiment of the present invention, a pause member 61 disposed on any IDS entity to pause a running function so as to resume at a pre-determined time. The

pause member 61 is disposed on an entity when one entity desires to pause a running
function in another entity in order to delegate that to some other entity or to reduce the
load on that entity temporarily.
In another embodiment of the present invention, a resume member 62, disposed on any
entity to resume the functions of any entity which have been stopped by pause member
61.
In yet another embodiment of the present invention, a change mode member 63,
disposed on any controlling entity to effect a change in a running mode of an entity to
start, stop or paused.
In further embodiment of the present invention, an announcer 51 in functional
connectivity with control message member 48, disposed on an IDS entity to facilitate
an IDS entity to inform about its current operational status to the other entities in the
system. The announcer 51 disposed to execute informative messages that are required
to be communicated among all the entities. The messages under this category are
passive i.e. they won't initiate any action in the received nodes except for the updating
their status in the neighbourhood knowledge base of the received node. The announcer
51 is further disposed to create a cohesive operational environment among IDS entities,
which is achieved by IDS entities announcing their status periodically through the
informative messages.
In yet another embodiment of the present invention, the announcer 51 further comprises
a shutdown member 65, which is disposed on an IDS entity, to enable the entity to sign
off by announcing the same to other entities of the network. A normal member 64,
which is a functional component of announcer 51, disposed to communicate with other
entities in a network the normal working of the entities to indicate the healthy state of
the network system. The normal member 61 is disposed to get triggered on any of the
events such as during reboot of the machine, restart of the service, periodically as a
heartbeat or after coming back to normalcy from some overloaded state.
An overload member 66 disposed in functional connectivity with announcer 51 to
communicate with other entities whenever an entity is overloaded or there is a shortage
of a resource, this message can be used to convey that information to neighbours.
In yet another embodiment of the present invention, an exception handler 52 and
success component 53, in functional connectivity with control message member 48 to
handle success/failure of actions taken in response to other control messages. The

exception handler 52 further comprises exception message component 68. The success component 53 further comprises success message component 69. The exception message 68 and success message components 69 together are disposed to handle success and exception scenarios in the network.
Fig 7 represents the application of our invention in IDMEF (Intrusion Detection Message Exchange Format), but not restricted to IDMEF. IDMEF is lETF's draft on communication message format for IDS Entities.
Presently the IDMEF-Message 78 facilitates communication of either the Alert 79 or Heartbeat 80 category. By addition of Control Message Module 48 of the present invention enables control communication amongst IDS entities in the form of Instruction Builder 49, Operation Executor 50, Announcer 51, Exception Handler 52 and Success Indicator 53.
The present invention also provides a method for the survivability and synchronisation of intrusion detection entities (IDEs) in computer network by way of control message communication, said method comprising the steps of detecting anomaly by an anomaly detector in an IDS entity of the computer network and initiating communication, receiving and analysing the anomaly by analyser cum decision maker, identifying the desired control message with inherent tasks for said anomaly, executing and performing the inherent task of said control message in the intrusion detection entity, and indicating success or failure of the selected task.
In the method of the present invention, the executing and performing of the inherent task further comprising the steps of, isolating an intrusion detection entity, delegating tasks of an intrusion detection entity to another, performing local logging or flushing logs, and synchronizing IDS entities by providing detection data, configuration and patches, and passing data from IDS entity to another.
The functional aspects of the flow of activities performed by the intrusion detection entity (sending entity) in a process of sending a control message are provided in the following flow chart.

I
The functional aspects of the flow of activities performed by the intrusion detection entity (receiving entity) in a process of sending a control message are provided in the

The present invention is further exempHfied in the form of following examples. However, the following examples should not be construed as limiting the scope of the invention.
Example 1 By Referring to Fig 1 if the Manager Ml intends to shutdown for some maintenance reasons. In absence of control messages, the manager Ml would have shut down, without notifying the agents, and would have resulted in following:
1. The agents Al & A2 try to send alerts to the manager and find that manager is
dead,
2. The alerts get delayed or worst still lost.
3. This could happen for every alert generated.
4. No proper reaction/response could be taken for the alerts generated.
But in presence of control message modules, the manager Ml makes an attempt to save the situation using the control messages. It tries to get a surrogate alert handler and finds it in the form of IA2. It then asks Al and A2 to report to it. Finally when the manager Ml is ready to resume normal operations, it demands logs of all the responses taken by 1A2. Referring to Fig. 6, which shows time on the Y-Axis and the entities on the X-axis, shows the flow of messages passed between IDS entities involved in the

Results obtained using the control messages include no alerts went unnoticed, lAl could respond to alerts and Manager could demand a storage/log of all the happenings during its absence. The scenario above shows that the manager made decisions and made appropriate use of the control messages to save the system. The manager had no information about the configuration of other Independent agents; as to what modules they were capable of running.
Example 2 Now again referring to Fig 1 wherein if one of the agents Al & A2 feels short of processing power because of overload. In absence of control messages, the agent could at best take measures like shutting down one of its detection module. This could result in following: Detection is hampered, either because it is stopped or because its constrained, the agent is not able to handle the overload and finally dies and nobody would perhaps know about this failure. In the presence of control messages, the manager gets notified of the overload. This enables the manager to find out of some other agent can take up the responsibility. In an attempt to relieve Al with some detection technique, Ml asks A2, lAl and IA2 to take up PAD (Protocol Anomaly Detection) technique so that Al could be asked to stop. But nobody have the expertise of this detection methodology. Manager is aware that Al has signature detection running. So the manager again asks help from A2, lAl and IA2. Fortunately IA2 offers help. Manager asks IA2 to update its signature database to that with Al and asks it to start the SD module. Finally, Al is asked to stop SD (Signature Detecfion) module and

some problem in the detection system, and get the detection module be nin at some other system. Therefore, the manager could handle a situation that would have been impossible without control messages. After the message 11, manager could very well restart the signature detection module back at Al. This would eventually restore the old system status. In this scenario, IA2 understands the calamity and helps survive the system.
Example 3 One of the most feared situations is a DOS attack: a Denial of Service (DOS) attack. (In such an attack, the attacker floods the server that provides some service. This causes the server to overloaded and eventually stop serving the legitimate clients. Such attacks can only be detected correctly with complicated statistical techniques involving analysis of data from many sources). Survivability is of utmost importance when the system itself is under attack. In case of a DOS attack on an agent, the agent gets overloaded. One of the agents feels short of memory because of overload. In absence of control messages, the detection is hampered, either because its stopped or because its constrained. If it's stopped, to save from overload, the attack becomes successful. Further, the agent is not able to handle the overload and finally dies and there would be a non-disclosure of failure.

In the presence of control messages, the manager gets notified of the overload. In such a case, the manager could very well take up the technique as mentioned in the earlier case (Example 2), but using the control messages, it tries to understand the situation by demanding logs of the recent happenings from all the agents. Since DOS attacks can be detected only with complex techniques, with inputs from multiple sources, the manager is in much better position to detect it. When the manager gets a hint of a DOS on one of its agent, it asks the agent to go underground. It achieves this by asking the agent to logically relocate itself on the network.

Presence of control messages, helped in achieving the following: The manager becomes aware of some problem in the detection system and further the DOS attack on the agent is detected and finally the agent is saved from the attack. Inference:
The manager was in the best position to detect the ongoing attack. However since the agents have detecting software, it could be possible to at least get a hint of the attack. In absence of control messages, there is nothing that the agent could do than to change to logging mode. Moreover changing to logging mode doesn't save the agent from the attack. If at all the agent decides to relocate itself, the manager cannot be notified, and it would end up denying service to the manager, as the manager could no longer contact the agent. This would again be a successful DOS attack as for an agent the manager is a legitimate client.

The system and the executable modules of present invention are implemented using an
object oriented language C++ on Fedora core Linux platform.
Hardware
Pentium III
CPU 1.3 Ghz
Memory 512 MB
Hard Disk 40 GB
Ethernet Interface: 10/100/1000Mbps Software
Operating System Fedora Core Linux
Language: C"^\ Java
The implementation of the subject matter of the present invention is not constrained to a specific hardware or software requirements. It is within the scope of the present invention to use any suitable hardware/software can for implementing the subject matter of the present invention.
Advantages
1. Irrespective of the architecture of the IDS (standalone solution, Distributed etc) the
present invention provides means to create a two-way communication environment for the internal and external components of IDS to work cohesively facilitating survivability.
2. The aim of functioning of various components cohesively is achieved through various identified control messages.
3. The control messages when initiated, addresses a wide range of survivability issues.

We claim:
1. A system for the survivability and synchronization of Intrusion Detection System (IDS) Entities in a computer network, said system comprising; an anomaly detector means to detect an anomaly in an IDS entity of the computer network and initiate communication, an analyser cum decision maker to take strategic decisions for survivability of one or more IDS Entities, an instruction builder to generate control messages, said control messages with inherent tasks, an operation executor to execute the tasks, an announcer to announce the status of an IDS entity, a success indicator to indicate the completed inherent tasks, and an exception handler to handle the unsuccessful tasks.
2. The system as claimed in claim 1, wherein the instructional builder consisting of an isolate member to generate control message for isolating an intrusion detection entity, a contact member to generate control message for delegating tasks of an intrusion detection entity to another, a log signal member to generate control message for performing logging events, a synchronize member to generate control message for synchronising intrusion detection entities, and a send-info member to generate control message for passing data from IDS entity to another.
3. The system as claimed in claim 1, wherein the operation executor consisting of a start, stop, pause and resume action members along with a switch mode member to execute the corresponding action in an IDS entity.
4. The system as claimed in claim 1, wherein the announcer consisting of normal, shutdown, and overload members to announce the on, off and overload status respectively of an entity,
5. The system as claimed in claim 1, wherein the exception handler consisting of exception message component to handle errors of any IDS entity.
6. The system as claimed in claim 1, wherein the success indicator consisting of success message component to indicate the affirmative result of any operation by the IDS entity.
7. The system as claimed in claim 1, wherein the control message of data of the send-info member consists of logs, alerts and configurations of an entity.
8. A method of surviving and synchronizing of Intrusion Detection System Entities (IDS) in a computer network, said method comprising the steps of:

(a) detecting anomaly by an anomaly detector in an IDS entity of the computer network and initiating communication, receiving and analysing the anomaly by analyser cum decision maker, identifying the desired control message with inherent tasks for said anomaly, executing and performing the inherent task of said control message in the intrusion detection entity, and indicating success or failure of the selected task. 9. The method as claimed in claim 8, wherein the executing and performing of the inherent task further comprising the steps of,
(a) isolating an intrusion detection entity, delegating tasks of an intrusion detection entity to another, performing local logging or flushing logs, and synchronizing IDS entities by providing detection data, configuration and patches, and passing data from IDS entity to another.

Documents:

325-CHE-2004 AMENDED CLAIMS 10-10-2013.pdf

325-CHE-2004 AMENDED PAGES OF SPECIFICATION 24-07-2013.pdf

325-CHE-2004 AMENDED CLAIMS 24-07-2013.pdf

325-CHE-2004 CORRESPONDENCE OTHERS 24-07-2013.pdf

325-CHE-2004 CORRESPONDENCE OTHERS 04-09-2013.pdf

325-CHE-2004 CORRESPONDENCE OTHERS 04-11-2013.pdf

325-CHE-2004 EXAMINATION REPORT REPLY RECEIVED 10-10-2013.pdf

325-CHE-2004 EXAMINATION REPORT REPLY RECEIVED 24-07-2013.pdf

325-CHE-2004 FORM-1 10-10-2013.pdf

325-CHE-2004 FORM-1 04-11-2013.pdf

325-CHE-2004 FORM-13 24-07-2013.pdf

325-CHE-2004 FORM-3 24-07-2013.pdf

325-CHE-2004 OTHER PATENT DOCUMENT 24-07-2013.pdf

325-CHE-2004 POWER OF ATTORNEY 24-07-2013.pdf

325-CHE-2004 AMENDED PAGES OF SPECIFICATION 10-10-2013.pdf

325-CHE-2004 CORRESPONDENCE OTHERS 11-11-2013.pdf

325-CHE-2004 FORM-13 27-07-2010.pdf

325-che-2004-abstract.pdf

325-che-2004-claims.pdf

325-che-2004-correspondnece-others.pdf

325-che-2004-description(complete).pdf

325-che-2004-description(provisional).pdf

325-che-2004-drawings.pdf

325-che-2004-form 1.pdf

325-che-2004-form 26.pdf

325-che-2004-form 3.pdf

325-che-2004-form 5.pdf

« Previous Patent

Next Patent »

Patent Number

257867

Indian Patent Application Number

325/CHE/2004

PG Journal Number

46/2013

Publication Date

15-Nov-2013

Grant Date

13-Nov-2013

Date of Filing

08-Apr-2004

Name of Patentee

CENTRE FOR DEVELOPMENT OF ADVANCED COMPUTING (CDAC)

Applicant Address

THE MINISTRY OF COMMUNICATIONS AND INFORMATION TECHNOLOGY,REGISTERED UNDER SOCIETES REGISTRATION ACT 1860,GOVERNMENT OF INDIA, LOCATED AT #68, ELECTRONICS CITY, BANGALORE 561229, INDIA

Inventors:

#	Inventor's Name	Inventor's Address
1	NEELAKANDAN SUBRAMANIAN	CENTRE FOR DEVELOPMENT OF ADVANCED COMPUTING, (A SCIETIFIC SOCIETY OF THE MINISTRY OF COMMUNICATIONS AND INFORMATION TECHNOLOGY), GOVERNMENT OF INDIA, 68, ELECTRONICS CITY, BANGALORE 561229 INDIA
2	NIHAR SATISH KHEDEKAR	THE MINISTRY OF COMMUNICATIONS AND INFORMATION TECHNOLOGY, REGISTERED UNDER SOCIETES REGISTRATION ACT 1860, GOVERNMENT OF INDIA, LOCATED AT #68, ELECTRONICS CITY, BANGALORE 561229, INDIA
3	PRAMOD SAKHARAM PAWAR	THE MINISTRY OF COMMUNICATIONS AND INFORMATION TECHNOLOGY, REGISTERED UNDER SOCIETES REGISTRATION ACT 1860, GOVERNMENT OF INDIA, LOCATED AT #68, ELECTRONICS CITY, BANGALORE 561229, INDIA
4	SRINIVAS GUNTUPALLI	THE MINISTRY OF COMMUNICATIONS AND INFORMATION TECHNOLOGY, REGISTERED UNDER SOCIETES REGISTRATION ACT 1860, GOVERNMENT OF INDIA, LOCATED AT #68, ELECTRONICS CITY, BANGALORE 561229, INDIA
5	MAYANK BHATNAGAR	THE MINISTRY OF COMMUNICATIONS AND INFORMATION TECHNOLOGY, REGISTERED UNDER SOCIETES REGISTRATION ACT 1860, GOVERNMENT OF INDIA, LOCATED AT #68, ELECTRONICS CITY, BANGALORE 561229, INDIA

PCT International Classification Number

G08B23/00

PCT International Application Number

N/A

PCT International Filing date

PCT Conventions:

#	PCT Application Number	Date of Convention	Priority Country
1			NA