Intrusion Detection Inter-component Adaptive Negotiation

The Intrusion Detection System (IDS) community is developing better techniques for collecting and analyzing data in order to handle intrusions in large, distributed environments [1, 5, 6]. To take advantage of this ongoing work, IDSs should be able to dynamically adapt to new and improved components and to changes in the environment. The Intrusion Detection Inter-component Adaptive Negotiation (IDIAN) project has developed a negotiation protocol to allow a distributed collection of heterogeneous ID components to inter-operate and reach agreement on each other's capabilities and needs { i.e., the information that can be generated and processed. Moreover, the negotiation is dynamic so the information generated and processed can evolve as the IDS evolves or the environment changes. The IDIAN project leverages the Common Intrusion Detection Framework (CIDF), an e ort by DARPA to develop a common language, protocols, and APIs that allow intrusion detection components to interoperate and share information. The IDIAN project has extended the CIDF language CISL (Common Intrusion Speci cation Language) with constructs for dynamic negotiation. One such construct is the notion of a lter to specify sets of IDS messages. Filters are useful in negotiating, for example, what data will be transmitted. The IDIAN project also adopts the CIDF framework architecture that classi es ID components according to their function. The negotiation protocol uses the notion of a contract { an association between two ID components, a producer and a consumer { which contains one or more possible agreements. An agreement commits the producer to provide the consumer with a set of services. For example, a detection component (producer) might have a contract with an analysis component (consumer) to provide a speci c set of audit data. At any give time, at most one of the agreements in a contract is in e ect, although the ID components may switch to one of the alternatives dynamically. Furthermore, two components may have multiple contracts operating at the same time. The primary function of the protocol is to allow ID components to dynamically negotiate new contracts/agreements and to change existing ones. An extension of the protocol is designed to handle hierarchical negotiations in which top-level components obtain the services of low-level components through intermediaries. To facilitate choosing among several options, the protocol uses the notion of cost to capture the relative cost to a producer (resp., consumer) to provide (process) a speci c set of services. Services provided by producers require a variety of system resources. A consumer may decide to use a particular service only if the cost is below a certain threshold. The absolute and relative amount of resources required to supply a particular service may vary over time, and the protocol allows producers and consumers to renegotiate when necessary. In addition to the protocol, the IDIAN project has developed several scenarios that demonstrate situations where an IDS must adapt to a changing environment. The scenarios can be divided into two general classes: 1. The acquisition of a new capability by the IDS. For example, an ID component may acquire a new attack signature or a new ID component may come on-line. The IDS must adapt by incorporating the new signature or ID component into the overall system. 2. An overload of the IDS caused, for example, by faults in the IDS itself or by a ooding attack. The IDS could adapt by reducing the amount of information being gathered, or by cutting o the ow of data from the ooding source. The IDIAN project has developed a demonstration of the protocol in which a new producer comes on-line and negotiates with an existing consumer. The new producer can report bu er over ow attacks detected by the StackGuard [2] system. Finally, the IDIAN project is using the formal description language Estelle [3] to specify the negotiation protocol.