Component-based Software Design

Han et al

Component-based Software Design and

Implementation for Network Security System
Jianchao Han, Mohsen Beheshti, Kazimierz Kowalski,
Johnly Tomelden, Joel Ortiz
Department of Computer Science, California State University Dominguez Hills (USA)
E-mail: {jhan, mbeheshti, kkowalski}@csudh.edu

ABSTRACT
A computer network intrusion detection and prevention system consists of collecting network traffic data, discovering user behavior patterns as intrusion detection rules, and applying these rules to prevent malicious and misuse. Many
commercial off-the-shelf (COTS) products have been developed to perform
each of these tasks. In this paper, the component-based software engineering approach is exploited to integrate these COTS products as components
into a computerized system to automatically detect intrusion rules from network
traffic data and setup IPTables to prevent future potential attacks. The component-based software architecture of this kind of system is designed, COTS
components are analyzed and selected, adaptor components to connect COTS
products are developed, the system implementation is illustrated, and the preliminary system experiment is presented.
Keywords: Component-based software engineering, Software reuse, Data
mining, Network security, Intrusion detection and prevention.

1- INTRODUCTION
As network attacks have increased in number and severity over the past years,
intrusion detection and prevention has become a necessary addition to the security infrastructure of most organizations.
A computer network intrusion detection and prevention system (IDPS) consists
of collecting network traffic data, discovering user behavior patterns as intrusion detection rules, and applying these rules to prevent malicious and misuse
[1]. Many commercial off-the-shelf (COTS) products have been developed to
perform each of these tasks. However, most these COTS products need users
to manually set up required rules to have the products work well. Unfortunately,
figuring out these rules is a challenging task. Our objective of this paper is to
compose these products to create an automatic intrusion detection and prevention system.
One of the most promising solutions to this objective today is the componentbased software development approach. This approach is based on the idea
that software systems can be developed by selecting appropriate off-the-shelf
85

Int.J. of Software Engineering, IJSE Vol.2 No.3 December 2009

components and then assembling them with well-defined software architecture

[2]. This software development approach is very different from the traditional approach in which software systems can only be implemented from scratch. These
commercial COTS components can be developed by different developers using
different languages and different platforms.
In this paper, we present our component-based design and implementation of
the network intrusion detection and prevention system. We first analyze the
characteristics and process of intrusion detection and prevention, and then follow the component-based software engineering process to design the software
architecture of the intrusion detection and prevention system, select COTS
products as the system components, develop adaptor components to compose
COTS products, illustrate the system implementation, and present our preliminary experiment.
The rest of this paper is organized as follows: Section II summarizes the related
work, including network intrusion detection and prevention as well as component-based software engineering. Section III introduces the intrusion detection
and prevention process, while the component-based software architecture to
implement this process is designed in Section IV. The component requirements
analysis and COTS components selection are discussed in Section V. The
adaptor components to assemble COTS products are developed in Section VI.
Our implementation and experiments are presented in Section VII. Finally, Section VIII is concluding remarks and our future work.

2- RELATED WORK
The problem of network intrusion detection has been studied extensively in
computer security and has received much attention in machine learning and
data mining community. Many different approaches have been developed and
implemented to detect anomalies and/or misuses. These approaches can be
summarized as follows [3, 4, 5, 6, 7, 8, 9, 10, 11]:
Using data mining techniques over system audit data to extract consistent and useful patterns of program and user behavior, and to build classifiers that can recognize anomalies.
Using temporal association rules (a data mining technique that uses time
concepts), in terms of multiple time granularities. The temporal association rules technique generates fuzzy and classical rules.
Using short sequences of system calls with which running programs perform as discriminators between normal and abnormal operating characteristics.
Distributing the detection task in multiple independent entities (autonomous agents) working collectively.

86

Component-based Software Design

Han et al

Using generic programming to build autonomous agents that detect intrusions.

Emulating mechanisms of the natural immune systems to detect anomalies in a distributed manner.
Using rough set classification technique to extract network features for
detecting intrusions and generating intrusion detection model.
Using multiple-iteration Support Vector Machine (SVM) to rank and select
significant features.
Using K-nearst neighbour algorithm and statistical analysis to detect
anormaly intrusions.
Primarily, the design and development of a network intrusion detection system
using machine learning and data mining techniques can be described as follows
[8]:
Capture network data by using tools such as Tcpdump, Dsniff, etc.;
Preprocess and transform the data into suitable input format;
Normalize the network flow and extract features of attack behavior or
normal usage patterns from the preprocessed data;
Design and use machine learning and data mining algorithm(s) to induce
intrusion detection rules;
Integrate the detection rules into the real-time IDS for detecting intrusions.
Component-based software engineering (CBSE) emerged in the late 1990s as
a reuse-based approach to software system development [12]. CBSE is the
process of defining, implementing and integrating or composing loosely coupled
independent components into systems. It has become a commonly used development paradigm and an important software development approach because
software systems are becoming larger and more complex and customers are
demanding more dependable software that is developed more quickly.
Currently, CBSE is being used in a wide range of domains from large enterprise systems to applications for embedded environments [13]. Using CBSE,
software systems are built by composition of reusable building blocks called
components. In addition to the services provided by a component, also the services required from other components or the environment are specified. Such an
explicit specification of provisions and dependencies makes the components
easier to reuse and therefore allows for rapid development.
There are many approaches to build applications from components [14]. Each
of these approaches uses different component models, i.e. the definition of what
87

Int.J. of Software Engineering, IJSE Vol.2 No.3 December 2009

a component is, which features it supports, how it can be composed, etc. With
respect to the used component model and supporting tools, the component
systems can be divided by several points of view, e.g. who drives the component system (industry driven vs. academia-driven systems), type of composition
(flat vs. hierarchical component models), target domain (enterprise application,
embedded applications, general purpose component models), supported parts
of application lifecycle (design-only system vs. systems supporting complete
development cycle). Each of these systems has its pros and cons and each of
them brings different advantages to CBSE [12].
CBSE can be implemented either in pipelines or flow-based paradigm. A flowbased implementation defines the application as a network of black box processes, which exchange data across predefined connections by message passing [10]. These black box processes can be reconnected endlessly to form
different applications without having to be changed internally. This implementation is thus naturally component-based, and the focus is on the application data
and the transformations applied to it to produce the desired outputs.
A component in CBSE is usually a software unit that can be independantly deployed and composed without modification with other components to create a
software system according to a composition standard and may be subject to composition by the third parties [15]. One of the most useful ways to consider a component is as a standalone service provider. Thus a reusable component emphasises two characteristics: The component is an independent executable entity and
the services offered by a component are made available through an interface and
all interactions are through that interface. Each component can be defined by their
two related interfaces [12]: a requires interface that defines the services from the
components environment that it uses and must be provided by other components
in the system; and a provides interface that defines the services provided by the
component to other components. The provides interface is essentially the component API and defines the methods that can be called by a user of the component.
Most intrusion detection systems have been designed and developed according to the composition of vaious components based on their functionalities [16,
17]. However, very few publications have researched and practiced on developing intrusion detection systems using component-based software engineering.
Yau and Zhang developed a framework for computer network intrusion detection, assessment and prevention [18], which consists of three components: intrusion detection component that uses the audit data collected from multiple
network nodes and services, intrusion assessment component and intrusion
prevention component that both use security dependency relation and ripple
effect analysis. However, the authors didnt composite any COTS products and
neither considered the interfaces between components. Kemmerer and Vigna
[19] proposed a component-based architecture WebSTAT to compose the domain independent STAT runtime with a number of language extensions, event
providers, attack scenarios, and response functions. However, their concern is
to integrate knowledge from different domains. Blumenthal et al. [20] developed
88

