Specifying Access Control Policies on Data Streams

Transcription

1 Specifying Access Control Policies on Data Streams Barbara Carminati 1, Elena Ferrari 1, and Kian Lee Tan 2 1 DICOM, University of Insubria, Varese, Italy {barbara.carminati,elena.ferrari}@uninsubria.it 2 School of Computing, National University of Singapore, Singapore tankl@comp.nus.edu.sg Abstract. Many data stream processing systems are increasingly being used to support applications that handle sensitive information, such as credit card numbers and locations of soldiers in battleground [1,2,3,6]. These data have to be protected from unauthorized accesses. However, existing access control models and mechanisms cannot be adequately adopted on data streams. In this paper, we propose a novel access control model for data streams based on the Aurora data model [2]. Our access control model is role-based and has the following components. Objects to be protected are essentially views (or rather queries) over data streams. We also define two types of privileges - Read privilege for operations such as Filter, Map, BSort, and a set of aggregate privileges for operations such as Min, Max, Count, Avg and Sum. The model also allows the specification of temporal constraints either to limit access to data during a given time bound or to constraint aggregate operations over the data within a specified time window. In the paper, we present the access control model and its formal semantics. 1 Introduction In many applications, data arrive in the form of high speed data streams. Examples of such applications include telecommunication, battle field monitoring, network monitoring, financial monitoring, sensor networks, and so on. These data typically contain information that is sensitive and thus unauthorized accesses should be avoided. As an example, consider battle field monitoring, where the positions of soldiers are protected information that should only be accessible to the battleground commanders. Clearly, there is a need to integrate access control mechanisms into data stream processing systems to achieve a controlled and selective access to data streams. However, to our knowledge, there has been no reported work that offers access control over data streams. From the data stream community, many data stream processing systems have been developed both academically (e.g., Aurora [2], Borealis [1], STREAM [3], TelegraphCQ [6]) and commercially (e.g., StreamBase [10]), but the focus in these systems has been on performance issues. On the other hand, though the data security community has a very rich history in developing access control models [5,7], these models are largely tailored to traditional DBMSs. Thus, they cannot be readily adapted to data stream applications, mainly because: (a) traditional databases are static and bounded while data streams are unbounded and infinite; (b) queries in traditional DBMSs are one time and ad-hoc but queries over R. Kotagiri et al. (Eds.): DASFAA 2007, LNCS 4443, pp , c Springer-Verlag Berlin Heidelberg 2007

2 Specifying Access Control Policies on Data Streams 411 data streams are typically continuous and long running; (c) in traditional DBMSs access control is enforced when users access the data; in data stream applications, access control enforcement is data-driven (i.e., whenever data arrive); (d) because of (c), access control is more computational intensive in data stream applications and specific techniques to handle it efficiently should be devised; (e) as data are streaming, temporal constraints (e.g., sliding windows) become more critical in data stream applications than in traditional DBMSs. To cope with all these new requirements, in this paper, we propose a novel access control model for data stream applications based on the Aurora model [2]. We have decided to cast our research into the Aurora framework because (a) while there is still no consensus on a standard data model and query language for stream data, Aurora has emerged as one of the most relevant and mature proposals in the field, and (b) a full implementation of its processing engine is publicly available [1]. Our access control model is role-based and has the following components. Objects to be protected are essentially views (or rather queries) over data streams. As such, access can be granted only on selected tuples and/or attributes of a data stream, as well as only on selected attributes/tuples of joined streams. We also define two types of privileges - Read privilege for operations such as Filter, Map, BSort, and aggregate privileges for operations such as Min, Max, Count, Avg, and Sum. In addition, to deal with the intrinsic temporal dimension of data streams we introduce two temporal constraints - general constraints, that allow access to data during a given time bound, and window constraints, that support aggregate operations over the data within a specified time window. This last feature is very relevant for data streams since we can customize aggregate operations according to data sensitivity, by regulating the size of the window over which the aggregate function can be computed. In this paper, we present the access control model by illustrating its syntax and formal semantics. We believe that the definition of an access control model on a formal basis is a key step to devise efficient methods for access control policy enforcement and to guarantee their correctness. To the best of our knowledge, this is the first reported work that proposes an access control model for data streams. The remainder of this paper is organized as follows. In the next section, we provide some background to this work and the motivating scenario we will use throughout the paper. In Section 3, we present the proposed access control model, whereas Section 4 presents its formal semantics. Finally, we conclude this paper with directions for future work in Section 5. 2 Background In this section, we first discuss a data stream scenario by highlighting its access control requirements. Then, we present a brief overview of the Aurora stream-processing engine. 2.1 A Motivating Scenario In this section, we introduce an illustrative scenario that highlights some essential requirements of an access control model for stream data, in terms of policies it should be

