International Journal of Computer Trends and Technology (IJCTT) volume 4 Issue 5May 2013

ISSN: 2231-2803 http://www.ijcttjournal.org Page 1115

Improving Policy Based Intrusion Response
Component of a Relational Database by Evaluation
of User
M. Dharani
#1
, T. Sangeetha
*2

#,*
PG Scholars, Department of CSE, Angel College of Engineering and Technology,
Tirupur, Tamilnadu, India

Abstract All over the world hundreds of thousand transactions
are performed at every second. It is very critical that a database
when utilized in certain problem which has to be solved. Hence
database management and technologies of data mining are
always most required domains. In this paper, the concept of
policy based user evaluation in a relational database is defined. A
policy is nothing but a rule or a statement of constraints upon
which a query is matched. In this research proposes a schema for
the user evaluation task which also can be used for policy
modification based on the potentially threatening users identified
as stake users. This paper also exploits the same information for
creation of policies to secure the tables which are targeted often.

Keywords intrusion response, user evaluation, relational
database, policy based
I. INTRODUCTION
Recently, we have seen an interest in solutions that
continuously monitor a database system and report any
relevant suspicious activity. Gartner research has identified
Database Activity Monitoring (DAM) as one of the top five
strategies that are crucial for reducing data leaks in
organizations. Such step-up in data vigilance by organizations
is partly driven by various government regulations concerning
data management such as SOX, PCI, GLBA, HIPAA and so
forth.
Organizations have also come to realize that current attack
techniques are more sophisticated, organized and targeted than
the broad-based hacking days of past. Often, it is the sensitive
and proprietary data that is the real target of attackers. Also,
with greater data integration, aggregation and disclosure,
preventing data theft, from both inside and outside
organizations, has become a major challenge. Standard
database security mechanisms, such as access control,
authentication, and encryption, is not of much help when it
comes to preventing data theft from insiders. Such threats
have thus forced organizations to re-evaluate security
strategies for their internal databases. Monitoring a database
to detect any potential abnormal user behavior is a crucial
technique that has to be part of any comprehensive security
solution for high-assurance database security.
Today there are several commercial products for database
monitoring against intrusions [2]. Malicious users represent
today's toughest challenge for security architects. Traditional
database security tools such as encryption and access controls
are rendered useless by a trusted employee who has--or can
easily obtain--the right credentials. In addition, more users in
the enterprise are getting database access, including DBAs,
application developers, software engineers, and even
marketing, HR, and customer support representatives. And
whether spurred by revenge or tempted by easy money,
insiders can sell their booty on a bustling information black
market [1]. Usually database security attacks can be classified
as external attack and insider attack.
In external attack unauthorized attempts are taken place to
access or destroy private data and in insider attack the
malicious actions are executed by authorized users. The
protection of database by the use of encryption techniques,
where the database may be encrypted but this kind of system
may lead to degradation of query performance [3].
II. POLICY LANGUAGE
An anomaly is detected by a detection engine as an event
that contains the anomaly attributes [4]. Such attributes of
anomalous nature can be user, role and the commands
executed on a database. So these events are taken into account
along with the environment where those events occurred in
consideration with these an event condition action (ECA)
language is devised to facilitate response policies. An ECA
rule is specified as follows:
ON {event} IF {condition} THEN {action}
In our context when an event of anomalous nature occurs,
the anomalous attributes are checked with its respective
conditions, when the conditions are found to cause any risk, a
response action is executed.
A. Anomaly attributes
An anomaly is detected based on a set of attributes such as
user, role, source, time of event; commands used and database
objects that are used. Thus the anomaly attributes
characterizes the anomalous event.
B. Policy condition
A policy condition which is the constituent of a response is
considered as a conjunction of predicates, where each
predicate signifies a single anomaly attribute. In the case of
different instances of the same attribute occurring in one
event, disjunctions among predicates is supported as given
below
International Journal of Computer Trends and Technology (IJCTT) volume 4 Issue 5May 2013
ISSN: 2231-2803 http://www.ijcttjournal.org Page 1116

