Intrusion Detection Management System for

eCommerce security

Jens Lichtenberg

and Jorge Marx G

omez

Ohio University, Athens, OH, USA,

Otto-von-Guericke-Universit

at, Magdeburg, Germany,

Abstract. One of the main problems in eCommerce applications and all other

systems handling conﬁdential information in general, is the matter of security.

This paper introduces the idea of an intrusion detection management system to

support the security. Intrusion detection per se, is the act of detecting an unautho-

rized intrusion by a computer or a network from the inside or the outside of the

affected system, making an intrusion the attempt to compromise or otherwise do

harm to other network devices. Next to the normal intrusion detection system an

Intrusion Management System applies different Intrusion Detection Systems to

not only detect a threat but also analyze it and propose counter measures to avoid

the compromise of the guarded system. For the treatment plan, depending on the

analysis, a multitude of counter measures is identiﬁed and ranked. The counter

measure identiﬁcation is done using data mining techniques on a counter mea-

sure repository, the ﬁnal ranking through sorting algorithms. Of the numerous

data mining techniques applicable for diagnostic or analytic purposes the nearest

neighbor and the correlation coefﬁcient techniques have been implemented. A

feasibility study has shown that an analyzer can match a problem against a solu-

tion repository and ﬁnd the optimal treatment suggestions, applied with a rank-

ing, in an acceptable short period of time. Future work will include the analysis

of attack characteristics and goals, and the interaction between system manager,

response planning and execution module and the attack analyzer. Furthermore the

counter measure repository will be evaluated and updated.

1 Introduction

An ecommerce system can be regarded as a distributed real-time system. Being an as-

sortment of different systems, some for interaction purposes, some for customer support

and some only for backup purposes, the distributed ecommerce system has to manage

the different resources to provide the best quality of service. The main research in dis-

tributed systems has focused recently on the development of powerful middleware ar-

chitectures and strong allocation algorithm ([2],[3],[4],[5],[6],[7]). Most of the resource

management architectures lack an integrated security component.

To address this problem, this paper builds upon the SECURE-RM idea developed

by the CIDDS workgroup at Ohio University, described in chapter “Related Work”. The

module proposed in this paper, enables the Secure-RM architecture to compare attack

pattern with solution ideas and ﬁnd the best solution for an impending attack.

Lichtenberg J. and Marx Gómez J. (2005).

Intrusion Detection Management System for eCommerce security.

In Proceedings of the 5th International Workshop on Pattern Recognition in Information Systems, pages 134-143

DOI: 10.5220/0002520101340143

 SciTePress

The matter of security in distributed systems in general and ecommerce systems

in particular is still a very serious problem. The integration of a solution identiﬁcation

module into a secure resource management environment, would provide the ecommerce

platform with the normal agility gained through the resource allocations by the resource

manager and also with another security layer. The identiﬁcation and defeat of attacks

on the ecommerce service provider side, helps him build trust and might even attract

customers that are currently scared off because of popular security breeches (Postbank

scandal in Germany, Late summer 2004).

2 Related Work

2.1 Secure-RM

Ecommerce systems, as much as other distributed real-time systems, have little toler-

ance for missing deadlines. If a distributed real-time system is attacked, the systems

performance may decrease since it is utilized increasingly and anomalously. This could

result to a system wide failure or malfunctioning. Since most of the mentioned resource

management systems lack the security component, Ohio University’s CIDDS research

group proposed an architecture called SECURE-RM ([8]).

SECURE-RM, as shown in Figure 1, employs multiple Intrusion detection systems,

gathering information about pending attacks. This information is analyzed by the Secu-

rity Management, which together with the “normal” resource management grasps the

impact of the intrusion and derives an action advice for the resource allocation enactor.

Fig.1. SECURE-RM

2.2 Intrusion Detection Systems

An intrusion according to Webster is “the act of wrongfully entering upon, seizing, or

taking possession of the property of another” ([9]). In computer science terms, intrusion

detection is the act of detecting an unauthorized intrusion by a computer or a network

from the inside or the outside of the affected system, making an intrusion the attempt

135

to compromise or otherwise do harm to other network devices. There are two kinds of

Intrusion Detection Systems, the ﬁrst analyzes log ﬁles from routers, ﬁrewalls, servers

and other network devices to detect previously known attack signatures, which have

been stored beforehand in the IDS’s database ([1]). This system, called rule-based IDS,

is fast and very secure in detecting older attacks, however it cannot protect a system

against attacks that occur for the ﬁrst time. The second type of IDS, the behavioral

based systems, store a “normal” system behavior into a database and analyzing log ﬁles

to determine an abnormal system state and certain behavior according to the state. This