3 412 B. Carminati, E. Ferrari, and K.L. Tan able to express. Before doing that we briefly introduce how data streams are modeled throughout the paper. A stream consists of an append-only sequence of tuples with the same schema. In addition to standard attributes A 1,..., A n the stream schema contains a further attribute, denoted as TS. TS stores the time of origin of the corresponding tuple, thus it can be exploited to monitor attributes values over time. As a scenario, we consider the military domain presented in [2], where stream data are used to monitor positions and health conditions (e.g., heart beats, blood pressure) of platoon s soldiers. Positions and health conditions are modeled by means of two distinct streams, namely, Position and Health, with the following schemas: Position(TS,SID,Pos,Platoon)and Health(TS,SID,Platoon,Heart, BPressure), wherethesid and Platoon attributes store soldier s and platoon s identifiers,respectively,both in theposition andhealth streams, the Pos attribute contains the soldier position, the Heart attribute stores the heart beats, whereas the BPressure attribute contains the soldier s blood pressure value. We assume that users posing queries are identified by their roles, e.g., captains, soldiers, doctors, etc. Let us now discuss some access control requirements that can arise in this scenario. Consider, for instance, the Position stream. Since the Pos attribute, modeling the position of a soldier, conveys sensitive information, it should be accessible only to selected users, such as for instance the captain of the soldier s platoon. In order to specify this requirement, the access control model should support policies specified at the attribute level, in addition to the whole stream. Another important requirement is to be able to specify policies that apply only on selected tuples within a data stream, identified on the basis of their content. Consider, for instance, the case where we would like to grant captains access to the positions of soldiers not belonging to their platoons, only if they cross some specified borders. This requirement can be modeled as a policy granting the access to the Pos attribute only if the corresponding tuple satisfies two conditions, i.e., the condition stating that the corresponding soldier does not belong to the captain s platoon and the condition stating that the soldier has crossed a given border. A further requirement is related to the temporal dimension of both data streams and some Aurora operators. For instance, sometimes it can be useful to constraint access to a data stream to selected temporal intervals. This is a relevant requirement, since a data stream contains an intrinsic notion of time that should be exploited in the specification of temporal constraints. For instance one can state that only during the action time doctors are authorized to monitor the heart beats of the soldiers. Other examples of access control requirements related to temporal constraints are those authorizing window-based operators only on selected time windows. For instance, a doctor can be authorized to monitor the average of soldier s heart beats with arbitrary window size, if soldier belongs to the same platoon of the doctor, otherwise with a window with a maximum size of 1 hour. This limitation prevents doctors to infer whether and when there have been some critical situations (i.e., those characterized by heart beats with high frequency for a time longer than one hour). Thus, an access control model for data streams should be able to support limitations on the windows over which window-based privileges can be exercised. In Section 3, we present an access control model to cope with all such requirements.

