Intrusion Detection in Role Administrated Database:
Transaction- Based Approach
Saad M. Darwish
Department of Information Technology
Institute of Graduate Studies and Research (IGSR)
Alexandria University
Alexandria, Egypt
saad.saad@alexu.edu.eg
Mahmoud M. Ghozlan
Department of Information Technology
IGSR, Alexandria University
Alexandria, Egypt
ghozlan.edu@gmail.com
Abstract Most of valuable information resources for all
organizations are stored in database. It's a serious subject to
protect this information against intruders. However,
conventional security mechanisms havent been designed to
detect anomalous actions of database users. Intrusion detection
systems (IDS) deliver an extra layer of security that cannot be
guaranteed by built-in security tools. IDS provide the ideal
solution to defend databases from intruders. In this paper, we
suggest an anomaly detection approach that summarizes the raw
transactional SQL queries into compact data structure called
hexplet, which can model normal database access behavior
(abstract the user's role profile) and recognize impostors
specifically tailored for rolebased access control (RBAC)
database system. This hexplet allows us to preserve the
correlation among SQL statements in the same transaction by
exploiting the information in the transaction-log entry. Our
target is to improve detection accuracy, specially the detection of
those intruders inside the organization who behave strange
behavior. Our model utilizes Naive Bayes Classifier (NBC) as a
simple technique for evaluating the legitimacy of transaction.
Experimental results show the performance of the proposed
model in the term of error equal rate.
Keywords Database security, Anomaly detection, Database
intrusion detection, Role-based profiling.
I. INTRODUCTION
In today's business world, most valuable asset of
organizations is its information and thus needs efficient
management and protection. Over the last few years database
systems form the central of the information systems
infrastructure, because they permit the efficient administration
and retrieval of huge amounts of data in addition to offer
mechanisms that can be employed to certify the integrity of the
stored data. Data found in these databases vary between private
information, banking transactions, personal medical data,
commercial contracts, etc. Any violation of security to these
978-1-4799-0080-0/13/$31.00 2013 IEEE
Shawkat K. Guirguis
Department of Information Technology
IGSR, Alexandria University
Alexandria, Egypt
Shawkat_g@yahoo.com
databases will lead to bad reputation of the organization, loss of
customers sureness and might even lead to lawsuits.
There are many ways to secure databases like user
authentication, data transaction encryption, data watermarking,
and intrusion detection. Each of these ways has its benefits and
they should work together to reach the maximum security level
of database. User authentication is a prevention technique that
prevents unauthorized users from gaining access to database.
Data transaction encryption is a prevention technique also,
which thwarts attackers from understanding the data in case of
sniffing on the session. Watermarking the data is a detection
technique that used to pledge data integrity. Intrusion Detection
is a detection technique that is used to identify the malicious
activities as early as possible if the system prevention
mechanisms were bypassed to minimize the harm caused by
intruders. For more information regarding these techniques
reader can refer to [1][2][3].
Actually, available database security mechanisms are not
basically designed to detect intruders; they are intended to
avoid the intruders. So, intrusion detection system is
considered to be the second defense line. Database Intrusion is
commonly defined as a set of actions that try to violate data
integrity, data confidentiality or data availability. While
database intrusion detection is the process of tracking
transactions submitted to database and analyzing them to detect
possible presence of intruders. In general, there are two types
of database intrusion attacks (I) insider and (II) outsider [1].
Insider's attacks are the ones when an intruder has all the
privileges to access the database, but he performs malicious
actions. Outsider's attacks are the ones when the intruder does
not have the proper rights to access the database, and attempts
to first rush into and then performs malicious actions.
Detecting insider's attacks is often more difficult than detecting
outsider's attacks.
73
 In the literature, database intrusion detection has two main
models [4] [5], anomaly detection and misuse detection. The
anomaly detection model is based on the profile of user's normal
behavior. It analyzes user's current session and compares it
against his normal behavior profile. If a major deviation is
found during the comparison, an alarm will be raised. This
includes monitoring the system states over a period of time
assuming that this monitored profile can mark the normal
profile of the system. In general, it is not easy to implement an
anomaly detection solution because profiling normal usage is
a challenging task and anomaly detection methods are also
subjected to high false-positive rates, particularly with over-
fitted normal profiles. On the other hand, relaxing the margins
on these profiles might results in missed attacks. In this case,
anomaly detection systems should be fine-tuned to find the
optimum thresholds. In contrast, the misuse detection model is
based on comparing user's session or commands with the
signature of attacks previously used by attackers. So, the
signature of attacks should be well known to be detected in this
model. Misuse detection is clever to detect only known attacks.
However, misuse detection can sometimes detect new attacks
which share characteristics with previously known attacks.
In database intrusion detection; there has been very few
techniques focused on evaluating the whole transaction instead
of evaluating single SQL statement. We believe that evaluating
the whole transaction leads to better intrusion detection results.
Existing security models are insufficient to stop misuse,
especially insider attacks by legitimate users. So, more efforts
are required for enhancing database intrusion detection system.
The contribution of this paper is an anomaly detection system
adapted for RBAC database system. This system builds and
maintains role profile representing precise and consistent user
behavior by means of special data structure which gives the
ability to determine role intruders. The recommended data
structure is transaction-based which maintains relationship
among queries in the same transaction, instead of the query-
based approach that can detect referred together attributes not
executed together attributes.
The paper is organized as follows: Next section presents
some of state-of-the-art work in detecting anomalous database
requests. We then discuss in detail the proposed work in this
field. We follow this by reporting the related experimental
results and then we end with concluding the paper and
demonstrate some preliminary ideas for future work.
II. RELATED WORK
In recent years, researchers have proposed many
approaches to increase intrusion detection efficiency and
accuracy. But most of these efforts concentrated on detecting
intrusion at the network or operating system level [6] [7]. For
instance, the technique presented in [6] attempts to profile
normal behavior for program. It tries to conclude the normal
system call sequences and save these sequences in the database
as normal program access patterns. These efforts are not
adequate for protecting database and not able of detecting
malicious data corruption
In the last few years, IDS for database have been started to
take place. Very limited research discussed the field of
database intrusion detection. For example, the approaches in
74
[8] [9] proposed architectures for intrusion tolerant database
systems. However, these approaches are more focused on
intrusion detection architectures, and database recovery in case
of an attack, instead of proposing specific algorithms for
performing the intrusion detection task on a DBMS. The
technique developed in [10] has used time signatures in finding
out database intrusions. It reviews the database behavior at the
level of sensor transactions. Sensor transactions are normally
small in size and have predefined semantics such as write only
operations and well defined data access patterns. If a
transaction tries to update a temporal data which has already
been updated in that period, an alarm is raised. But, this
algorithm is suitable only for real-time database systems.
In addition to the previous approaches, the work in [11] can
be regarded as DBMS specific ID mechanism, where the
authors fingerprint the access patterns of genuine database
transactions and use them to identify possible intrusions. They
summarize SQL queries into regular expression fingerprints.
The given query is reported as malicious if it does not match
any of the existing fingerprints. However, generating and
maintaining the complete set of fingerprints for all transactions
is a hard activity. Moreover, if any of the legal transaction
fingerprints are missing, it may cause many false alarms.
Among the most noticeable approaches in database
intrusion detection are those in [12] [13] [14]. The techniques
in [12] and [13] are provided for discovery relationships among
transactions and use this information to check hidden
anomalies in the database log file. They are based on the
following idea: if a data item is updated, this update does not
happen alone but is accompanied by a set of other activities
that are also logged in the database log files. So, they find out
the dependency between data items where data dependency
refers to the access correlations among data items. Transactions
that do not follow any of these mined data dependency rules
are marked as malicious transactions. These approaches find
out malicious transactions by comparing those sets for different
item updates (the read set, the pre-write set, and the post-write
set). However, these techniques dont focus on role profiles.
The method mentioned in [14] is a misuse detection system
tailored to relational database systems. It uses audit-log data to
construct profiles that describe typical users activities. It
identifies data items frequently accessed together and saves this
information for later comparison. If the system determines
substantial incidents of data items that are accessed together,
but not in normal patterns as identified before, an anomaly is
marked. The disadvantage of such approach is that the number
of users for a database system can be quite large and
maintaining/updating profiles for such large number of users
are not easy tasks. Architectures for Hippocratic databases [15]
have been planned as a mechanism to protect the privacy of
data they manage. But, even though the architecture includes
intrusion detection as a core component, it does not specify any
methods for performing the intrusion detection task.
Approaches which are conceptually most similar to ours are
[16-19]. The methods declared in [16] [17] are talking about
creating profiles for each role; not for each user. The method
suggested in [16] creates its own data structure "triplet", which
stores three basic data about the executed SQL statement (the
command, tables accessed and columns accessed) and then
uses it to create role profiles. This method has been extended in
[17], in which the authors upgraded their data structure to
contain information about the SQL query predicate to increase
the efficiency of intrusion detection system. Their data
structure "quiplet" stores five basic information about the SQL
statement (SQL command, relations accessed, attributes
accessed, tables accessed in SQL query predicate and columns
accessed in SQL query predicate). They also use profiling
technique to detect SQL injections. Furthermore, the technique
proposed by the authors in [18] is an implementation to
intrusion detection mechanism in the DBMS layer using the
data structure presented in [17].
The approach stated by the researchers in [19] uses its own
data structure to create a profile for each role in the database.
This type of data structure is used in further comparisons to
detect anomaly access behavior in the database. In their
approach, database log file is read to extract the list of tables
accessed by transaction and list of attributes read and written
by transactions. The main disadvantages of this approach are
that; it doesn't keep any information about SQL query predicate
in the data structure and doesn't extract the correlation among
queries in the same transaction.
In [20] authors proposed database intrusion detection
mechanism that can provide an additional security layer to the
database. It can be considered as generic approach for any
database application to detect the malicious activities. Their
approach concentrated on security policies for transactions
permitted by DBMS. Its designed to mine audit log of
legitimate transaction performed on database and generate
signature for legal transactions as per security policy. The
transactions not compliant to signature of valid transaction are
identified as malicious transaction.
Most of the IDS that are discussed above show a lot of
variance in their accuracy and efficiency. The main challenge
faced most of them is that any trial to improve the rate of
correct intrusion detection, generally causes an increase in the
false alarms as well. In this work, our attention is to build an
intrusion detection scheme, which employs the concept of
creating profiles based on transaction for each role in the
database, by means of utilizing the usage of database log file to
extract profile features with the aim to improve intrusion
detection performance. The main challenge in attacking our
problem is to extract the right information from the database
traces, so that accurate profiles can be built. To address this
problem, we propose a new representation for the database log
records, which could holds information about a whole
transaction not only a single query. Algorithms in [16] [17] are
similar to our approach in the concept but our approach
surpasses them in keeping dependency between SQL
statements in the same transaction and evaluating the whole
transaction as one unit, rather than evaluating each SQL
statement individually.
III. THE PROPOSED SYSTEM
The approach we follow is similar to the one suggested by
Kamra et al. [17]; However, we improved the representation of
SQL commands to also include information about the whole
transaction. Our ID system builds a profile for each role and is
75
able to conclude role intruders, that is, individuals that while
holding a definite role diverge from the normal activities of
that role. With respect to ID, using roles means that the number
of profiles to form and maintain is much smaller than those one
would need when considering individual users. This implies
that an ID solution, based on RBAC, could be easily deployed
in practice.
The two difficulties that we report in this work are as
follows: how to construct and maintain profiles signifying
precise and stable user behavior, how to employ these profiles
for carrying out the ID task at hand. The main challenge in
overcoming these difficulties is to extract the right information
from database log, so that accurate profiles can be built. When
role information exists, the problem is transformed into a
supervised learning problem. Comparing to the work in [19],
the proposed system employs a new representation for the
database log records that holds information about the whole
transaction's commands not only the list of attributes read and
written by transactions as in the comparable work. By using
this representation, we may possibly enhance intrusion
detection performance.
A. System Design
The system's design consists of three main components: the
traditional DBMS tool that grips the query execution process,
the database audit log files and the ID mechanism. These
modules form the new stretched DBMS enriched with an
independent ID system operates at application level. The flow
of interactions for the ID process is shown in Fig. 1. Every time
a transaction is issued, it is examined by the ID mechanism
before execution. First, the system transforms the new
transaction into data structure supported by our ID mechanism
(hexplet). Then the system check the hexplet contrary to the
existing profiles and submit the assessment of the transaction
(anomalous vs. not anomalous) to the response engine. The
response engine applies a policy base of existing response
mechanisms to issue a reply depend on the valuation of the
transaction submitted by the comparison process. In case of
intrusion, the most common action is to send an alert to the
security administrator. However other actions are possible such
as disable the user or drop the query. If by assessment, the
transaction is not anomalous, the response engine simply
updates the database audit log and the profiles with the new
transaction's information. Before the detection phase, the
learning phase should be performed to create the initial profiles
from a set of intrusion free records from the database audit log.
B. Hexplet Data Structure
In order to identify user behavior, the recommended system
uses the database log file for mining information regarding
users' actions. The log records, after being processed, are used
to form preliminary profiles representing acceptable actions.
Each one or more entry (each single transaction) in the log file
is represented as a separate data unit; these units are then
combined to form the desired profiles. We assume that, SQL
queries related to the same transaction are marked together in
the log file.
 Learning Phase relations in the database. Element SEL-ATTR-BIN[i][j] is equal
to 1 if the SQL query references the j-th attribute of the i-th
relation in the query predicate; otherwise, it is equal to 0. The
Transaction's Hexplets
DB log file
Role Based sixth field is a reference which repeated as long as the
Transformation Profile Creator
remaining SQL commands in the transaction; the first five
elements in the reference hold the same preceding five
components, and so on. To summarize, in query based
Role Profiles approach, both queries of the same transaction are recorded in
Intrusion Detection Phase different data structure (i.e. different actions); but in our
approach complete transaction is recorded in one data structure
New
(i.e. queries form one action). Consider for example that the
Hexplet Compare Role
Transaction
Transaction's Profile against user issued the following transaction:
Transformation New Transaction
Start Transaction
Alarm Delete From R2 Where R2.A2 = 16 and R2.B2 = 5
Drop Response Select * from R2
Transaction Engine
End Transaction
No Action
in query based approach, this action could be considered as
Fig. 1. The proposed intrusion detection system normal. It may result in false negative. But, as the proposed
approach binds all the queries of the same transaction in one
In order to construct profiles, we need to preprocess the log behavior, it will certainly improve the performance of IDS.
file items and translate them into a format that can be analyzed
by our algorithm. Therefore, we symbolize each transaction by C. Classifier
a basic data unit that holds six fields, and thus it is called a In this work, we employ the Naive Bayes Classifier (NBC)
hexplet. Our hexplet is an extension to the data structure for the ID task in RBAC-administered databases. The
presented in [17]; it represents a single transaction and consists motivation for utilizing NBC is its low computational
of a linked list of quiplets. Hexplet contains the following requirements for detection task. The small running time is
information: the first five elements represent the first SQL mainly due to the attribute independence assumption. For a
statement in the transaction (SQL command, relations better understanding of the concepts underlying the NBC
accessed, attributes accessed, tables accessed in SQL query [16][17]. In the classification problem, a set of training
predicate and columns accessed in SQL query predicate); the hexplets is provided, and a new instance with attribute values is
sixth element holds information about rest of SQL commands given (correspond to the set of observations). The goal is to
in the transaction (if any). predict the target value, or the class, of this new instance. The
approach we define here is to assign to this new instance the
For the sake of simplicity we characterize a generic hexplet
most probable class value MAP , given the attributes
using a 6-ary relation H c, PR , PA , SR , SA , NH , where c
,, that describe it. That is
corresponds to the first SQL command, PR to the projection
relation information, PA to the projection attribute information, MAP max , ,, 1
SR to the selection relation information, SA to the selection
attribute information, all for the first SQL command, and NH using Bayes theorem we can rewrite the expression as:
refers to the next hexplet, which represents the next SQL
command in the transaction (if any) and this hexplet contains
also a reference to the next hexplet (if any) and so on. Table 1 , , ,
shows two different transactions and their representation max ,
, ,,
according to hexplets. In the example, we consider a database
schema consisting of two relations R1 = {A1; B1; C1; D1} and
R2 = {A2; B2; C2; D2}. The complete representation of the
hexplet is (SQL-CMD, PROJ-REL-BIN [], PROJ-ATTR-BIN TABLE I. EXAMPLES OF HEXPLET CONSTRUCTION
[][],SEL-REL-BIN[], SEL-ATTR-BIN[][], NEXT-HEXPLET).
Transaction Hexplet
The first field is symbolic and corresponds to the first SQL
command in the transaction, the second is a binary vector that Start Transaction {<select> < 1; 1 > < [1; 0; 1; 0];
contains 1 in its i-th position if the i-th relation is projected in SELECT R1:A1;R1:C1;R2:B2;R2:D2 [0; 1; 0; 1] > < 1; 1 >
FROM R1;R2 WHERE R1:A1 = R2:B2 < [1;0; 0; 0]; [0; 1; 0; 0]>
the SQL query. The third field is a vector of n vectors, where n End Transaction <{Null}>}
is the number of relations in the database. Element PROJ-
Start Transaction
ATTR-BIN[i][j] is equal to 1 if the SQL query projects the j-th SELECT R1:A1;R1:C1;R2:B2;R2:D2
{<select> < 1; 1 > < [1; 0; 1; 0];
attribute of the i-th relation; otherwise, it is equal to 0. Likewise, [0; 1; 0; 1] > < 1; 1 > < [1;0; 0;
FROM R1;R2
0]; [0; 1; 0; 0]>
the fourth field is a binary vector that contains 1 in its i-th WHERE R1:A1 = 5 and R2:B2 = 5
<{<delete> <0; 1> <[0; 0; 0; 0];
position if the i-th relation is used in the SQL query predicate. Delete From R2
[0; 0; 0; 0]> <0; 1> <[0;0; 0; 0];
Where R2:A2 = 16 and R2:B2 = 5
The fifth field is a vector of n vectors, where n is the number of End Transaction
[1; 1; 0; 0]> <{Null}>}>}

76
 max , ,, , only and read-write roles. The dataset used for training should
max . 2
in this case, estimating is simple since it requires just
counting the frequency of in the training data.
requires only a frequency count over the tuples in the training
data with class value equal to . To tackle the problem of zero
probability (number of observations is very small in large
training sets or zero), we adopt a standard Bayesian approach in
estimating this probability as discussed in [17].
The NBC directly applies to our anomaly detection
framework by considering the set of roles in the system as
classes and the log file hexplets as the observations. In what
follows, we show how equation 1 can be applied for our data
type (hexplet). If R denotes the set of roles, the predicted role
of a given observation H c, PR , PA , SR , SA , NH is
MAP arg max
. ,
. , 3 comparing the classification behavior when log files are
where is the number of SQL Commands in the transaction,
is the number of attributes appears in the projection part for
the current processing SQL command k, and is the number
of attributes appears in the selection part for the current
processing SQL command k. With the above equation in place,
the ID task is quite straightforward. For every new transaction,
its MAP is predicted by the classifier. If this MAP is different
from the original role associated with the transaction, an
anomaly is detected. For accepted transactions, the classifier can
be updated in a direct way by increasing the frequency count of
the relevant attributes. The procedure for ID can easily be
generalized for the case when a user is assigned more than one
role at a time. This is because our method detects anomalies on
a per transaction basis rather than per user basis. Hence, as long
as the role associated with the transaction is consistent with the
role predicted by the classifier, the system will not detect an
anomaly.
IV. EXPERIMENTAL EVALUATION
Time in Seconds
be intrusion free (trusted transactions) and we used the
database log file after revision for this purpose. The
intruders/anomalous queries were generated by reading the
database log and change the role assigned to each transaction
randomly. The queries in this dataset consist of a mix of select,
insert, update, and delete commands collected at random and
hence the number of both of them is random.
For the experimental assessment, we investigate the quality
of results of our method by calculating the precision and recall
percentages, which are defined as follows [16]:
Precision 4
Recall 5
here, TP is the number of times the system was able to detect
intruders correctly, FP is the number of times the system raise a
wrong alarm, while FN is the number of times that an intruder
access the database and the system couldnt detect him. The
results are average over a 5-fold cross validation for the dataset
to achieve randomization. One matter of concerns is the low
recall rate for this dataset because it reflects the ability of the
system to prevent intruders from accessing the database. The
objective of this evaluation is two-fold. First, we present results
modeled using the proposed hexplet and existing f-quiplet
representations. Second, we measure the performance of our
system in terms of computational cost related to time
consumed to train our algorithm and time consumed to assess
transaction.
TABLE II. AVERAGE PRECISION & RECALL STATISTICS %
Precision Recall
Hexplet 94.18 94
F Quiplet [17] 95.62 85
(Total Training Time (Seconds
120
100

80
These sections reports results from our experimental
evaluation of the proposed approach that illustrating its 60
performance as an intrusion detection mechanism. The 40
experiments are performed on the MySQL 5.2 CE DBMS on 20
Microsoft Windows 7 Enterprise SP1 32 bit running on a 0
machine has the following configurations: Intel Core Duo CPU 0 200 400 600 800 1000120014001600180020002200
T2350 @ 1.86 GHz 1.87 GHz , 2 GB of RAM. The real dataset
used for evaluating consists of 2000 transactions (6500 SQL
Statements). Each of them contains a random number of SQL Number of Transactions
statements. The database itself consists of 55 Relations Fig. 2. Total training time with different number of transactions
(Tables) with 665 attributes (columns) in all. In the database
there are 8 roles that access the database with different read

77

(Average Detection Time (Milliseconds
200
Time in Milliseconds
150
100
50
0 previous test cases should be performed in the database layer to
200 400 600 800 1000 1200 1400 1600 1800 2000
Number of Trained Hexplets
Fig. 3. Average detection time with different number of trained hexplets
In Test Case 1 we applied our algorithm and the algorithm
presented in [17] on the evaluation dataset descried at the
beginning of this section. (Table II) shows the superior
performance of hexplet compared to other alternative regarding
the recall rate. Such result because hexplet takes into account
the correlation between SQL statements in the transaction,
unlike f-quiplet which only take into account the column
access of each individual query. Due to the high restrictions
imposed by our approach, the precision percentage in lower
compared to the other method. Its known that the database
design and data nature might affect the precision and recall
percentages.
To improve the performance of our method and reduce the
false positive rate to be 0, we could perform a very simple
check before applying our detection method. We can check the
new transaction hexplet against stored hexplets for the role of
the user issued the transaction. If it matches any of existing
hexplet for his role then the transaction wont be anomalous
otherwise we apply our detection method on the transaction to
validate it. This track helps in many situations like when a role
made a regular transaction rarely, so, if we applied our
detection method directly, a false positive will appear in this
case.
Test Case 2 shows the results demonstrating the low
execution time of our approach, for both the training and
detection phases. As expected, the training time as a function
of the number of transactions in the training data increases
linearly with the number of transactions in the training data.
The system needs the training phase only once at the
beginning. Fig. 2 shows the training time in milliseconds for
different number of hexplets. In general case, there are many
factors that can affect the training and detection time like
number of SQL statements in the transaction and number of
attributes in each SQL statement. Fig. 3 shows the average
detection time as a function of number of trained hexplets.
Also, as predictable, the detection time increases with the
number of trained hexplets. Although, the execution time of the
approaches presented in [16] is better than our approach,
because our approach is more complex than this approach,
which deals with transaction not a single SQL statement, but
the experiments confirm the low overhead associated with our
approach on the subject of recall meter.
78
The complexity of the detection algorithm is O R N A)
where R is the number of roles in the database, N is the number
of SQL statements in the transaction, and A is the average
number of attributes in each SQL statement in the transaction,
and. This gives us a chance to discover the opportunity of
integrating our approach with other query processing features
of a database for an integrated online ID mechanism
entrenched inside a database. It should be noted that, all
give more accurate results and better performance, but because
of the complexity of editing database code and design, we
performed previous test cases with a C#.NET windows based
application tight to the database to prove the logic and the
availability of applying our idea.
V. CONCLUSIONS AND FUTURE WORK
This paper suggested a transaction-based anomalous
detection system in RBAC database. This machine learning
system capable of extracting valuable information from the log
files regarding the access patterns of queries in the same
transaction. The use of roles that are employed for training a
classifier makes our system practical even for databases with
large user population. As compared to query-based approaches,
the available system will certainly enhance the false negative
rate as it has deliberated the correlation among queries of a
transaction. Future works include elaborating other machine
learning techniques to improve the intrusion detection's
accuracy and study the case when role information is not
present in the log records.
REFERENCES
[1] B. Panda and J. Giordano, ''Defensive Information Warfare'', ACM of
Communications, vol. 42, No. 7, pp. 30-32, 1999.
[2] R. Agrawal, and J. Kiernan, ''Watermarking Relational Databases'',
Proceedings of the 17th International Conference on Very Large
Databases, pp. 155 186, Hong Kong, August 20 - 23, 2002.
[3] G. Agnew, Secure Electronic Transactions: Overview, Capabilities, and
Current Status, A Chapter in Payment technologies for E-commerce
Book, Springer-Verlag, ISBN: 3-540-44007-0, pp. 211 - 226, 2003.
[4] V. Chandola, A. Banerjee, and V. Kumar, ''Anomaly Detection: A
Survey'', ACM of Computing Surveys, vol. 41, No. 3, pp. 1-58, 2009.
[5] D. Kang, D. Fuller, and V. Honavar, ''Learning Classifiers for Misuse
and Anomaly Detection Using a Bag of System Calls Representation'',
Proceedings of 3rd IEEE International Workshop on Information
Assurance, pp. 117 118, USA, March 23 - 24, 2005.
[6] A. Ghosh, A. Schwartzbard, and M. Schatz, ''Learning Program
Behavior Profiles for Intrusion Detection'', Proceedings of the 1st
Workshop on Intrusion Detection and Network Monitoring, pp. 51 62,
USA, April 9 - 12, 1999.
[7] T. Lane and C. Brodley, ''Sequence Matching and Learning in Anomaly
Detection for Compute Security'', Proceedings of AAAI-97 Workshop
on AI Approaches to Fraud Detection and Risk Management, pp. 43
49, USA, July 16 17, 1997.
[8] Z. J.- Ming, and M. J.-Feng, ''Intrusion-Tolerant Based Architecture for
Database System Security'', Journal of Xidian University, vol. 30, No.1,
pp. 85-89, 2003.
[9] P. Liu, ''Architectures for Intrusion Tolerant Database Systems'',
Proceedings of the 17th Annual Computer Security Applications
Conference, pp. 311 - 320, USA, December 09 - 13, 2002.
[10] V. Lee, J. Stankovic, and S. Son, ''Intrusion Detection in Real-time
Database Systems Via Time Signatures'', Proceedings of 6th IEEE Real-
Time Technology and Applications Symposium, pp. 124 - 133,USA,
May 31-June 02, 2000.
[11] S. Lee, W. Low, and P. Wong, ''Learning Fingerprints for a Database
Intrusion Detection System'', Proceedings of the 7th European
Symposium on Research in Computer Security, Switzerland, pp. 264 -
170, October 14 - 18, 2002.
[12] Y. Hu and B. Panda, ''Identification of Malicious Transactions in
Database Systems'', Proceedings of 7th International Database
Engineering and Applications Symposium, pp. 329 - 335, Hong Kong,
July 18-17, 2003.
[13] Y. Hu, and B. Panda, ''A Data Mining Approach for Database Intrusion
Detection'', Proceedings of ACM Symposium on Applied Computing,
pp. 711 - 718, Cyprus, March 14-16, 2004.
[14] C. Chung, M. Gertz, and K. Levitt, ''DEMIDS: A Misuse Detection
System for Database Systems'', Proceedings of the 3rd International
Working Conference on Integrity and Internal Control in Information
Systems, , pp. 159 - 168, Netherlands, November 17-19, 1999.
[15] R. Agrawal, J. Kiernan, R. Srikant, and Y. Xu, ''Hippocratic Databases'',
Proceedings of the 17th International Conference on Very Large
Databases, pp. 143 - 154, Hong Kong, August 20 - 23, 2002.
[16] E. Bertino, A. Kamra, E. Terzi, and A. Vakali, ''Intrusion Detection in
RBAC-Administered Databases'', Proceedings of the 21st Annual
Computer Security Applications Conference, pp. 160 - 172, USA,
December 05 - 09, 2005.
[17] A. Kamra, E. Terzi, and E. Bertino, ''Detecting Anomalous Access
Patterns in Relational Database'', The Very Large Database Journal, vol.
16, Issue 5, pp. 1063 - 1077, 2008.
[18] A. Kamra, E. Bertino, and G. Lebanon, ''Mechanisms for Database
Intrusion Detection and Response'', Proceedings of the 2nd SIGMOD
PhD Workshop on Innovative Database Research, pp. 31 - 36, Canada,
June 13, 2008.
[19] U. P. Rao, G. Sahani, and D. Patel, ''Machine Learning Proposed
Approach for Detecting Database Intrusions in RBAC Enabled
Databases'', Proceedings of the International Conference on Computing
Communication and Networking Technologies, pp. 1 - 4, India, July 29 -
31, 2010.
[20] Y. Rathod, M. Chaudhari, and G. Jethava, ''Database Intrusion Detection
by Transaction Signature'', Proceedings of 3rd International Conference
on Computing Communication & Networking Technologies, India, pp. 1
- 5, July 26 - 28, 2012.

79