Architecture of the Intrusion Detection System


All intrusion detection systems can be classified as being members of one of two categories - standalone or client-server systems. Products associated with the first category collect information, analyze it and react to events at a single host. Systems from the second category are built according to another principle. The intrusion detection modules (sensors) are installed at the most critical points of the corporate network. These modules detect attacks and react. All management tasks are carried out from the centralized console, to which all alerts are sent. The architecture of this intrusion detection system is rather simple. It is shown in Fig. 6.12. It includes seven modules, each of which is responsible for a specific task. The data-source processing module is responsible for interaction with the log file, network adapter or OS kernel to obtain data, on the basis of which the system determines presence of an attack. The second module manages all components of the intrusion detection system and organizes their interaction.

click to expand
Fig. 6.12. Architecture of the intrusion detection system

The data is stored in a normal log file, storing all information on registered attacks and suspicious events. This log file can have a normal text-file format (like, for example, the Snort system) or be stored in the database. The database can be local (as, for example, the MS Access database in the eTrust IDS system) or client-server (like Oracle databases in Cisco IDS 4200, or MS SQL in RealSecure Network Sensor). The knowledge base contains information based on which the system decides if it should report an attack on the basis of the information from a specific data source. Depending on the analysis methods implemented, this database can store attack signatures, user profiles, etc. Comparison of the rules stored in the knowledge base to records from a specific data source is performed by the intrusion detection module, which, based on the results of the comparison, can issue commands to the reaction module. A graphic user interface makes administrative tasks intuitive and convenient to perform. Using the GUI, you can collect information from all intrusion detection system components as well as perform management tasks. In some intrusion detection systems (especially those implemented for Unix), the graphic user interface is lacking (for example, in the Snort system). If the intrusion detection system is built as a standalone agent, then all above-mentioned modules reside on the same computer. If the system was designed taking into account the client-server architecture, it has two basic levels - the sensor, which is also known as the agent or tracking module (engine), and the console. The sensor is responsible for detecting attacks and reacting to them, and then transferring the data on the detected unauthorized activity to the management console (Fig. 6.13).

click to expand
Fig. 6.13. Architecture of the intrusion detection system sensor

Usually, the sensor starts as a service or daemon and runs 24 hours per day. Since it transmits alerts of detected attacks to the console, it has no GUI module for displaying this data on the sensor.

The console is designed to control the sensor and collect information from all sensors to which it is connected (Fig. 6.14).

click to expand
Fig. 6.14. Architecture of the intrusion detection system console

Usually, a single console can coordinate an unlimited number of sensors. Similarly, any sensor can send information to several consoles simultaneously, thus making the console fail-proof. Many intrusion detection systems, such as RealSecure Network Sensor or Cisco IDS 4200, are structured according to this principle (Fig. 6.15).

click to expand
Fig. 6.15. Console fault-tolerant implementation

To prevent two consoles from changing the settings of the remote sensor simultaneously, one of them must have special status. Only the console that is assigned this status is permitted to change the configuration of a remote sensor and perform other management operations. This mechanism is similar to the principles implemented in the Check Point Firewall-1 system. According to these principles, only one administrator at a time can connect the firewall with Read/Write capabilities. Other administrators work only with Read capabilities.

The data storage contains information collected from all sensors. It is clear that the console lacks modules responsible for gathering data from the data sources, analyzing this data and reacting to the attacks. All the above-mentioned functions are delegated to sensors. This is done in order to prevent the disruption of the functions of the data channels between the console and sensor in the event of data channel or console failure. Thus, in case of such a failure, the sensors continue to function autonomously. Even if this happens, the sensors continue to detect attacks and react to them. When the connection to the console is restored, the sensors then send it all the accumulated information. Unfortunately, this fact has not yet been understood by all intrusion detection system developers. For example, I once had to investigate a system built according to a different principle. Sensors for this IDS only collected data from log files or from network traffic, while all processing is performed on the console (Fig. 6.16). There is no need here to explain the results that this structure can produce. In the event of a failure in the console or the communication channel between the console and remote sensor(s), the latter turn into useless programs that reside in the RAM and collect information, but can not accomplish anything, since all of the processing is centralized on the console. Furthermore, when the connection to the console is restored, a vast amount of information from all of the sensors floods to it. Besides net-work overload, this might cause the console to fail once again, since it will prove unable to process such a large amount of information. The situation can continue indefinitely, and the failures will persist.

click to expand
Fig. 6.16. Incorrect architecture in the intrusion detection system

A classic two-level "console/sensor" scheme is oriented toward a relatively small number (up to a few dozen) of sensors connected to a single console. This scheme is ideal for remote offices or affiliates that perform security management for themselves, or for small companies with centralized management of all sensors. As a further advance in this model, Cisco has suggested a new approach, which significantly improves the integration between centralized and decentralized sensors in the intrusion detection system. This scheme is especially advantageous for companies with hierarchical structures in their information-security departments. Usually, such organizations have, by default, a centralized department that develops a unified information-security policy and controls all security departments located in the remote affiliates.

The configuration of the hierarchical intrusion detection system developed by Cisco is shown in Fig. 6.17.

click to expand
Fig. 6.17. Hierarchical management of intrusion detection system sensors

When the sensor detects an attack, it immediately sends information about this attack to the affiliate-management console. In this aspect, the scheme suggested by Cisco does not differ significantly from the classical two-level scheme. However, if the sensor detects an attack it considers to be particularly dangerous (or any other attack specified by administrator), it sends an alert to the affiliate console, as well as to the centralized console located in the headquarters of the information-security department

Besides the above-mentioned architectures, there is yet another scheme, also known as the "sensor/control server/administrator console" architecture (Fig. 6.18). In this case, sensors send information about the detected attacks on the controller server rather than on the administrator console. The advantage of this scheme lies in the fact that all data on the security policies loaded to the sensors, as well as events registered by the sensors and other information, are stored on the controller server rather than on the administrative console. The role of the administrative console can be delegated to any computer, while the server is normally a powerful and fault-resistant system, on which the probability of failure is significantly lower than that in any other server or workstation. The NetProwler intrusion detection system is built according to this scheme.

click to expand
Fig. 6.18. Three-level sensor-management scheme




Protect Your Information with Intrusion Detection
Protect Your Information with Intrusion Detection (Power)
ISBN: 1931769117
EAN: 2147483647
Year: 2001
Pages: 152

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net