Host-Level Intrusion Detection Systems | Protect Your Information with Intrusion Detection (Power)

Now we will discuss the drawbacks typical only for host-level intrusion detection systems.

Log-File Size

One of the main drawbacks of host-level intrusion detection systems is the necessity of storing large amounts of data. This problem is especially important for heavily loaded servers, since all events must be logged, which results in the uncontrollable growth of event logs.

Storage Interval

This problem is closely related to the log-file size problem, since the time interval during which the logged events must be stored depends directly on their accumulation. The longer you store log files, the more data they contain. On the one hand, since the data amount increases, the analysis becomes more efficient, and the probability of detecting sophisticated attacks or ones distributed in time also grows. On the other hand, it is problematic to store such amounts of data for a long time.

Performance Problems

Controlling all events that take place on a protected computer results in performance problems. This trend is especially obvious for systems that control the current activity of a specific user or any other network subject, since intrusion detection tools must control any chain of calls to the system resources and check if that specific action is authorized. For tools intended for log-file analysis, this problem is less critical, but it still retains its importance, since logging all activities significantly degrades the performance of the controlled host.

Protection of Log Files

The next problem specific to host-level intrusion detection systems is the protection of log files from unauthorized access. In network-level intrusion detection systems, all log files are stored only on the central console (for client/server architecture), while information from remote network sensors is transmitted to the console rather quickly. Thus, this information is not stored on the sensor for a long time. The situation is different for systems that analyze events on specific hosts. Such systems are approximately 10 or more times as numerous as network-level intrusion detection systems. Besides this, in contrast to network sensors that can be protected by strong security (since their only function is intrusion detection), host-level intrusion detection systems operate on hosts for which intrusion detection is not the primary function. As a rule, these hosts perform functions that are quite different, such as transaction processing, file storage, providing Web services, and so on. Furthermore, the list of users who have the right to access network sensors can be limited to one or two persons, which is clearly impossible for system sensors. By definition, such hosts must be accessed by hundreds or even thousands of users. This is why the problem of protecting the log-file data becomes so important for system sensors.

Types and Level of Detail of Logged Events

Besides the problems that were already mentioned, you must not forget yet another one, which is no less important. The available operating systems and applications do not log all the events that are possible in the analyzed software. Furthermore, even if some events are logged, the level of registered details is insufficient. This is especially true for Microsoft products.

Lack of a Universal Data Storage Format

There is also a problem with the development of a unified log-file format for intrusion detection systems. This aspect mainly relates to the limitations and specific features characteristic of different sources of information about attacks. For example, let's consider the most difficult case—two different operating systems such as Unix and DOS. The events registered in these two operating systems are very different. Some Unix operations are not applicable to DOS, such as usage of inter-processor links in multiprocessor systems. Likewise, the loading and unloading of TSR programs in DOS has no adequate analog in Unix. Because of all this, it is rather problematic to develop a unified log-file format for both operating systems. Although research in this field has been going on for quite a long time (for example, consider the CERIAS project aimed at designing a universal data format for auditing systems, or the WELF extended log-file format for firewalls and VPN devices developed by WebTrends Corporations), more or less satisfactory results are not expected in the near future.