4 Specifying Access Control Policies on Data Streams Aurora In recent years much effort has been spent on the area of stream-processing engines [1,2,3,6]. Among these engines, one of the most relevant and mature proposals is Aurora [2]. Aurora has been recently transferred to the commercial domain (i.e., the Stream- Base engine [10]), and redesigned with distributed functionalities (i.e., Borealis [1]). However, due to the scope of the paper in what follows we focus on Aurora streamprocessing engine, by briefly introducing the underlying query model and algebra, and referring the interested readers to [2] for a detailed discussion of the core Aurora engine. Aurora query model. In order to cope with the latency requirements implied by streams, Aurora exploits an inbound processing instead of the traditional outbound processing, typical of conventional DBMSs, where data are stored and indexed before being queried. This means that query processing is performed directly on incoming streams. Aurora query processing exploits a dataflow paradigm, by modeling queries as a loopfree direct graph of operations (called boxes in Aurora), where tuples flow through all processing operations defined in the graph (called network in Aurora). Health Filter Filter( Heart >100 )(Health) Join Position Map Map(Pos,SID)(Position) Join(Health.SID=Position.SID)(Health, Position) Fig. 1. An example of query in Aurora An example of Aurora network is given in Figure 1, where two input streams, namely Health and Position, go through two different boxes (i.e., Filter and Map) before being joined together. Aurora algebra. We provide now a brief overview of Aurora operators. In this paper, we focus more on the operators semantics rather than on details regarding their implementation. For this reason, for some of the Aurora operators described in [2] we provide a simplified syntax. The first operator is the Filter box, which acts like a relational selection but having the capability to apply several distinct selections on a stream at the same time, and to route output tuples on the basis of satisfied predicates. The Filter syntax is Filter(P 1,...,P n )(S), where P 1,...,P n are predicates over stream S. The result of the Filter operator consists of n +1different streams S 1,...,S n, such that each stream S j, contains those tuples of S satisfying predicate P j, j {1,...,n}. Moreover, tuples that do not satisfy any predicate among P 1,...,P n are returned in an additional stream S n+1. Note that in the paper we do not consider the (n +1)th stream, i.e., the stream containing tuples not satisfying any predicate, by simply assuming that these tuples are not given output. Moreover, we assume that no Filter operation is performed if the set of predicates is empty. Let us consider the Position

5 414 B. Carminati, E. Ferrari, and K.L. Tan stream of our motivating scenario, if we are interested in selecting only those soldiers whose position crossed a given border k, we can specify the following expression: Filter(Pos>k)(Position). Another relevant operator of Aurora algebra is the Map box, which can be considered as a generalized projection operator. The syntax of Map is the following: Map(A i =F i,...,a j =F j )(S), where {A i,...,a j } is a subset of the attributes of S schema, and F i,...,f j are arbitrary functions over the input stream. Thus, instead of projecting the value of an attribute A i,themap operator projects the result of an arbitrary functions applied on it. In the paper, for simplicity, we consider a Map operator projecting only attributes values. This can be obtained by applying only the identity function rather than arbitrary function, which is omitted in the following examples. Let us consider for instance the Health stream. Map(SID,Heart)(Health) projects attributes SID and Heart. Moreover, if the set of attributes specified in the Map operator is empty, we assume that the operation returns the input stream. In the Aurora algebra there is a further operator, Bsort, which sorts the tuples of a stream applying a bound pass bubble sort. The simplified syntax of this operator is the following: Bsort(S). For instance, Bsort(Position) performs the bubble sort on the Position stream. 1 The Aurora algebra provides also an aggregate operator, i.e., Aggregate box, by which it is possible to apply both SQL-style aggregate operations and Postgres-style user-defined functions over data streams. Aggregate operators are evaluated according to a sliding window-based approach. This implies that the Aggregate operator receives as input both the size of the window and an integer specifying how to advance the window when it slides. The simplified syntax used throughout the paper is the following: Aggregate(F, Size s, Advance i)(s), where F can be either an SQL-style aggregate operation or a Postgres-style user-defined function. As an example, Aggregate(Avg(Heart),2,1)(Health) returns the average of the soldier heart beats computed over windows with size 2 hours and advance step of 1. The Aurora algebra also provides the Join operator. The join operator is a binary operator where the join predicate is specified as input. Throughout the paper, we adopt a variation that allows an arbitrary number of operators (not necessarily two). More precisely, we use the following syntax: Join(P)(S 1,...,S n ). 2 Let us consider once again, the Position and Health streams. Join(Position.SID=Health.SID) (Position, Health) performs the natural join of Position and Health streams. Moreover, if no predicate is specified in the join operator, the result is the Cartesian product of the input streams. A further operator is the Resample box, which can be helpful to align pairs of streams. The simplified syntax used in the paper is the following: Resample(F) (S 1,...,S n ), where F is the interpolator function used in the semijoin-like synchronization. Finally, a further relevant operator is the Union box, which is used to merge a set of streams, having a common schema, into a unique output stream. 1 According to the algebra in [2], it is possible to specify as input the assumed ordering over output streams. 2 Note that the syntax proposed in [2], allows one to specify as input also the assumed ordering over input streams S 1,S 2.

