and effective emergency management is the availability of an infrastructure on support of information sharing. Indeed, during emergency situations it is vital that ...
2011 IEEE International Conference on Privacy, Security, Risk, and Trust, and IEEE International Conference on Social Computing
Secure information sharing on support of emergency management Barbara Carminati, Elena Ferrari, Michele Guglielmi DICOM, University of Insubria, Italy {barbara.carminati, elena.ferrari, michele.guglielmi}@uninsubria.it
In order to achieve this goal, when an emergency happens, it is necessary to bypass the regular access control policies and grant users access to resources not normally authorized, in order to handle the emergency. However, such downgrading of the information security classification should be temporary and controlled, that is, regulated by proper emergency policies. Moreover, enforcement of emergency policies should not cause too much overhead, since a timely response is one of the key requirements of emergency management. Therefore what is needed is a system able to: 1) make a user able to specify emergency policies; 2) detect the events that cause the triggering of an emergency policy; 3) make immediately available to the authorized subjects information covered by the emergency policy. In this respect, the contributions of this paper is twofold. First, we propose a novel concept of emergency policies, capable of enforcing a flexible and secure information sharing in emergency situations. A key feature on our policies is the possibility of expressing complex emergency situations by also considering information related to the emergency context. Moreover, we extend regular access control policies with temporary access control policies, that override regular policies during emergency situations. Such policies also support obligations, that is, set of actions that must be fulfilled when a certain event occurs in the system. The second contribution is that we show how the emergency policy enforcement mechanism can benefit from the recent advent of Complex Event Processing (CEP) systems [5], [6], [7] as they allow to easily capture complex event patterns signaling the beginning/ending of an emergency. We also report preliminary experiments on the overhead implied by the triggering of emergency policies. Policy languages in support of emergency management have been already proposed in the literature. For instance, [8], [9], [10], [11], [12], [13], [14] use the concept of Break-the-Glass (BtG) policies to manage emergency situations. According to this paradigm, when a subject requests an access, the system checks regular access control policies. In case the request is denied, the system verifies whether this decision can be overridden by a BtG policy and, in such a case, the subject is notified and asked to confirm. In our proposal, when an access is denied by a regular policy, the system checks if this decision can be overridden by a temporary access control policy activated by the emergency and, in this case, the access is granted. These two approaches seem similar, but there are important differences: (i) BtG policies are always active, whereas our emergency policies are active
Abstract—One of the most strategic component for an efficient and effective emergency management is the availability of an infrastructure on support of information sharing. Indeed, during emergency situations it is vital that the necessary information timely reaches the right person. Even if emergency management usually requires to bypass access control policies in place during the system normal operations, it is crucial that such process is temporary and controlled by proper emergency policies. To cope with these requirements, in this paper we present a system able to: 1) detect the events that cause the triggering of an emergency policy; 2) make immediately available to the authorized subjects information covered by the emergency policy. This is achieved by the definition of flexible emergency policies and by the use of a Complex Event Processing system on support of event monitoring and policy triggering. The paper also presents preliminary experiments on system overhead.
I. I NTRODUCTION “Emergency management is the generic name of an interdisciplinary field dealing with the strategic organizational management processes used to protect critical assets of an organization from hazard risks that can cause disasters or catastrophes, and to ensure the continuance of the organization within their planned lifetime” [1]. The main building blocks to deal with this complex process are: risk reduction; preparing resources to respond to the emergency; responding to the emergency and the damages it caused (response phase); and return as soon as possible to the state before emergency, or to a “safe” state in case the original situation cannot be restored (recovery phase). It is today well recognized that a key requirement for all the phases of emergency management is the possibility of a flexible and timely information sharing. For instance, as pointed out in [2], [3], two very different emergency situations, like attacks of September 11, 2001, and the Hurricane Katrina, have shown that the lack of effective information sharing between Federal, State and local agencies resulted, on the one hand, in the failure of Federal authorities to intercept the Twin towers attack and, on the other, in the lack of a prompt and effective response and recovery from the hurricane. One of the key priority (see e.g., [4]) is therefore the development of an information sharing environment able to deliver the right information to the right people at the right time. In traditional information systems, information sharing is usually regulated by a proper set of pre-defined access control policies that state who can access which data portion and under which mode. This model does not fit the emergency management scenario, where usually there is the need to access resources with greater flexibility than during the normal system operations. 978-0-7695-4578-3/11 $26.00 © 2011 IEEE DOI
988
only during emergencies and this allows a more precise tuning of normal policy overriding (ii) a user can decide when to use a BtG policy to override a regular one, whereas in our proposal only the system can override a regular policy. An important advantage of our schema is in term of security, because a user can not decide whether to break the glass, rather only the system can override a regular policy and only during an emergency. Another advantage is the rapidity in emergency management, i.e., a user can wait a while to respond when the system prompts the BtG request, while in our model the system overrides immediately regular policies when the emergency is detected. Our work is also related to context-aware access control [15] since emergency situations are modeled by taking into account contextual information and temporary access control policies support the specification of constraints on contexts. Since we do not aim to propose a new way of context modeling, rather to exploit the existing ones to better capture emergency situations, we can consider our work to be orthogonal to the efforts in the field of context-aware access control. Some works also proposed to use contexts to model particular emergency situations (see for example [16], [17]). However, in our model, emergencies are detected automatically by the CEP, whereas in the cited work emergencies are indirectly activated by users (i.e., users set the attributes that determine a state of emergency [16] ) or automatically from context information [17], but without the use of event processing or CEP systems. The remainder of the paper is organized as follows. Section II deals with emergency modeling, whereas Section III presents emergency policies. System architecture is illustrated in Section IV, whereas Section V presents our preliminary performance evaluation. Finally, Section VI concludes the paper.
emergency event can be simple, as a query on a single data stream (e.g., s.heart_rate < 60,1 where s is the patient vital signs stream and heart_rate one of its attributes), as well as more complex, like an aggregation query on a joint set of streams (e.g., an event to detect an epileptic attack should join many information about patient vital stream and movement sensors stream). To catch these emergency events, the proposed representation has to be able to model queries on streams. This can be done through stream query languages. However, in addition to conditions on streams, we are also interested in the detection of relationships between simple/complex events that might happen with different temporal order. For instance, let us assume that patients wear also movement sensors. To catch the emergency of the patient fall, it is necessary to detect this sequence of events: the patient falls to the ground and he/she does not stand up within the next 2 minutes. The literature offers several languages for event pattern specification (e.g., Amit [18], XChangeEQ [19], SpaTec [20], TESLA [21] and SASE+ [22], [23]). Some languages have also been proposed by vendors (e.g., Streambase, Sybase, Oracle CEP). These languages mainly differ in the set of constructs they support. However, up to now, a standard event specification language has not yet emerged. To overcome the problem of lack of standardization, we make use of a Core Event Specification Language, hereafter CESL, which helps us to develop a framework which is as much as possible independent from the target CEP system. Table I reports the main constructs of the proposed core language. Stream operators are taken from [24]. Note that, in addition to simple/complex events/event patterns detected from data streams, also contextual information might trigger an emergency. As an example, knowing that a patient suffers from diabetes impacts the condition on glucose level for hyperglycemia emergency. Emergency events are therefore defined to consider both information coded into data streams as well as context information, where a context is represented as a set of pairs specifying a set of context characteristics relevant for emergency management.
II. E MERGENCY DESCRIPTION Critical scenarios are often observed analyzing relevant information (e.g., body measures) collected by means of a set of sensor networks. In general, gathered data are sent to a monitor unit in the form of data streams (i.e., an append-only sequence of tuples with the same schema). This allows the monitor unit to continuously analyze them and immediately trigger the emergency when some particular constraints hold. Therefore, a CEP can play the role of monitor unit.
Definition II.1. (Emergency Event): Given a set of streams S, and a context C, an emergency event ev is defined as (eventP attern, exp, identif ier), where EventP attern is an event pattern on streams in S specified according to CESL, exp is a boolean expression on attributes in C, and identif ier is a subset of attributes in S. An emergency event ev is activated when ev.eventP attern is detected and ev.exp is satisfied.
Example II.1. Let us consider as reference scenario patient remote monitoring. We assume that patients wear several monitoring devices that catch their health measures (e.g., temperature, heart rate, blood pressure, glucose, etc.). All gathered measures are encoded as tuples in a data stream and sent to a CEP, which can easily detect any anomaly signaling an emergency situation. As an example, an event modeling an emergency situation is given by heart rate measure lower than 60 bpm.
Every time an emergency event is triggered an emergency instance is created. Several instances of the same emergency event could hold at the same time, but with different values for attributes in identif ier. The identif ier component plays a key role in that it ensures to trigger an emergency instance only once, as the following example clarifies.
According to the above scenario, conditions triggering the emergency are expressed as constraints on streams. Following stream terminology, we say that an emergency event happens when a tuple satisfying an emergency condition arrives. The
Example II.2. Let us consider again the patient monitoring 1 Here and in the following we use dot-notation to indicate attributes of objects (e.g., streams, events).
989
stream
S
predicate selection projection window w
P =aθb σ(P )(S) π(A1 , ..., An )(S) time-based window [s, o] tuple-based window [s, o]
aggregation
event-based window [e1 , e2 ] mixed window [e1 , s] (F, A)(S)[s, o]
join
Join(P )(S1[s1 , o1 ], S2[s2 , o2 ]),
event type event instance array
ET ET e ET e[ ] ET e[ ][w]
sequence
ET1 e1 , ET2 e2 [e1 , S1 ], ..., ETn en [en−1 , Sn−1 ]
negation iteration
¬ ET e[w] ET e[ ][w]{P } where P is a predicate P = α θ β and e[] is an array of event instances of the event type ET that occur in window w.
Stream Operators a stream S with attributes Att(S) = {A1 , ..., An } is a real-time, continuous, ordered (potentially unbounded) sequence of tuples. a is an attribute ∈ Att(S), θ ∈ {|=|≤|≥}, b is an attribute ∈ Att(S) or a constant. selection of stream S that satisfies predicate P . projection of stream S over attributes {A1 , ..., An } ∈ Att(S). s (size) is the window size, denoted as number of time units, o (offset) is the number of time units which represents how the window advances to form a new window. s is the window size, denoted as number of tuples, o is the number of tuples which represents how the window advances to form a new window. window is created when event e1 occurs and is closed when event e2 occurs. window is created when event e1 occurs and the window size is s. aggregation of attribute A of stream S according to function F over windows generated with size s and offset o. join with respect to predicate P over tuples of sliding windows of stream S1(i.e., S2) generated with size s1(i.e., s2) and offset o1(i.e., o2). Basic Event Operators an event type is a query over one or more streams. an event instance is a tuple satisfying the query ET . declaration of the array e[ ] of event instances of the event type ET . declaration of the array e[ ] of event instances of the event type ET that occur in window w. Event Pattern Operators it matches if event e2 (of the event type ET2 ) occurs within S1 time units after occurrence of event e1 , event e3 occurs within S2 time units after e2 and so on, defining in this way the sequence {e1 , e2 , e3 , ..., en }. matches if event e has not occurred in window [w]. α = (att, i), θ ∈ {|=|≤|≥} , β = (att, j) or a constant. att is an attribute ∈ Att(ET ), i and j are indexes ∈ I, such that: I = {1, ..., |e|} ∪ {∗, ..i, i − x} , x ∈ {0, ..., i − 1}), and j < i. An index i represents a specific event in e[] when i ∈ {1, ..., |e|}, all events in e[] when i = ∗, all events before e[i] when i = ..i, or the event occurred x-events before e[i] when i = i − x.
Table I CESL OPERATORS
that init.identif ier = end.identif ier.
scenario assuming that every 30 seconds each sensor catches the heart rate value of patients and sends it to the monitoring system as a stream S of tuples (heart_rate, patient_id). Let us assume an emergency event ev defined as (heart_rate < 60, −, patient_id), which implies that ev is activated when heart_rate < 60 and only if no other instance of the same emergency event is activated for the same patient_id. As an example, consider the following tuples generated by monitoring patients a and b: (61, a), (60, a), (59, a), (58, a), (57, b). When the third tuple arrives an instance for ev is created for patient a, but when the fourth tuple is received no new instance is created since the heart rate was already lower than 60 bpm for patient a. In contrast, it is correct to create a new instance when the fifth tuple is received because it comes from a different patient (b).
In case the ending event is not specified, an emergency expires only when init becomes false or when the time period in timeout is expired. As an example, in an emergency situation for an attack of tachycardia, the init event is defined so as to become active when pulse becomes higher than 90 bpm, whereas the end event is not specified and timeout is set to ∞. In this case, the emergency ends when the pulse returns lower than 90 bpm. Example II.3. According to Definition II.2 the emergency modeling a cardiac arrest situation can be represented as follows: CardiacArrest { init: (VitalSigns1 v, _, patient_id); VitalSigns1 = σ(heart_rate = 0)(S); end: (VitalSigns2 v, _, patient_id); VitalSigns2 = σ(heart_rate > 60)(S); timeout: ∞; }
Emergency events are the building blocks of the proposed emergency representation, which has been designed based on the concept that an emergency situation starts once an emergency event happens and stops when another one is detected . As such, we model an emergency as a couple of emergency events, called init and end. Hereafter, without loss of generality we refer to init and end as events, specifying simple/complex or pattern only if needed.
III. E MERGENCY P OLICIES In this section we first introduce emergency policy specification, then we deal with specification correctness.
Definition II.2. (Emergency): An emergency e is a tuple (init, end, timeout), where init and end are emergency events specified according to Definition II.1, such that init denotes the event triggering the emergency e, end is the optional event that turns off e, timeout is the time within e expires even though end has not occurred.2 To bind init and end to refer to the same emergency instance, we assume
A. Emergency Policy Specification An emergency policy aims to make emergency managers able to state the access control policies that have to be in place during response and recovery. To this purpose, we design an emergency policy such that it identifies both the temporary access control policies to be activated and the emergency that has to trigger their activations. More precisely, an emergency policy specifies the template of the temporary access control policy that has to be enforced during the
2 timeout is a temporal expression in the form [n time_unit], where n ∈ N ∪ {∞} and time_unit ∈ {ms, s, mi, h, d, w, mo, y}, ms=milliseconds, s=seconds, mi=minutes, h=hours, d=days, w=weeks, mo=months, y=years.
990
authorized user exercises priv on obj;
emergency. When an emergency occurs, an instance of the corresponding temporary access control policy template is created and stored among regular access control policies. In defining temporary access control policy templates and their association with an emergency, the emergency manager has to be able to specify conditions on values extracted from context as well as emergency instances. For example, the temporary access control policy can grant the access only to the Electronic Medical Record (EMR) of the patient for which the emergency is instantiated and only to the paramedic who answered the emergency call. Further requirements arise from the reference scenario.
emergency obligation: is an action or a set of actions that must be executed after the detection of emg. Example III.2. Let us assume that the monitored patient is hospitalized at home and assisted by his/her personal doctor who is allowed to read his/her EMR and to write prescriptions. When CardiacArrest emergency (Example II.3) is detected an emergency obligation is triggered that implies to automatically call an ambulance for the patient address. Moreover, an access control policy with the following parameters is enabled: the target object is the EMR of the patient under emergency condition, the only subjects allowed to access this EMR are paramedics on the ambulance, the granted privileges are read/write, and the obligation consists of sending an email to the patient doctor when a paramedic accesses the patient EMR.
Example III.1. In the patient remote scenario, regardless the kind of emergency, a prompt response of doctor is always required. Therefore, the emergency manager should be able to specify in the emergency policy which actions, if any, have to be immediately executed after the emergency detection in order to handle the crisis. For instance, the emergency policy should require to automatically call an ambulance when a patient is under emergency conditions. Moreover, in normal situation an EMR can only be accessed by the doctor of the user to which the EMR refers to. Obviously, in emergency situations, in addition to this access control policy, new ones granting the access to others taking care of the patient at the time of the emergency (e.g., ER doctors, paramedics) should be activated. According to part 146 (Security and Privacy) of the Health Insurance Portability and Accountability Act (HIPAA), "An individual has a right to receive an accounting of disclosures of protected health information made by a covered entity (health plans, health care clearinghouses and health care providers)". In order to accomplish this goal when a person, not normally authorized, accesses an EMR during an emergency an audit log has to be created. This highlights that it is also relevant to be able to specify actions that must be executed when the temporary privileges are exercised, e.g., creation of an audit file.
B. Emergency Policy Correctness The main benefit of emergency policies is the activation/deactivation of temporary access control policies when given events (i.e., init and end) are detected. However, since the consequence of events detection is the release of sensitive information, particular attention has to be paid in properly defining the init and end emergency events. In this section, we are not interested in possible syntactic or semantic errors in the init/end emergency event specification. Rather, we are interested in those init and end event specifications that are both semantically and syntactically correct, but that, due to wrong correlations, could compromise the activation of emergency policies. In particular, we have identified a possible incorrect correlation when init and end events are defined so as to have predicates that simultaneously hold, that is, when at least a tuple can exist verifying both init and end predicates. In this case, the arrival of this tuple implies the simultaneous creation and deletion of emergency instances and the corresponding temporary access control policy, as the following example shows.
As such, the temporary access control template has to support the obligation concept, that is, the specification of actions that have to be fulfilled every time an authorized user exercises the privilege stated by an emergency policy. The example also pointed out that emergency management requires the modeling of further obligations, not related to privilege execution, to which we refer to as emergency obligations. To keep all these issues into account, we propose the following definition of emergency policies.
Example III.3. Let us consider the following definition of bradycardia emergency. Bradycardia { init: (VitalSigns1 v, _, patient_id); VitalSigns1 = σ(heart_rate ≤ 60)(S); end: (VitalSigns2 v, _, patient_id); VitalSigns2 = σ(heart_rate ≥ 50)(S); timeout: ∞; }
Definition III.1. (Emergency Policy): An emergency policy is a pair (emg, ans), where emg is an emergency, as specified in Definition II.2, and ans contains a set of temporary access control policy templates and/or emergency obligations of the following forms:
Tuples with heart rate in the interval [50, 60] satisfy both init and end events. Thus, the arrival of the sequence of tuples with heart rate 52, 54, 56 for the same patient, results in the creation and simultaneously removal of three instances of an emergency with the consequent activation/deactivation of the corresponding temporary access control policy.
temporary access control policy template: is a tuple (sbj,obj, priv, exp, obl), with the following semantics: when the exp boolean expression on contexts is true, users identified by the subject specification sbj are authorized to exercise the priv privilege on the protection object obj. In case obl is not null, it denotes a set of actions that must be fulfilled every time an
To avoid this situation, we perform validity checks on predicates in init and end event specifications. We consider simple/complex events as well as event patterns. Let us start to consider init/end consisting of simplex/complex events. What
991
respectively) in DN F − init (DN F − end, respectively) are defined; if these two sets are disjoint the validity checks fail, in that the predicates are independent and they could simultaneously hold. Otherwise, (2) for each common attribute between these two sets, by using the V alues() function it verifies if there is at least one value in the attribute domain that satisfies both i_clause and e_clause. Since a DNF-clause is a conjunction, if all common attributes between i_clause and e_clause could hold simultaneously then also the two clauses could hold at the same time, therefore the validity check fails. Otherwise, the validity check is satisfied.
we need to verify is that ranges of attribute values making the predicates in init and end true are disjoint.3 Unfortunately, such validity checks cannot be always performed at policy specification time. Indeed, there could exist dependencies among predicates in init/end that can be detected only at run-time. For example, when init or end contain a predicate comparing two attribute values of the same stream (e.g., a predicate that is true if the average heart rate in the last day is greater than the patient average heart rate computed in the last week). In this paper, we focus on static validity checks only, that is, checks that can be performed during emergency policy specification, leaving as future work the problem of run-time validity checks. In particular, we support validity checks for predicates of the form P = α θ β, where α is an attribute, θ = {< | > | = | ≤ | ≥}, and β is a constant value. We denote with Pinit (Pend , respectively) the set of predicates specified in init (end) events, and with Attinit (Attend , respectively) the set of attributes over which such predicates are specified. The validity check is not performed directly on init and end events, rather on their Disjunctive Normal Forms (DNF), namely DN F -init and DN F -end. This facilitates the checks in that it requires only to verify if there is at least a pair of clauses in DN F -init and DN F end that could simultaneously hold on the same attribute. If this is the case, the validity check fails. In order to verify if two clauses could simultaneously hold, we make use of a function, V alues(C, att), which takes as input a clause C and an attribute att and returns the set of values in Datt that makes C true, where Datt is the domain of attribute att. Given two clauses C1 and C2 , for each attribute a over which both C1 and C2 specify predicates, we compare the values returned by V alues(C1 , a) and V alues(C2 , a). If these two sets of values are not disjoint then the two clauses might simultaneously hold. Referring to Example III.3, init and end have both a unique predicate, which implies that their DNFs have a unique clause with a single predicate, say Cinit = heart_rate ≤ 60 and Cend = heart_rate ≥ 50. The validity check computes V alues(heart_rate ≤ 60, heart_rate) = [0, 60] and V alues(heart_rate ≥ 50, heart_rate) = [50, 300], where [0,300] is the heart rate domain. Thus, it verifies the wrong correlations since the two sets are not disjoint.4 In general, the validity check process implies to transform the init and end events into DNF formulas and to compare any clause in DN F init with any clause in DN F -end according to the method described above, and to stop if there is at least a pair of clauses whose predicates simultaneously hold. More precisely, the comparison is computed as follows: (1) the process determines the attributes on which predicates in i_clause (e_clause,
Example III.4. Suppose that a patient monitoring system monitors two different patient attributes (hr = heart_rate, t = temperature) and an emergency is initialized/ended by the following init and end events. init : (hr > 9 ∧ t > 6) ∨ (hr > 6)
(1)
end : (hr ≤ 6 ∧ t ≤ 9) ∨ (hr ≤ 9)
(2)
The validity check first considers the first clause of init and end and verifies that for the common attribute hr the intersection of values returned by the V alues() function is empty. However, this is not true for attribute t (i.e. V alues(hr > 9 ∧ t > 6, t) ∩ V alues(hr ≤ 6 ∧ t ≤ 9, t) = [7, 9]). Although, the two predicates might simultaneously hold on t, they cannot simultaneously hold on hr, therefore the two clauses cannot hold at the same time. The other couples of clauses, i.e., 9 ∧ t > 6), (hr ≤ 9)>, 6), (hr ≤ 6 ∧ t ≤ 9)>, and 6),(hr ≤ 9)> cannot hold at the same time except the latter (i.e., (hr > 6) and (hr ≤ 9)), which can simultaneously hold, for example if a tuple (hr = 8) is received. Since these two clauses can hold simultaneously and a DNF is a disjunction, init and end might also simultaneously hold, therefore they are not correctly defined. Validity checks can be performed also in case init/end contain event patterns (i.e., iteration, negation, sequence). Here, we exploit again the V alues() function to compute the range of satisfiability of predicates in the events specified in the pattern, so as to verify that they do not simultaneously hold. In doing that, we have also to consider the temporal order required by the pattern (i.e., the windows specified in the pattern, cfr. Table I). Let us consider, as an example, that init and end contain an event sequence. A simultaneously holding of both the sequences is possible only if: (a) they specify the same temporal order according to which events have to occur (i.e., the set of windows in the sequence), (b) each event ej in the init sequence simultaneously holds with the corresponding j-th event in the end sequence.
3 As described in [24], any stream query Q can be represented according to three components: STRs, theset of streams given as input to Q, ATTs, the attributes specified in π and operators, and EXPs, the predicates specified in σ and Join operators. We can define the stream resulting from Q as the Cartesian product of streams in STRs, where all attributes specified in ATTs are projected, and all predicates specified in EXPs are applied. Thus, as predicates in init and end event specifications we can consider those in the EXPs component. 4 Note that, a conjunctive clause C might contain more predicates over the same attribute a. That is C = C1 ∧ C2 . In this case V alues(C, a) is computed as V alues(C1 , a) ∩ V alues(C2 , a).
Example III.5. Consider the reference scenario of the patient remote monitoring and suppose that stream S also encodes the temperature measurements. An emergency is detected when a patient temperature is increasing i.e., a sequence of events with increasing temperature values is received. IncreasingTemperature { init: (VS1 v1 , VS2 v2 [v1 ,5m], VS3 v3 [v2 ,5m],
992
Temporary acp istances
context handler
id
sbj
obj
priv
exp
obl
10
Paramedic.id = 12
EMR.id = 2
read
...
...
8 CEP
Policies and Emergencies Repository
Emergency 4 Handler
CardiacArrest Init (VitalSigns1 v,_, patient_id); VitalSigns1=σ(heart_rate=0)(S);
O1
1 e1
2 Init handler
e1.heart_rate = 0 e1.patient_id = 2
S
6
End (VitalSigns2 v,_, patient_id); VitalSigns2=σ(heart_rate>60)(S);
3
O2
5 e2
End handler
e2.heart_rate = 80 e2.patient_id = 2
Emergency descriptions id init end identifier 1 o1 o2 patient_id Emergency Policies emergency_id policy_template_id 1 10 Temporary acp template id sbj 10
7
Paramedic.id = E-call.paramedic_id
∞
obj
priv
exp
obl
EMR.id = emg.patient_id
read
...
...
Emergency Instances Handler (EIH) emg_id 1
Figure 1.
timeout
identifier 2
Emergency Policy Management
local repository. More precisely, the local repository contains emergency descriptions (init, end, identif ier, timeout), emergency policies (emg,ans) and temporary access control policy templates (sbj, obj, priv, exp, obl). Once the init/end events are registered, the Init Handler and End Handler start the listening. When a tuple satisfying some init event arrives, it is passed to the Init Handler, which first verifies whether an emergency instance referring to this init event has been already created and, if this is the case, it checks if it is related to the same identifier value. If these checks fail, the Init Handler creates a new emergency instance and a temporary access control policy instance. An emergency instance is created by the Emergency Instances Handler (EIH) and contains information related to the emergency, such as emergency_id and identifier values, whereas a temporary access control policy instance contains actual values of objects and subjects described in the corresponding access control policy template. When a tuple satisfying some end event arrives, it is passed to the End Handler that deletes the emergency instance and the temporary access control policy instances related to this end event, if any. Context Handler checks if exp is satisfied in context C, it is called by the Init Handler before the creation of a new emergency instance, if required (i.e., exp is not null). The Context Handler is also connected to the CEP in order to retrieve context information related to events.
_, patient_id); VS1 = σ( 35 ≤ temp ≤ 37)(S); VS2 = σ( 38 ≤ temp ≤ 40)(S); VS3 = σ( temp ≥ 41)(S); end: (VS4 v4 , VS5 v5 [v1 ,5m], VS6 v6 [v2 ,5m], _, patient_id); VS4 = σ( 34 ≤ temp ≤ 37)(S); VS5 = σ( 38 ≤ temp ≤ 41)(S); VS6 = σ( temp ≥ 42)(S); timeout: ∞; }
Suppose that, for a certain patient a sequence of tuples with temperatures 36, 39, 44 is received. Since init and end contain sequences defined over the same windows and predicates can simultaneously hold, there would be created and simultaneously deleted an emergency instance of IncreasingT emperature emergency with the consequent activation/deactivation of the corresponding temporary access control policy. Thus, the overall idea is that it is possible to detect wrong correlation between init and end event patterns, if: (a) they both specify the same windows (i.e., the same set of windows in case of sequences, or the same window in case of iteration/negation); (b) each pair of corresponding event in the event pattern5 simultaneously hold. IV. E MERGENCY P OLICY E NFORCEMENT In this section, we show how the proposed emergency policies can be enforced on top of a CEP system. The main component of the proposed architecture (see Figure 1) is the Emergency Handler that carries out both registration and enforcement of emergency polices. Given an emergency policy, the first task implies the registration of init and end events in the CEP, as well as emergency polices information in the
Example IV.1. This example shows how emergency enforcement works in the emergency situation described in Example II.3 using the emergency policy presented in Example III.2 (paramedics allowed to read patient EMR). Init and end events contain the two patterns presented in Example II.3 and they are connected to the Emergency Handler. When an event e1 (e1 .heart_rate = 0) satisfying init is detected, then: (1) e1 is sent to the Init Handler, (2) the Init Handler searches in the local repository the emergency (id = 1, init =
5 In sequence/iteration pattern, corresponding events are events that are in the same position/iteration in the pattern.
993
30
Emergency instance retrieval time (ms)
Emergency Retrieval Time (ms)
35
16 14 12 10 8 6 4 2 0
25 20 15 10 5 0
0
2000
4000
6000
8000
10000
0
12000
2000
Number of Emergencies Figure 3.
6000
8000
10000
12000
Emergency instances retrieval time
Emergency description retrieval time
Temporary Access Control Template retrieval time (ms)
Figure 2.
4000
Number of Emergency Instances
o1 , term = o2 , identif iers = patient_id, timeout = ∞) corresponding to the output stream o1 and checks through the EIH if an emergency instance with the same id and identif ier already exists, if this check fails, (3) a new emergency instance (emg_id = 1, identif ier = 2) is created and (4) a new temporary access control policy (id = 10, paramedic.id = 12, EM R.id = 2, priv = read, ...) is instantiated. When an event e2 (e2 .heart_rate = 80) which satisfies end is detected, then (5) e2 is sent to the End Handler, (6) the End Handler searches the emergency corresponding to output stream o2 in the local repository, then (7) it deletes the related emergency instance through the EIH and (8) it deletes the related temporary access control policy.
25
20 15 10 5 0 0
2000
4000
6000
8000
10000
12000
Number of Temporary Access Control Templates
Figure 4.
Temporary access control template retrieval time
emergency instances retrieval time is around 30 milliseconds also with an high number of emergency instances, and the growth is linear in the number of emergency instances. In order to evaluate temporary access control template retrieval time, we measure the time required to retrieve temporary access control policy templates, by varying the number of templates. The results are shown in Figure 4. The overall time required to execute the three steps shown in previous experiments is illustrated in Figure 5. The presented experimental results show that, when the number of emergency descriptions, emergency instances and temporary templates increases, more CPU time is needed to retrieve the required information. However, every retrieval time has a linear growth, therefore the proposed enforcement mechanism is scalable. Although our prototype performance are good, this is not enough for a CEP system. For example, if a subject wants to access a stream with a rate of 1000 tuples per second and the time to retrieve the temporary access control policy is 50 milliseconds then 50 tuples are lost between the subject request and the effective access to
V. E XPERIMENTS AND R ESULTS In this section, we present some performance results of the prototype system we have developed. The current prototype is implemented in Java, it uses the Streambase CEP platform, whereas the experiments were run on an Intel Core i7 2.00 GHz CPU machine with 4Gb RAM, running Windows 7. The prototype implements the architecture explained in the previous section, therefore we carried out experiments to test the following steps: time to search an emergency description, points 2/6 in Figure 1 (emergency description retrieval time), time to find an emergency instance, points 3/7 (emergency instances retrieval time), time to retrieve a temporary access control template, points 4/8 (temporary access control template retrieval time). In order to evaluate these times we have performed several tests with automatically generated datasets of emergency events, emergency descriptions, emergency instances, and temporary access control templates. Emergencies are chosen from a pre-defined set of events of variable complexity (i.e., varying number of I/O streams and operators). Using these datasets, we measured the CPU time required to retrieve emergencies, emergency instances and temporary access control templates, by varying the number of corresponding instances in the local repository. As expected, the emergency description retrieval time increases with the number of emergency descriptions and the growth is linear as shown in Figure 2. Next experiments are on the emergency instances retrieval time. This test is similar to the previous one, but in this case the variable is the number of emergency instances (from 10 to 10.000). As shown in Figure 3, the
Retrieval Time (ms)
Emergency
Emergency Instance
Temporary Access Control Template
80 60 40 20 0 10
100
500
1000
2000
5000
10000
Number of Emergency, Emergency Instances, Templates Figure 5.
994
Overall enforcement time
the stream. This issue can be solved with buffering technique i.e., when a subject requires a resource, the prototype stars to buffer incoming tuples and, if the access is granted, tuples in the buffer are sent to the subject. Even though this situation might happen only in an extreme case with a high stream rate and a high number of temporary templates, we are planning to implement buffering in our prototype because a real time response is very important in emergency management.
[12] A. D. Brucker, H. Petritsch, and S. G.Weber, “Attribute-based encryption with break-glass,” in Workshop In Information Security Theory And Practice (WISTP), ser. Lecture Notes in Computer Science, P. Samarati, M. Tunstall, and J. Posegga, Eds. Heidelberg: Springer-Verlag, 2010, no. 6033, pp. 237–244. [13] C. Ardagna, S. De Capitani di Vimercati, S. Foresti, T. Grandison, S. Jajodia, and P. Samarati, “Access control for smarter healthcare using policy spaces,” Computers and Security, vol. 29, no. 8, pp. 848–858, November 2010. [14] S. Marinovic, R. Craven, J. Ma, and N. Dulay, “Rumpole: a flexible break-glass access control model,” in Proceedings of the 16th ACM symposium on Access control models and technologies, ser. SACMAT ’11. New York, NY, USA: ACM, 2011, pp. 73–82. [15] E. Ferrari, Access Control in Data Management Systems, ser. Synthesis Lectures on Data Management. Morgan & Claypool Publishers, 2010. [16] K. Kawagoe and K. Kasai, “Strac: Personal information access control for emergency systems,” in Services (SERVICES-1), 2010 6th World Congress on, july 2010, pp. 280 –286. [17] A. Samuel, A. Ghafoor, and E. Bertino, “Context-aware adaptation of access-control policies,” Internet Computing, IEEE, vol. 12, no. 1, pp. 51 –54, jan.-feb. 2008. [18] A. Adi and O. Etzion, “Amit - the situation manager,” The VLDB Journal, vol. 13, pp. 177–203, May 2004. [19] M. Eckert and F. Bry, “Rule-based composite event queries: the language xchangeeq and its semantics,” Knowl. Inf. Syst., vol. 25, pp. 551–573, December 2010. [20] S. Schwiderski-Grosche and K. Moody, “The spatec composite event language for spatio-temporal reasoning in mobile systems,” in Proceedings of the Third ACM International Conference on Distributed EventBased Systems, ser. DEBS ’09. New York, NY, USA: ACM, 2009, pp. 11:1–11:12. [21] G. Cugola and A. Margara, “Tesla: a formally defined event specification language,” in DEBS, 2010, pp. 50–61. [22] J. Agrawal, Y. Diao, D. Gyllstrom, and N. Immerman, “Efficient pattern matching over event streams,” in Proceedings of the 2008 ACM SIGMOD international conference on Management of data, ser. SIGMOD ’08. New York, NY, USA: ACM, 2008, pp. 147–160. [23] D. Gyllstrom, E. Wu, H. Chae, Y. Diao, P. Stahlberg, and G. Anderson, “Sase: Complex event processing over streams,” in In Proceedings of the Third Biennial Conference on Innovative Data Systems Research, 2007. [24] B. Carminati, E. Ferrari, J. Cao, and K. L. Tan, “A framework to enforce access control over data streams,” ACM Trans. Inf. Syst. Secur., vol. 13, pp. 28:1–28:31, July 2010.
VI. C ONCLUSIONS In this paper, we have proposed a novel notion of emergency policies able to manage a flexible and secure information sharing during emergency situations. Emergency policies are capable of expressing complex emergency situations, override regular policies with temporary access control policies during these situations and support obligations. Performance evaluation reported in this paper have shown the feasibility of the underlying enforcement mechanism. We plan to extend this work along several directions. A first direction is related to the development of a complete prototype and to carry out more extensive performance tests. Additionally, we plan to investigate efficient buffering techniques to avoid the loss of stream tuples due to emergency policies enforcement. We also intend to investigate how to detect init and end wrong correlations for more complex predicates. ACKNOWLEDGMENTS The research presented in this paper was partially funded by the European Office of Aerospace Research and Development (EOARD). R EFERENCES [1] G. D. Haddow and J. A. Bullock, Introduction to emergency management. Amsterdam: Butterworth-Heinemann, 2003. [2] “Federal response to hurricane katrina: Lessons learned,” Assistant to the President for Homeland Security and Counter Terrorism, Tech. Rep., February 2006. [3] “The 9/11 commission report,” National Commission on Terrorist Attacks Upon the United States, Tech. Rep., July 2004. [4] “Securing the homeland through information sharing and collaboration,” Department of Homeland Security Information Sharing Strategy, Tech. Rep., April 2008. [5] StreamBase, “Stream sql.” [Online]. Available: http://streambase.com/ developers/docs/latest/streamsql/index.html [6] Sybase, “Cep sql.” [Online]. Available: http://infocenter.sybase.com/ help/index.jsp?topic=/com.sybase.infocenter.dc01031.0400/doc/html/ swa1260999782352.html [7] Oracle, “Cep.” [Online]. Available: http://download.oracle.com/docs/cd/ E13213_01/wlevs/docs30/index.html [8] “Break-glass: An approach to granting emergency access to healthcare systems,” White paper, Joint NEMA/COCIR/JIRA Security and Privacy Committee (SPC), 2004. [9] A. Ferreira, R. Cruz-Correia, L. Antunes, P. Farinha, E. OliveiraPalhares, D. W. Chadwick, and A. Costa-Pereira, “How to break access control in a controlled manner,” in Proceedings of the 19th IEEE Symposium on Computer-Based Medical Systems. Washington, DC, USA: IEEE Computer Society, 2006, pp. 847–854. [10] A. Ferreira, D. Chadwick, P. Farinha, R. Correia, G. Zao, R. Chilro, and L. Antunes, “How to securely break into rbac: The btg-rbac model,” in Proceedings of the 2009 Annual Computer Security Applications Conference, ser. ACSAC ’09. Washington, DC, USA: IEEE Computer Society, 2009, pp. 23–31. [11] A. D. Brucker and H. Petritsch, “Extending access control models with break-glass,” in Proceedings of the 14th ACM symposium on Access control models and technologies, ser. SACMAT ’09. New York, NY, USA: ACM, 2009, pp. 197–206.
995