Component-based Software Design

Han et al

a component-based framework for application software for sensor networks to

provide the functionality of single sensors, sensor nodes, and the whole sensor
network. Their objective is to classify applications into sensor applications, node
applications, and network applications. Mostarda and Navarra [21] presented
an approach to provide intrusion detection systems facilities into wireless sensors network. The approach is based on the DESERT tool [22] which allows
the generation of decentralized monitoring systems for component based applications. The authors derived a new component-based software framework to
dynamically enforce a set of properties of the sensors behavior.
In the component-based software development, components cannot be completely secure and thus easily become vulnerable. Some researchers have investigated this issue and proposed approaches to detect component intrusions
[23] or protect distributed components [24].
In this paper we attempt to apply the flow-based paradigm of CBSE in the development of a computer network security software system to detect and prevent
intrusions. We propose the component-based software architecture for the process of intrusion detection and prevention, and composite the COTS products
into the system by developing glue adaptors. The intrusion detection and presention system developed in this manner has been experimented.

3- INTRUSION DETECTION AND PREVENTION PROCESS

A network intrusion detection and prevention system (IDPS) is to monitor computer systems for signs of security violations [3, 4, 5, 25]. Intrusion detection
system (IDS) is an application system to automate the process of network intrusion monitoring by analyzing and response on real time security problems. Intrusion detection technology has been developed for years and nowadays quality
signature has been developed to facilitate intrusion blocking using advance inline intrusion prevention system (IPS).
Basically, an intrusion detection system collects information gathered from the
network, host, or file systems and analyzes the information to find suspicious
activities. The increased connectivity between computer systems has opened
up many possibilities of attacks, such as attempted break-in, tempered executables, denial of service, leakage, masquerade attack, malicious use, etc. Suspicious network activities are usually divided into two main categories [1]: misuse
and anomaly. Detecting misuses is to analyze the network traffic information
and compare to large databases of attack signatures to find patterns signaling
well known attacks that have already been documented. The obvious disadvantage of the misuse detection is that it is not capable of detecting new attacks. On
the other hand, detecting anomalies is to compare the actual network traffic data
to a profile of all allowed normal user behavior. Any deviation from the profile is
considered to be a suspicious action. Anomaly detection seems to be able to
detect all kind of attacks, including novel or unknown attacks. However, it can
only signal that some event is unusual, but not necessarily hostile, thus generat89

Int.J. of Software Engineering, IJSE Vol.2 No.3 December 2009

detection seems to be able to detect all kind of attacks, including novel or

unknown attacks. However, it can only signal that some event is unusual, but
not necessarily hostile, thus generating false alarms [6]. This is why anomaly
ing false usually
alarms [6].
This
detection
usuallyIntrusion
leads to detection
a high rate
detection
leads
to isa why
highanomaly
rate of false
positives.
of
false
positives.
Intrusion
detection
systems
must
be
capable
of
distinguishing
systems must be capable of distinguishing between normal (not securitybetween
(not security-critical)
abnormal
user activities,
critical)
andnormal
abnormal
user activities, toand
discover
malicious
attemptstoindiscover
time.
However
translating
behaviors
(ortranslating
a complete
user-system
in a
malicious
attempts user
in time.
However
user
behaviors session)
(or a complete
is security-related
often not that simple,
many
consistent
security-related
user-system
session) in a decision
consistent
decisionbecause
is often not
that
behavior
patterns are
unpredictable
and unclear.
simple, because
many
behavior patterns
are unpredictable and unclear.
Theprocesses
processesinina atypical
typicalintrusion
intrusiondetection
detectionsystem
systeminclude
includedata
datacollection,
collection,
The
datapre-processing,
pre-processing,pattern
patterndetection,
detection,and
andresponse
response
and
prevention
[26].
The
data
and
prevention
[26].
The
intrusiondetection
detectionand
andprevention
preventionprocess
processis isillustrated
illustratedininFigure
Figure1 1and
anddedeintrusion
scribedasasbelow.
below.
scribed

Data
capture

Traffic data

Data
preprocess

Learning data

Intrusion
prevention

Detection rules

Induce
detection
rules

Figure 1 Intrusion detection and prevention process

Figure 1 Intrusion detection and prevention process

1. The first step of intrusion detection and prevention is to normalize the network flow and capture the network traffic data, such as the packet data;

1. The first step of intrusion detection and prevention is to normalize the

2. The second step is to extract significant features from the traffic data, prenetwork flow and capture the network traffic data, such as the packet
process these data such as normalization, discretization, handling missdata;
ing values, etc., and transform the data into suitable format for next step;
2. The second step is to extract significant features from the traffic data,
3. The
third step
is todata
design
andasuse
pattern recognition
approach,
or mapreprocess
these
such
normalization,
discretization,
handling
chine
learning
algorithm(s)
to induce
intrusion
detection
missing
values,and
etc.,data
andmining
transform
the data into
suitable
format for
next
rules;
step;
3.
The third
to design
and usethe
pattern
recognition
or
4. Finally,
thestep
last isstep
is to integrate
intrusion
detectionapproach,
rules discovmachine
learning
and
data
mining
algorithm(s)
to
induce
intrusion
deered in previous step into the real-time system for detecting and preventtection
rules;intrusions.
ing
potential
4. Finally, the last step is to integrate the intrusion detection rules discovThere many commercial tools exist to collect data from the network traffic, such
ered in previous step into the real-time system for detecting and preas Snort [7], Tcpdump, Dsniff [27], etc. [8]. The audit data collected this way may
venting potential intrusions.
not be understandable to other components of the detection system, and thus
needs pre-processed. Data pre-processing includes transforming data to understandable format, handling noisy data and/or missing data, mapping data type,
and selecting significant data portion. Pattern detection is to find rules to rec90

Component-based Software Design

Han et al

ognize normal and abnormal activities. Currently, existing commercial products

based on data mining and machine learning techniques have been extensively
used to perform this task [9], such as inducing classification rules to recognize
anomalies [29], discovering temporal association rules to detect time-related
correlations, finding short sequences of system calls to discriminate between
normal and abnormal operating characteristics [30]. Finally, to respond and prevent potential network attacks, researchers and practitioners have developed
and applied firewalls to filter out malicious use of networks [31].

4- COMPONENT-BASED SOFTWARE ARCHITECTURE

INTRUSION DETECTION AND PREVENTION

FOR

