1. technology and computing
2. computer security
3. network security

84-10-28
DATA SECURITY MANAGEMENT
INTRUSION DETECTION:
HOW TO UTILIZE A STILL
IMMATURE TECHNOLOGY
Eugene Schultz and Eugene Spafford
INSIDE
What Is Intrusion Detection? Why Use Intrusion Detection? How IDSs Work;
Approaches to Intrusion Detection; Advantages and Limitations of Intrusion Detection Technology;
Assessing Intrusion Detection Requirements; Developing an Intrusion Detection Architecture
INTRODUCTION
Defending one’s systems and networks is an arduous task indeed. The
explosive growth of the Internet, combined with the ever-expanding nature of networks in and of itself, makes simply keeping track of change
nearly an overwhelming challenge. Add the task of implementing proper
security-related controls and the problem becomes of far greater magnitude than even the most visionary experts could have predicted 20 years
ago. Although victories here and there in the war against cybercriminals
occur, reality echos the irrefutable truth that “cyberspace” is simply too
big a territory to adequately defend.
Worse yet, security-related controls
PAYOFF IDEA
that work today will in all likelihood
If your organization does not currently use intrufail tomorrow as the perpetrator
sion detection technology, it is badly behind the
community develops new ways to
intrusion detection “power curve.” Furthermore,
an organization that buys, then rolls out, a new
defeat these controls. As well, the
IDS product is by no means ready to reap the bencontinuing rush to market software
efits immediately. A definite, steep learning curve
with more new features is resulting
for using intrusion detection technology exists.
in poorly designed and poorly tested
Even if you start deploying this technology now, it
takes time to assimilate the mentality of intrusion
software being deployed in critical
detection and the technology associated with it
situations. Thus, the usual installainto an organization’s culture. It is important,
tion is based on poorly designed,
therefore, to become familiar with and start using
buggy software that is being used in
this technology as soon as possible to avoid fallways unanticipated by the original
ing behind even further. The alternative is to continue to function as the proverbial ostrich with its
designers, and that is under continuhead beneath the sand.
ing attack from all over.
10/99
Auerbach Publications
© 1999 CRC Press LLC
Schultz and Wack1 have argued that InfoSec professionals need to
avoid relying on an approach that is overly reliant on security-related
controls. Determining from a cost-benefit perspective the controls that
most effectively reduce risk, then implementing and maintaining those
controls is an essential part of the risk management process. Investing all
of one’s resources in controls is, however, not wise because this strategy
does not leave resources for detecting and responding to the security-related incidents that invariably occur. The so-called “fortress mentality”
(implementing security barrier after security barrier but doing nothing
else) in the InfoSec arena does not work any better than did castles in
the United Kingdom when Oliver Cromwell’s armies aimed their cannons
at them. It is far better to employ a layered, defense-in-depth strategy that
includes protection, monitoring, and response.2,3
Merely accepting the viewpoint that it is important to achieve some
degree of balance between deploying controls and responding to incidents that occur, unfortunately, does little to improve the effectiveness of
an organization’s InfoSec practice. An inherent danger in the incident response arena is the implicit assumption that if no incidents surface, all is
well. Superficially, this assumption seems logical. Studies by the U.S. Defense Information Systems Agency (DISA) in 1993 and again in 1997,
however, provide statistics that prove it is badly flawed. Van Wyk4 found
that of nearly 8800 intrusions into Department of Defense systems by a
DISA tiger team, only about one in six was detected. Of the detected intrusions, approximately only 4 percent were reported to someone in the
chain of command. This meant that of all successful attacks, less than 1
percent were both noticed and reported. A similar study by the same
agency three years later produced nearly identical results.
One could perhaps argue that perhaps many Department of Defense
personnel do not possess as high a level of technical knowledge as do
their counterparts in industry because industry (with its traditionally higher
salaries) can attract top technical personnel who might more readily be
able to recognize the symptoms of attacks. In industry, therefore, according to this line of reasoning, it would be much more likely that some technical “guru” would notice intrusions that occurred. This reasoning is at best
only partially true, however, in that in the DISA studies little attempt was
made to cover up the intrusions in the first place. In what might be called
“more typical” intrusions, in contrast, attackers typically devote a large portion of their efforts to masquerade the activity they have initiated to avoid
being noticed. This is further supported by the latest CSI/FBI survey5 that
indicated that many firms are unable to determine the number or nature of
intrusions and losses to their enterprise from IT system attacks, but that
losses and number of incidents are continuing to increase.
The main point here is that effective incident response is important
and necessary, but it hardly does any good if people do not notice incidents that occur in the first place. Human efforts to notice incidents, as
© 1999 CRC Press LLC
10/99
good as they may be, are in many if not most operational settings inadequate. InfoSec professionals often need something more: an automated
capability that enables them to be able to discover incidents that are attempted or actually succeed. The solution is intrusion detection. This article covers the topic of intrusion detection, covering what it is, the types
of requirements that apply to intrusion detection systems (ISDs), and
ways that intrusion detection systems can be deployed.
WHAT IS INTRUSION DETECTION?
Intrusion detection refers to the process of discovering unauthorized use
of computers and networks through the use of software designed for this
purpose. Intrusion detection software in effect serves a vigilance function. An effective intrusion detection system both discovers and reports
unauthorized activity, such as log-on attempts by someone who is not
the legitimate user or an account, and unauthorized transfer of files to another system. Intrusion detection can also serve a role of helping to document the (attempt at) misuse so as to provide data for strengthening
defenses, or for investigation and prosecution after the fact.
Intrusion detection is misnamed. As a field, it originally started as a
form of misuse detection for mainframe systems. The original idea behind automated intrusion detection systems is often credited to James P.
Anderson for his 1980 paper on how to use accounting audit files to detect inappropriate use. Over time, systems have become more connected
via networks; attention has shifted to penetration of systems by “outsiders,” thus including detection of “intrusion” as a goal. This discussion will
use the common meaning of “intrusion detection” to include detection of
both outsider misuse and insider misuse; users of ID systems should likewise keep in mind that insider misuse must also be detected.
Why Utilize Intrusion Detection?
One possible approach to intrusion detection would be to deploy thousands of specially trained personnel to continuously monitor systems and
networks. This approach would in almost every setting be impossible to
implement because it would be impractical. Few organizations would be
willing to invest the necessary level of resources and the time required to
train each “monitor” to obtain the needed level of technical expertise.
Running one or more automated programs designed to effectively do the
same thing, but without the involvement of thousands of people, is a
more logical approach, provided of course that the program yields acceptable results in detecting unauthorized activity.
Additionally, although many people with high levels of technical expertise could be deployed in such a monitoring role, it may not be desirable to do so from another perspective. Even the most elite among the
experts might miss certain types of unauthorized actions given the typically gargantuan volume of activity that occurs within today’s systems
© 1999 CRC Press LLC
10/99
and networks. A suitable intrusion detection program could thus uncover
activity that experts miss.
Detection per se is not, however, the only purpose of intrusion detection. Another very important reason to use IDSs is that they often provide
a reporting capability. Again, the worst-case scenario would be relying
on a substantial number of human beings to gather intrusion data when
each person uses a different format to record the data in addition to
terms and descriptions that are ambiguous to everyone but that person.
Trying to combine each observer’s data and descriptions to derive patterns and trends would be virtually impossible; making sense out of any
one observer’s data would at a minimum be very challenging.
An effective intrusion detection system provides a reporting capability
that not only produces human friendly information displays but also interfaces with a central database or other capability that allows efficient
storage, retrieval, and analysis of data.
How IDSs Work
IDSs work in a large variety of ways related to the type of data they capture, as well as the types of analysis they perform. At the most elementary level, a program that runs on one or more machines receives audit log
data from that machine. The program combs through each entry in the
audit logs for signs of unauthorized activity. This type of program is part
of a host or system-based IDS. At the other extreme, an IDS can be distributed in nature.6 Software (normally referred to as agent software) resides in one or more systems connected to a network. Manager software
in one particular server receives data from the agents it knows about and
analyzes the data.7 This second approach characterizes a network-based
IDS (see Exhibit 1).
Intrusion Detection Capability for Analysis
Note that if the data that each agent sends to the manager has not been
tampered with, the level of analysis possible is more powerful than with
host or system-based IDSs for several reasons:
1. Although a host-based IDS may not be dependent on audit data (if it
has its own data capturing service independent of auditing), audit
and other types of data produced within single systems are very subject to tampering or deletion. An attacker who disables auditing or an
intrusion data collection service on a given machine effectively disables that IDS that runs on that machine. This is not true, however,
in the case of a network-based IDS, which can gather data not only
from individual machines but also from passive devices (e.g., protocol analyzers) and other, more difficult to defeat machines such as
© 1999 CRC Press LLC
10/99
EXHIBIT 1 — A Depolyment of an IDS in Which Agent Software Running
on Hosts Sends Data to a Central Network
firewalls. In other words, network-based IDSs are not as dependent
on data from individual systems.
2. Network-based IDSs, furthermore, can utilize data that are not available in system-based IDSs.8 Consider, for example, an attacker who
logs on to one system as user “BROWN,” then logs on to another
system on the same network as “SMITH.” The manager software can
assign a net ID to each user, thus enabling it to know that the user
who has a log-on shell in both systems is the same user. This IDS can
then generate an alarm based on the fact that the user in this example has logged on to different accounts with different names. This
level of analysis is not possible if an IDS does not have data from
multiple machines on the net.
A third form of IDS, currently quite popular, involves one or more systems that observe network traffic (usually at a border location, such as
near a firewall), and scan for packet traffic that indicates misbehavior.
These “network intrusion detection systems” are easy to deploy to protect an enterprise from attack from the outside, but they have the drawback of missing internal behavior that may also be of interest.
APPROACHES TO INTRUSION DETECTION
Not only do different implementations of IDSs work using fundamentally
different kinds of data and analysis methods, but they also differ in the
types of approaches to intrusion detection that have been incorporated
© 1999 CRC Press LLC
10/99
into their design. The correct question here is not, “do you want to deploy an intrusion detection system (IDS)?, but rather, “which type of IDS
do you want to deploy?” The following are the major types of IDSs.
Anomaly Detection Systems
Anomaly detection systems are designed to discover anomalous behavior; that is, behavior that is unexpected and abnormal. At the most elementary level, anomaly detection systems look for use of a computer
system during a time of the day or night in which the legitimate user
hardly if ever uses the computer. Statistical profiles indicating percentiles
of measurable behavior and what falls within one standard deviation of
the norm, two standard deviations, etc., are often the basis for determining whether or not a given user action is anomalous. At a more sophisticated level, one might profile variables and processes such as types of
usage by each specific user. One user, for example, might access a server
mostly to read e-mail, another might balance usage time between e-mail
and using spreadsheet-based applications, and a third might mostly write
and compile programs. If the first user suddenly starts compiling programs, an anomaly detection system should flag this type of activity as
suspicious.
Misuse Detection Systems
The main focus of misuse detection systems is on symptoms of misuse
by authorized users. These symptoms include unauthorized log-ons or
bad log-on attempts to systems, in addition to abuse of services (e.g.,
Web-based services, file system mounts, etc.) in which users do not need
to authenticate themselves. In the latter case, therefore, good misuse detection systems will identify specific patterns (called signatures) of anomalous actions. If an anonymous FTP user, for example, repeatedly enters
cd …, cd …, cd … from a command line, there is a good chance that the
user is attempting a “dotdot” attack to reach a higher level directory than
FTP access is supposed to allow. It is very unlikely that a legitimate user
would repeatedly enter these keystrokes.
Target Monitoring Systems
Target monitoring systems represent a somewhat radical departure from
the previously discussed systems in that target monitoring systems do not
attempt to discover anomalies or misuse. Instead, they report whether
certain target objects have been changed; if so, an attack may have occurred. In UNIX systems, for example, attackers often change the
/sbin/login program (to cause a pseudo-login to occur in which the password of a user attempting to log in is captured and stored in a hidden
file) or the /etc/passwd file (which holds names of users, privilege levels,
© 1999 CRC Press LLC
10/99
etc.). In Windows NT systems, someone may change .DLL (dynamically
linked library) files to alter system behavior. Most target monitoring systems use a cryptographic algorithm to compute a cryptochecksum for
each target file. Then, if the cryptochecksum is calculated later in time
and the new cryptochecksum is different from the previous one, the IDS
will report the change. Although this type of IDS superficially does not
seem as sophisticated as the previous ones, it has several advantages
over anomaly and misuse detection systems, including:
1. When intruders break into systems, they frequently make changes
(sometimes accidentally, sometimes on purpose). Changed files, executables that are replaced with Trojan horse versions, etc., are therefore excellent potential indications that an attack has occurred.
2. Target monitoring systems are not based on statistical norms, signatures, and other indicators that may or may not be valid. These systems are, therefore, not as model dependent — they are instead
simple and straightforward. Furthermore, they do not really need to
be validated because the logic behind them is so obvious.
3. They do not have to be continuously run to be effective. All one has
to do is run a target monitoring program at one point in time, then
another. Target monitoring systems thus do not generally result in as
much performance overhead as do other types of IDSs.
Systems that Perform Wide-Area Correlation of Slow and “Stealth” Probes
Not every attack that occurs is an all-out attack. A fairly typical attack pattern is one in which intruders first probe remote systems and network
components such as routers for security-related vulnerabilities, and then
actually launch attacks later. If attackers were to launch a massive number of probes all at once the likelihood of noticing the activity would increase dramatically. Many times, therefore, attackers probe one system,
then another, then another at deliberately slow time interviews. The result is a substantial reduction in the probability that the probes will be
noticed. A fourth type of IDS performs wide-area collection of slow and
stealth probes to discover the type of attacks mentioned in this section.
MAJOR ADVANTAGES AND LIMITATIONS OF INTRUSION DETECTION TECHNOLOGY
Advantages
Intrusion detection is potentially one of the most powerful capabilities
that an InfoSec practice can deploy. Much of attackers’ ability to perpetrate computer crime and misuse depends on their ability to escape being noticed until it is too late. The implications of the DISA statistics
cited earlier are potentially terrifying; in the light of these findings, it
might therefore be more reasonable to ask how an InfoSec practice that
claims to observe the principle of “due dilligence” could avoid using an
© 1999 CRC Press LLC
10/99
IDS enterprisewide. It is strongly emphasized that any InfoSec practice
that does not utilize IDS technology to at least some degree is not practicing due dilligence because it will necessarily overlook a large percentage of the incidents that occur. Any practice that remains unaware of
incidents does not understand the real risk factor; sadly, it only mimics
the behavior of an ostrich with its head under the sand. Simply put, an
effective IDS can greatly improve the capability to discover and report
security-related incidents.
Also note that the complexity of configuration of most systems, and
the poor quality of most commercial software, effectively guarantees that
new flaws will be discovered and widely reported that can be used
against most computing environments. Patches and defenses are often
not as quickly available as attack tools, and defenses based on monitoring and response are the only way to mitigate such dangers.
The failure to use such mechanisms is a failure to adequately provide
comprehensive security controls. In addition to increasing an organization’s capability to notice and respond to incidents, ISDs offer several
other major benefits. These include:
1. Cost reduction. Automated capabilities over time generally cost less
than humans performing the same function. Once an organization
has paid the cost of purchasing and installing one or more IDSs, the
cost of an intrusion detection capability can be quite reasonable.
2. Increased detection capability. An effective IDS is, as mentioned earlier, able to perform more sophisticated analysis (e.g., by correlating
data from a wide range of sources) than are humans. The epidemy
of the problem of reading and interpreting data through human inspection is reading systems’ audit logs. These logs typically produce
a volume of data that system administrators seldom have time to inspect at all or at least in any detail. Remember, too, that attackers often have the initial goal of disabling auditing once they compromise
a system’s defenses. IDSs do not necessarily rely on audit logs.
3. Deterrent value. Attackers who know intrusion detection capabilities
are in place are often more reluctant to continue unauthorized computer-related activity. IDSs thus, to some degree, serve to deter unauthorized activity.
4. Reporting. An effective IDS incorporates a reporting capability that
utilizes standard, easy-to-read and understand formats and database
management capabilities.
5. Forensics. A few IDSs incorporate forensics capabilities. Forensics involves the proper handling of evidence that can be used in court. A
major goal of forensics in fact is to collect and preserve evidence
about computer crime and misuse that will be admissible in a court
of law.
© 1999 CRC Press LLC
10/99
6. Failure detection and recovery. Many failures exhibit features similar
to misuse or intrusion. Deployment of good IDs can result in advance notice of these symptoms before they result in full failures.
Furthermore, some IDs can provide audit data about changes, thus
allowing failed components to be restored or verified more quickly.
Disadvantages
On the other hand, intrusion detection is beset with numerous limitations. Some of the most critical of these drawbacks include:
1. Immaturity. Most (but not all) IDSs available today have significant
limitations regarding the quality of functionality they provide. Some
are, in reality, little more than prototypes with a sophisticated user interface. Others purport to compare signatures from a signature library to events that occur in systems or networks, but the vendors or
developers refuse to allow potential customers to learn how complete and how relevant these libraries are. Equally troubling is the
fact that new types of attacks occur all the time; unless someone updates the signature library accordingly, detection efficiency will fall
over time. Still other IDSs rely on statistical indicators such as “normal usage patterns” for each user. A clever perpetrator can, however,
patiently and continuously engage in activity that does not fall out of
the normal range but comes close to doing so. The perpetrator thus
can adjust the statistical criteria over time. Someone who normally
uses a system between 8 a.m. and 8 p.m. may, for example, want to
attack the system at midnight. If the perpetrator were to simply attack
the system at midnight, alarms might go off because the IDS may not
consider midnight usage within the normal range of usage for that
user. But if the perpetrator keeps using the system from, say, 11 a.m.
to 11 p.m. every day for one week, usage at midnight might now no
longer be considered statistically deviant.
2. False positives. Another serious limitation of today’s IDSs is false positives (Type I errors). A false positive occurs when an IDS signals that
an event constitutes a security breach, but that event in reality does
not involve such a breach. An example is multiple, failed log-ins by
users who have forgotten their passwords. Most of the IDS customer
community today is concerned about false alarms because they are
often so disruptive and because they sidetrack the people who investigate the false intrusions from other, legitimately important tasks.
3. Performance decrements. Deploying IDSs results in system or network performance hits. The actual amount of decrement depends on
the particular IDS; some are very disruptive to performance. Anomaly-based systems are often the most disruptive because of the complexity of matching required.
© 1999 CRC Press LLC
10/99
4. Initial cost. The initial cost of deploying IDSs can be prohibitive.
When vendors of IDS products market their products, they often
mention only the purchase cost. The cost to deploy these systems
may require many hours of consultancy support, resulting in a much
higher cost than originally anticipated.
5. Vulnerability to attack. IDSs themselves can be attacked to disable the
capabilities they deliver. The most obvious case is when a trusted employee turns off every IDS, engages in a series of illegal actions, and
then turns every IDS on again. Any attacker can flood a system used
by an IDS capability with superfluous events to exceed the disk space
allocated for the IDS data, thereby causing legitimate data to be overwritten, system crashes, and a range of other undesirable outcomes.
6. Applicability. IDSs are, by definition, designed to uncover intrusions
— unauthorized access to systems; yet a large proportion of the attacks reported recently (at the time this article was written) were either probes (e.g., use of scanning programs to discover vulnerabilities
in systems) or denial-of-service attacks. Suppose that an attacker
wants to cause as many systems in an organization’s network to crash
as possible. Any IDSs in place may not be capable of discovering and
reporting many denial-of-service attacks in the first place. Even if they
are capable of doing so, knowing that “yes, there was a denial of service attack” hardly does any good if the attacked systems are already
down. Additionally, many (if not most) of today’s IDSs do a far better
job of discovering externally initiated attacks than ones that originate
from inside. This is unfortunate, given that expected loss for insider
attacks is far higher than for externally originated attacks.
7. Vulnerability to tampering. IDSs are vulnerable to tampering by unauthorized as well as authorized persons. Many ways to defeat IDSs are
widely known, within both the InfoSec and perpetrator communities.
In a highly entertaining article, Cohen9 describes 50 of these ways.
8. Changing technology. Depending on a particular technology can result in loss of protection as the overall computing infrastructure
changes. For example, network-based intrusion detection is often
foiled by switch-based IP networks, ATM-like networks, VPNs, encryption, and alternate routing of messages. All of these technologies
are becoming more widely deployed as time goes on.
The advantages and disadvantages of intrusion detection technology
are summarized in Exhibit 2.
ASSESSING INTRUSION DETECTION REQUIREMENTS
The relationship of intrusion detection to risk. A large number of organizations go about the process of risk management by periodically performing risk assessments, determining the amount of resources available,
© 1999 CRC Press LLC
10/99
Exhibit 2 — Summary of Advantages and Disadvantages of Intrusion Detection Technology
• Cost reduction (at least over time)
resulting from automation
• Increased efficiency in detecting
incidents
• Can deter unauthorized activity
• Built-in reporting, data management, and
other functions
• Built-in forensics capabilities
• Many IDSs do not deliver the
functionality that is needed
• Unacceptably high false alarm rates
• Generally produce performance
decrements
• Initial cost may be prohibitive
• May yield superfluous data
• IDSs themselves are vulnerable to attack
and then allocating resources according to some method of prioritybased risk mitigation strategy (i.e., introducing one or more controls that
counter the risk with the greatest potential for negative impact, then implementing one or more measures that address the risk with the second
greatest negative impact, until the resources are spent). Regardless of
whether or not one agrees with this mode of operation, it tends to guarantee that intrusion detection needs will be overlooked. In simple terms,
intrusion detection does not address any specific risk as directly as measures such as encryption and third-party authentication solutions.
Developing Business-Related Requirements
Developing specific, business-related requirements concerning intrusion
detection is anything but an easy process. The difficulty of doing so is in
all likelihood one of the major detractors in organizations’ struggles in
dealing with intrusion detection capabilities. Business units, furthermore,
may be the most reluctant to utilize intrusion detection technology because of the typical level of resources (personnel and monetary) required
and because this technology may superficially seem irrelevant to the
needs of fast-paced business units in today’s commercial environments.
On the other hand, obtaining buy-in from business units and developing business requirements for intrusion detection at the level of business
units is probably not, in most cases, the primary goal anyway. In most organizations, if intrusion detection technology is to be infused successfully, it must be introduced as a central capability. Business requirements
and the business rationale for intrusion detection technology are likely to
be closely related to the requirements for an organization’s audit function. The ultimate goal of intrusion detection technology in business
terms is the need to independently evaluate the impact of system and
network usage patterns in terms of the organization’s financial interests.
As such, it is often easiest to put intrusion detection technology in the
hands of an organization’s audit function.
© 1999 CRC Press LLC
10/99
Decision Criteria
Suppose that an organization decides to introduce intrusion detection
technology. After deriving the business requirements that apply to the organization, the next logical step is to determine whether the organization
will build a custom IDS or buy a commercial, off-the-shelf version. The
latter is generally a much wiser strategy — building a custom IDS generally requires far more time and resources than one might ever imagine.
Additionally, maintenance of custom-built IDSs is generally a stumbling
block in terms of long-term operations and cost. The exception to the
rule is deploying very simple intrusion detection technology. Setting up
and deploying “honey pot” servers, for example, is one such strategy.
“Honey pot” servers are, in essence, alarm servers connected to a local
network. Normally, nobody uses a “honey pot” server, but this host is assigned an interesting but bogus name (e.g., patents.corp.com). If anyone
logs in or even attempts to log in, software in this type of server alerts
the administrator, perhaps by having the administrator paged. The major
function of “honey pot” servers is to indicate whether an unauthorized
user is “loose on the Net,” so that one or more individuals can initiate
suitable incident response measures. This strategy is not elegant in terms
of the intrusion detection capability that it provides; it is, however, not
only simple, but is also very cost-effective. Better yet, an older, reasonably low-ended platform (e.g., a Sparcstation 5) is generally more than
sufficient for this type of deployment.
Buying a commercial IDS product is easier when one systematically
evaluates the functionality and characteristics of each candidate product
against meaningful criteria. At a minimum, one should apply the following criteria:
1. Cost. This includes both short- and long-term costs. As mentioned
previously, some products may appear to cost little because their
purchase price is low; but life-cycle deployment costs may be intolerable.
2. Functionality. The difference between a system- versus a networkbased IDS is very important here. Many intrusion detection experts
assert that system-based IDSs are in general better for detecting insider activity, whereas network-based IDSs more often better for detecting externally originated attacks. This consideration is, however,
only a beginning point with respect to determining whether or not a
product’s functionality is suitable. The presence or absence of functions such as reporting capabilities, data correlation from multiple
systems, and near realtime alerting is also important to consider.
3. Scalability. Each candidate tool should scale not only to business requirements but also to the environments in which it is to be deployed. In general, it is best to assume that whatever product one
buys will have to scale upward in time, so obtaining a product that
© 1999 CRC Press LLC
10/99
4.
5.
6.
7.
8.
can scale not only to the current environment, but also later to more
complex environments, is frequently a good idea.
Degree of automation. The more features of an IDS product that are
automated, the less human intervention is necessary.
Accuracy. An IDS product should not only identify any bona fide intrusion that occurs but should also minimize the false alarm rate.
Interoperability. Effective IDSs can interoperate with each other to
make data widely available to the various hosts that perform intrusion detection management and database management.
Ease of operation. An IDS that is easy to deploy and maintain is
more desirable than one that is not.
Impact on ongoing operations. An effective IDS causes little disruption in the environment in which it exists.
DEVELOPING AN INTRUSION DETECTION ARCHITECTURE
After requirements are in place and the type of IDS to be used is selected,
the next logical phase is to develop an architecture for intrusion detection. In the current context, the term “architecture” is defined as a highlevel characterization of how different components within a security
practice are organized and how they relate to each focus within that
practice. Consider, for example, the following components of an InfoSec
practice (see Exhibit 3).
To develop an intrusion detection architecture, one should start at the
highest level, ensuring that the policies include the appropriate provisions for deploying, managing, and accessing intrusion detection technology. For example, some policy statement should include the
provision that no employee or contractor will access or alter in any way
any IDS that is deployed. Another policy statement should specify how
much intrusion detection data are at a minimum to be captured and how
it must be archived. It is also important to ensure that an organization’s
EXHIBIT 3 — A Simple Framework for a Security Architecture
© 1999 CRC Press LLC
10/99
InfoSec policy clearly demarcates what “unauthorized activity” constitutes if the output of the IDS is to have any real meaning.
At the next level down, one might write specific standards appropriate
to each type of IDS deployed. For IDSs with signature libraries, for example, it is important to specify how often the libraries should be upgraded. At the lowest level, one might include recommendations such as
how much disk space to allocate for each particular IDS installation. It is
important to realize that an intrusion detection capability does not work
well in isolation; it needs to be part of the inner fabric of an organization’s culture. As such, developing an intrusion detection architecture is
a very important step in successfully deploying intrusion detection technology. Note also that developing such an architecture is not as simple
as diagrams such as Exhibit 3 might imply; it requires carefully analyzing
for each component of the architecture exactly what intrusion detection
requires and how to embody the solution for each need within that component. Equally importantly, it requires consensus among organizations
that will or might be affected by the rollout of intrusion detection technology in addition to buy-in from senior-level management.
CONCLUSION
This article examined intrusion detection and its potential role in an InfoSec practice, arguing against the “fortress mentality” that results in implementation of security control measures such as password hackers
without realizing that no defense measure is 100 percent effective anyway. It is important, therefore, to devote a reasonable portion of an organization’s resources to detecting incidents that occur and effectively
responding to them. This article took a look at its advantages and disadvantages, and then discussed how one can effectively introduce intrusion
detection technology into an organization. Finally, considerations related
to deploying IDSs were discussed.
Intrusion detection in many ways stands at the same crossroads that
firewall technology did nearly a decade ago. The early firewalls were really rather crude, and most organizations viewed them as interesting but
impractical. Intrusion detection technology was available before the first
firewall was ever implemented, but the former has always faced more of
an uphill battle. The problem to a large extent can be characterized as
due to the mystery and evasiveness that has surrounded IDSs. Firewalls
are more straightforward — the simplest firewalls simply block or allow
traffic destined for specific hosts.
One can be reasonably sure when buying a firewall product how this
product will work. The same has not been true in the intrusion detection
arena. Yet at the same time, intrusion detection is rapidly gaining acceptance among major organizations around the world. Although the technology surrounding this area is far less than perfect, it is now for the
© 1999 CRC Press LLC
10/99
most part sufficiently reliable and sophisticated to warrant its deployment. To ignore and avoid deploying this technology now, in the authors’ judgment, constitutes a failure to adopt the types of measures
responsible organizations are now putting in place, which in simple
terms is a failure to observe “due care” standards.
The good news is that intrusion detection technology is becoming increasingly sophisticated every year. Also encouraging is the fact that performance-related problems associated with IDSs are becoming relatively
less important because operating systems and the hardware platforms on
which they run are constantly improving with respect to performance
characteristics. The research community, additionally, is doing a better
job in pioneering the way for the next generation of intrusion detection
technology. Some current advances in intrusion detection research include areas such as interoperability of IDSs, automatic reporting, and automated response (in which the IDS takes evasive action when it
determines that an attack is in progress).
The bad news is that if an organization does not currently use intrusion detection technology, it is badly behind the intrusion detection
“power curve.” Consider, furthermore, that an organization that buys,
then rolls out a new IDS product is by no means ready to reap the benefits immediately. A definite, steep learning curve for using intrusion detection technology exists. Even if one starts deploying this technology
now, it takes time to assimilate the mentality of intrusion detection and
the technology associated with it into an organization’s culture. It is important, therefore, to become familiar with and start using this technology as soon as possible to avoid falling behind even further. The
alternative is to continue to function as the proverbial ostrich with its
head beneath the sand.
REFERENCES
1. Schultz, E.E. and Wack, J., Responding to Computer Security Incidents, in M. Krause and H.F. Tipton
(Eds.), Handbook of Information Security, Boston: Auerbach, p. 53–68, 1996.
2. Garfinkel, S. and Spafford, G., Practical UNIX and Internet Security, O’Reilly & Associates, Inc., 1996.
3. Garfinkel, S. and Spafford, G., Web Security and Commerce, O’Reilly & Associates, Inc., 1997.
4. Van Wyk, K.R., Threats to DoD Computer Systems, paper presented at 23rd Information Integrity Institute Forum, (cited with author’s permission).
5. Power, Richard, Issues and Trends: 1999 CSI/FBI Computer Crime and Security Survey, Computer Security
Journal, XV(2), Spring 1999
6. Mukherjee, B., Heberlein, L.T., and Levitt, K.N., Network Intrusion Detection, IEEE Network, 8(3), 26–41,
1994.
7. Crosbie, M. and Spafford, E.H., Defending a Computer System using Autonomous Agents, Proceedings
of 18th National Information Systems Security Conference, p. 549–558, 1995.
8. Herringshaw, C., Detecting Attacks on Networks, IEEE Computer, 30(12), 16–17, 1997.
9. Cohen, F., Managing Network Security. Part 14: 50 Ways to Defeat Your Intrusion Detection System, Network Security, December, p. 11–14, 1997.
Eugene Schultz can be contacted through both Global Integrity Corporation and Purdue University. Eugene Spafford can be contacted through Purdue University.
© 1999 CRC Press LLC
10/99