IT Baseline Protection Manual - The Information Warfare Site

Safeguard Catalogue - Communications Remarks
____________________________________________________________________ .........................................
In the case of anomaly detection, on the other hand, the assumption is that the
normal behaviour of users or computers can be statistically recorded, and
deviations from this are judged to be attacks. One example of this is the period
of time within which a user is normally logged in at her computer. If she
almost always works from Monday to Friday within the period from 8 a.m. to
5 p.m. with deviations of no more than 2 hours, any activity on Saturday or at
midnight can be classified as an attack. The problem with anomaly detection
is how to determine what is normal behaviour. Some conclusions can be
drawn on the basis of threshold values or probability considerations. It appears
questionable, however, whether it makes sense to immediately classify an
activity by user A on Monday at 7.10 p.m. as an attack. Also, a user's normal
behaviour usually changes, meaning that adaptations have to be made. Who
tells the ID system, though, that this change in behaviour is OK and not an
attack?
It also makes sense to subdivide ID systems according to the type of data
acquisition involved. This can be done either with the aid of a dedicated
sniffer somewhere in the network (network-based ID system), or it can be part
of the normal logging functionality on one of the connected computers (hostbased
ID systems). There are advantages and disadvantages to both. It has to
be said that it is easier for network-based systems to detect a wide-ranging
attack that affects various computers at the same time. It is considerably more
difficult, however, to detect complex attacks (e.g. via other intermediate
stations) on one computer. Over and above this, network-based systems
cannot analyse encrypted data. As for the host-based ID systems, extensive
changes may have to be made to the logging functions for the computers
before they can be used.
Because data privacy stipulations or staff agreements also have to be observed
even when logging information is evaluated automatically, it may be
necessary in some circumstances to store the data under a pseudonym.
The following aspects should be taken into account before coupling an ID
system, IR system and firewall:
- Is it possible to deliberately initiate an attack on the firewall which is
erroneously interpreted by the ID system as a genuine attack? If the IR
system subsequently triggers the disabling of certain services across the
firewall, this can have considerable consequences for availability.
- The interaction between the ID system, the IR system and the firewall
should be sufficiently transparently documented. Otherwise it is not
possible to assess at any one time who the firewall is administered by:
by the IR system or by administration staff. If there is any doubt,
decisions by the administration staff should take priority.
In order to rule out attacks against an ID system itself, it should be invisible
from the network, as far as this is possible. The simplest provision is to assign
an IP address that is not routed in the Internet. It is also recommended to
deactivate the ARP protocol for the corresponding interface so that there will
be no response to either ARP or IP packets.
____________________________________________________________________ .........................................
IT-Baseline Protection Manual: Oktober 2000