One can realize that standardized Commercial-Off-The-Shelf (COTS) products

for network traffic data collection, intrusion pattern detection, and firewalls for
intrusion prevention have been applied in various fields. However, most these
COTS products require users to manually set up special formats of rules to have
the products perform appropriately. For example, Snort is an intrusion detection
tool, but it requires that users classify attacks and set detection rules; Firewalls
are used to prevent intrusions, but firewall rules must be pre-set by users manually. Unfortunately, figuring out these rules is not that easy.
In order to take advantage of these existing COTS products, we adopt component-based approach to develop our intrusion detection and prevention software system. One may also realize that it is difficult to get COTS products to
work together because each product embeds its own assumptions about how
it will be used. Therefore, there usually exists incompatibility between these
components. To overcome this problem, adaptor components may need to be
developed to interface COTS products.
The components in the component-based system are usually sequentially composed, meaning that the constituent components will be executed in sequence
[15]. The primary design of this network intrusion detection system consists of
five basic components, which are described as follows:
1. Data collection component: Captures packet data in network traffic and
stores in the audit logs;
2. Data format adaptor component: Preprocesses and transforms the data
into the suitable input format for pattern recognition;
3. Intrusion pattern recognition component: Induces intrusion detection
rules, a set of alert rules for recognizing malicious activities;
4. Pattern format adaptor component: Adapts intrusion detection rules into
suitable format for intrusion prevention;
5. Intrusion prevention component: Sets up firewall rules to prevent potential attacks.
91

4. Pattern format adaptor component: Adapts intrusion detection rules

into suitable format for intrusion prevention;
5. Intrusion prevention component: Sets up firewall rules to prevent
potential attacks.
Int.J. of Software Engineering, IJSE Vol.2 No.3 December 2009
These components are sequentially composed together and executed in sequence. Thus, our component-based software architecture with sequential comThese
are sequentially
positioncomponents
can be illustrated
in Figure 2. composed together and executed in sequence. Thus, our component-based software architecture with sequential composition can be illustrated in Figure 2.

Figure 2 Component-based software architecture for network intrusion

Figure 2 Component-based
softwareand
architecture
forsystem
network intrusion detection and
detection
prevention
prevention system

Among the five components in this design architecture, three components: Traffic data collection, Intrusion pattern recognition, and Intrusion prevention, can
Among the five components in this design architecture, three components:
be selected from COTS products, while Data and Pattern format adaptor comTraffic data collection, Intrusion pattern recognition, and Intrusion prevention,
ponents should be designed and developed accordingly to solve the problems
can be selected from COTS products, while Data and Pattern format adaptor
of incompatibility between the COTS components selected.
components should be designed and developed accordingly to solve the problems of incompatibility between the COTS components selected.

5- COMPONENT REQUIREMENTS AND SELECTION

In this section, we analyze interfaces of three components including Traffic data
collection, Intrusion pattern recognition and Intrusion prevention and select
COTS products to play the role of these components, while in next section, the
two adaptor components will be developed.

5-1 TRAFFIC DATA COLLECTION

The objective of traffic data collection is to collect information of network connections to identify the characteristics of each connection. Since the connection
characteristics can be identified from the packet head, COTS products that can
collect packet information are preferred for this component. There many COTS
92

Component-based Software Design

Han et al

exist to perform this task, such as Snort [7], Tcpdump, Dsniff [27]. In our design,
Snort has been selected.
Snort is an open source network intrusion detection system that is capable of
performing real time trafficanalysis and packet logging on IP networks, such
as protocol analysis, contentsearching/matching. Snort canbeusedto detect a
variety of attacks and probes, such as buffer overflows, stealth port scans, CGI
attacks, SMB probes, OS fingerprinting attempts, and much more. Snort uses
a flexible language to describe traffic that it should collect or pass, as well as a
detectionenginethat utilizes the modular plugin architecture. Snort also has a
modular real-time alerting capability, incorporating alerting and logging plugins
for syslog, a ASCII text files, UNIX sockets, database (Mysql/PostgreSQL/Oracle/ODBC) or XML.
Snort has many functions, but we are currently using it for logging packet information. Snort uses rules to match packet information and payload for classifying the packet. Snort Version 2.4.3 (Build 26) developed by Sourcefire. Inc.
[7] is selected, where the Sniffer function is used. We are using MySQL [28] as
the packet data storage, although Snort can be setup to use MsSQL, Postgre,
Oracle, and the file format.
One can see that the requires interface of Snort is the network packets, while
its provides interface is a MySQL database. The Snort database contains four
tables to record information of the network packets that use the following protocols, icp, udp, icmp, and ip, and two other important tables acid_event and
opt, where acid_event consolidates all the logs of alerts that Snort captures and
orders them by the cid field, while opt holds the optional data that can be part of
the TCP/IP protocol. The Snort rules are set to collect all packets.

5-2 INTRUSION PATTERN RECOGNITION

The objective of Intrusion pattern recognition is to find packet patterns that are
potential attacks. This can be accomplished by various data mining and pattern
recognition algorithms. See5/C5.0 is selected to perform this task.
See5/C5.0 [29] is the commercial version of C4.5 decision tree and rule induction product by Rulequest developed by Quinlan [32]. See5 is the software that
runs on a windows platform while C5.0 is designed to run on Linux.
Using classification techniques in conjunction with the data mining tool C5.0/
See5, one can analyze the Snort database to identify any anomalies in the
traffic patterns, thus giving us a better understanding of how to detect and prevent security flaws in todays networks and computer systems. Anomalies may
include multiple attacks from the same IP address, multiple occurrences of a
certain type of attack, and can also detect clustered ranges of IP addresses.
Classifiers generated by See5 are generally in the form of decision trees or sets
of if-then rules, which are usually easier to understand than other formats such
as neural networks.
93

Int.J. of Software Engineering, IJSE Vol.2 No.3 December 2009

The requires interface of See5/C5.0 are two files called the .data file (training
data set) and the .names file (the describer file). The .names file starts with the
target attribute, followed by an arbitrary list of the attributes that are described
ether implicitly or explicitly. The .data file is composed of data fields separated
by commas with ? and N/A filler fields representing missing data or not applicable data.
The provides interface of See5/C5.0 is a decision tree. Following is an example
of the decision tree:
ip_len <= 377: 2 (269728/120)
ip_len > 377:
:...udp_dport <= 1187: 2 (908)
udp_dport > 1187: 1 (8547)
See5/C5.0 can also be set to output a set of decision rules. Following are examples of these decision rules:
Rule 1: (8547, lift 32.2)

ip_len > 377, udp_dport > 1187

class 1 [1.000]

Rule 2: (262430, lift 1.0)

udp_dport <= 1187 class 2 [1.000]

Rule 3: (269728/120, lift 1.0)

ip_len <= 377 class 2 [1.000]

5-3 INTRUSION PREVENTION

