23-03-2012, 07:58 PM
can someone help me how to implement anamoly detection in relational databases.
23-03-2012, 07:58 PM
can someone help me how to implement anamoly detection in relational databases.
18-04-2012, 05:30 PM
i want design and implementation of an intrusion response system for relational databases ppt free download plz send me
18-04-2012, 05:35 PM
i wnt design and implementation of an intrusion response system for relational databases ppt free download plz send me
18-04-2012, 07:00 PM
i need help for project .my project name online student feedback system
22-06-2012, 11:19 AM
Desingn and implementation of intrusion response system for relational database project ppt
need..
30-07-2012, 07:02 PM
i wnt design and implementation of an intrusion response system for relational databases ppt free download plz send me
31-07-2012, 10:19 AM
to get information about the topic "design and implementation of intrusion response system for relational databases full implementation" related topic refer the link bellow https://seminarproject.net/Thread-intrus...l-database
02-08-2012, 07:19 AM
Desingn and implementation of intrusion response system for relational database project full documents need. Request to quickly send reply
need.. need...
16-08-2012, 10:35 PM
I need the design and implementation of intrusion response system for relational database system full project document and source code.
Please send me.. I am M.Tech (CS) Student studied in PRIST University, Trichy thanking yours truly R.Jothi
02-09-2012, 05:33 PM
i wnt design and implementation of an intrusion response system for relational databases ppt and documentation plz send me
26-11-2012, 05:42 PM
Design and Implementation of an Intrusion Response System for Relational Databases
Design and Implementation.pdf (Size: 1.22 MB / Downloads: 56) Abstract The intrusion response component of an overall intrusion detection system is responsible for issuing a suitable response to an anomalous request. We propose the notion of database response policies to support our intrusion response system tailored for a DBMS. Our interactive response policy language makes it very easy for the database administrators to specify appropriate response actions for different circumstances depending upon the nature of the anomalous request. The two main issues that we address in context of such response policies are that of policy matching, and policy administration. For the policy matching problem, we propose two algorithms that efficiently search the policy database for policies that match an anomalous request. We also extend the PostgreSQL DBMS with our policy matching mechanism, and report experimental results. The experimental evaluation shows that our techniques are very efficient. The other issue that we address is that of administration of response policies to prevent malicious modifications to policy objects from legitimate users. We propose a novel Joint Threshold Administration Model (JTAM) that is based on the principle of separation of duty. The key idea in JTAM is that a policy object is jointly administered by at least k database administrator (DBAs), that is, any modification made to a policy object will be invalid unless it has been authorized by at least k DBAs. We present design details of JTAM which is based on a cryptographic threshold signature scheme, and show how JTAM prevents malicious modifications to policy objects from authorized users. We also implement JTAM in the PostgreSQL DBMS, and report experimental results on the efficiency of our techniques. INTRODUCTION RECENTLY, we have seen an interest in products that continuously monitor a database system and report any relevant suspicious activity [1]. Database activity monitoring has been identified by Gartner research as one of the top five strategies that are crucial for reducing data leaks in organizations [2], [3]. Such step-up in data vigilance by organizations is partly driven by various US government regulations concerning data management such as SOX, PCI, GLBA, HIPAA, and so forth [4]. 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, are not of much help when it comes to preventing data theft from insiders [5]. Such threats have thus forced organizations to reevaluate security strategies for their internal databases [4]. POLICY LANGUAGE The detection of an anomaly by the detection engine can be considered as a system event. The attributes of the anomaly, such as user, role, SQL command, then correspond to the environment surrounding such an event. Intuitively, a policy can be specified taking into account the anomaly attributes to guide the response engine in taking a suitable action. Keeping this in mind, we propose an Event- Condition-Action (ECA) language for specifying response policies. Later in this section, we extend the ECA language to support novel response semantics. ECA rules have been widely investigated in the field of active databases [10]. Attributes and Conditions Anomaly Attributes The anomaly detection mechanism provides its assessment of the anomaly using the anomaly attributes. We have identified two main categories for such attributes. The first category, referred to as contextual category, includes all attributes describing the context of the anomalous request such as user, role, source, and time. The second category, referred to as structural category, includes all attributes conveying information about the structure of the anomalous request such as SQL command, and accessed database objects. Details concerning these attributes are reported in Table 1. The detection engine submits its characterization of the anomaly using the anomaly attributes. Therefore, the anomaly attributes also act as an interface for the response engine, thereby hiding the internals of the detection mechanism. Note that the list of anomaly attributes provided here is not exhaustive. Our implementation of the response system can be configured to include/exclude other user-defined anomaly attributes. Response Actions Once a database request has been flagged off as anomalous, an action is executed by the response system to address the anomaly. The response action to be executed is specified as part of a response policy. Table 2 presents a taxonomy of response actions supported by our system. The conservative actions are low severity actions. Such actions may log the anomaly details or send an alert, but they do not proactively prevent an intrusion. Aggressive actions, on the other hand, are high severity responses. Such actions are capable of preventing an intrusion proactively by either dropping the request, disconnecting the user or revoking/denying the necessary privileges. Fine-grained response actions are neither too conservative nor too aggressive. Such actions may suspend or taint an anomalous request. A suspended request is simply put on hold, until some specific actions are executed by the user, such as the execution of further authentication steps. Lifecycle of a Response Policy Object In this section, we describe the signature share generation, the signature share combining, and the final signature verification operations, in the context of the administrative lifecycle of a response policy object. The steps in the lifecycle of a policy object are policy creation, activation, suspension, alteration, and deletion. The lifecycle is shown in Fig. 1 using a policy state transition diagram. The initial state of a policy object after policy creation is CREATED. After the policy has been authorized by k 1 administrators, the policy state is changed to ACTIVATED. A policy in an ACTIVATED state is operational, that is, it is considered by the policy matching procedure in its search for matching policies. If a policy needs to be altered, dropped or made nonoperational, it must be moved to the SUSPENDED state. The transition from the ACTIVATED state to the SUSPENDED state must also be authorized by k 1 administrators, before which the policy is in the SUSPEND IN-PROGRESS state. Attacks and Protection In this section, we describe possible attacks on JTAM and strategies to protect from them. Recall that the threat scenario that we address is that a DBA has all the privileges in the DBMS, and thus it is able to execute arbitrary SQL commands on the sys_response_policy catalog. Signature Share Verification It is possible for a malicious administrator to replace a valid signature share with some other signature share that is generated on a different policy definition. However, such attack will fail as the final signature that is produced by the signature share combining algorithm will not be valid. Note that by submitting an invalid signature share, a malicious administrator can block the creation of a valid policy. We do not see this as a major problem since the threat scenario that we address is malicious modifications to existing policies, and not generation of policies themselves. Final Signature Verification A final signature on a policy is present in all the policy states except the CREATED state. As described earlier, the final signature is verified using the public key ðn; eÞ corresponding to the value of k. The public key is assumed to be signed using a trusted third party certificate that can not be forged. Thus, if a malicious DBA replaces the server generated public key, the final signature will be invalidated. Apart from verifying the final signature immediately after policy activation, suspension, and drop, the signature must also be verified before a policy may be considered in the policy matching procedure. Such strategy ensures that only the set of response policies, that have not been tampered, are considered for responding to an anomaly. Note that RSA signature verification requires modular exponentiation of the exponent e [17]. The overhead to carry out such modular exponentiation increases with the number of bits set to one in the exponent e. As we show later in our experiments, an appropriate choice of e, such as 3, 17, or 65,537 can lead to a very low signature verification overhead. However, the cumulative overhead of verifying signatures on every policy during the policy matching procedure may be high. An alternative strategy is to create a dedicated DBMS process that periodically polls the sys_response_policy table, and verifies the signature on all policies. |
|