NIST releases 51 page Special Publication on Intrusion Detection Systems

NIST has released a 51 page comprehensive report on Intrusion Detection Systems. Intrusion detection systems (IDSs) are software or hardware systems that automate the process of monitoring the events occurring in a computer system or network, analyzing them for signs of security problems. As network attacks have increased in number and severity over the past few years, intrusion detection systems have become a necessary addition to the security infrastructure of most organizations.

This guidance document is intended as a primer in intrusion detection, developed for those who need to understand what security goals intrusion detection mechanisms serve, how to select and configure intrusion detection systems for their specific system and network environments, how to manage the output of intrusion detection systems, and how to integrate intrusion detection functions with the rest of the organizational security infrastructure. References to other information sources are also provided for the reader who requires specialized or more detailed advice on specific intrusion detection issues.....

19 August 2001
Source:

Click here to DOWNLOAD the .pdf document from NIST (852kb) or

Click here to read the full document online at Cryptome.org

Here is a sample of the first pages of this document

[Released by NIST on 16 August 2001; 51 pages]

NIST Special Publication on Intrusion Detection Systems

Intrusion Detection Systems

Rebecca Bace1 and Peter Mell2

__________________

1 Infidel, Inc., Scotts Valley, CA
2 National Institute of Standards and Technology

Intrusion Detection Systems

NIST Special Publication on Intrusion Detection Systems

1. Introduction

2. Overview of Intrusion Detection Systems

2.1. What is intrusion detection?
2.2. Why should I use Intrusion Detection Systems

2.2.1. Preventing problems by increasing the perceived risk of discovery
and punishment of attackers
2.2.2. Detecting problems that are not prevented by other security measures
2.2.3. Detecting the preambles to attacks (often experienced as network probes
and other tests for existing vulnerabilities)
2.2.4. Documenting the existing threat
2.2.5. Quality control for security design and administration
2.2.6. Providing useful information about actual intrusions

2.3. Major types of IDSs

2.3.1. Process model for Intrusion Detection
2.3.2. How do I distinguish between different Intrusion Detection
approaches?
2.3.3. Architecture
2.3.4. Goals
2.3.5. Control Strategy
2.3.6. Timing
2.3.7. Information Sources
2.3.8. IDS Analysis
2.3.9. Response Options for IDSs

2.4. Tools that Complement IDSs

2.4.1. Vulnerability Analysis or Assessment Systems
2.4.2. File Integrity Checkers
2.4.3. Honey Pot and Padded Cell Systems

3. Advice on selecting IDS products

3.1. Technical and Policy Considerations

3.1.1. What is your system environment?
3.1.2. What are your security goals and objectives?
3.1.3. What is your existing security policy?

3.2. Organizational Requirements and Constraints

3.2.1. What are requirements that are levied from outside the organization?
3.2.2. What are your organization's resource constraints?

3.3. IDS Product Features and Quality

3.3.1. Is the product sufficiently scalable for your environment?
3.3.2. How has the product been tested?
3.3.3. What is the user level of expertise targeted by the product?
3.3.4. Is the product designed to evolve as the organization grows?
3.3.5. What are the support provisions for the product?

4. Deploying IDSs

4.1. Deployment strategy for IDSs
4.2. Deploying Network-Based IDSs

4.2.1. Location: Behind each external firewall, in the network DMZ
4.2.2. Location: Outside an external firewall
4.2.3. Location: On major network backbones
4.2.4. Location: On critical subnets

4.3. Deploying Host-Based IDSs
4.4. Alarm strategies

5. Strengths and Limitations of IDSs

5.1. Strengths of Intrusion Detection Systems
5.2. Limitations of Intrusion Detection System

6. Advice on dealing with IDS output

6.1. Typical IDS Output
6.2. Handling Attacks

7. Computer Attacks and Vulnerabilities

7.1. Attack Types
7.2. Types of Computer Attacks Commonly Detected by IDSs

7.2.1. Scanning Attack
7.2.2. Denial of Service Attacks
7.2.3. Penetration Attacks
7.2.4. Remote vs. Local Attacks
7.2.5. Determining Attacker Location from IDS Output
7.2.6. IDSs and Excessive Attack Reporting

7.3. Types of Computer Vulnerabilities