6 Specifying Access Control Policies on Data Streams An Access Control Model for Data Streams Generally, an access control policy states which subjects can access which (portions of) objects and under which conditions. Thus in designing an access control model for data streams we first need to specify the basic components of an access control policy, that is, the subject, protection object and privilege specification. Then, we will formally introduce access control policies for data streams, whereas their formal semantics is presented in Section 4. Subject specification. We specify subjects according to a role-based approach [8]. Thus, access control policies associate permissions with roles, instead of with subjects, and subjects acquire permissions through their membership to roles. Examples of roles for our reference scenario are soldier, doctor,andcaptain. Protection object specification. As pointed out in Section 2.1, an access control model for data streams should allow attribute-level and tuple-level access control. Thus, there is the need of an object specification flexible enough to represent, for instance, a whole stream, only selected stream s attributes, as well as only tuples satisfying certain conditions. To model such a variety of granularity levels, we borrow some ideas from how access control is enforced in traditional RDBMSs, where different granularity levels are supported through views. The idea is quite simple: define a view satisfying the access control restrictions and grant the access on views instead of on base relations. A view is defined by means of a CREATE VIEW statement, where the SELECT clause of the query defining the view specifies the authorized attributes, the FROM clause specifies a list of relation(s)/views, and the WHERE clause states conditions on attributes values. We adopt the same idea to specify protection objects to which an access control policy applies. However, since a standard query language for data streams has not yet emerged, 3 we give a language independent representation of protection objects. Basically, we model a protection object by means of three components, which correspond to the SELECT, FROM and WHERE clauses of an SQL statement. Before presenting the formal definition of protection object specification we need to introduce some notations. In what follows, we denote with Source the set of all the streams to be protected, whereas given a stream S we denote with S.schema the set of attributes in S s schema. Definition 1. (Protection Object Specification). A protection object specification p obj is a triple (STRs, ATTs, EXPs),where: - STRs is a set of streams {S 1,...,S n }, belonging to Source; - ATTs denotes a set of attributes A 1,...,A l,wherea j, j {1,...,l}, belongs to the schema of the stream resulting from the Cartesian product {S 1... S n } of the streams in STRs.IfATTs is equal to symbol *, it denotes all the attributes belonging to the schema of the stream resulting from the Cartesian product {S 1... S n }. - EXPs is a boolean formula, built over predicates of the form: A i value or A i A j,wherea i, A j are attributes belonging to the schema of the Cartesian product {S 1... S n }, is an operator of the Aurora algebra, and value is a value compatible 3 However, several research groups are doing a lot of work in this direction (see, for instance, [4,9]).