SQLcmd IN {select,delete}
ROLE IN {DBA, user}
SRC_IP IN{192.168.0./26

TABLE I
LIST OF ATTRIBUTES AND THEIR DESCRIPTION

C. Formal Definition of a policy
Let PA ={A1, A2 . . , An} be the set of anomaly attributes
where each attribute Ai has domain Ti of values. Let a
predicate Pr be d efined as Pr: Akc, where Ak PA, is a
comparison operator in {<, >, <=, >=, =, !=, LIKE, IN,
BETWEEN } and c is a constant value in Tk. The condition
of a response policy Pol is defined as Pol(C): Prk and Prl and
Prm where Prk; Prl . . . Prm are predicates of type Pr.
An ECA policy can be categorized as aggressive when it is
highly severe, as conservative when it is of lower severity and
as fine-grained which are neither conservative nor too
aggressive.
An ECA policy can normally take up any of the respective
action of the above three types. But there are some cases,
where interactions are required with users mainly when a fine-
grained or aggressive response action has to be taken up; it is
always worthy to make a confirmation for that.
So the ECA policies are extended with a confirmation
action, to resolve the effects of initial action, with the user. If
confirmation succeeds, the resolution action is taken; else the
action to be executed on failure is taken.
Note that these confirmation actions may not be mandatory
at all scenarios thus the ECA can be extended and represented
as
ON {Event}
IF {Condition}
THEN {Initial Action}
Confirm {Confirmation Action}
ON SUCCESS {Resolution Action}
ON FAILURE {Failure Action}

For example, the policy below re-authenticates users who
are logged from inside the organizations internal network for
write anomalies to tables in the DBO schema. If re-
authentication fails, drop the request and disconnect the user
else does nothing
ON ANOMALY DETECTION

IF Role! =DBA and Sourec IP IN 192.168.0.21/53 and Obj
Type=table and Objs IN dbo.* and SQLCmd IN {Insert,
Update, Delete}

THEN SUSPEND
CONFIRM RE-AUTHENTICATE
ON SUCCESS NOP
ON FAILURE ABORT, DISCONNECT
III. PROPOSED WORK
Our work is to define a table schema which can be used for
the evaluation of the database user. The table to be defined is
not only used for storing evaluation of the user but also data
like the time duration between last anomalous query received
from the user and the current anomalous query. The following
is the instance for the proposed schema.
Name Null? Type
---------------------------------------------------------------
USER_ID NUMBER(10)
USER_NAME VARCHAR2(20)
AQUERY_COUNT NUMBER(5)
LAST_ACTIVITY DATE
DUR_BTW_SUCCESSIVE NUMBER(2)
POLICY1_COUNT NUMBER(4)
POLICY2_COUNT NUMBER(4)
POLICY3_COUNT NUMBER(4)
POLICY4_COUNT NUMBER(4)
POLICY5_COUNT NUMBER(4)

In the above table definition User_id is a unique number to
identify the user and User_name column should contain the
DB user name of the user. The policies defined can contain
user name as one of the parameters to check the anomalous
queries. The user should be evaluated for the number of
anomalous queries he posted against the database. This can be
stored against in the field Aquery_count which is the most
important field of the schema and it plays a vital role in
identifying the stake users. Last_activity column of the table is
a system timestamp to store the time at which the query was
posted by that user. Duration_between_successive column is
to store the number of days between the last activity and the
current activity. This duration column is to find out the
frequency of the users malicious activity. The remaining
columns are used as counters for the number of times the
policy is matched with the query run by the user. It is clear
that a policy is defined based on the need to protect an entity
in the database. Whenever the entity is accessed without
sufficient privileges a policy defined will be matched to the
anamalous query. The proposed table schema contains a
Attributes Description
User
Role
Client App

Source IP

Date Time
Database
Schema
Obj type

Obj(s)

SQLCmd

Obj attr(s)
The user associated with the request.
The role associated with the request.
The client application associated with
the request.
The IP address associated with the
request.
Date/Time of the anomalous request.
The database referred to in the request.
The schema referred to in the request.
The object types referred to in the request
such as table, view, stored procedure.
The object name(s) referred to in the
request.
The SQL Command associated with the
request.
The attributes of the object(s) referred in the
request.
International Journal of Computer Trends and Technology (IJCTT) volume 4 Issue 5May 2013
ISSN: 2231-2803 http://www.ijcttjournal.org Page 1117

column for each policy as a counter value column. Consider a
user posting an anamalous query. Obviously the query will be
matched to one of the policies. Our idea is to increment the
cell addressed at (User id, policyn_count) where User id is the
user who posted the query and the policyn_count refers to the
nth policy matched with the query.
Another proposed concept is the exploitation of the table
data to create new policies for the tables that are targeted
often. New policies in the catalogs are defined in such a way
that the policy responds to the anamalous query with more
effective response rather than the previous response. This task
can be done using the policyn_count field of the proposed
schema by using the sum of each of policyn_count column
values we can find out the policy that is often matched with
the anamalous queries. The policy with the highest sum
implies to the number of attacks on the entity tied with the
policy. Hence that policy can be strengthened by redefining
the response action to be taken or creating a new policy for the
entity.
Our proposed schema for the user evaluation table contains
a simple, sophisticated tool to find out the users who have
posted anamalous queries, a query count column. Preparing a
summary on this column will give way in identifying the stake
users, partially stake users and minimal stake users.
IV. CONCLUSION AND FUTURE WORK
The proposed schema will be highly useful for identifying
and segregating the groups of users who are intentionally or
unintentionally has drove themselves into an anomalous
behavior. This segregation will be much more exploited when
it comes to address the online access of any databases in a
way that avoiding the risk of losing the users who are
normally set with false alarm for their activities.
The solution is provided by tracing a sequence of activities
by the entire users for a stipulated period of time and devising
a specific policy for the most frequent anomalous behaviors.
This work can also focus and corner the users who
intentionally generate a false alarm and still appear to be a
stake free user. This is a serious issue to be noted and
responded as such a behavior can trigger a set of response
actions from the system until the proof of false alarm is
notified.
The result of our approach to devise new policies has led us
to implement the schema in a real time application in the
future. Such an implementation in a real time application is
advisable because of the fact that we cannot simulate or
falsely generate all the possible intrusion on a database system
as it is a tedious job. This implementation can help in bringing
up the exact efficiency and effectiveness of the proposed
schema.
We have also intended to extend the mechanism of
detecting the anomalous users by tracing the user activities
through classification. The labeling of different types of user
activities enables the DBAs to effectively revoke any
privileges from the group of users labeled as anomalous and to
grant privileges to the users who have been revoked from their
actual privileges due to false alarms.
V. REFERENCES
[1] Andrew Conry Murray, The Threat from Within posted on August 1,
2005 [ONLINE] Available: http://www.networkcomputing.com/
[2] Ashish Kamra, Elisa Bertino, and Rimma Nehme, Responding to
Anomalous Database Requests, W. J onker and M. Petkovic (Eds.):
SDM 2008, LNCS 5159, pp.5066, 2008.
[3] Udai Pratap Rao and Dhiren R. Patel, Design and Implementation of
Database Intrusion Detection System for Security in Database,
International Journal of Computer Applications (09758887), vol.35,
No.9, 2011.
[4] Ashish Kamra and Elisa Bertino, Design and Implementation of an
Intrusion Response System for Relational Databases, IEEE
Transactions on Knowledge and Data Engineering, vol.23, No.6, 2011.