The objective of intrusion prevention is to filter out potential attacks. The most
common technique for this purpose is using a firewall. In our design and implementation, IPTables Version 1.2.11 developed by Netfilter/IPTables Software
[33] is selected to perform this task.
IPTablesis used to set up, maintain, and inspect the tables of IP packet filter
rules in the Linux kernel.IPTables has three ways using three tables to handle
packets (Filter, NAT, and Mangle). For intrusion prevention task, we choose to
filter out malicious packets.
The filtertable containsanumberof built-in chains and may also contain userdefined chains. Eachchainis a list of rules which can match a set of packets.
94

Component-based Software Design

Han et al

Each rule specifies what to do with a packet that matches.This is called a target, which may beajumptoauser-defined chain in the same table.
The requires interface of IPTables is a set of firewall rules. These rules can be
set from the console or a system file, e.g. /etc/sysconfig in CentOS.These firewall rules have the following format:
-A INPUT -m <matching options> <<matching options option>
<matching option parameter> <target -j REJECT|ACCEPT|...>
-A INPUT -p tcp --src-port 80-m length --length 100 -j REJECT
There are many matching options available for IPTables.
IPTables does not have explicit provides interface, but provides a packet-filtering service. Afirewall rule specifies criteria for a packet and a target.If the
packet does not match, the next rule in the chain is examined; if it does match,
then the next rule isspecified bythevalue of the target, which can be the name
of a user-defined chain or one of the special values ACCEPT, DROP, QUEUE,
or RETURN. ACCEPT means to let the packet through. DROP means to drop
the packet onthefloor.QUEUE means to pass the packet to user space (ifsupported by the kernel).RETURN means stop traversing this chain and resume
at the next rule in the previous (calling) chain. If the end ofabuilt-inchain is
reached or a rule in a built-in chain with target RETURN is matched, the target
specified by the chain policy determines the fate of the packet.
Figure 3 shows the implementation architecture of our component-based intrusion detection and prevention system with requires and provides interfaces of
each component.
Internet
the
unknown

SNORT

Packet data

Data adaptor
IPTables Firewall

Converted data
Prevention firewall
Rules

Pattern adaptor

Detection decision
tree

See5/ C5.0

Figure 3 Component interfaces

Figure 3 Component interfaces

95
6- THE ADAPTOR COMPONENTS DESIGN

Int.J. of Software Engineering, IJSE Vol.2 No.3 December 2009

6- THE ADAPTOR COMPONENTS DESIGN

In order to compose COTS components to create a system, glue code that
links the components may be needed [12]. This glue code can be either simple
statements or adaptor components to tackle the problem of incompatibility between the provides and requires interfaces of these COTS products. Generally,
an adaptor component is to convert one interface to another. The precise form
of the adaptor component depends on the type of composition.
Two adaptor components in the architecture in Figure 2 are Data adaptor and
Pattern adaptor. The main task of Data adaptor is to reconcile the provides
interface of Snort to the requires interface of See5/C5.0, while Pattern adaptor
is to reconcile the provides interface of See5/C5.0 to the requires interface of
IPTable.

6-1 THE DATA ADAPTOR

The Data adaptor component converts the provides interface of Snort, which is
a MySQL database with six tables, to the requires interface of See5/C5.0, which
is of two files: .names and .data. This transformation can be done by either using a software program such as ODBC and JDBC or writing a transformation
program such as a PHP script. The latter is chosen in our system design and
implementation.
Since packets for different protocols have different data items (features), while
See5/C5.0 requires all instances have the same attributes, the Data adaptor
component needs to distinguish these packets. Three PHP scripts are written to
extract packets with protocols tcp/ip, udp and icmp.
In our implementation, we use PHP scripts embedded SQL to port the Snort
MySql database into a format that See5 can understand. While the PHP script
is in execution, it opens the Snort database and stores it in a buffer for manipulation. Storing the Snort database into a buffer is an advantage because manipulating the data in the database using PHP is faster and more efficient than
manipulating the Snort database directly from the MySQL command console.
Once the Snort database is stored in the buffer, the PHP script begins to select
the data via queries from multiple tables that we think are the most important to
our research. While the data is being selected, it is simultaneously being stored
into a new table within the Snort database. Once the PHP script fulfills selecting and adding the related data into the new table, it is now possible to directly
export the new table into a flat file with the .data extension that is required to
run See5 [29].
Basically, the transformation of data from the Snort database to the See5 system includes converting the database schema into the .names file and selecting
data from tables to generate the .data file, both of which are required as the
input See5 for its execution.

96

Component-based Software Design

Han et al

6-2 THE PATTERN ADAPTOR

The requires interface of the Pattern adaptor component is either a decision tree
or a set of decision rules generated by See5/C5.0, while its provides interface
is an iptable that will be used by IPTables. The objective of this component is to
automatically transform a decision tree or a set of decision rules to the format
of iptable. This task is performed by a PHP script to synchronize with the Data
adaptor component.
The Pattern adaptor component is implemented in two steps. The first step is to
sort and format decision rules (or represented as a decision tree) for preparation of converting them into the firewall rules. The rule set generated from See5/
C5.0 contains a massive amount of information. In terms of the rule search that
IPTables matches packets, finding a way to convert the result information to
best prevent potential attacks is necessary. The second step is to create a way
to generate and refine the firewall rules, and place the firewall rules into the firewall. This step forces the new generated rules into the existing iptables in order
to preserve the previous information.
This transformation is performed by analyzing the tree, finding the
path to sig_class_id = 1 (indicating malicious), applying conversion to
each rule along the path, and applying the matching to the iptables
rule.
The attributes whose conversion in the standard iptables could not
be found are excluded. For TCP these were ip_id, ip_csum, tcp_seq,
tcp_off, tcp_win, and tcp_csum. Matching for these attributes would
need to be done in the iptables U32.
To transform a See5 tree into iptables rules, the following steps need
to be done:
- The first stage is to find all the rules for each classification. We took both 0
(not malicious) and 1 (malicious) classification, mainly 1 for being malicious
and gathered all the rules.
(eg. under tcp (tcp_sport > 1104) & (ip_len > 1272) & (tcp_sport < 1100) classified as 1 malicious)
- Each rules would be sorted to find ranges for many of the attributes such as
ports.
(eg. under tcp (tcp_sport > 1100) & (tcp_sport < 11004) & (ip_len > 1272))
- The rules would then be converted as follows:
under tcp rules to -p tcp
(tcp_sport > 1100) & (tcp_sport < 1104) to --source-port 1100:1104

97

Int.J. of Software Engineering, IJSE Vol.2 No.3 December 2009

(ip_len > 1272) to -m length --length 1272:65535

Then the above conversion is added to the rule format which starts with a
<chain> and ends with -j <target>. The result below:
-a CSRL-RULES -p tcp --source-port 1100:1104 -m length length
1272:65535 -j REJECT
The -a CSRL-RULES is the chain which is chained to RH-Firewall-1-INPUT
which is chained to INPUT chain.
The above line generated is added to the /etc/sysconfig/iptables file. Once all
the rules have been converted, then the command service iptables restart is
executed.

7- THE SYSTEM IMPLEMENTATION AND EXPERIMENT

