A Security Punctua.on Framework for Enforcing Access Control on Streaming Data. Rimma V. Nehme, Elke A. Rundensteinerr, Elisa Ber.

Transcription

1 A Security Punctua.on Framework for Enforcing Access Control on Streaming Data Rimma V. Nehme, Elke A. Rundensteinerr, Elisa Ber.no Presented by Thao Pham

2 Mo.va.on Mobile devices make available personal informa.on: loca.on, health condi.on, Some people wish to block certain businesses from sending them loca.on based adver.sements I don t want people to know that I am in a casino! A pa.ent is willing to let the closest hospital learn of his health condi.on only if his vital signs go far above the norm

3 Mo.va.on (cont.) Highly dynamic environment: Very fine grain granularity: policies are specific for each individual that provides the data. Policy changes frequently with the change in data sensi.vity

4 Mo.va.on (cont.) Consider some approaches: Store and probe: all policies are stored in one place (e.g. a table) and probed whenever access to the data is requested (like RBAC in tradi.onal DBMS) The table can be very large, frequent updates and look up can lead to bosleneck Tuple embedded : Embedding policy in each tuple: bigger tuple size, redundant when some adjacent tuples share the same policy.

5 Proposed streaming model Security policy as a special tuple in the stream, called security punctua-on (sp) An sp tells the stream processor the policy to be applied for the tuples following it

6 Talk outline The proposed security punctua.on model Implementa.on of the model on a DSMS Solu.ons for some related issues Experimental results

7 Security punctua.on model The system has two kinds of users: Data providers: provide the streaming data and specify the policies that must be applied to his data Envision that individual devices can inject their security restric.ons together with their data. Query specifiers: query the streaming data Each query specifier belongs to one or more roles.

8 sp model (cont.) The paper uses flat RBAC in its example, but this model is general for other basic access control models Consider read privilege only A policy a punctua.on specifies who (which role(s)) can access when on which data In this model, a policy is analogous to an access control list (specifies a set of roles that can access a set of tuples)

9 2 types of policies: sp model (cont.) Provider specified policies: streamed with data as sps Server side policies: Can apply more constraints, but may not override user policies

10 sp model Streaming data and Punctua.ons A data stream s is a sequence of tuples of the form t = [sid, 9d, A, ts] 9d can be the value of the tuple s primary key, or can be some value(s) to iden9fy a data provider A punctua9on always precedes the data for which it describes the policy. The stream tuples and sps is assumed to arrive in order

11 sp model Punctua.on structure DDP: The set of streams, tuples, asributes that the policy applies to (specified in regular expression). SRP: The set of roles that the policy applies to (specfied in regular expression) Sign: grant (+) or deny ( ) access Immutable: this policy can be combine with server side policies (false) or not (true) Ts: the.me the policy goes into effect.

12 sp_model Punctua.on structure (cont.) Stream level policy: < s1, *, * C + > Tuple level policy: < *, [120,133], * GP + > AEribute level policy: < {s1, s2}, *, [temperature, Beats per min] {D, ND} + >

13 Implementa.on in a DSMS Intui.vely, some kind of security filters need to stand somewhere in the query plan look for sps and update the policies. correspondingly filter out sensi.ve tuples. Consider some approaches: Pre filtering: no more sharing between queries. Post filtering: waste of processing cost.

14 Implementa.on (cont.) The paper advocates intermediate filtering with the novel Security Shield (SS )operator.

15 Implementa.on The Security Shield op An SS maintains its current state, including p: the set of roles associated with the query, called security predicate p = {R1, R2} SS1 p = {R1, R2, R3, R4} SS2 SS3 p = {R3, R4} user1 (roles: R1, R2) user2 (roles: R3, R4) P t : the current access control of a tuple t given by an sp the set of roles that may access t t passes the SS if

16 Implementa.on The Security Shield op (cont.) How the SS works: Upon receiving a new sp if the sp has the same ts with the policy P t in its state: union the SRP in the sp with Pt if ts (sp) > ts (P t ): replace Pt by the set of roles defined in the sp s wait something is SRP missed here! For all tuples following the sp: If the intersec.on of P t and the security predicate of SS is empty, discard them

17 Implementa.on The Security Shield op (cont.) Let s discuss In the defini.on: The punctua.on has its DDP to specify which data (streams/ asributes/ tuples) the policy applies to which means only part of the tuples that follows are applied this policy But now in the implementa.on when a new tuple t arrives, SS interprets the policy in the state as the policy for this tuple. If there is no match (the intersec9on is empty), the tuples following the sp are discarded This is fine because the model assume deny by default But what should happen if the intersec.on is NOT empty? Pass all the tuples to the next operator???

18 Implementa.on The SP analyzer From my understanding, the very important component that determines the correctness and effec.veness of the implementa.on is the SP analyzer

19 Implementa.on The SP analyzer (cont.) The paper designs the SP analyzer for the following purposes: To combine the security punctua.ons with similar policies to reduce memory and processing overhead To combine data providers policies with server side policies. In my opinion, unless there s an assump.on that every tuple coming to the SP Analyzer is preceded by a ps that is applies to it, the SP should also rearrange punctua.ons among tuples so that the implementa.on of the SS is correct! Details on the implementa.on of the SP analyzer is necessary: how long it should keep the coming tuples and punctua.ons for combining similar policies?

20 Related issues The implementa.on of other normal operators is adjusted to handle the sps Whether an sp is passed to the next operator or discarded How to pass the sp to the next operator to preserve the correctness of the policy. Cost models and rules for spliqng/ merging/ moving the new SS operator so that it can be considered in a query op.miza.on algorithm.

21 Experimental results Compare the overhead of the proposed approach with some other alternates

22 Experimental results (cont.) Overhead of SS compared to other operators

23 Conclusion Strengths: A novel model that use punctua.ons as a mean to specify access control policies Allow very fine grain policies and can support a highly dynamic environment Covers some other important issues: how to adjust the processing of normal operators, how the novel SS can be considered in query op.miza.on.

24 Conclusion (S) Weaknesses: There s a big ques.on in the implementa.on of the SS This mostly drops the meaning of the experimental results; Although men.oned in the defini.on, the asribute level access control is not addressed in the implementa.on Aggregate privilege is not considered.

25 Further discussion Observe that for a par.cular data provider, there s a list of roles that he usually allows access to his data. Only in special cases that he may wish to further grant/deny access to some roles. So, how about using punctua.on only for these special cases? Then the punctua.on has the start and stop meaning. The usual cases can be handled by using some methods like authoriza.on views as in the paper we discussed last week!