An Efficient Approach for Leakage Tracing

Transcription

1 International Journal of Electronics and Computer Science Engineering 2301 Available Online at ISSN Paladugu Divya 1, V.Sivaparvathi 2, M.Salaja 3, V. Sowjanya 4, 1 Student, PVP Siddhartha Institute of Technology, in the Department of Computer Science and Engineering, Vijayawada,Krishna(dt) 2 Assistant Professor, PVP Siddhartha Institute of Technology, in the Department of Computer Science and 3 Assistant Professor, PVP Siddhartha Institute of Technology, in the Department of Computer Science and 4 Assistant Professor, PVP Siddhartha Institute of Technology, in the Department of Computer Science and 1 paladugu.divya@gmail.com, 2 vallabhaneni_sp@yahoo.in, 3saili_klce@yahoo.com, 4 sowji_635@yahoo.com, Abstract- Data distribution across trusted agents by a distributor is difficult to analyze and manage as there is always the danger of misappropriation by one or more number of agents. A prior approach such as Watermarks that alters the data is of no use. In case of a leak the data is found at an unauthorized place (e.g., on the web or somebody s laptop). Nothing can be done in former s case. In a latter scenario data allocation strategies like injecting realistic but fake data records to the original sensitive data were developed such that these fake tuples can be used to identify the leaker among the trusted agents. Also guilt assessment algorithms were proposed for distributing objects to agents, in a way that improves the chances of identifying a leaker. These strategies have limited functionality as they function with an assumption that there are a fixed set of agents with requests known in advance. We propose to extend the functionality of these techniques to handle more number of agents using staged event-driven architecture (SEDA). Using this model a distributor can assess the likelihood of a leaker among more number of trusted agents in the aftermath of a leak. I INTRODUCTION In today technically empowered data rich environment, it is a major challenge for data holders to prevent data leakage. In the course of doing business, sometimes sensitive data must be handed over to supposedly trusted third parties. We call the owner of the data the distributor and the supposedly trusted third parties the agents. Our goal is to detect when the distributor s sensitive data has been leaked by agents, if possible to identify the agent that leaked the data and functionality of the technique is extended in order to detect leakers among more number of trusted agents. Traditionally, water marking is used for detecting leakages which a unique code is embedded in each distributed copy. If any unauthorized party accesses the copy then traitor can be identified. Further, if data receipts are malicious then watermarks can sometimes destroyed. Later approaches use perturbation techniques that modify data and make it less sensitive before being handed to agents. Fake data allocation schemes and use of unobtrusive techniques like Allocation for Explicit Data Requests, Random Agent Selection, fake object allocation, Greedy Selection of agent for optimization, Data allocation, Object Selection etc were used to trace data leakages. But fails in scalability aspects as these techniques function with an assumption that there are a fixed set of agents with requests known in advance. Previously, a guilt assessment algorithm was proposed for distributing objects to agents, in a way that improves the chances of identifying a leaker. This model is for assessing the guilt of agents. Here, the fake objects acts like a type of watermark for the entire set, without any modifications in individual members. If it turns out that an agent was given one or more fake objects that were leaked, then the distributor can be more confident that agent was guilty. These strategies have limited functionality as they function with an assumption that there are a fixed set of agents with requests known in advance. In this paper, we uses Fake data allocation schemes along with unobtrusive techniques like Allocation for Explicit Data Requests, Random Agent Selection, fake object allocation, Greedy Selection of agent for optimization, Data allocation, Object Selection etc were used to trace data leakages and refines scalability issues by using staged event-driven architecture (SEDA) that is intended to support massive concurrency demands among trusted agents and simplifies the construction of well-conditioned services.