7-1 THE SNORT SETUP
The setup of the SNORT system is important in order to collect packets or test
new SNORT rules as the SNORT program can be used for either [7]. A tap is set
up to have the network traffic be repeated to the station with the SNORT system
set in promiscuous mode in order to excerpt network traffic.
When the SNORT system is setup during installation, the MySql database management system [34] is used as the SNORT database. The main point on this
one is to get normal traffic and suspected intrusion traffic recorded on to the network sniffer. We use two servers running a Linux server and a Windows server
respectively in order to keep the gathering of information more cross platform.
To check if the SNORT rule added works, we have to use the signature table
looking at the sig_sid column. The SNORT community has chosen to allocate
sig_sid in one millions local rules that will be used. The way that SNORT holds
the IP addresses in the database is using the aton form to make the IP address
an integer to hold and compare. Once that is complete we can then move on to
the transfer of the database for use by other applications such as JACED_IPTables.php [33] and see5 [29].
We set up the network with taps to gather the information then set the SNORT
system up to collect the information that can be used.
The SNORT system uses a rule set to set an action based on rules as to whether to capture a network packet or release it. The SNORT community keeps a
directory full of files that put over 2k rules for specific network intrusions. The full
documentation of the snort rules can be found in [7].

98

Component-based Software Design

Han et al

An example for us to look and dissect is:

alert tcp any any 192.168.1.0/24 111
(content:00 01 86 a5; msg:mountd access;)
The first part of the rule is the login method there is alert, log, pass, activate,
dynamic, drop, reject, and sdrop.
The second part of this example is the protocol type that it detects TCP, UDP,
ICMP, and IP are the current protocols snort is able to detect.
The next part is for the IP address and port information witch can be given a key
word any for any IP or any port. The directional can be also <> to specify any
direction. The rule can treat incoming or outgoing network packet information
with the directional switch ([], [], <>).
Using above packet protocol pattern, we can start looking at the specifics enclosed in the parentheses. This field has many options, e.g. sid to identify each
rule, the msg option to add a comment to the database.
Above login method can be changed. For this purpose, we created a new type
of method using the following lines in the snort.config file:
ruletype nonalert
{
type alert
output database: log,
dbname=snortTest

mysql,

user=snort

password=password

host=localhost
}
This rule type creates an alert called nonalert to capture incoming traffic into a
database called snorttest.
The following are the rules that are added to the database using above rule type
nonalert to log normal traffic
pass tcp 0.0.0.0 any <> $HOME_NET any
pass udp 0.0.0.0 any <> $HOME_NET any
pass icmp 0.0.0.0 any <> $HOME_NET any
pass ip 0.0.0.0 any <> $HOME_NET any
nonalert tcp $EXTERNAL_NET any <> $HOME_NET any (msg:Traffic
CSRL 1.0 tcp; classtype:not-suspicious; sid: 1000001;)
99

Int.J. of Software Engineering, IJSE Vol.2 No.3 December 2009

nonalert udp $EXTERNAL_NET any <> $HOME_NET any (msg:Traffic

CSRL 1.0 udp; classtype:not-suspicious; sid: 1000002;)
nonalert icmp $EXTERNAL_NET any <> $HOME_NET any
(msg:Traffic CSRL 1.0 icmp; classtype:not-suspicious; sid: 1000003;)
nonalert ip $EXTERNAL_NET any <> $HOME_NET any (msg:Traffic
CSRL 1.0 ip; classtype:not-suspicious; sid: 1000004;)
We add a rule in the file of local. Rules to the community downloaded rules and
check the SNORT database in order to confirm implementation of the new rule.
To get a view of the database stored in our system under MySql, we use the
describe command on all tables. Then later when the system is populated with
logs, the select query finds what is in the tables. The .config and .conf files of
the SNORT system are also used to find what is called and what is skipped from
the file systems /etc/snort/ directory for the SNORT system [7]
These rules filter out traffic from the routers and then log the incoming traffic into
the nonalert database snorttest.

7-2 THE DATA ADAPTOR IMPLEMENTATION AND EXPERIMENT

In order to adhere to the See5 system format of the data set, we need to convert
various tables in the SNORE database. The transformation can be done by either using a software program such as ODBC and JDBC or writing a transformation program such as a PHP script. The latter is chosen in the implementation of
our system since the SNORE system is setup with MySQL and it is to write PHP
scripts to extract information from the MySQL database [28].
PHP (Personal Home Page) is a computer scripting language originally designed for producing dynamic web pages. In our implementation, we are using
PHP to communicate directly with the SNORT database so that the data in
MySql can be ported into a format that See5 will understand. While the PHP
script is in execution, it opens the SNORT database and stores it in a buffer
for manipulation. Storing the SNORT database into a buffer is an advantage
because manipulating the data in the database using PHP is faster and more
efficient than manipulating the SNORT database directly from the MySQL command console. Once the SNORT database is stored in the buffer, the PHP
script begins to select the data via queries from multiple tables that we think are
the most important to our research. While the data is being selected, it is simultaneously being stored into a new table within the SNORT database. Once the
PHP script is finished selecting and adding the related data into the new table,
it is now possible to directly export the new table into a flat file with the .data
extension that is needed to run See5.
Basically, the transformation of data from the SNORT database to the See5
system includes converting the database schema in to a .names file and selecting data from tables to generate the .data file, both of which are required as the
input See5 for its execution. The See5 system execution will output either a set
100

Component-based Software Design

Han et al

of classification rules or a decision tree.

The MySql commands are embedded in the PHP scripts to quickly generate
the desired results. The following is a snippet of PHP script that is used in our
implementation to define the query from the acid_event table.
$eventQuery=select cid,sig_class_id, sig_priority, timestamp, layer4_
sport, layer4_dport, signature from acid_event order by cid;;
$resultEvent = mysql_query($eventQuery, $conn) or die(problemi .
mysql_error());
$cidNum=mysql_num_rows($resultEvent) or die(snap); echo $cidNum . <br />;
$resultIPHDR = mysql_query(select * from iphdr order by cid;,
$conn) or die(problem);
echo mysql_num_rows($resultIPHDR). <br />;
$iphdrNum = 0;
$iphdrMax = mysql_num_rows($resultIPHDR);
By embedding these queries into our intrusion detection system to get network
traffic into a database to be used for data mining this makes automation of this
process can be made with an interface, in order to have the process do the data
set retrieval.

7-3 THE PATTERN RECOGNITION EXPERIMENT

To experiment with the pattern recognition component, 18 attributes from the
SNORT database are choosen and selected for the input to See5. These attributes are listed in Appendix A.1.
The output of See5 is a decision tree that determines the malicions visit. Our
experiment with TCP protocol is illustrated in Appendix A.2, which corresponds
to the decision tree in Appendix A.3.

7-4 THE INTRUSION PREVENTION EXPERIMENT

The decision rules generated by See5 are converted to the firewall rules and
are set to the firewall system. This is accomplished by the pattern adaptor. The
firwall rules that are transformed from the decision rules generated by See5 is
listed in Appendix B.