7 416 B. Carminati, E. Ferrari, and K.L. Tan Table 1. Examples of protection object specifications Streams Attributes Expressions Position * - Position * Position.Platoon=X123 Health, Position Health.Heart, Health.SID Position.SID= Health.SID AND Position.Platoon=X123 with the domain of A i.ifexps is omitted, it denotes all the tuples in the Cartesian product {S 1... S n }. Given a protection object specification p obj, we use the dot notation to refer to its components. According to Definition 1, a protection object specification p obj identifies a view over the Cartesian product {S 1... S n },wheres j p obj.strs, j {1,...n}. The view is obtained by selecting from the Cartesian product all attributes specified in p obj.atts, and by considering only those tuples satisfying conditions expressed in p obj.exps. Example 1. Table 1 presents three examples of protection object specifications defined according to Definition 1. The first protection object specification identifies the whole Position stream. By contrast, in the second protection object specification a condition on its content (i.e., Position.Platoon=X123) is specified, thus identifying only those tuples of the Position stream having the Platoon attribute equal to X123. Finally, the third specification defines a protection object generated over the Cartesian product of Position and Health, where only Heart and SID attributes are projected. The condition expressed by the EXPs component ensures that only tuples having Position.SID= Health.SID (i.e., join predicate) and referring to soldiers belonging to platoon X123 are considered. Privileges. Privileges supported by the proposed access control model authorize all operations provided by Aurora (see Section 2.2), namely, Filter, Map, BSort, Union, Aggregate, Join and Resample. Instead of defining a different privilege for each operation, we assume that there exists a Read privilege which authorizes a subject to exercise the Filter, Map and BSort operations on a protection object, that is, all operations that require to read tuples from the data stream. Note that, if the Security Administrator (SA) wants to limit the right to read a stream only to selected attributes and/or tuples, the SA can grant the Read privilege directly on a protection object modeling the corresponding view. The same happens if the Read privilege has to be granted on the result of a join operation (or on a subset of its tuples). In contrast, our policy format does allow the SA to specify the Read privilege for a view consisting of the union of more data streams because we assume that the Union operation is authorized if the requesting user has the Read privilege on the two operand streams. The other class of privileges supported by our model, called Aggregate privileges, corresponds to aggregate functions allowed by Aurora. As introduced in Section 2.2, Aurora supports both SQL-style aggregate operations and Postgres-style user-defined functions. Here, to be as system independent as possible, we consider as aggregate functions only the standard SQL-style functions. Thus, the aggregate privileges are: Min, Max, Count, Avg,andSum.