2 IJECSE,Volume1,Number 4 Paladugu Divya et al II RELATED WORK The data allocation strategies are concerned, mostly relevant to watermarking that is used as a means of establishing original ownership of distributed objects. Watermarks [2] were initially used in images, video, and audio data whose digital representation includes considerable redundancy. Recently, [1], [8], [9] and other works have also studied marks insertion to relational data [3]. Our approach and watermarking are similar in the sense of providing agents with some kind of receiver identifying information. However, by its very nature, a watermark [2] modifies the item being watermarked. If the object to be watermarked cannot be modified, then a watermark cannot be inserted. In such cases, methods that attach watermarks to the distributed data are not applicable. Water mark is added in to three types of files they are IMAGE,PDF&XLS forms and each format have its own type watermark. The guilt detection approach presented is related to the data provenance problem[3]: tracing the lineage of S objects implies essentially the detection of the guilty agents and assume some prior knowledge on the way a data view is created out of data sources. Our problem formulation with objects and sets is more general As far as the data allocation strategies[7] are concerned. Finally, there are also lots of other works [4], [7] on mechanisms that allow only authorized users to access sensitive data through access control policies[6]. Such approaches prevent in some sense data leakage by sharing information only with trusted parties. However, these policies are restrictive and may make it impossible to satisfy agents requests. III PROBLEM DEFINITION Suppose a distributor owns a set O = {o1,.., o m } of valuable data objects. The distributor wants to share some of the objects with a set of agents A1,A2,,An but does wish the objects be leaked to other third parties. An agent Ai receives a subset of objects Ri which belongs to O, determined either by a sample request or an explicit request, Sample Request Ri = SAMPLE (O, mi ) : Any subset of mi records from O can be given to Ai. Explicit Request Ri = EXPLICIT ( O,condi ) : Agent Ai receives all the O objects that satisfy condi. The objects in O could be of any type and size, e.g., they could be tuples in a relation, or relations in a database. After giving objects to agents, the distributor discovers that a set S of O has leaked. This means that some third party called the target has been caught in possession of S. For example, this target may be displaying S on its web site, or perhaps as part of a legal discovery process, the target turned over S to the distributor. Since the agents A1,A2,,An, have some of the data, it is reasonable to suspect them leaking the data. However, the agents can argue that they are innocent, and that the S data was obtained by the target through other means. IV AGENT GUILT MODEL In this model we taken O as the total content of objects and the R s are used as the set of objects given to the agents and s is the target set which contains the leaked objects. There are O={o 1,o 2,o 3 }; R1={o 1,o 3 }; R2={o 2,o 3 }; S={o 1,o 2,o 3 }. In this case, all three of the distributor s objects have been leaked and appear in S. Let us first consider how the target may have obtained object o 1, which was given to both agents. The target either guessed o 3 or one of A1 or A2 leaked it. We know that the probability of the former event is p, so assuming that probability that each of the two agents leaked o 3 is the same we have the following cases: the target guessed o 3 with probability p; agent A1 leaked o 3 to S with probability (1 - p)/2; agent A2 leaked o 3 to S with probability (1 -p)/2;

3 2303 Similarly, we find that agent A1 leaked o 2 to S with Probability 1 - p since he is the only agent that has o 2. Given these values, the probability that agent A1 is not Guilty, namely that A1 did not leak either object is: (1 -(1 - p)/2) -(1 -(1 - p)); And the probability that A1 is guilty is: 1 - Pr{G1} V DATA ALLOCATION Main problem in leakage detection is the data allocation: how can the distributor intelligently give data to agents in order to improve the chances of detecting a guilty agent. The two types of requests : sample and explicit. Fake objects are objects generated by the distributor that are not in set O. The objects are designed to look like real objects, and are distributed to agents together with O objects, in order to increase the chances of detecting agents that leak data. The distributor may be able to add fake objects to the distributed data in order to improve his effectiveness in detecting guilty agents. However, fake objects may impact the correctness of what agents do, so they may not always be allowable. The distributor gives the data to agents such that he can easily detect the guilty agent in case of leakage of data. To improve the chances of detecting guilty agent, he injects fake objects into the distributed dataset. These fake objects are created in such a manner that, agent cannot distinguish it from original objects. with the addition of fake tuples. Whenever any user request for the tuple it follows the following steps: 1. The request is sent by the user to the distributor. 2. The request may be implicit or explicit. 3. If it is implicit a subset of the data is given. 4. If request is explicit, it is checked with the log, if any previous request is same. 5. If request is same then system gives the data objects that are not given to previous agent. 6. The fake objects are added to agent s request set. 7. Leaked data set L, obtained by distributor is given as an input. 8. Calculate the guilt probability Gi of user. VI THE STAGED EVENT-DRIVEN ARCHITECTURE The staged eventdriven architecture (SEDA) is designed to enable high concurrency, load conditioning, and ease of engineering for Internet services which improve the scalability and a distributor can assess the likelihood of a leaker. SEDA decomposes an application into a network of stages separated by event queues and introduces the notion of dynamic resource controllers[10] to allow applications to adjust dynamically to changing load. SEDA Support massive concurrency[5], Simplify the construction of well-conditioned services, Enable introspection and Support self-tuning resource management. The fundamental unit of processing within SEDA is the stage. A stage is a self-contained application component consisting of an event handler, an incoming event queue, and a thread pool. Stage threads operate by pulling a batch of events off of the incoming event queue and invoking the application-supplied event handler. The event handler processes each batch of events, and dispatches zero or more events by enqueuing them on the event queues of other stages.