8- CONCLUDING REMARK AND FUTURE WORK

In this paper, the component-based software engineering approach is exploited
to develop the architecture and implement the software system for automatic
network intrusion detection and prevention. The network intrusion detection and
prevention process is introduced, the requirements of intrusion detection and
101

Int.J. of Software Engineering, IJSE Vol.2 No.3 December 2009

prevention system is analyzed, the component-based software architecture with

sequential composition is designed, the components requirements as well as
requires and provides interfaces are investigated and COTS products are selected to meet these components requirements, and two adaptor components
are developed to glue COTS components by reconciling the provides interface
of one component and the requires interface of another. These adaptor components are implemented in the PHP language.
The environment for the network intrusion detection and prevention system has
been set up in the computer security research laboratory (CSRL) at the California State University, Dominguez Hills, the initial version of the software system
has been implemented, and the preliminary experiment has been conducted.
As discussed in this paper, the adaptor components transform audit data from
one COTS component to another, which causes overhead of the system performance, such as selecting/querying network traffic data from multiple sensors.
However, the impact of this overhead on the system performance has not been
studied yet. Our future work will focus on the following: improvement and refinement of the adaptor components, more experiments on real-time traffic data,
the system performance, and online deployment of the system with incremental
data mining algorithms and dynamic update of firewall rules.

APPENDIX A
A-1 ATTRIBUTES USED IN See5
Decision attribute:
sig_class_id:

integers 1 to 34

| description of alert

Condition attributes:
sig_priority:

continuous

| priority from classification

ip_ver:

continuous

| vertion of ip common 4

ip_hlen:

continuous

| total lenght of header information 32

ip_tos:

continuous

|type of service used. random?

ip_len:

continuous

| total lenght of datagram

ip_flags:

continuous

| 3 bits with 001 = fragd, 010 = if its

bits.

102

last part;added1,2

Component-based Software Design

Han et al

ip_off:
N/A,0

| used by routers to fragment data-

grams by offseting;addedN/A

ip_proto:

continuous

| Protocol <=list

opt_proto:

continuous

| what is in data

opt_code:

continuous

| what is in data; added148

opt_len:
continuous

| used to determin the lenght of the

datagram

tcp_off:

0,5 to 12

| offset to reasemble packet.

tcp_flags:

N/A,0,2,4,16,17,18,20,24,25,194,196.

tcp_urp:

| 6 bit number for flags. 194 is more t

hen 6 bits?

N/A,0,1,512,7424,64630,23410,45075

| urgent bit, points to end of urgent

massage

icmp_type:
continuous.

| massage about the routs datagrams

take only.

icmp_code:

N/A,0,1,2,3,4,10,13

| 8 bit depends on the icmp type.

icmp_seq:

continuous

| ICMP sequence number

A-2 DECISION TREE GENERATED BY See5 FOR TCP PROTOCOL

See5 [Release 2.05] Tue Nov 25 16:28:08 2008
------------------Class specified by attribute `sig_class_id
Read 235584 cases (24 attributes) from see5tcp.data
Attributes excluded:
ip_id
ip_csum
tcp_seq
tcp_off
tcp_win
tcp_csum
103

Int.J. of Software Engineering, IJSE Vol.2 No.3 December 2009

Decision tree:
ip_flags > 0: 1 (1157)
ip_flags <= 0:
:...ip_len > 357:
:...ip_src <= 3.520088e+009:
: :...tcp_sport <= 1104: 2 (36356/14)
: : tcp_sport > 1104:
: : :...tcp_dport <= 285:
: :
:...ip_len <= 1272: 2 (370/4)
: :
: ip_len > 1272:
: :
: :...ip_src <= 3.284041e+009: 1 (37/2)
: :
:
ip_src > 3.284041e+009: 2 (2)
: :
tcp_dport > 285:
: :
:...ip_len > 479: 2 (54/2)
: :
ip_len <= 479:
: :
:...ip_len > 374: 1 (424)
: :
ip_len <= 374:
: :
:...ip_len <= 370: 2 (8)
: :
ip_len > 370: 1 (98)
: ip_src > 3.520088e+009:
: :...ip_ttl <= 107:
:
:...tcp_sport <= 46209: 2 (22/2)
:
: tcp_sport > 46209: 1 (3)
:
ip_ttl > 107:
:
:...ip_ttl <= 178: 1 (496)
:
ip_ttl > 178:
:
:...ip_len > 425:
:
:...tcp_dport <= 285: 2 (10)
:
: tcp_dport > 285: 1 (7)
:
ip_len <= 425:
:
:...tcp_sport > 1915: 1 (196)
:
tcp_sport <= 1915:
:
:...ip_len <= 400: 2 (14)
:
ip_len > 400: 1 (25)
ip_len <= 357:
:...ip_len <= 78: 2 (153436/6)
ip_len > 78:
:...ip_len <= 81:
:...tcp_dport <= 5190:
: :...ip_ttl <= 127: 2 (1584)
: : ip_ttl > 127:
: : :...ip_dst > 1.438688e+009: 2 (923/43)
: :
ip_dst <= 1.438688e+009:
: :
:...ip_dst <= 1.156555e+009: 1 (13)
: :
ip_dst > 1.156555e+009: 2 (181/7)
104

Component-based Software Design

Han et al

: tcp_dport > 5190:

: :...tcp_dport > 52187: 2 (14)
:
tcp_dport <= 52187:
:
:...ip_ttl <= 127: 2 (2)
:
ip_ttl > 127:
:
:...tcp_dport <= 10173: 2 (5/1)
:
tcp_dport > 10173: 1 (12)
ip_len > 81:
:...ip_ttl <= 47:
:...ip_src <= 1.295234e+009:
: :...ip_len > 256: 1 (13)
: : ip_len <= 256:
: : :...ip_len <= 136: 1 (2)
: :
ip_len > 136: 2 (19/1)
: ip_src > 1.295234e+009:
: :...tcp_sport <= 24038: 2 (144)
:
tcp_sport > 24038:
:
:...ip_len <= 136: 2 (64)
:
ip_len > 136:
:
:...ip_len <= 149: 1 (8)
:
ip_len > 149: 2 (79/3)
ip_ttl > 47:
:...ip_ttl <= 178:
:...ip_len <= 135: 2 (16485/1)
: ip_len > 135:
: :...ip_len <= 140:
:
:...ip_len <= 136: 1 (24)
:
: ip_len > 136: 2 (120)
:
ip_len > 140:
:
:...tcp_sport <= 37937: 2 (17384/10)
:
tcp_sport > 37937:
:
:...ip_ttl <= 49:
:
:...ip_len <= 290: 2 (121/1)
:
: ip_len > 290: 1 (9)
:
ip_ttl > 49:
:
:...ip_src > 1.242446e+009: 2 (636)
:
ip_src <= 1.242446e+009:
:
:...ip_src <= 1.222776e+009: 2 (73/3)
:
ip_src > 1.222776e+009: 1 (5)
ip_ttl > 178:
:...tcp_sport <= 186: 2 (2734)
tcp_sport > 186:
:...tcp_dport > 808: 1 (41)
tcp_dport <= 808:
:...ip_src > 1.451703e+009: 2 (1928)
ip_src <= 1.451703e+009:
:...ip_src <= 1.058254e+009: 2 (188)
ip_src > 1.058254e+009:
105

Int.J. of Software Engineering, IJSE Vol.2 No.3 December 2009

:...ip_len <= 177: 2 (40)

ip_len > 177:
:...ip_src > 1.281022e+009: 1 (6)
ip_src <= 1.281022e+009:
:...ip_src > 1.094183e+009: 2 (4)
ip_src <= 1.094183e+009:
:...ip_len <= 276: 1 (4)
ip_len > 276: 2 (4)
Evaluation on training data (235584 cases):

Decision Tree

---------------
Size
Errors

51 100( 0.0%) <<

(a) (b) <-classified as

----- ----
2578 98 (a): class 1

2 232906 (b): class 2

Attribute usage:

100% ip_flags

100% ip_len

26% tcp_sport

19% ip_ttl

18% ip_src

3% tcp_dport
Time: 6.3 secs

A-3 DECISION RULES PRUNNED FROM THE DECISION TREE

See5 [Release 2.05] Thu Sep 11 13:51:24 2008
------------------Options:

Rule-based classifiers
Class specified by attribute `sig_class_id
Read 100274 cases (18 attributes) from see5udp.data
Rules:
Rule 1: (21338, lift 4.2)