8 Specifying Access Control Policies on Data Streams 417 Temporal constraint specification. As discussed in Section 2.1, an access control model for data streams should be able to handle two different kinds of temporal constraints, that we call general and window-based constraints. Constraints of the first kind state limitations on the time during which subjects can exercise privileges on protection objects. They can be expressed in the form: [begin,end],wherebegin and end are the lower and upper bounds, begin end, andend can assume the infinite value. 4 The begin and end values can be explicitly specified by the SA or can be returned by a predefined set of system functions SF. For instance, we can assume a function TAction start(a), which returns the time TS when a given action a starts, and a function TAction end(a) that returns the time TE when an action a ends. It is important to note that by definition a stream always contains a temporal information, i.e., the timestamp TS. Therefore a general time constraint GTC identifies all and only those tuples satisfying the predicate: TS begin TS end. For the second type of constraints, that is, those related to window-based operators, according to the Aurora algebra, a window is specified by two information: the window s size and the advance step. A window time constraint can therefore be defined by a pair: [size,step], denoting the maximum size and advance step allowed in a window-based operation. Thus, by specifying a window time constraint in an access control policy granting an aggregate privilege p on a protection object o, the SA is able to limit the window size and step according to which the aggregate operation can be executed. For instance, if the SA wants to limit a doctor to compute the average of heart beats of soldiers not belonging to his/her platoon only on a window with size 5 hours and a step of 2, he/she can state an access control policy granting the Avg privilege on the corresponding protection object by specifying [5h,2] as window time constraint. We are now ready to formally define access control policies for data streams. Definition 2. (Access control policy for data streams). An access control policy for data streams is a tuple: (sbj, obj, priv, GTC, WTC), where: sbj is a role; obj is a protection object specification defined according to Definition 1; priv {Read, Min, Max, Count, Avg, Sum}; GTC is a general time constraint; and WTC is a window time constraint. Given an access control policy acp we denote with acp.sbj, acp.obj, acp. priv, acp.gtc and acp.wtc the sbj, obj, priv, GTC, andwtc components, respectively. We assume that all the specified access control policies are stored into a unique authorization catalog, called SysAuth. More precisely, SysAuth contains a different tuple for each access control policy, whose attributes store the access control policy components, as illustrated by the following example. Example 2. Table 2 presents an example of SysAuth catalog, containing a set of access control policies for the Position and Health streams. The first policy authorizes captains and doctors to exercise the Read privilege (i.e., Filter, Map and Bsort operations) on the position and id of all and only soldiers belonging to their platoons, where this condition is modeled as a predicate (i.e., Position.Platoon=self. 4 We assume that begin and end value are specified by means of an SQL-like syntax.

9 418 B. Carminati, E. Ferrari, and K.L. Tan Table 2. Examples of access control policies for data streams Subject Protection Object Privilege GTC WTC Streams Attributes Expressions Size step Captain, Position Pos, SID Position.Platoon=self.Platoon Read Doctor Captain Position Pos, SID Pos k Avg [TAction start(a), TAction end(a)] 1 1 Doctor Health Heart, SID Health.Platoon=self.Platoon Read Doctor Health Heart, SID Health.Platoon self.platoon Avg Doctor Health, Heart, SID Position.SID= Health.SID AND Read [TAction start(a), TAction end(a)] - - Position Pos k2 Platoon). 5 The second policy authorizes captains to access the average position of soldiers that are across some border k (here modeled as Pos k), as well as their ids, but only during action a. Moreover, this policy states that the average can be computed only on windows of 1 hour with 1 as step. The third policy allows a doctor to monitor the heart beats only of those soldiers belonging to his/her platoon. In contrast, by means of the fourth policy a doctor is able to monitor the average of heart beats of soldiers not belonging to his/her platoon, but only with a window of size and step equal to 1. Finally, the fifth policy states that during action a doctors are authorized to monitorthe heart beats of all the soldiers that do not cross some border k2, independent from their platoons. 4 Access Control Policies Semantics In this section, we introduce the semantics of the access control policies presented in Section 3. In particular, given an access control policy acp in order to define its semantics we need to define the semantics of the subject, protection object, and privilege component, as well as the semantics of window time constraints. We do not provide an explicit semantics for general time constraints since we include it in the protection object specification semantics. Definition 3. (Subject specification semantics). Let Roles be the set of all possible roles, and Sbj be the set of all possible subjects. We denote with λ(r) the set of subjects authorized to play role r Roles, and returned by the assignment function λ : Roles Sbj. Given an access control policy acp, thesemantics of the subject specification of acp, is given by the α function, defined as follows: α(acp)= λ(acp.sbj) Definition 4. (Protection object specification semantics). Given an access control policy acp, the protection object specification semantics of acp is the set of tuples denoted by the protection object specification and the general time constraint stated in acp. On the basis of the semantics of Aurora operators, the protection object specification semantics is given by the β function defined as follows: 5 We assume that each subject has an associated profile, i.e., a set of attributes modeling the subject s characteristics, like for instance the platoon one belongs to.

