“Is there any other point to which you would wish to
draw my attention?”
“To the curious incident of the dog in the nighttime.”
“The dog did nothing in the nighttime.”
“That was the curious incident,” remarked Sherlock
--Sir Arthur Conan Doyle
Given a variety of rich information sources about the system activities
you're charged with monitoring, the next stop on the intrusion detection circuit
is analysis. With analysis, you're faced with the core issue of intrusion
detection: What is going on here, and should I be interested in or concerned
Within the analysis function, information is synchronized, classified,
and subjected to scrutiny of various types to identify activity patterns of
security significance. This chapter covers the vast area of analysis, considers
the various goals of analysis, and discusses the issues you must take into
account when devising an analysis scheme for a particular goal or system.
It also explores the variables that affect the quality of the analysis.
In considering the analysis functions of intrusion detection, let's start by articulating the detection
process in intuitive terms. This definition will lend structure to the subsequent
discussion of the fundamental issues and functions of analysis.
Analysis, in the context of intrusion detection, is organizing and characterizing data about user and
system activity to identify activity of interest. This activity can be isolated
either as it happens or after the fact. In some cases, further analysis is
needed to establish accountability for the activity. Depending on the type
of analysis, additional evaluation may be performed to tune or otherwise improve
the outcome of subsequent analysis.
Intrusion detection is the second step in a general system security
management process model, pictured in Figure 4.1.
This model is helpful because certain analysis functions serve the needs of
the investigative and resolution steps of the management process.
Security managers hope to gain several benefits by performing intrusion detection analysis.
The overarching assumption is that people use intrusion detection systems
to improve the security of their information systems.
Significant deterrence One
benefit a security manager seeks is to deter problem behaviors. The knowledge
that analysis is being performed and the credible threat of discovery
and punishment serve as a deterrent to intruders.
Quality control for security design and administration
Problems that are discovered in the course of analysis can indicate flaws
the design and management of security for the system. The security manager,
so notified, can then correct theseproblems before an adversary utilizes
them to damage or steal information.
Useful information on actual intrusions This
information should be relevant, detailed, and trustworthy so that it can
or civil legal remedies. It can also be used to identify needed corrections
in the organization's security configuration, policy, or strategy.
Now that the goals of the analysis process are outlined, it's time to
consider how each one drives specific functional requirements for an intrusion
detection system. Structuring the requirements as sets of prioritized goals
and subgoals helps to optimize the system.
Intrusion detection analysis supports two basic requirements. One
is, as we've mentioned before, accountability, which
refers to the ability to link an activity with the person or entity responsible
for it. Accountability requires you to be able to consistently and reliably
identify and authenticate each user of the system. Furthermore, you must also
be able to reliably associate each user with the audit or other event records
of her activities.
Although the concepts of accountability are straightforward and common
in businessenvironments, they are difficult to implement in network environments.
Unless you're in an environment featuring a single sign-on system,
which centralizes identification and authentication for a large network, a
user may have different user identities on different systems within the network.
Because host-level audit trails reflect user activity in terms of the user's
local identity, keeping track of user identity in activities that involve
multiple hosts and user accounts requires additional processing.
The second requirement for intrusion
detection analysis is real-time detection and response.
This requirement includes the ability to quickly recognize the chain of events
associated with an attack, and the ability to then block the attack (for instance,
by terminating the network connection used by the attacker) or to shield the
system from the impact of the attack (for instance, by tracing the commands
sent by the attacker and restoring any altered files or objects to their pre-attack
Analysis also has subgoals. For instance, you might need to retain information in a form that
supports system and network forensic analysis. Another subgoal might involve
retaining some knowledge about the system performance or identifying problems
that affectsystem performance. Yet another might involve archiving and protecting
the integrity of event logs required by regulators or law enforcement entities.
After goals and requirements are articulated, they should be prioritized.
Prioritization is necessary to determine the structure of the analysis subsystem.
The priorities can be ranked by schedule (for instance, “this requirement
will be serviced before that one”), by system(for example, “all
requirements associated with system X will be serviced before those associated
with other systems”), or by other attributes.
At times, the goals and requirements of analysis may conflict. For example,
one goal of analysis is to minimize the impact of analysis on the performance
and resource consumption of the target system. However, the requirement to
maintain logs for legal purposes often conflicts with this goal. In another
example, the system overhead required to maintain accountability may affect
the analyzer's ability to identify intrusions quickly enough tosupport active
To understand the nature of intrusion detection analysis,
you should consider the full range of intrusion analysis available to customers,
starting with those used in older systems. Although the focus here is on techniques
suitable for automation, consider the full spectrum of discovery techniques
for security intrusions and other violations of policy.
Humans (“wetware” or “carbon units”) are the
most obvious and traditionally the most common source of intrusion information.
A system manager may report that a machine is acting funny, or a user may
report finding evidence of unauthorized activity on a system. Unfortunately,
this approach is of extremely limited value because most incidents gounnoticed
at sites where no intrusion detection systems are in place. For instance,
one early study showed that over a period of time in which a prototype intrusion
detectionsystem detected several hundred intrusions, only 20f those were
detected by the humans charged with performing manual intrusion detection.
Events external to the computer system often trigger suspicion of potential
intrusion. These events include hiring and firing (especially of key personnel),
reports of anomalies (such as sudden unexplained affluence of employees who
work on critical systems), results of security penetration tests, and discovery
of missing goods or information. These events are sometimes tracked as part
of a traditional corporate fraud detection or loss control program.
News coverage or warnings posted to the Internet about particular classes
of attacksalso trigger suspicion of potential intrusion. This information
appears to encourage the installation or use of antivirus tools.
Next are the signs of intrusion that come from the victim systems. The
first sign isevidence of an intruder having primed the system for future attack,
which includes signs of trojan horse placement (that is, tampered system files)
and unauthorized accountadditions to password files or trusted host configuration
files (such as /etc/.rhosts in UNIX systems). These examples were the first
symptoms of security problems targeted by early security tools such as COPS.
As precursors to intrusion alert customers
to likely incidents, so do those indicators left in the wake of intrusions.
These artifacts, evidence of past intrusions, can be
reliable indicators of attack for both intrusion detection and vulnerability
analysis. They can be discovered in real time (immediately upon the completion
of the first step of an intrusion) or after the fact (during batch mode analysis
of log files). Artifacts that are discovered immediately can be used by intrusion
detection systems functioning in real time. Examples of artifacts of intrusions
include password sniffer log files, unexplained system failures, and damaged
files. Note that some artifacts are incidental to the intrusion (that is,
they are not an intended goal of the intrusion) but excellent indicators,
nevertheless, for detection purposes. Examples of such incidental outcomes
include abnormal patterns of system resource use, discrepancies in accounting
records (due to intruders deleting some, but not all,evidence of their activities),
and unusual network traffic levels.
The final scenario for detecting
misuse became possible with the advent and availability of intrusion detection
systems--recognizing attacks by monitoring systems in real time. The
ability to detect attacks by using these systems has opened the door to attack-blocking
and other adaptive system responses to detected problems.
One of the primary architects of OpenCable, Michael
Adams, explains the key concepts of this initiative in his book
Broadband, Second Edition
by George Abe
Introduces the topics surrounding high-speed networks
to the home. It is written for anyone seeking a broad-based familiarity
with the issues of residential broadband (RBB) including product
developers, engineers, network designers, business people, professionals
in legal and regulatory positions, and industry analysts.