Presented during The Third IEEE International Conference on Information Privacy, Security, Risk and Trust (PASSAT), MIT, Boston, USA, October 9 - 11, 2011.

1. Barbara Carminati, Elena Ferrari, Michele Guglielmi
European Office of Aerospace
University of Insubria, Italy Research & Development

2. Emergency Management
 Do you think it would have been Federal
possible for the United States government
to intercept 9/11 attack ?
 Do you think it would have been
Information
possible for the United States to DHS State
manage a more effective Sharing
response and recovery after the
hurricane Katrina?
Local
Agencies
Traditional Access Emergency Access
Control Control

3. Traditional vs Emergency Access Control
Traditional access control models are regulated by a
proper set of pre-defined access control policies.
An Emergency access control model should (during
an emergency) bypass the regular access control
policies and grant users access to resources not
normally authorized.
Downgrading of information security
Complex
Event
Processing
Temporary Controlled Timely (CEP)

4. Emergency Access Control Policies
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
Temporary Complex
Emergency access Event
Obligations
policies control Processing
policies (CEP)

5. Our Model vs BtG (Break the Glass)
 a subject requests an access
 the system checks regular access control policies
 if the access request is denied, the system verifies
whether this decision can be overridden by a BtG policy
 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 and, in this case, the access is granted.
 BtG policies are always active  emergency policies are active only
during emergencies
 a user can decide when to use a BtG  only the system can override a
policy to override a regular one regular policy
 a user can wait a while to respond  system overrides immediately
when the system prompts the BtG regular policies when an
request emergency is detected

6. Emergency Events
Simple query on a Bradycardia: patient
single data stream heart rate lower than
Simple/Complex 60
Event
Epileptic attack: join
Complex query like an
aggregation query on a many information
joint set of streams about patient vital
stream and movement
Emergency sensors stream
Event
Patient fall: it is
Relationships necessary to detect
between
simple/complex this sequence of
Event
Pattern
events that might events: the patient
happen with
different temporal falls to the ground and
order.
does not stand up by
the next 2 minutes.

7. Event Language
The literature offers several languages for event
pattern specification (e.g., Amit, XChangeEQ, SpaTec,
TESLA and SASE+). Some languages have also been
proposed by vendors (e.g., Streambase, Sybase, Oracle
CEP). However, up to now, a standard event
specification language has not yet emerged
We make use of a Core Event Specification Language
(CESL).

8. CESL Language
CESL supports the following operators:
 Query Stream Operators: selection, projection,
aggregation, join.
 Event Operators: event type, event instance, array of
event instances.
 Event Pattern Operators: sequence, negation,
iteration.

9. Reference scenario
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
s.heart_rate < 60
anomaly signaling an emergency
situation.

10. Emergency Event
Given a set of streams S, and a context C, an
emergency event ev is defined as
(eventPattern, exp, identifier)
 eventPattern: is an event pattern on streams in S
 exp: is a boolean expression on attributes in C
 identifier: is a subset of attributes in S

11. Identifier
Consider the patient monitoring scenario
S = (heart_rate, patient_id)
(heart_rate < 60, - , patient_id)
(62,a) (61,a) (59,a) (58,a) (57,b)

12. Emergency
An emergency e is a tuple
(init, end, timeout)
 init: denotes the event triggering the emergency
 end: is the optional event that turns off the emergency
 timeout: is the time within the emergency expires even
though end has not occurred

13. Emergency Example
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: ∞;
}

14. Emergency Policies Requirements
Traditional Access Control Policy
(sbj, obj, priv)
 emergency: that has to trigger temporary access
control policies activation/deactivation
 temporary access control policy: to be activated
during an emergency
Emergency Access Control Policy
(emg, sbj, obj, priv)

15. Emergency Policy Requirements
In patient remote monitoring scenario:
Automatically call an ambulance
Emergency
Obligations
Paramedics are allowed to access
patient EMR during the emergency Subject and object
constraints
An audit log is created
Access Control
Obligations