10 Specifying Access Control Policies on Data Streams 419 if acp.obj.strs =1, then β(acp)= Map(A 1,...,A n )(Filter(acp.obj. EXPs TS acp.gtc.begin TS acp.gtc.end)(acp.obj.strs)), otherwise β(acp)= Map(A 1,...,A n ) (Filter(acp.obj.EXPs TS acp.gtc. begin TS acp.gtc.end)(join({s 1,...,S n }))), S j acp.obj.strs j {1,...n}; where {A 1,...,A n } belongs to acp.obj.atts. If acp.obj.atts =*, then {A 1,...,A n } are all the attributes of streams belonging to acp.obj.strs. Table 3. Protection object specification semantics for the access control policies in Table 2 Acp Protection object semantics acp 1 Map(Pos, SID)(Filter(Position.Platoon=self.Platoon)(Position)) acp 2 Map(Pos, SID)(Filter(TS TAction start(a) AND TS TAction end(a) AND Pos k) (Position)) acp 3 Map(Heart, SID)(Filter(Health.Platoon=self.Platoon)(Health)) acp 4 Map(Heart, SID)(Filter(Health.Platoon self.platoon)(health)) acp 4 Map(Heart, SID)(Filter(TS TAction start(a) AND TS TAction end(a) AND Position.SID= Health.SID AND Pos k) (Join(Health, Position))) Example 3. Table 3 presents the protection object specification semantics for the access control policies presented in Table 2. The first row refers to the first access control policy in Table 2, where no general time constraints are specified and the protection object is defined overa single stream, i.e.,position, by projecting the Pos and SID attributes and applying the condition Position.Platoon=self.Platoon. The semantics of the corresponding protection object is the set of tuples resulting from a Filter operation applied to the Position stream, with expression Position.Platoon= self.platoon. Then, to obtain the final set of tuples representing the semantics, a Map operator is applied to the resulting stream projecting the Pos and SID attributes. By contrast, a general time constraint is specified in the second access control policy in Table 2. In such a case, in addition to the predicate specified in the protection object (i.e., Pos k), the Filter operator also contains the conditions related to the general time constraint (i.e., TS TAction start(a) TS TAction end(a)). The semantics of the protection object specification of the third and fourth policies are similar to the first one, since similar to the first access control policy, the third and fourth access control policies do not have any general time constraint, and the protection objects are defined in terms of a single stream. By contrast the protection object specification of the last policy denotes a view generated on two streams (i.e., Health and Position streams). In such a case, the tuples denoting the protection object specification semantics are the result of a join operator applied on Health and Position streams, where no join predicate is specified, thus to obtain the Cartesian product. To the resulting stream a Filter operator is applied with the expressions contained in the protection object specification, that is, the join predicate Position.SID=Health. SID and the predicate Pos k2. Then, the predicate modeling the general time constraint (i.e., TS TAction start(a) TS TAction end(a)) is added to the expression. Finally, the Map operation projects the Heart and SID attributes. The semantics of privilege specification is given by the following definition.

11 420 B. Carminati, E. Ferrari, and K.L. Tan Definition 5. (Privilege semantics). Given an access control policy acp,theprivilege semantics of acp is given by the χ function defined as follows: if acp.priv=read, thenχ(acp) = {Filter,Bsort,Map,Union,Join, Min,Max,Count,Avg,Sum} χ(acp)= acp.priv,otherwise. Finally, we need to state the semantics of window time constraints. Definition 6. (Window Time constraint semantics). Given an access control policy acp,thewindow time constraint semantics of acp is given by the δ function defined as follows: if acp.priv {Min, Max, Count, Avg, Sum},thenδ(acp)=[acp.WTC.size, acp.wtc.step]; δ(acp)= null, otherwise. We are now ready to define the semantics of an access control policy. Definition 7. Access control policy semantics. Given an access control policy acp, the semantics of acp is defined as follows: φ(acp)= {(S,T,p,WTC) S=α(acp), T=β(acp), p=χ(acp), WTC=δ(acp)} According to Definition 7, given an access control policy acp we define its semantics as a set of authorizations defined as tuples: (S,T,p,WTC), wheres is a subject or a set of subjects identified by the subject specification semantics of acp, T is a set of tuples identified by the protection object specification semantics of acp, andp is a set of privileges. If p is an aggregate privilege (i.e., Min, Max, Count, Avg,andSum)the last component of the policy semantics, i.e., WTC, contains the window time constraint, if any, specified in acp. An authorization (S,T,p,WTC) states that subjects belonging to S are authorized to exercise privileges p on all and only the tuples belonging to set T, constrained by the window time constraint WTC, ifany. Example 4. Let us consider the second access control policy in Table 2, assuming that in the system the only users to which role Doctor is associated are Alice and Bob. According to Definition 7, the semantics of this access control policy is the set of authorizations (S,T,p,WTC), wheres denotes Alice and Bob, T is a set of all tuples identified by expression Map(Pos, SID)(Filter(TS TAction start(a) AND TS TAction end(a) AND Pos k)(position)), p is the Avg privilege, and WTC denotes the window time constraint, i.e., size and step equal to 1. 5 Conclusion In this paper, we have presented an access control model and its formal semantics specifically tailored to stream data. The model is role-based and allows the specification of policies at different granularity levels. It supports a set of privileges corresponding to the operations that can be executed over stream data. Moreover, it allows the SA