method allows for the detection of new unknown attacks but is susceptible to false pos-

itive and false negative alerts thus dampening the trust in the system. An IDS can, upon

detection of an intrusion, issue alarms or alerts and take various kinds of automatic

action, ranging from shutting down Internet links or speciﬁc servers to launching back-

traces. The implementation of an Intrusion Detection System can be software based,

hardware based or combined in preinstalled and preconﬁgured stand-alone IDS boxes.

There are three basic types of Intrusion Detection Architectures implementing Intrusion

Detection Systems: Network based IDS, Host based IDS and Distributed IDS.

In practice a combination of all three approaches can be implemented to allow for

a higher state of security. An IDS can not only serve as an intrusion detector alone, but

can also monitor database access, DNS functionality and it can also protect the e-mail

servers and be applied as a company policy watch to provide the enterprise with the

possibility to enforce copyright and electronic laws.

2.3 SNORT

An example for an intrusion detection system is SNORT ([1]), an efﬁcient, stable, free-

ware, and open source implementation. It is considered a lightweight intrusion detection

system, leaving a small footprint on the system with the possibility to run on various

platforms, including Windows and Unix. Providing a real-time IP trafﬁc analysis there

are three ways to conﬁgure SNORT’s core packet sniffer. In the ﬁrst conﬁguration, it is

unaltered set up as a network sniffer, reading packages of the network and displaying

them to the screen. The second way is a setup as a package logger, writing transmit-

ted packages to the disks. The last way is a setup up as a network intrusion detection

system, analyzing network trafﬁc for matches against a user-deﬁnable rule-set, making

SNORT a rule-based IDS with the ability to identify:

– CGI scans

– Buffer overﬂows

– SMB probes

– Unauthorized server services

– OS ﬁngerprinting attemps

– Obfuscation (camouﬂaging the source code)

Identifying an intrusion, SNORT can record, ignore or alert a system administrator

about the unhealthy trafﬁc activities. The logging or alerting methods can be set up

using Syslog, XML, plain text or WinPopUps.

The Snort Architecture as shown in Figure 2 consists of a Sniffer, a Preprocessor,

a Detection Engine, and an alert and logging module, responsible for the output. The

136

Sniffer, as SNORT’s core component, is responsible for network analysis and trou-

bleshooting. It can analyze and benchmark the performance of the network backbone

and can be used to eavesdrop for security risks like clear-text passwords. The raw data

packages picked up by the Sniffer are then passed on to the Preprocessor, which formats

them according to speciﬁc plug-ins, which also check for certain behavior types in the

packages and then pass them on to the detection engine. In the detection engine the data

is checked against a set of rules. If rules match the data in package, they are send to the

alert and logging processor, where they can be passed to different outputs.

Fig.2. SNORT Architecture

The open lines or current pitfalls of the SNORT architecture and IDS, in general, are

mostly the missing of a number of packages, allowing the chance of intrusion attempts

to go unnoticed, and the necessary handling of false positives and negatives, whereas

the false negatives are much more dangerous then false negatives, since they can allow

the inﬁltration of a system without notice of the IDS and system administrator.

2.4 INBOUNDS

INBOUNDS, the Integrated Network-Based Ohio University Network Detective Ser-

vice, is network based real-time intrusion detection systems, developed at Ohio Univer-

sity as a project of Tjaden, Welch and Ostermann ([8]). It detects suspicious behavior,

which marks it as a misuse or behavioral detecting IDS. INBOUNDS analyzes infor-

mation gathered by package sniffers, like TCPTrace, and system host monitors, using

those supplied by Ohio Universitys DeSiDeRaTa Resource Management architectures.

The usage of system monitors and different package sniffers make INBOUNDS an in-

tegrated system, allowing its low overhead and scalability properties. The INBOUNDS

architecture consists of ﬁve components and is designed to function in a large distrib-

uted system, where security and Quality of Service level must be insured dynamically.

There are ﬁve architectural levels. The Data collection captures, ﬁlters, processes, and

summarizes system information. It is assembled out of different package sniffers, hosts

and network monitors. Each data collection module produces a data stream, which is

stored in the historical and current data repository. The data visualization module and

the ﬁnal analysis module can request the data in the current data repository. The histor-

ical data repository summarizes the information from the collection module. The data

137

visualization module allows the user to view a visualization of the data streams in the

current and historical repository, to help him making sense of the gathered information.

The ﬁnal Intrusion Detection service recognizes suspicious behavior and notiﬁes the

historical data repository and the visualization module to record and display the alert.

Currently the system is implemented at Ohio University for intrusion detection. The

main research projects concerning INBOUNDS is the strengthening of the DeSiDeRaTa

Inbounds link within the Secure-RM, to allow an insight into attack strategy ([10], [11]).

