next up previous contents
Next: 2.1.2 The decision enforcement Up: 2.1 Components of an Previous: 2.1 Components of an

  
2.1.1 The monitoring application

In our definition of an adaptive security management system we included the need to monitor in real time. In essence the monitors contains a "sensor object", the eyes and the senses of the adaptive security system. Without the brain however it has no idea what it is looking at and it does not know what to look for.

Depending on what the system under consideration is, the monitor can be implemented as a dedicated stand-alone device or it can be part of an already existing service.

Many services that are provided using computer networks already have some sort of security in place. Remote login servers usually require authentication and so can FTP or WWW servers. It is clear that instead of simply logging intrusion attempts we could notify a central instance straight away of such an event. In this case the monitoring application would simply be provided by (interaction of) software that is already available. On UNIX systems for instance it is perfectly possible to have an administrator being sent an e-mail when the system is shut down.

The availability and utility of this sort of system is however often limited. The notification channel is not necessarily suitable for sending the messages, for instance because it uses the same subsystem that is under attack, like in the case of a denial of service by flood pinging. Clearly, sending e-mail upon notification of this type of attack will not do anything -- except for making things slightly worse probably -- as both the attacker and the notification service use the same network cable. The chance that the existing service spots all possible indications of an attack is also quite unlikely. Often an intrusion attempt over the network will use a combination of techniques addressed at various services, like in the case of a port scan, or an attacker can exploit bugs in the software2.1 (do we hear someone mentioning sendmail?). Special dedicated client applications could possibly do a better job, at the expense of having to figure out how the service software and the dedicated monitor will interact.

For some application domains like computer security, relying on existing services only could prove to be adequate and effective. In the case of network security, it seems that we will need additional dedicated devices. Such a device could be a passive box attached to a broadcast network medium like ethernet with an interface in promiscuous mode. It does not provide network services to end users -- hence the term passive -- but analyses the contents of each packet on the wire. This way it could detect a network storm or a port scan on an active server.

This however does not solve the problem of notification in itself. A passive dedicated device listening to traffic on the network will still be unable to send a notification to the central management service. A second dedicated channel seems indispensable. Alternatively a fail-safe critical system that incorporates both the security enforcement application and the monitor could, on detection of an attack and a communication malfunction or impediment, autonomously decide to take action if configured so in advance by the central management system (for more see section 2.1.2 on the decision enforcement application). A self-monitoring process checks if the application and the sensor device are functioning properly.

It would therefore be appropriate for the monitor to not only implement a sensor object and a notification service, but also to have default values set for its operation. Default operation could consist of the monitor logging all traffic locally until the contact with the central management system is restored, or autonomously trying to contact an associated decision enforcement application to take a predefined action.

As the basic property of the monitor is to filter out events at the source it might also be useful to have it told what to look for exactly (``Have the brain tell the eyes what to look for'') and enable it to filter out the relevant data before contacting the management service. An interface for incoming messages could allow the management service to change the monitor's filtering granularity. Figure 2.2 gives a schematic representation of the concept of a monitor object.

  
Figure 2.2: A graphical representation of the monitor object concept
\resizebox*{5cm}{!}{\includegraphics{monitor_object.eps}}


In a real-time environment the monitor should take the initiative to warn the central management system in case something is perceived to be wrong. We will use the term signalling for this. An alternative scenario consists of the central system polling the monitor at regular intervals2.2. In an environment where timeliness is essential, real-time signalling is preferable to polling where an attack or failure can occur in-between two polling events.



Footnotes

... software2.1
If such an attack would be spotted by the software, it would dramatically simplify bug hunting.
... intervals2.2
Note that this is not a discussion on the low level implementation of messaging systems using interrupts or a similar concept. Central to the discussion is the party that takes the initiative. The monitor could send the central system a message, what we called a ``signal'', thereby merely setting a flag in the central system's memory that is checked, i.e. ``polled'', every x milliseconds by the central system

next up previous contents
Next: 2.1.2 The decision enforcement Up: 2.1 Components of an Previous: 2.1 Components of an
(c) 1998, Filip Schepers