7.3.1. Input Validation Error:
7.3.2. Access Validation Error:
7.3.3. Exceptional Condition Handling Error:
7.3.4. Environmental Error:
7.3.5. Configuration Error:
7.3.6. Race Condition:

8. The Future of IDSs

9. Conclusion

Appendix A - Frequently Asked Questions about IDSs

Appendix B - IDS resources

Intrusion Detection Systems

Rebecca Bace3, Peter Mell4

1. Introduction

Intrusion detection systems (IDSs) are software or hardware systems that
automate the process of monitoring the events occurring in a computer system
or network, analyzing them for signs of security problems. As network attacks
have increased in number and severity over the past few years, intrusion
detection systems have become a necessary addition to the security infrastructure
of most organizations. This guidance document is intended as a primer in
intrusion detection, developed for those who need to understand what security
goals intrusion detection mechanisms serve, how to select and configure intrusion
detection systems for their specific system and network environments, how
to manage the output of intrusion detection systems, and how to integrate
intrusion detection functions with the rest of the organizational security
infrastructure. References to other information sources are also provided
for the reader who requires specialized or more detailed advice on specific
intrusion detection issues.

___________________

3 Infidel, Inc., Scotts Valley, CA
4 National Institute of Standards and Technology

2. Overview of Intrusion Detection Systems

2.1. What is intrusion detection?

Intrusion detection is the process of monitoring the events occurring in
a computer system or network and analyzing them for signs of
intrusions, defined as attempts to compromise the confidentiality,
integrity, availability, or to bypass the security mechanisms of a computer
or network. Intrusions are caused by attackers accessing the systems from
the Internet, authorized users of the systems who attempt to gain additional
privileges for which they are not authorized, and authorized users who misuse
the privileges given them. Intrusion Detection Systems (IDSs) are software
or hardware products that automate this monitoring and analysis process.
2.2. Why should I use Intrusion Detection Systems?

Intrusion detection allows organizations to protect their systems from the
threats that come with increasing network connectivity and reliance on
information systems. Given the level and nature of modem network security
threats, the question for security professionals should not be whether
to use intrusion detection, but which intrusion detection features
and capabilities to use.

IDSs have gained acceptance as a necessary addition to every organization's
security infrastructure. Despite the documented contributions intrusion detection
technologies make to system security, in many organizations one must still
justify the acquisition of IDSs. There are several compelling reasons to
acquire and use IDSs:

1. To prevent problem behaviors by increasing the perceived risk of discovery
and punishment for those who would attack or otherwise abuse the system,

2. To detect attacks and other security violations that are not prevented
by other security measures,

3. To detect and deal with the preambles to attacks (commonly experienced
as network probes and other "doorknob rattling" activities),

4. To document the existing threat to an organization

5. To act as quality control for security design and administration, especially
of large and complex enterprises

6. To provide useful information about intrusions that do take place, allowing
improved diagnosis, recovery, and correction of causative factors.

2.2.1. Preventing problems by increasing the perceived risk of discovery
and punishment of attackers

A fundamental goal of computer security management is to affect the behavior
of individual users in a way that protects information systems from security
problems. Intrusion detection systems help organizations accomplish this
goal by increasing the perceived risk of discovery and punishment of attackers.
This serves as a significant deterrent to those who would violate security
policy.

2.2.2. Detecting problems that are not prevented by other security
measures

Attackers, using widely publicized techniques, can gain unauthorized access
to many, if not most systems, especially those connected to public networks.
This often happens when known vulnerabilities in the systems are not corrected.