ip_src > 2.161575e+008

udp_dport <= 138

-> class 0 [1.000]
Rule 2: (20068, lift 4.2)

ip_len > 86

udp_sport <= 138

-> class 0 [1.000]
Rule 3: (668, lift 4.2)

ip_len > 91
106

Component-based Software Design

Han et al

udp_dport > 1900

-> class 0 [0.999]
Rule 4: (2435/5, lift 4.2)

ip_dst <= 3.381627e+009

udp_len <= 47

-> class 0 [0.998]
Rule 5: (210, lift 4.2)

ip_len <= 80

udp_dport > 1900

-> class 0 [0.995]
Rule 6: (265, lift 1.3)

ip_src <= 2.161575e+008

udp_dport <= 138

-> class 1 [0.996]
Rule 7: (196, lift 1.3)

ip_id > 64056

ip_id <= 64242

udp_dport > 138

-> class 1 [0.995]
Rule 8: (78671/2358, lift 1.3)

udp_dport > 138

-> class 1 [0.970]
Default class: 1
Evaluation on training data (100274 cases):

Rules

---------------
No
Errors

8 8( 0.0%) <<

(a) (b) <-classified as

---- ---23688 8 (a): class 0
76578 (b): class 1

Attribute usage:
100% udp_dport
22% ip_src
20% ip_len
20% udp_sport
2% ip_dst
2% udp_len

Time: 2.3 secs

107

Int.J. of Software Engineering, IJSE Vol.2 No.3 December 2009

APPENDIX B
The firewall rules transformed from the decision rules generated from See5 are
listed as below:
# Firewall configuration written by system-configsecuritylevel
# Manual customization of this file is not recommended.
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:RH-Firewall-1-INPUT - [0:0]
:CSRL-RULES - [0:0]
:CSRL-CH01 - [0:0]
:CSRL-CH02 - [0:0]
:CSRL-CH03 - [0:0]
:CSRL-CH04 - [0:0]
:CSRL-CH05 - [0:0]
:CSRL-CH06 - [0:0]
:CSRL-CH07 - [0:0]
:CSRL-CH08 - [0:0]
:CSRL-CH09 - [0:0]
:CSRL-CH10 - [0:0]
:CSRL-CH11 - [0:0]
-A
-A
-A
-A

INPUT -j RH-Firewall-1-INPUT
FORWARD -j RH-Firewall-1-INPUT
RH-Firewall-1-INPUT -i lo -j ACCEPT
RH-Firewall-1-INPUT -j CSRL-RULES

#CSRL IPTABLES ADDITIONAL PROTO 1 WANNABEE - TCP WIN AND

THE CSUM
#OUT OF 28 POSSIBLE LEAVES 20 IMPLEMENTED
#-A RH-Firewall-1-INPUT -i bond0 -j CSRLRULES
-A CSRL-RULES -p tcp -f -j REJECT
-A CSRL-RULES -p tcp --source-port 0:46209 -m length
--length 357:65535 -m iprange --src-range 209.208.71.192255.255.255.254 -m ttl --ttl-lt 107 -j ACCEPT
-A CSRL-RULES -p tcp --source-port 46209:65535 -m length
--length 357:65535 -m iprange --src-range 209.208.71.192255.255.255.254 -m ttl --ttl-lt 107 -j REJECT
-A CSRL-RULES -p tcp -m length --length 357:65535 -m
108

Component-based Software Design

Han et al

iprange --src-range 209.208.71.192-255.255.255.254 -m ttl

--ttl-gt 107 -j CSRL-CH01
-A CSRL-CH01 -m ttl --ttl-lt 179 -j ACCEPT
-A CSRL-RULES -p tcp --destination-port 0:285 -m length
--length 357:65535 -m iprange --src-range 209.208.71.192255.255.255.254 -m ttl --ttl-gt 107 -j CSRL-CH02
-A CSRL-CH02 -m ttl --ttl-gt 178 -j ACCEPT
-A CSRL-RULES -p tcp --destination-port 285:65535
-m length --length 425:65535 -m iprange --src-range
209.208.71.192-255.255.255.254 -m ttl --ttl-gt 107 -j
CSRL-CH03
-A CSRL-CH03 -m ttl --ttl-gt 178 -j REJECT
-A CSRL-RULES -p tcp --destination-port 285:65535
-m length --length 425:65535 -m iprange --src-range
209.208.71.192-255.255.255.254 -m ttl --ttl-gt 107 -j
CSRL-CH04
-A CSRL-CH04 -m ttl --ttl-gt 178 -j REJECT
-A CSRL-RULES -p tcp --source-port 1915:65535 -m length
--length 357:425 -m iprange --src-range 209.208.71.192255.255.255.254 -m ttl --ttl-gt 107 -j CSRL-CH05
-A CSRL-CH05 -m ttl --ttl-gt 178 -j REJECT
-A CSRL-RULES -p tcp --source-port 0:1915 -m length
--length 357:400 -m iprange --src-range 209.208.71.192255.255.255.254 -m ttl --ttl-gt 107 -j CSRL-CH06
-A CSRL-CH06 -m ttl --ttl-gt 178 -j ACCEPT
-A CSRL-RULES -p tcp --source-port 0:1915 -m length
--length 400:65535 -m iprange --src-range 209.208.71.192255.255.255.254 -m ttl --ttl-gt 107 -j CSRL-CH07
-A CSRL-CH07 -m ttl --ttl-gt 178 -j REJECT
-A CSRL-RULES -p tcp --source-port 0:1104 -m length
--length 357:65535 -m iprange --src-range 0.0.0.1209.208.71.192 -m ttl --ttl-gt 107 -j ACCEPT
-A RH-Firewall-1-INPUT -i eth0 -j ACCEPT
-A RH-Firewall-1-INPUT -i eth1 -j ACCEPT
-A RH-Firewall-1-INPUT -i bond0 -j ACCEPT
COMMIT
109

