05-09-2012, 10:05 AM
Doing intrusion detection using embedded sensors Thesis proposal
Doing intrusion detection.pdf (Size: 184.9 KB / Downloads: 34)
Abstract
Intrusion detection systems have usually been developed using large host-based components. These components
impose an extra load on the system where they run (sometimes even requiring a dedicated system)
and are subject to tampering or disabling by an intruder.
Additionally, intrusion detection systems have usually obtained information about host behavior through
indirect means, such as audit trails or network packet traces. This potentially allows intruders to modify the
information before the intrusion detection system obtains it, making it possible for an intruder to hide his
activities.
In this document I propose work that will attempt to show that it is possible to perform intrusion detection
using small sensors embedded in a computer system. These sensors will look for signs of specic intrusions.
They will perform target monitoring by observing the behavior of the system directly, instead of through an
audit trail or other indirect means. Furthermore, by being built into the code of the operating system and its
programs, they may not impose a considerable extra load on the host they monitor.
I will also explore the possibility of applying a group of sensors built to detect known intrusions, to detecting
new intrusions. If this is shown to be possible, it would be a step towards determining the types of data that
need to be collected to successfully detect new intrusions.
The work I propose is divided in four stages: a) building the necessary infrastructure for the implementation
of the sensors, b) implementing sensors for detecting known intrusions, c) testing new attacks against the group
of implemented sensors, and d) performing analysis on the data obtained in step © to determine if the existing
sensors can be used to detect new attacks.
Introduction
The eld of intrusion detection has received increasing attention in recent years. One reason for this is the explosive
growth of the Internet and the large number of networked systems that exist in all types of organizations. The
increase in the number of networked machines has lead to an increase in unauthorized activity [9], not only
from external attackers, but also from internal attackers, such as disgruntled employees and people abusing their
privileges for personal gain [42].
To detect and counteract unauthorized activity, it is desirable for network and system administrators to
monitor activity in their networks. Because even a single host can generate several megabytes of logging and
audit data in a single day, it is desirable to have tools that can automatically monitor computer systems and detect
when unauthorized activity is taking place. These tools are commonly known as intrusion detection systems.
Intrusion Detection
Intrusion detection is dened as \the problem of identifying individuals who are using a computer system without
authorization (i.e., `crackers') and those who have legitimate access to the system but are abusing their privileges
(i.e., the `insider threat')" [39]. I add to this denition the identication of attempts to use a computer system
without authorization or to abuse existing privileges. My working denition matches the one given by Heady et al.
[22], where an intrusion is dened as \any set of actions that attempt to compromise the integrity, condentiality,
or availability of a resource," disregarding the success or failure of those actions.
The dictionary denition of the word intrusion [36] does not include the concept of an insider abusing his or
her privileges to perform unauthorized actions, or attempting to do so. A more accurate phrase to use is intrusion
and insider abuse detection. In this document I use the term intrusion to mean both intrusion and insider abuse.
Related work
The rst work performed on intrusion detection is commonly considered to be the one reported by Anderson [1],
which introduced, among others, the idea of doing anomaly detection by creating proles of normal use and
detecting deviations from those proles. This idea was later formally presented by Denning [14] in what is
considered to be the seminal paper for modern intrusion detection.
In the area of host-based intrusion detection there has been substantial work using dierent methods for
analyzing data generated by the host. One of the rst host-based intrusion detection systems implemented was
IDES [15, 16, 31, 34], which used both a statistical detection engine based on Denning's model [14] and a rulebased
expert system for detecting known intrusions by their signatures [35]. Kumar [29] used pattern matching
techniques to detect and classify attacks. More recently, Forrest et al. [18] have applied classication techniques
to sequences of Unix system calls to identify anomalous behavior in Unix processes. Also, Lane and Brodley [30]
have used classication of command sequences to perform automatic user identication. Lunt [32, 33] has surveyed
the most common host-based intrusion detection and audit trail analysis techniques.
The area of network-based intrusion detection has also seen a good amount of work. One of the rst implemented
network-based intrusion detection system was the Network Security Monitor (NSM) [23], which applies
both statistical models and rule-based detection to network connections, using the trac source, destination and
service as relevant features for classication.
Proposed work
One or more Unix systems will be instrumented with sensors designed to detect specic known attacks. One
possible source of information about such attacks is the CVE (Common Vulnerability and Exposure enumeration)
[37] from MITRE. Once a sucient number of sensors is implemented and tested, new attacks will be
performed against the instrumented system to determine if and how the existing sensors will react to the new
attacks. Some analysis is going to be performed on the data produced by the sensors under the new attacks, as
well as on the patterns of sensors triggered by the attacks.
Number of sensors needed
Sensors will be built based on the vulnerability and attack list provided by the CVE [37]. This list is not a
taxonomy or a classication scheme, and is used only as a fairly complete list of known vulnerabilities.
Frequently, the discovery and publication of an attack triggers exploration in the same direction or in the same
program, and causes the discovery of similar or related problems. For this reason, attacks that are published close
in time may be correlated. To avoid these correlations and get a representative sample of the \attack space"1,
attacks will be selected from the list randomly without replacement.
This process will continue until the last 15 attacks selected from the list are already detected by previously
implemented sensors (following the sensor implementation design considerations described in Section 5.1), or until
the CVE list is exhausted. The last version (September 9, 1999) of the CVE list contains 321 entries. From this
list, all the entries for non-Unix and closed-source programs were removed, leaving 226 entries. The number
15 was chosen to represent approximately 5% of this list. The criterion behind this is that if we start nding
redundancy in the sensors needed, it is time to move on to verifying the second hypothesis.
Implementation platform
The \attack space" is considerably large, because each attack can be characterized by a number of features, as
shown by Krsul [28]. To simplify the practical study of this space, I will eliminate one of the features with the most
variance: the operating system and platform of the attack. In the current version of the CERIAS vulnerability
database [7], of the eighteen multiple-choice features dened, \operating system" has originally 47 dened values,
making it the second largest one. Of these values, 31 correspond to Unix-style systems.
To reduce the number of dierent systems that have to be instrumented, all the sensors will be implemented
on the same platform. Because sensors will be designed to detect the attack attempts and not their success,
the attack does not need to exist in the implementation platform anymore, and in fact may be an attack for a
completely dierent platform. In this sense, the instrumented systems will work like universal honeypots2 because
they will be able to accept and monitor attacks for dierent platforms.