16. Emergency Policy
An emergency policy is a pair (emg, ans) where emg
is an emergency and ans is:
 temporary access control policy template: is a
tuple (sbj, obj, priv, exp, obl) when the context
expression exp is true, users identified by sbj are
authorized to exercise the privilege priv on the object
obj . In addition, the action obl is executed.
 emergency obligation: an action or a set of actions
that must be executed after the detection of emg

17. Emergency Policy Example
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.
 CardiacArrest emergency detection  automatically call an
ambulance for the patient address.
 Object: the EMR of the patient under emergency condition
 Subjects: paramedics on the ambulance
 Privileges: read/write
 Obligation: sending an email to the patient doctor when a
paramedic accesses the patient EMR.

18. Emergency Policy Correctness
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 events.
Bradycardia {
init: (VitalSigns1 v, _, patient_id);
VitalSigns1 = (heart_rate ≤ 60)(S);
end: (VitalSigns2 v, _, patient_id);
VitalSigns2 = (heart_rate ≥ 50)(S);
timeout: ∞;
}
52 54 56
creation and simultaneously removal of three instances of an emergency with the
consequent activation/deactivation of the corresponding temporary access control policy.
Validity Checks

19. Emergency Policy Enforcement
Emergency
Handler
CEP Policies and
Emergencies Repository
 CEP: capture complex event patterns signaling the
beginning/ending of an emergency
 Emergency Handler: carries out registration and enforcement
of emergency polices
 Repository: contains emergency descriptions (init, end,
identifier, timeout), emergency policies (emg,ans) and
temporary access control policy templates (sbj, obj, priv, exp,
obl)

20. Enforcement Example
CEP
Emergency
CardiacArrest handler
Init
o1 e1 Init
(VitalSigns1 v,_, patient_id); handler
VitalSigns1=σ(heart_rate=0)(S); e1.heart_rate = 0
S e1.patient_id = 2
End
(VitalSigns2 v,_, patient_id);
o2 e2 End
handler
VitalSigns2=σ(heart_rate>60)(S); e2.heart_rate=80
e2.patient_id=2
Policies and Emergencies
Repository

21. Enforcement Example Emergency Policies and Emergency Repository
handler
Emergencies
id init end identifier timeout obligation
o1 e1 Init 1 O1 O2 patient_id ∞ call(ambulance)
e1.heart_rate = 0 handler Emergency_policy
e1.patient_id = 2 emergency_id policy_template_id
1 10
Temporary acp templates
o2 e2 End
id sbj obj priv obligation
handler
e2.heart_rate=80 10 Paramedic.id = EMR.id = read mailto(user)
call.paramedic_id emg.patient_id
e2.patient_id=2
Emergency instances
emergency_id identifier
1 2
Temporary acp template instances
id sbj obj priv obligation
10 Paramedic.id = 12 EMR.id = 2 read mailto(user)

22. Experiments and Results
We implemented a prototype in Java, using the Streambase
CEP platform; the experiments were run on an Intel Core i7
2.00 GHz CPU machine with 4Gb RAM, running Windows 7.
 Emergency retrieval time
 Emergency instances retrieval time
 Temporary access control template retrieval time

23. Experiments and Results
16 35
Emergency instance
Emergency Retrieval
retrieval time (ms)
14 30
12 25
10
Time (ms)
20
8
6 15
4 10
2 5
0 0
0 5000 10000 15000 0 5000 10000 15000
Number of Emergencies Number of Emergency Instances
25 Emergency
retrieval time (ms)
Temporary Access
Control Template
Retrieval Time (ms)
20 Emergency Instance
15 Temporary Access Control Template
10 80
60
5
40
0 20
0 5000 10000 15000 0
10 100 500 1000 2000 5000 10000
Number of Temporary Access Control
Templates Number of Emergency, Emergency
Instances, Templates

24. Conclusions
 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
 support obligations
Future Extensions
We plan to extend this work along several directions:
 Develop of a complete prototype to carry out more extensive
performance tests.
 Buffering strategies to avoid latency in information deliver
 Extend correctness validity checks for more complex event specification