Int.J. of Software Engineering, IJSE Vol.2 No.3 December 2009

ACKNOWLEDGMENT
This paper is based on work supported by the National Science Foundation
(NSF) through grant CNS-0540592 and NGA. Any opinions, findings, and conclusions or recommendations expressed in the paper are those of the authors
and do not necessarily reflect the views of the NSF.

REFERENCES
[1] R. G. Bace, Intrusion Detection, Sans Publishing, 1999.
[2] G. Pour, Component-Based Software Development Approach: New
Opportunities and Challenges, Proceedings Technology of Object-Oriented
Languages, 1998. TOOLS 26., pp. 375-383.
[3] H. Debar and A. Wespi, Aggregation and Correlation of Intrusion-Detection
Alerts. Proc. of RAID, 2001.
[4] P. Ning, Intrusion Detection in Distributed Systems: An Abstraction-Based
Approach, Springer, 2003.
[5] D. Wagner and D. Dean, Intrusion Detection via Static Analysis,
Proceedings of the 2001 IEEE Symposium on Security and Privacy, 2002.
[6] C. Y. Chung, M. Gertz, and K. Levitt, Discovery of Multi-Level Security
Policies, The Fourteenth Annual IFIP WG 11.3 Working Conference on
Database Security, 2000
[7] M. Roesch, The Story of Snort: Past, Present and Future. 2005, http://www.
net-security.org /article.php?id=860 .
[8] L. L. Peterson and S. B. Davie, Computer Networks: A systems Approach,
Morgan Kaufmann Publisher. San Francisco, CA. 2003.
[9] J. Han, K. Kowalski, M. Beheshti, Detecting Network Intrusions Based on
a Generalized Rough Set Model, Proc. of International Symposium on
Telecommunications, 247-252, September 10-12, 2005, Shiraz, Iran.
[10] J. Gomez and D. Dasgupta, Evolving Fuzzy Classifiers for Intrusion
Detection, Proc. of IEEE Workshop on Information Assurance, New York,
June, 2002.
[11] L. Kuang, and M. Zulkerning, An Anomaly Intrusion Detection Method using
the CSI-KNN Algorithm, pp. 921-926, The 23rd Annual ACM Symposium on
Applied Computing, Fortaleza, Brazil, 2008.
110

Component-based Software Design

Han et al

[12] I. Sommerville, Software Engineering, 8th ed. Addison-Wesley, 2007.

[13] G. T. Heineman, W. T. Councill, Component-based Software Engineering:
Putting the Pieces Together, Addison-Wesley, 2001.
[14] H. W. Schmidt, I. Crnkovic, G. T. heineman, and J. A. Stafford (eds.),
Component-Based Software Engineering, Lecture Notes in Computer
Science 4608, Springer, July 2007.
[15] C. Szyperski, Component Software: Beyond Object-oriented Programming,
2nd ed. Addison-Wesley, 2002.
[16] E. Kirda, S. Jha, and D. Balzarotti, Recent Advances in Intrusion Detection,
Lecture Notes in Computer Science, Vol. 5758, 2009. Springer Berlin/
Heidelberg.
[17] R. Lippmann, E. Kirda, and A. Trachtenberg, Recent Advances in Intrusion
Detection, Lecture Notes in Computer Science, Vol. 5230, 2008. Springer
Berlin/Heidelberg.
[18] S. Y. Yau, and X. Zhang, Computer Network Intrusion Detection,
Assessment and Prevention Based on Security Dependency Relation, 23rd
Annual International Computer Software and Applications Conference, pp.
86-91, 1999.
[19] R. A. Kemmerer, and G. Vigna, Sensor Families for Intrusion Detection
Infrastructures, Managing Cyber Threats: Issues, Approaches and
Challenges, ed. By V. Kumar, J. Srivastava and A. Lazarevic, Vol. 5, pp.
1-41, Springer-Verlag, 2005.
[20] J. Blumenthal, m. Handy, F. Golatowski, M. Haase, and D. Timmermann,
Wireless Sensor Networks New Challenges in Software Engineering,
Proc. IEEE International Conference on Emerging Technologies and
Factory Automotion, pp. 551-556, 2003.
[21] L. Mostarda, and A. Navarra, Distributed Intrusion Detection Systems for
Enhancing Security in Mobil Wireless Sensor Networks, International
Journal of Distributed Sensor Networks, Vol. 4, Issue 2, pp. 83-109, 2008.
[22] P. Inverardi, and L. Mostarda, DESRT: a decentralized monitoring tool
generator, Proc. of the 22nd IEEE/ACM International Conference on
Automated Software Engineering, pp. 529-530, 2007.
[23] M. Hussein, and M. Zulkernine, Intrusion detection aware component111

Int.J. of Software Engineering, IJSE Vol.2 No.3 December 2009

based systems: A specification-based framework, Journal of Systems and

Software 80(5): pp. 700-710, 2007
[24] B. Claude, N. D. Palma, R. Lachaize, and D. Hagimont, Self-protection
for distributed Component-Based Applications, Lecture Notes in Computer
Science, Vol. 4280, pp. 184-198, Springer Berlin/Heidelberg, 2006.
[25] W. Lee, J. Cabrera, A. Thomas, N. Balwalli, S. Saluja, and Y. Zhang,
Performance Adaptation in Real-Time Intrusion Detection Systems, Proc.
of RAID, 2002.
[26] W. Lee, and S. Stolfo, A Framework for Constructing Features and Models
for Intrusion Detection Systems, ACM Transactions on Information and
System Security: 3 (4), November 2000.
[27] D. Dittrich, Network sniffers and You, http://staff.washington.edu/dittrich/
misc/sniffers/, 1998.
[28] B. Schwartz, P. Zaitsev, V. Tkacbenko, J. D. Zawodny, A. Lentz, & D. J.
Balling, High Performance MySQL, OReilly Media, 2nd ed., 2008.
[29] Rulequest Research, See5: An Tutorial, http://www2.cs.uh.edu/~ceick/ai/
C5-Tutorial.html
[30] K. Julisch and M. Dacier, Mining intrusion detection alarms for actionable
knowledge, Proc. of the 8th ACM SIGKDD, 366-375, 2002.
[31] B. Richard, The Tao of Network Security Monitoring: Beyond Intrusion
Detection. Pearson Education, Inc., 2004, Boston, MA.
[32] J. R. Quinlan, C4.5: Programs for Machine Learning, Morgan Kaufmann
Publisher, 1993.
[33] O. Andreasson, IPTables Tutorials 1.2.2, http://iptables-tutorial.frozentux.
net/iptables-tutorial.html
[34] W.P. Stevens, How Data Flow can Improve Application Development
Productivity, IBM System Journal, Vol. 21, No. 2, 1982.

112