The Common Intrusion Detection Framework Architecture Phil Porras, SRI Dan Schnackenberg, Boeing Stuart Staniford-Chen, UC Davis, editor Maureen Stillman, Oddysey Research Felix Wu, NCSU 1. Abstract We give an architectural overview of the Common Intrusion Detection Framework, including how it views IDS systems as divided up into components, and the layered model it introduces for communication between those components. 2. Introduction This document is part of a series produced by the Common Intrusion Detection Framework (CIDF) working group. The other documents provide: * A language that allows intrusion detection components to exchange data in semantically well-defined ways. * A messaging and directory specification that defines the way in which components can locate and authenticate each other, and encapsulate messages amongst themselves. This document does not provide much implementation relevant detail, but provides background to make the other documents more comprehensible. Increasingly, intrusions are taking on a grander scale. Many attacks can be orchestrated over a wide area network, and over a long period of time. In such an environment, the ability of intrusion detection systems and their components to share information about these attacks is especially important. Such sharing would allow systems to warn others about possible impending attacks. In order to achieve this, it is necessary for IDS systems to have well defined interfaces to share information. This document describes the architectural assumptions that are made by CIDF to partition these interfaces. The remainder of this document is organized as follows. Section 3 defines the overall requirements that CIDF is intended to meet. Section 4 defines the way CIDF views an IDS as divided into components, and Section 5 defines the way communication interfaces are layered. 3. Requirements CIDF should allow: That IDS systems can be componentized into modules of distinct functionality. That such components should be re-usable in a context different than that they were originally developed for. That components can share data, either by APIs or across the network, in order to reach conclusions that they could not reach by themselves. That new components can come on line and automatically find the other components that they need to communicate with ("plug-and-play"). That groups or systems of components can be combined together and masquerade as a single component to the rest of the world. Beyond these requirements, CIDF should constrain the design decisions of IDS builders as little as possible. 4. Components and Data CIDF adopts a view of Intrusion Detection Systems in which they consist of discrete components which communicate via message passing. Several kinds of components are envisaged: * Event generators (colloquially "E-boxes") * Event analyzers ("A-boxes") * Event databases ("D-boxes") * Response units ("R-boxes") All four kinds of components exchange data in the form of {\em generalized intrusion detection objects (gidos)} which are represented via a standard common format (defined in [CISL]). A gido encodes the fact that some particular occurrence happened at some particular time, or some conclusion about a set of events, or an instruction to carry out an action. Event generators produce gidos but do not consume them. Their task is to sample the particular environment they are specialized for, and turn occurences in that environment into CIDF gidos for use by other components. Analyzers take in gidos, and analyze them as to their significance (policy violations, anomalies, intrusions). Their conclusions are turned out as yet other gidos. Event databases store events for later retrieval. Components are logical entities and may represent anything which produces or consumes gidos. A component might be implemented as a single process on a computer (or even a thread), or might be a collection of many processes on a number of computers. 4.1 Event Generators The role of an event generator is to obtain events from the larger computational environment outside the intrusion detection system and provide them in the CIDF gido format to the rest of the system. For example, event generators might be simple filters that take C2 audit trails and convert them into gidos. Another filter may passively monitor a network and generate events based on the traffic thereon. A third might be application code in an SQL database program which generates events describing database transactions. It seems that these components are likely to be re-usable in that CIDF has a standard gido format, and so converting features of typical computational environments into that format will be a task that many groups will need to perform. Hence, it is useful to specify an interface for how event generators are configured and used. Event generators provide events as soon as they occur (with the possible exception of transport queuing). Storage of events is handled in event databases. 4.2 Event Analyzers Analyzers are the components we typically think of in the intrusion detection context. They receive gidos from other components, analyze them, and return new gidos (which presumably represent some kind of synthesis or summary of the input events). Thus for example, an analyzer might be a statistical profiling tool which examines whether events being supplied to it now are statistically unlikely to be from the same time series as events supplied to it in the past. Another example is a signature tool which examines sequences of events looking for particular patterns which represent known misuse of the system. Another example would be a correlator which simply examines events and attempts to determine whether they are causally related to one another, and then puts them together into composite events which can be further analyzed. 4.3 Event Databases These components simply exist to give persistence to CIDF gidos where that is necessary. 4.4 Response units. Response units consume gidos which direct them to carry out some kind of action on behalf of other CIDF components, and they carry out this action. This includes such things as killing processes, resetting connections, altering file permissions, etc. 4.5 Component Identity. It is necessary for components to have identifiers used to distinguish one component from another. ##Editorial # Headache - this used to be Open Group OID format, but we need to change # strategy given demise of OGRI. 5. Layers and services CIDF components communicate over a layered architecture, which consists of three layers: Gido layer Message layer Negotiated Transport layer The Gido format is defined in [CISL]. Gidos get encapsulated in messages, the format for which is defined in [Comm]. Finally, messages get sent over one of possibly several transport mechanisms, which can be negotiated depending on the needs of the components in question. This mechanism is also defined in [Comm]. The gido layer exists because for IDS systems to meaningfully interoperate, they must have a common understanding of the semantics of the data they send to each other. Hence, the gido format is a rich, extensible format with defined semantics for expressing events of interest to IDS systems. The message layer exists because the various transport options available lack desireable features. The message layer guarantees the ability to send encrypted authenticated messages reliably, and through firewalls, NAT devices, etc. The message layer carries no information about the semantics of the message, it is merely concerned with getting it from source to destination. Correspondingly, the gido layer contains no information about the delivery arrangements and is only concerned with the meaning of the information delivered. The transport mechanism is not part of the CIDF specification, but is one of several widely available transport mechanisms; the choices are specified in [Comm]. Finally, library interfaces for CIDF components to use are defined in [API]. 6. References [CISL] A Common Intrusion Specification Language, CIDF working group document. [Comm] Communication in the Common Intrusion Detection Framework, CIDF working group document. [API] Common Intrusion Detection Framework APIs, CIDF working group document.