12 Specifying Access Control Policies on Data Streams 421 to specify temporal constraints. This is particularly relevant for aggregate operations where one can constrain the aggregate operation only to specific time intervals. The work reported in this paper is the first step of a wider project, aiming at developing a complete and fully implemented access control mechanism for stream data. Future work include definition of efficient enforcement strategies for policies specified according to our access control model and the implementation on top of the Borealis data stream engine. Additionally, we plan to extend the presented model to deal with data updates and multiple queries. References 1. D.J. Abadi, Y. Ahmad, M. Balazinska, U. Çetintemel, M. Cherniack, J.H. Hwang, W. Lindner, A. Maskey, A. Rasin, E. Ryvkina, N. Tatbul, Y. Xing, and S.B. Zdonik. The design of the borealis stream processing engine. In Proceedings of Conference of Innovative Data System Research (CIDR 05), pages , Asilomar, USA, D.J. Abadi, D. Carney, U. Çetintemel, M. Cherniack, C. Convey, S. Lee, M. Stonebraker, N. Tatbul, and S.B. Zdonik. Aurora: a new model and architecture for data stream management. In VLDB Journal, 12(2): , A. Arasu, B. Babcock, S. Babu, M. Datar, K. Ito, I. Nishizawa, J. Rosenstein, and J. Widom. Stream: The Stanford stream data manager. In Proceedings of ACM SIGMOD 03, page 665, San Diego, USA, B.Babcock, S. Babu, M. Datar, R. Motwani, and J. Widom. Models and issues in data stream systems. In Proceedings of ACM SIGMOD-SIGACT-SIGART symposium on Principles of database systems (PODS 02), pages 1 16, New York, USA, S. Castano, M.G. Fugini, G. Martella, and P. Samarati. Database Security. Addison-Wesley, S. Chandrasekaran, O. Cooper, A. Deshpande, M.J. Franklin, J.M. Hellerstein, W. Hong, S. Krishnamurthy, S. Madden, V. Raman, F. Reiss, and M.A. Shah. TelegraphCQ: continuous dataflow processing for an uncertain world. In Proceedings of Conference of Innovative Data System Research (CIDR 03), Asilomar, USA, E. Ferrari and B. Thuraisingham. Secure Database Systems. In O. Diaz and M. Piattini editors, Advanced Databases: Technology and Design, Artech House, London, D.F. Ferraiolo, R. Sandhu, S.Gavrila, D.R. Kuhn, and R. Chandramouli. Proposed nist standard for role-based access control. In ACM Transaction on Information System Security, 4(3): , L. Golab and M.T. Ozsu. Issues in data stream management. In SIGMOD Record, 32(2): 5 14, StreamBase Home Page.