4 IJECSE,Volume1,Number 4 Paladugu Divya et al Fig: SEDA resource controllers The SEDA design facilitates debugging and performance analysis of services, which has traditionally been a challenge for complex multithreaded servers. The decomposition of application code into stages and explicit event delivery mechanisms facilitates inspection. To keep each stage within its operating regime, SEDA makes use of a set of resource controllers[10], which automatically adapt the resource usage of the stage based on observed performance and demand. Abstractly, a controller observes runtime characteristics of the stage and and adjusts allocation and scheduling[5] parameters to meet performance targets. Controllers can operate either with entirely local knowledge about a particular stage, or work in concert based on global state. The first is the thread pool controller, which adjusts the number of threads executing within each stage. The goal is to avoid allocating too many threads, but still have enough threads to meet the concurrency demands of the stage. The controller periodically samples the input queue and adds a thread when the queue length exceeds some threshold, up to a maximum number of threads per stage. Threads are removed from a stage when they are idle for a specified period of time. The second is the batching controller, which adjusts the number of events processed by each invocation of the event handler within a stage (the batching factor). The controller attempts to trade off these effects by searching for the smallest batching factor that sustains high throughput. It operates by observing the output rate of events from a stage (by maintaining a moving average across many samples) and decreases the batching factor until throughput begins to degrade. If throughput degrades slightly, the batching factor is increased by a small amount. The controller responds to sudden drops in load by resetting the batching factor to its maximum value. Each stage has an associated controller that adjusts its resource allocation and behavior to keep the application within its operating regime. The thread pool controller adjusts the number of threads executing within the stage, and the batching controller adjusts the number of events processed by each iteration of the event handler. By using this SEDA, the functionality of these techniques is extended to handle more number of agents. By using this model a distributor can assess the likelihood of a leaker among more number of trusted agents. VII CONCLUSION Data leakage is a silent type of threat. Major challenge for data holders to prevent data leakage because sometimes sensitive data must be handed over to supposedly trusted third parties. Earlier approaches use perturbation techniques that modify data and make it less sensitive before being handed to agents. Some other techniques Fails in scalability aspects as with an assumption that there are a fixed set of agents with requests known in advance. In this paper, we uses Fake data allocation schemes along with unobtrusive techniques like Allocation for Explicit Data Requests, Random Agent Selection, fake object allocation, Greedy Selection of agent for optimization, Data allocation, Object Selection etc were used to trace data leakages and refines scalability issues by using staged event-driven architecture (SEDA) that is intended to support massive concurrency demands among trusted agents and simplifies the construction of well-conditioned services. Using this model a distributor can assess the likelihood of a leaker among more number of trusted agents in the aftermath of a leak.

5 2305 VIII REFERENCES [1] L. Sweeney, Achieving k-anonymity privacy protection using generalization and suppression, River Edge, NJ, USA, pp , [2] R. Agrawal and J. Kiernan, Watermarking relational databases, in VLDB 02: Proceedings of the 28 th international conference on Very Large Data Bases. VLDB Endowment, 2002, pp [3] P. Buneman and W.-C.Tan, Provenance in Databases, Proc.ACM SIGMOD, pp , [4] P. Papadimitriou and H. Garcia-Molina, Data leakage detection, Stanford University, Tech. Rep., [Online]. Available: http: //dbpubs.stanford.edu/pub/ [5] T. Anderson, B. Bershad, E. Lazowska, and H. Levy. Scheduler activations: Effective kernel support for the user-level management of parallelism. ACM Transactions on Computer Systems, 10(1):53 79, February [6] S. Jajodia, P. Samarati, M.L. Sapino, and V.S. Subrahmanian, Flexible Support for Multiple Access Control Policies, ACM Trans. Database Systems, vol. 26, no. 2, pp , [7] Rudragouda G Patil, Development of Data leakage Detection Using Data Allocation Strategies International Journal of Computer Applications in Engineering Sciences,VOL I, ISSUE II, JUNE [8] J.J.K.O. Ruanaidh, W.J. Dowling, and F.M. Boland, Watermarking Digital Images for Copyright Protection, IEE Proc. Vision, Signal and Image Processing, vol. 143, no. 4, pp , [9] F. Guo, J. Wang, Z. Zhang, X. Ye, and D. Li, An Improved Algorithm to Watermark Numeric Relational Data, Information Security Applications, pp , Springer, [10] G. Banga, P. Druschel, and J. Mogul. Resource containers: A new facility for resource management in server systems. In Proc. Third Symposium on Operating Systems Design and Implementation (OSDI 99), February 1999.