Although vendors and administrators are encouraged to address vulnerabilities
(e.g. through public services such as ICAT,
http://icat.nist.gov) lest they enable
attacks, there are many situations in which this is not possible:

• In many legacy systems, the operating systems cannot be patched or updated.

• Even in systems in which patches can be applied, administrators sometimes
  have neither sufficient time nor resource to track and install all the necessary
  patches. This is a common problem, especially in environments that include
  a large number of hosts or a wide range of different hardware or software
  environments.

• Users can have compelling operational requirements for network services and
  protocols that are known to be vulnerable to attack.

• Both users and administrators make errors in configuring and using systems.

• In configuring system access control mechanisms to reflect an organization's
  procedural computer use policy, discrepancies almost always occur. These
  disparities allow legitimate users to perform actions that are ill advised
  or that overstep their authorization.

In an ideal world, commercial software vendors would minimize vulnerabilities
in their products, and user organizations would correct all reported
vulnerabilities quickly and reliably. However, in the real world, this seldom
happens thanks to our reliance on commercial software where new flaws and
vulnerabilities are discovered on a daily basis.

Given this state of affairs, intrusion detection can represent an excellent
approach to protecting a system. An IDS can detect when an attacker has
penetrated a system by exploiting an uncorrected or uncorrectable flaw.
Furthermore, it can serve an important function in system protection, by
bringing the fact that the system has been attacked to the attention of the
administrators who can contain and recover any damage that results. This
is far preferable to simply ignoring network security threats where one allows
the attackers continued access to systems and the information on them.

2.2.3. Detecting the preambles to attacks (often experienced as network
probes and other tests for existing vulnerabilities)

When adversaries attack a system, they typically do so in predictable stages.
The first stage of an attack is usually probing or examining a system or
network, searching for an optimal point of entry. In systems with no IDS,
the attacker is free to thoroughly examine the system with little risk of
discovery or retribution. Given this unfettered access, a determined attacker
will eventually find a vulnerability in such a network and exploit it to
gain entry to various systems.

The same network with an IDS monitoring its operations presents a much more
formidable challenge to that attacker. Although the attacker may probe the
network for weaknesses, the IDS will observe the probes, will identify them
as suspicious, may actively block the attacker's access to the target system,
and will alert security personnel who can then take appropriate actions to
block subsequent access by the attacker. Even the presence of a reaction
to the attacker's probing of the network will elevate the level of risk the
attacker perceives, discouraging further attempts to target the network.

2.2.4. Documenting the existing threat

When you are drawing up a budget for network security, it often helps to
substantiate claims that the network is likely to be attacked or is even
currently under attack. Furthermore, understanding the frequency and
characteristics of attacks allows you to understand what security measures
are appropriate to protect the network against those attacks.

IDSs verify, itemize, and characterize the threat from both outside and inside
your organization's network, assisting you in making sound decisions regarding
your allocation of computer security resources. Using IDSs in this manner
is important, as many people mistakenly deny that anyone (outsider or insider)
would be interested in breaking into their networks. Furthermore, the information
that IDSs give you regarding the source and nature of attacks allows you
to make decisions regarding security strategy driven by demonstrated need,
not guesswork or folklore.

2.2.5. Quality control for security design and administration

When IDSs run over a period of time, patterns of system usage and detected
problems can become apparent. These can highlight flaws in the design and
management of security for the system, in a fashion that supports security
management correcting those deficiencies before they cause an incident.

2.2.6. Providing useful information about actual intrusions

Even when IDSs are not able to block attacks, they can still collect relevant,
detailed, and trustworthy information about the attack that supports incident
handling and recovery efforts. Furthermore, this information can, under certain
circumstances, enable and support criminal or civil legal remedies. Ultimately,
such information can identify problem areas in the organization's security
configuration or policy.

2.3. Major types of IDSs

There are several types of IDSs available today, characterized by different
monitoring and analysis approaches. Each approach has distinct advantages
and disadvantages. Furthermore, all approaches can be described in terms
of a generic process model for IDSs.

2.3.1. Process model for Intrusion Detection

Many IDSs can be described in terms of three fundamental functional
components:

• Information Sources - the different sources of event information used
  to determine whether an intrusion has taken place. These sources can be drawn
  from different levels of the system, with network, host, and application
  monitoring most common.

• Analysis - the part of intrusion detection systems that actually organizes
  and makes sense of the events derived from the information sources, deciding
  when those events indicate that intrusions are occurring or have already
  taken place. The most common analysis approaches are misuse detection and
  anomaly detection.

• Response - the set of actions that the system takes once it detects
  intrusions. These are typically grouped into active and passive measures,
  with active measures involving some automated intervention on the part of
  the system, and passive measures involving reporting IDS findings to humans,
  who are then expected to take action based on those reports.

2.3.2. How do I distinguish between different Intrusion Detection
approaches?

There are several design approaches used in Intrusion Detection. These drive
the features provided by a specific IDS and determine the detection capabilities
for that system. For those who must evaluate different IDS candidates for
a given system environment, these approaches can help them determine what
goals are best addressed by each IDS.

2.3.3. Architecture

The architecture of an IDS refers to how the functional components of the
IDS are arranged with respect to each other. The primary architectural components
are the Host, the system on which the IDS software runs, and the Target,
the system that the IDS is monitoring for problems.

2.3.3.1. Host-Target Co-location

In early days of IDSs, most IDSs ran on the systems they protected. This
was due to the fact that most systems were mainframe systems, and the cost
of computers made a separate IDS system a costly extravagance. This presented
a problem from a security point of view, as any attacker that successfully
attacked the target system could simply disable the IDS as an integral portion
of the attack.

2.3.3.2. Host-Target Separation

With the advent of workstations and personal computers, most IDS architects
moved towards running the IDS control and analysis systems on a separate
system, hence separating the IDS host and target systems. This improved the
security of the IDS as this made it much easier to hide the existence of
the IDS from attackers.

2.3.4. Goals

Although there are many goals associated with security mechanisms in general,
there are two overarching goals usually stated for intrusion detection systems.

2.3.4.1. Accountability

Accountability is the capability to link a given activity or event back to
the party responsible for initiating it. This is essential in cases where
one wishes to bring criminal charges against an attacker. The goal statement
associated with accountability is: "I can deal with security attacks that
occur on my systems as long as I know who did it (and where to find them.)"
Accountability is difficult in TCP/IP networks, where the protocols allow
attackers to forge the identity of source addresses or other source identifiers.
It is also extremely difficult to enforce accountability in any system that
employs weak identification and authentication mechanisms.

2.3.4.2. Response

Response is the capability to recognize a given activity or event as an attack
and then taking action to block or otherwise affect its ultimate goal. The
goal statement associated with response is "I don't care who attacks my
system as long as I can recognize that the attack is taking place and block
it." Note that the requirements of detection are quite different for
response than for accountability.

2.3.5. Control Strategy

Control Strategy describes how the elements of an IDS is controlled, and
furthermore, how the input and output of the IDS is managed.

2.3.5.1. Centralized (Figure 1)

Under centralized control strategies, all monitoring, detection and reporting
is controlled directly from a central location

Figure 1: Centralized Control

2.3.5.2. Partially Distributed (Figure 2)

Monitoring and detection is controlled from a local control node, with
hierarchical reporting to one or more central location(s).

Figure 2: Distributed Control Strategy

2.3.5.3. Fully Distributed (Figure3)

Monitoring and detection is done using an agent-based approach, where response
decisions are made at the point of analysis.

Figure 3: Fully Distributed (Agent-Based) Control

2.3.6. Timing

Timing refers to the elapsed time between the events that are monitored and
the analysis of those events.

2.3.6.1. Interval-Based (Batch Mode)

In interval-based IDSs, the information flow from monitoring points to analysis
engines is not continuous. In effect, the information is handled in a fashion
similar to "store and forward" communications schemes. Many early host-based
IDSs used this timing scheme, as they relied on operating system audit trails,
which were generated as files. Interval-based IDSs are precluded from performing
active responses.

2.3.6.2. Real-Time(Continuous)

Real-time IDSs operate on continuous information feeds from information sources.
This is the predominant timing scheme for network-based IDSs, which gather
information from network traffic streams. In this document, we use the term
"real-time" as it is used in process control situations. This means that
detection performed by a "real-time" IDS yields results quickly enough to
allow the IDS to take action that affects the progress of the detected attack.

2.3.7. Information Sources

The most common way to classify IDSs is to group them by information source.
Some IDSs analyze network packets, captured from network backbones or LAN
segments, to find attackers. Other IDSs analyze information sources generated
by the operating system or application software for signs of intrusion

2.3.7.1. Network-Based IDSs

The majority of commercial intrusion detection systems are network-based.
These IDSs detect attacks by capturing and analyzing network packets. Listening
on a network segment or switch, one network-based IDS can monitor the network
traffic affecting multiple hosts that are connected to the network segment,
thereby protecting those hosts.

Network-based IDSs often consist of a set of single-purpose sensors or hosts
placed at various points in a network. These units monitor network traffic,
performing local analysis of that traffic and reporting attacks to a central
management console. As the sensors are limited to running the IDS, they can
be more easily secured against attack. Many of these sensors are designed
to run in "stealth" mode, in order to make it more difficult for an attacker
to determine their presence and location.

Advantages of Network-Based IDSs:

• A few well-placed network-based IDSs can monitor a large network.

• The deployment of network-based IDSs has little impact upon an existing network.
  Network-based IDSs are usually passive devices that listen on a network wire
  without interfering with the normal operation of a network. Thus, it is usually
  easy to retrofit a network to include network-based IDSs with minimal effort.

• Network-based IDSs can be made very secure against attack and even made invisible
  to many attackers.

Disadvantages of Network-Based IDSs:

• Network-based IDSs may have difficulty processing all packets in a large
  or busy network and, therefore, may fail to recognize an attack launched
  during periods of high traffic. Some vendors are attempting to solve this
  problem by implementing IDSs completely in hardware, which is much faster.
  The need to analyze packets quickly also forces vendors to both detect fewer
  attacks and also detect attacks with as little computing resource as possible
  which can reduce detection effectiveness.

• Many of the advantages of network-based IDSs don't apply to more modem
  switch-based networks. Switches subdivide networks into many small segments
  (usually one fast Ethernet wire per host) and provide dedicated links between
  hosts serviced by the same switch. Most switches do not provide universal
  monitoring ports and this limits the monitoring range of a network-based
  IDS sensor to a single host. Even when switches provide such monitoring ports,
  often the single port cannot mirror all traffic traversing the switch.

• Network-based IDSs cannot analyze encrypted information. This problem is
  increasing as more organizations (and attackers) use virtual private networks.

• Most network-based IDSs cannot tell whether or not an attack was successful;
  they can only discern that an attack was initiated. This means that after
  a network-based IDS detects an attack, administrators must manually investigate
  each attacked host to determine whether it was indeed penetrated.

• Some network-based IDSs have problems dealing with network-based attacks
  that involve fragmenting packets. These malformed packets cause the IDSs
  to become unstable and crash.

2.3.7.2. Host-Based IDSs

Host-based IDSs operate on information collected from within an individual
computer system. (Note that application-based IDSs are actually a subset
of host-based IDSs.) This vantage point allows host-based IDSs to analyze
activities with great reliability and precision, determining exactly which
processes and users are involved in a particular attack on the operating
system. Furthermore, unlike network-based IDSs, host-based IDSs can "see"
the outcome of an attempted attack, as they can directly access and monitor
the data files and system processes usually targeted by attacks.

Host-based IDSs normally utilize information sources of two types, operating
system audit trails, and system logs. Operating system audit trails are usually
generated at the innermost (kernel) level of the operating system, and are
therefore more detailed and better protected than system logs. However, system
logs are much less obtuse and much smaller than audit trails, and are furthermore
far easier to comprehend. Some host-based IDSs are designed to support a
centralized IDS management and reporting infrastructure that can allow a
single management console to track many hosts. Others generate messages in
formats that are compatible with network management systems.

Advantages:

• Host-based IDSs, with their ability to monitor events local to a host, can
  detect attacks that cannot be seen by a network-based IDS.

• Host-based IDSs can often operate in an environment in which network traffic
  is encrypted, when the host-based information sources are generated before
  data is encrypted and/or after the data is decrypted at the destination host

• Host-based IDSs are unaffected by switched networks.

• When Host-based IDSs operate on OS audit trails, they can help detect Trojan
  Horse or other attacks that involve software integrity breaches. These appear
  as inconsistencies in process execution.

Disadvantages:

• Host-based IDSs are harder to manage, as information must be configured and
  managed for every host monitored.

• Since at least the information sources (and sometimes part of the analysis
  engines) for host-based IDSs reside on the host targeted by attacks, the
  IDS may be attacked and disabled as part of the attack.

• Host-based IDSs are not well suited for detecting network scans or other
  such surveillance that targets an entire network, because the IDS only sees
  those network packets received by its host.

• Host-based IDSs can be disabled by certain denial-of-service attacks.

• When host-based IDSs use operating system audit trails as an information
  source, the amount of information can be immense, requiring additional local
  storage on the system.

• Host-based IDSs use the computing resources of the hosts they are monitoring,
  therefore inflicting a performance cost on the monitored systems.

2.3.7.3. Application-Based IDSs

Application-based IDSs are a special subset of host-based IDSs that analyze
the events transpiring within a software application. The most common information
sources used by application-based IDSs are the application's transaction
log files.

The ability to interface with the application directly, with significant
domain or application-specific knowledge included in the analysis engine,
allows application-based IDSs to detect suspicious behavior due to authorized
users exceeding their authorization. This is because such problems are more
likely to appear in the interaction between the user, the data, and the
application.

Advantages:

• Application-based IDSs can monitor the interaction between user and application,
  which often allows them to trace unauthorized activity to individual users.

• Application-based IDSs can often work in encrypted environments, since they
  interface with the application at transaction endpoints, where information
  is presented to users in unencrypted form.

Disadvantages:

• Application-based IDSs may be more vulnerable than host-based IDSs to attacks
  as the applications logs are not as well-protected as the operating system
  audit trails used for host-based IDSs.

• As Application-based IDSs often monitor events at the user level of abstraction,
  they usually cannot detect Trojan Horse or other such software tampering
  attacks. Therefore, it is advisable to use an Application-based IDS in
  combination with Host-based and/or Network-based IDSs.

2.3.8. IDS Analysis

There are two primary approaches to analyzing events to detect attacks: misuse
detection and anomaly detection. Misuse detection, in which the analysis
targets something known to be "bad", is the technique used by most commercial
systems. Anomaly detection, in which the analysis looks for abnormal patterns
of activity, has been, and continues to be, the subject of a great deal of
research. Anomaly detection is used in limited form by a number of IDSs.
There are strengths and weaknesses associated with each approach, and it
appears that the most effective IDSs use mostly misuse detection methods
with a smattering of anomaly detection components.

2.3.8.1. Misuse Detection

Misuse detectors analyze system activity, looking for events or sets of events
that match a predefined pattern of events that describe a known attack. As
the patterns corresponding to known attacks are called signatures, misuse
detection is sometimes called "signature-based detection." The most common
form of misuse detection used in commercial products specifies each pattern
of events corresponding to an attack as a separate signature. However, there
are more sophisticated approaches to doing misuse detection (called "state-based"
analysis techniques) that can leverage a single signature to detect groups
of attacks.

Advantages:

• Misuse detectors are very effective at detecting attacks without generating
  an overwhelming number of false alarms.

• Misuse detectors can quickly and reliably diagnose the use of a specific
  attack tool or technique. This can help security managers prioritize corrective
  measures.

• Misuse detectors can allow system managers, regardless of their level of
  security expertise, to track security problems on their systems, initiating
  incident handling procedures.

Disadvantages:

• Misuse detectors can only detect those attacks they know about - therefore
  they must be constantly updated with signatures of new attacks.

• Many misuse detectors are designed to use tightly defined signatures that
  prevent them from detecting variants of common attacks. State-based misuse
  detectors can overcome this limitation, but are not commonly used in commercial
  IDSs.

2.3.8.2. Anomaly Detection

Anomaly detectors identify abnormal unusual behavior (anomalies) on a host
or network. They function on the assumption that attacks are different from
"normal" (legitimate) activity and can therefore be detected by systems that
identify these differences. Anomaly detectors construct profiles representing
normal behavior of users, hosts, or network connections. These profiles are
constructed from historical data collected over a period of normal operation.
The detectors then collect event data and use a variety of measures to determine
when monitored activity deviates from the norm.

The measures and techniques used in anomaly detection include:

• Threshold detection, in which certain attributes of user and system behavior
  are expressed in terms of counts, with some level established as permissible.
  Such behavior attributes can include the number of files accessed by a user
  in a given period of time, the number of failed attempts to login to the
  system, the amount of CPU utilized by a process, etc. This level can be static
  or heuristic (i.e., designed to change with actual values observed over time)

• Statistical measures, both parametric, where the distribution of the profiled
  attributes is assumed to fit a particular pattern, and non-parametric, where
  the distribution of the profiled attributes is "teamed" from a set of historical
  values, observed over time.

• Rule-based measures, which are similar to non-parametric statistical measures
  in that observed data defines acceptable usage patterns, but differs in that
  those patterns are specified as rules, not numeric quantities

• Other measures, including neural networks, genetic algorithms, and immune
  system models.

Only the first two measures are used in current commercial IDSs.

Unfortunately, anomaly detectors and the IDSs based on them often produce
a large number of false alarms, as normal patterns of user and system behavior
can vary wildly. Despite this shortcoming, researchers assert that anomaly-based
IDSs are able to detect new attack forms, unlike signature-based IDSs that
rely on matching patterns of past attacks.

Furthermore, some forms of anomaly detection produce output that can in turn
be used as information sources for misuse detectors. For example, a
threshold-based anomaly detector can generate a figure representing the "normal"
number of files accessed by a particular user; the misuse detector can use
this figure as part of a detection signature that says "if the number of
files accessed by this user exceeds this "normal" figure by ten percent,
trigger an alarm."

Although some commercial IDSs include limited forms of anomaly detection,
few, if any, rely solely on this technology.The anomaly detection that exists
in commercial systems usually revolves around detecting network or port scanning.
However, anomaly detection remains an active intrusion detection research
area and may play a greater part in future IDSs.

Advantages:

• IDSs based on anomaly detection detect unusual behavior and thus have the
  ability to detect symptoms of attacks without specific knowledge of details.

• Anomaly detectors can produce information that can in turn be used to define
  signatures for misuse detectors.

Disadvantages:

• Anomaly detection approaches usually produce a large number of false alarms
  due to the unpredictable behaviors of users and networks.

• Anomaly detection approaches often require extensive "training sets" of system
  event records in order to characterize normal behavior patterns.

2.3.9. Response Options for IDSs

Once IDSs have obtained event information and analyzed it to find symptoms
of attacks, they generate responses. Some of these responses involve reporting
results and findings to a pre-specified location. Others involve more active
automated responses. Though researchers are tempted to underrate the importance
of good response functions in IDSs, they are actually very important. Commercial
IDSs support a wide range of response options, often categorized as active
responses, passive responses, or some mixture of the two.

2.3.9.1. Active Responses

Active IDS responses are automated actions taken when certain types of intrusions
are detected. There are three categories of active responses.

Collect additional information

The most innocuous, but at times most productive, active response is to collect
additional information about a suspected attack. Each of us have probably
done the equivalent of this when awakened by a strange noise at night. The
first thing one does in such a situation is to listen more closely, searching
for additional information that allows you to decide whether you should take
action.

In the IDS case, this might involve increasing the level of sensitivity A
information sources (for instance, turning up the number of events logged
by an operating system audit trail, or increasing the sensitivity of a network
monitor to capture all packets, not just those targeting a particular port
or target system.) Collecting additional information is helpful for several
reasons. The additional information collected can help resolve the detection
of the attack (assisting the system in diagnosing whether an attack did or
did not take place). This option also allows the organization to gather
information that can be used to support investigation and apprehension of
the attacker, and to support criminal and civil legal remedies.

Change the Environment

Another active response is to halt an attack in progress and then block
subsequent access by the attacker. Typically, IDSs do not have the ability
to block a specific person's access, but instead block Internet Protocol
(IP) addresses from which the attacker appears to be coming. It is very difficult
to block a determined and knowledgeable attacker, but IDSs can often deter
expert attackers or stop novice attackers by taking the following actions:

• Injecting TCP reset packets into the attacker's connection to the victim
  system, thereby terminating the connection,

• Reconfiguring routers and firewalls to block packets from the attacker's
  apparent location (IP address or site),

• Reconfiguring routers and firewalls to block the network ports, protocols,
  or services being used by an attacker, and

• In extreme situations, reconfiguring routers and firewalls to sever all
  connections that use certain network interfaces.

Take Action Against the Intruder

Some who follow intrusion detection discussions, especially in information
warfare circles, believe that the first option in active response is to take
action against the intruder. The most aggressive form of this response involves
launching attacks against or attempting to actively gain information about
the attacker's host or site. However tempting it might be, this response
is ill advised. Due to legal ambiguities about civil liability, this option
can represent a greater risk than the attack it is intended to block.

The first reason for approaching this option with a great deal of caution
is that it may be illegal. Furthermore, as many attackers use false network
addresses when attacking systems, it carries with it a high risk of causing
damage to innocent Internet sites and users. Finally, strike back can escalate
the attack, provoking an attacker who originally intended only to browse
a site to take more aggressive action.

Should an active intervention and traceback of this sort be warranted (as
in the case of a critical system) human control and supervision of the process
is advisable. We strongly recommend that you obtain legal advice before pursuing
any of these "strike-back" options.

Click here to DOWNLOAD the .pdf document from NIST (852kb) or

Click here to read the full document online at Cryptome.org