|
|
Intrusion Detection
Many intrusion detection systems base their operations
on analysis of OS audit trails. This data forms a footprint of system
usage over time. It is a convenient source of data and is readily
available on most systems.
From these observations, the IDS will compute metrics
about the system's overall state, and decide whether an intrusion
is currently occurring. An IDS may also perform its own system monitoring.
It may keep aggregate statistics which give a system usage profile.
These statistics can be derived from a variety of sources such as
CPU usage, disk I/O, memory usage, activities by users, number of
attempted logins, etc. These statistics must be continually updated
to reflect the current system state. They are correlated with an
internal model which will allow the IDS to determine if a series
of actions constitute a potential intrusion. This model may describe
a set of intrusion scenarios or possibly encode the profile of a
clean system.
Characteristics of a Good Intrusion Detection System
An intrusion detection system should address the following
issues, regardless of what mechanism it is based on:
- It must run continually without human supervision. The system
must be reliable enough to allow it to run in the background of
the system being observed. However, it should not be a "black
box". That is, its internal workings should be examinable from
outside.
- It must be fault tolerant in the sense that it must survive
a system crash and not have its knowledge-base rebuilt at restart.
- On a similar note to above, it must resist subversion. The system
can monitor itself to ensure that it has not been subverted.
- It must impose minimal overhead on the system. A system that
slows a computer to a crawl will simply not be used.
- It must observe deviations from normal behavior.
- It must be easily tailored to the system in question. Every
system has a different usage pattern, and the defense mechanism
should adapt easily to these patterns.
- It must cope with changing system behavior over time as new
applications are being added. The system profile will change over
time, and the IDS must be able to adapt.
- Finally, it must be difficult to fool. The last point raises
an issue about the type of errors likely to occur in the system.
These can be neatly categorized as either false positive, false
negative, or subversion errors.
A false positive occurs when the system classifies
an action as anomalous (a possible intrusion) when it is a legitimate
action. A false negative occurs when an actual intrusive action
has occurred but the system allows it to pass as non-intrusive behavior.
A subversion error occurs when an intruder modifies the operation
of the intrusion detector to force false negatives to occur.
False positive errors will lead users of the intrusion detection
system to ignore its output, as it will classify legitimate actions
as intrusions. The occurrences of this type of error should be minimized
(it may not be possible to completely eliminate them) so as to provide
useful information to the operators. If too many false positives
are generated, the operators will come to ignore the output of the
system over time, which may lead to an actual intrusion being detected
but ignored by the users.
A false negative error occurs when an action proceeds even though
it is an intrusion. False negative errors are more serious than
false positive errors because they give a misleading sense of security.
By allowing all actions to proceed, a suspicious action will not
be brought to the attention of the operator. The intrusion detection
system is now a liability as the security of the system is less
than it was before the intrusion detector was installed.
Subversion errors are more complex and tie in with false negative
errors. An intruder could use knowledge about the internals of an
intrusion detection system to alter its operation, possibly allowing
anomalous behavior to proceed. The intruder could then violate the
system's operational security constraints. This may be discovered
by a human operator examining the logs from the intrusion detector,
but it would appear that the intrusion detection system still seems
to be working correctly.
Another form of subversion error is fooling the system over time.
As the detection system is observing behavior on the system over
time, it may be possible to carry out operations each of which when
taken individually pose no threat, but taken as an aggregate form
a threat to system integrity.
How would this happen? As mentioned previously, the detection system
is continually updating its notion of normal system usage. As time
goes by a change in system usage patterns is expected, and the detection
system must cope with this. But if an intruder could perform actions
over time which were just slightly outside of normal system usage,
then it is possible that the actions could be accepted as legitimate
where as they really form part of an intrusion attempt. The detection
system would have come to accept each of the individual actions
as slightly suspicious, but not a threat to the system. What it
would not realize is that the combination of these actions would
form a serious threat to the system.
Acquiring
and Deploying Intrusion Detection Systems from NIST
Careful planning, phased deployments, and specialized training are
among the steps that can be taken to minimize the potential for
costly deployments, poor returns on investment, or high maintenance
costs while maximizing the security benefit to an organization.
|
 |
 |