Through the knowledge about the attack signatures a decision maker could be applied

to diagnose the effect of applicable counter measures.

3 Modular Framework

This chapter proposes a solution identiﬁcation module for occurring security problems.

The basic structure of the module is shown in Figure 3. An attack is detected and iden-

tiﬁed by the intrusion detection systems. The attack proﬁle is passed on to the solu-

tion identiﬁcation module, which then matches the attack pattern to different solutions

through the means of data mining. Possible solutions are ranked and a solution report

is passed on to an enactor component, which has to conduct the necessary measures to

secure the system. After the deployment of security measures, the enactor stores posi-

tive feedback in the solution repository. Solution algorithms can also be added, deleted

or modiﬁed manually in the repository.

Fig.3. Module Framework

The Solution Identiﬁcation Module creates structures of the attack proﬁle and the

different solutions. After preprocessing the necessary information the two structures

are handed down to the data mining technique. Setting solutions and attack proﬁle in

relation, the preliminary results are sorted according to their attack compatibility. The

separation of the data mining technique and the actual module allows for fast updates

of techniques according to speciﬁcations and experimental data and also ensures that

the technique used is the best and latest choice for the problem at hand.

To allow the system to stay up to date, the used data mining techniques can be ex-

changed easily. This exchangeability of the techniques allows for a thorough testing and

experimenting, which techniques provide the best performance under everyday usage.

138

In the context of this research two techniques have been implemented into the “Tech-

nique Library”. First, we have the Nearest Neighbor technique, which is an algorithm

implementation of the Inductions Decision Tree paradigm. Correlation Coefﬁcient tech-

nique, marking the second approach, is part of Multivariate Exploratory Data Analysis.

With these two techniques implemented both major parts of Data Mining techniques

have been covered, Induction being part of the New Analytic Techniques and Multi-

variate EDA as a part of Traditional Exploratory Data Analysis.

Built upon the SECURE-RM architectural approach, the module can be used as

an Attack Analyzer for an Intrusion Detection Management System, as shown in Fig-

ure 6. While an Intrusion Detection System only monitors network activity to detect

abnormal behavior or certain behavior signatures indicating an apparent attack on the

system, an Intrusion Detection Management System (IDMS) applies multiple Intrusion

Detectors. These Detectors send their gathered information, much like a Software or

Hardware monitor in a resource management system, to a diagnosis module. The diag-

nosis module, called Attack Analyzer in an IDMS, detects certain attack behavior from

the gathered data and proposes responses to occuring attacks. In tight cooperation with

the “Response Planning and Executioning” part of the IDMS the Attack Analyzer pro-

vides the System Manager with knowledge about the nature and severity of the attack to

allow him to discern between serious dangers to the network or harmless script attacks.

The basic structure of an IDMS is shown in Figure 4.

Fig.4. Intrusion Detection Management System

While the proposed diagnosis module can generally be integrated into an IDMS, it

can even be applied on IDS level. The structure of an IDS, like SNORT, can be easily

expanded to include a Solution Repository in the means of the proposed module, as

shown in Figure 5.

The proposed module can be trained to allow a variety of different responses. To

counter an attack on a network structure, an Intrusion Detection Management System

can reallocate tasks to other machines, it could shut down parts of the network or the

network in total. Likewise the IDMS could invoke counterattacks to retrace the way to

the attacker, identifying him to allow for prosecution.

A categorization for different attacks and the necessary countermeasures can be

found in Figure 6. The actions to be taken are indicated by the grid color, green indicat-

ing threats that need no drastic actions but just the allocation of some tasks, yellow for

139

Fig.5. SNORT Structure including the module

attacks that call for drastic resource allocation and the disabling of the most vulnerable

parts of the network, red ﬁnally for threats that call for a network-wide shutdown to

prevent damage to the system and/or company.

Fig.6. Threat Taxonomy ([1], p.391)

This threat taxonomy can be implemented in the diagnosis module, using it as the

information in the algorithm repository to provide the system manager with the knowl-

edge about the severity of the threat (critical, moderate or minimal) and the proposed ac-

tion to be taken (disable, log or alert). To allow for a categorization of countermeasures

in the taxonomy from threat level information, a simple nearest neighbor technique can

be applied to use the module for IDS and IDMS.

4 Experimental Framework

The Performance experiments were conducted on two different machines, running two

different Linux distributions, each with two different versions. The ﬁrst computer was

an Ohio University machine running Fedora Core 1, a Red Hat spawn. This machine

is part of the Center for Intelligence, Distributed and Dependable Systems Laborato-

ries. It is setup with AMD XP 2000+ and 512 MB RAM. The second machine is part

140

