Configuration of the Event Logging and Alerting Mechanisms

---

Upon registering security-related events, the IDS must do the following:

• Log the event and notify the administrator of the detected attacks, vulnerabilities, or other security policy violations.

• Log and issue notification of the events related to the IDS itself (e.g., when the log file is full, when the connection between the sensor and the console is interrupted, etc.)

Correct configuration of the event-logging and alerting mechanisms will decrease the interval between attack detection and the reaction to it. These mechanisms must be considered in such a way as to inform all responsible individuals only of the events that are actually important, such as:

• Attacks that really were implemented

• Potential attacks that could result in compromising the whole network

• Failed attempts to logon to the system

• Modifications or configuration changes introduced into the IDS or another installed security tool

• System messages (e.g., memory overflow, interruption of the connection between console and sensor, etc.).

The security policy — or the IDS operating plan — must describe all event-logging and alerting mechanisms, and list all events that will result in the activation of these mechanisms.

Log Files

There is no need to store log files for longer than 3 or 4 weeks. Since IDSs — with the exception of scanners and integrity control systems — are security tools operating in real-time mode, storing log files for longer periods has no practical purpose. Experience has shown that IDS administrators rarely investigate even events that took place during the previous week, to speak nothing about two or three-week-old records. This does not concern security scanners, which can access even three- or six-month-old records, in order to investigate the changes that have taken place within the scanned segment (Fig. 11.11). In any case, it is a good idea to archive log files after a specified time period, in order to store them for future use and access them as needed.

Fig. 11.11. Comparison of the security level for a specified time period

When configuring the logging subsystem, the following aspects should be taken into account:

• The location of the log files of each IDS component (local or remote). In some systems, these paths are specified by default. However, for some systems, the directory and filename for the log file must be specified explicitly.

• Expected size of the log file for each component. As a rule, for "classical" IDS sensors, it is possible to specify the maximum log-file size. For consoles or security scanners, on the other hand, this parameter is not specified, since it is impossible to know beforehand how rapidly the log file will fill up. There are two methods of specifying log-file size: by bytes or by records. Different IDSs combine both these methods. (It is actually quite difficult to choose between the two methods, as both of them have advantages.)

• Access rights to log files and their components. It is recommended that you make the list of users that have access to the logged data as short as possible. This is especially true for IDS systems that store critical information on system vulnerabilities, which can cause significant damage if misused. In some systems, such as RealSecure and Internet Scanner, access rights to log files and other components are set automatically during system installation. In other systems, this operation must be performed manually, using the mechanisms provided by the operating system.

• Using cryptographic transformations (integrity control and encryption) for additional protection of log files. As I already noted, it is not advisable to apply these operations to log files that are constantly having new records added relating to the attacks and vulnerabilities discovered, since this will have a negative impact on the system's overall performance. The continuous calculation and recalculation of checksums may take up all of the system's resources, which will reduce system performance, or even make the logging of some events impossible.

• Log-file backup and recovery. Since log files fill up quite rapidly, only those events that are really important should be logged; otherwise, log files will quickly grow in size and take up all the available disk space, and subsequent events will not be registered. This can sometimes serve as an opportunity to implement a Denial of Service attack (Log Flood) on the IDS. Since it is impossible to predict the rate at which log files will fill up with new records, it is recommended that you enable the automatic synchronization mechanism implemented in some IDSs (such as RealSecure). This makes it possible to copy the log file from the network sensor to the central console when specific criteria are satisfied (for example, when the number of records reaches a specified limit, or when the log-file size exceeds a certain value). If the criterion is satisfied, but synchronization can not occur — for example, if the connection between the sensor and the console has been interrupted — synchronization will be reattempted after the so-called "notification interval" elapses. Both the synchronization criterion and the notification interval must be specified by the administrator (Fig. 11.12).

Fig. 11.12. Synchronization of log files

It should be specifically pointed out that currently, hard disks are inexpensive, and therefore, are not something on which users should economize. The amount of disk space for storing log files should not limit logging frequency or the number of registered events.

E-Mail Notifications and SNMP Traps

This is relatively simple, but, to be implemented properly, two important aspects must be taken into account. First, e-mail messages are unprotected, and any intruder can intercept, read, modify, or even replace them (especially if they are transmitted via public networks). Secondly, when using e-mail or SNMP notifications, you may encounter an "endless loop" situation (Fig. 11.13), although only in classical network-level IDSs. Although such cases are relatively rare, the possibility grows with cluster configurations made up of IDS sensors, or when there are two backup sensors from different manufacturers within the network segment.

Fig. 11.13. The endless loop situation

---