runs continuously and autonomously in a particular environment, and is able to carry out

activities in a flexible and intelligent manner. We have drawn from this idea of

implementing sensors as autonomous agents and thus detectors in our system are also

used in such a manner. They are not required for the rest of the system to function. Hence

killing a detector does not hamper the IDS in any way other than rendering the IDS

incapable of monitoring the particular security function that the detector was observing.

 Detectors report suspicious activity in the form of events to the coordinator. It is

not necessary for the detectors to report every event to the coordinator. The detector can

perform analysis and then report only select events to the coordinator. Reporting every

event helps in keeping the rest of the system knowledgeable, but at the same time,

increases message traffic and protocol load. The architecture gives us the ability to tune

or configure the interface of the detectors and thus decide what kinds of events are

reported by the detectors. This can also be controlled by specific response agents that

may react to excessive messages from a detector and consequently rewrite the

detector/interface configuration files, to make them stop sending those particular

messages.

3.1.2 Interfaces

 The interfaces (I in Figure 3.1) are small software wrappers that help the IDS

understand the detectors. They were introduced in AAFID [4], as a means of integrating

detectors into the AAFID system. Interfaces translate the events reported by the detector

into the common Event Reporting Language that is used by the rest of the IDS. An

interface is necessary only for third party Detectors. They can be directly programmed

into the ones that are developed in-house. The use of interfaces helps to integrate any

detector into the IDS. It can also be used to integrate entire third-party IDSs into the