of a private network and was run under Fedora Core 1 and 2, and Knoppix 3.3 and

3.4. Knoppix is a dynamic Linux distribution, which can be started from CD and is not

copied to the hard disk. It is optimized for system recovery, but serves well as a compar-

ison to the hard drive depending Fedora Cores. The second machine is a Pentium 3 1.2

GHz notebook with 256 MB RAM. No other tasks were run on the two machines during

the experiments. In the ﬁrst part of the experiments, the performance of the module is

analyzed. To achieve a better insight into the composition of the performance, different

setups are compared with changing machines and changing operating systems.

The performance of the two used data mining techniques was measured using the

UNIX function times() ([12]). To be able to measure the execution times, each solution

identiﬁcation and ranking run was conducted 1000 times. The results in all these runs

were always the same, only differing in their performance, which was added up. To

achieve an even better average, these 1000 runs were measured 10 times. The ﬁnal

results for each measurement had to be added up once more and divided by 10 to get

the ﬁnal average for one algorithmical setup.

The performance of the techniques was measured through the CPU time used while

executing instruction in the user space, a structure created by the times() function called

UTIME. It is measured in CLK

TCK, which is deﬁned in “limits.h” as 3 clock ticks

per second. The results of the experiments are presented in Figures 7 to 11. They all

show a logarithmically ascending nearest neighbor function. The correlation coefﬁcient

distribution tends to be almost linear with a step at around 290 algorithms. Only using

Knoppix 3.3, the step is very distinct, while other distributions barely allow for time

difference at all. Considering the Fedora Core 1 implementation on the Ohio University

computer, it can be said that even here a slight logarithmic or power distribution of

the nearest neighbor results can be found, while the correlation coefﬁcient result settle

around a linear distribution.

Fig.7. UTIME Private Fedora Core 1 Fig.8. UTIME Private Fedora Core 2

Analyzing the memory usage of the proposed module, the experiments using Fe-

dora Core 2 show two distinct steps for both the nearest neighbor and the correlation

coefﬁcient technique. This means, that up to a certain number of solution algorithms, a

constant number of kilobytes is sufﬁcient to execute the identiﬁcation. Once a certain

141

Fig.9. UTIME OU Fedora Core 1

Fig.10. UTIME Private Knoppix 3.3

Fig.11. UTIME Private Knoppix 3.4 Fig.12. Memory Usage Fedora Core 2

level is reached however, the system assigns another block of kilobytes to the process.

This leads to the steps shown in Figure 12.

5 Conclusions

This paper shows that a lightweight Intrusion Detection Management Systems can be

found using the architectural ideas of SECURE-RM. The module presents the system

administrator with fast solution suggestion to an apparent problem, giving him a mul-

titude of choices to respond to a threat. On an easier level, the module could be imple-

mented into a normal intrusion detection system, to present the user, not only with a

threat warning, but also with countermeasure proposals. The module, henceforth, not

only affects resource management systems, but can also be applied to its security spawn

and even purely security-oriented systems.

The future work concerning this project will include the implementation of more

data mining techniques into the technique library, the implementation of system man-

ager interfaces to allow for easier setup and management, and ﬁnally the integration of

the module into a live resource management system to emphasize the SECURE-RM

approach.

142

References

1. BEALE, J., FOSTER, J. C. and POSLUNS, J. (2003) Snort 2.0 Intrusion Detection

2. BRANDT, S. et al. (1998): A dynamic quality of service middleware agent for mediating

application resource usage

3. FLEEMAN, D. et al. (2002): Quality-based Adaptive Resource Management Architecture

(QUARMA): A CORBA Resource Management Service

4. HABAN, D. and SHIN, K. G. (1990): Applications of real-time monitoring for scheduling

tasks with random execution times

5. LEE, C., SIEWIOREK, D. and RAJKUMAR, R. (1997): A Resource Allocation Model for

QoS Management IEEE

6. LEE, C. and SIEWIOREK, D. (1998): An Approach for Quality of Service Management

7. MOERLAND, T. (2002) Resource Management and Scheduling

http://www.liacs.nl/home/llexx/gc/rm.pdf

8. TJADEN, B. et al. (2000): INBOUNDS: The integrated, Network-Based Ohio University

Network Detective Service Webster’s Online Dictionary

9. WEBSTER (2001): Webster’s Online Dictionary (2001)

10. WELCH, L. R. (1998): Speciﬁcation, Modeling, Analysis of Dynamic Real-Time Systems

11. WELCH, L. R. and SHIRAZI, Behrooz A. (1998): Distributed, Scalable, Dependable Real-

Time Systems: Middleware Services and Applications

12. WOLF, F. (2004) Performance Measurement 1, Class Notes

143