Barbara Carminati, Elena Ferrari, Michele Guglielmi

University of Insubria, ItalyEuropean Office of Aerospace

Research & Development

Emergency Management Do you think it would have been

possible for the United Statesto intercept 9/11 attack ?

Do you think it would have beenpossible for the United States tomanage a more effectiveresponse and recovery after thehurricane Katrina?

Information

Sharing

Federal government

State

Local Agencies

DHS

Traditional Access Control

Emergency Access Control

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 (duringan emergency) bypass the regular access controlpolicies and grant users access to resources notnormally authorized.

Downgrading of information security

Temporary Controlled Timely

ComplexEvent

Processing (CEP)

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

Emergencypolicies

Temporaryaccesscontrolpolicies

Obligations

ComplexEvent

Processing (CEP)

Our Model vs BtG (Break the Glass)

BtG policies are always active

a user can decide when to use a BtGpolicy to override a regular one

a user can wait a while to respond when the system prompts the BtGrequest

emergency policies are active onlyduring emergencies

only the system can override a regular policy

system overrides immediately regular policies when an emergency is detected

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 systemchecks if this decision can be overridden by a temporary access controlpolicy and, in this case, the access is granted.

Emergency Events

EmergencyEvent

Simple/ComplexEvent

Simple query on a single data stream

Complex query like an aggregation query on a

joint set of streams

EventPattern

Relationshipsbetween

simple/complex events that might

happen with different temporal

order.

Bradycardia: patientheart rate lower than60

Epileptic attack: join many information about patient vital stream and movement sensors stream

Patient fall: it is necessary to detect this sequence of events: the patientfalls to the ground and does not stand up by the next 2 minutes.

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).

CESL Language

Query Stream Operators: selection, projection, aggregation, join.

Event Operators: event type, event instance, array of event instances.

Event Pattern Operators: sequence, negation, iteration.

CESL supports the following operators:

Reference scenarioPatients wear several monitoringdevices that catch their healthmeasures (e.g., temperature, heartrate, blood pressure, glucose, etc.).All gathered measures are encoded astuples in a data stream and sent to aCEP, which can easily detect anyanomaly signaling an emergencysituation.

s.heart_rate < 60

Emergency EventGiven 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

Identifier

(62,a) (61,a) (59,a) (58,a) (57,b)

Consider the patient monitoring scenario

S = (heart_rate, patient_id)

(heart_rate < 60, - , patient_id)

EmergencyAn 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

Emergency Example

CardiacArrest {

init: (VitalSigns1 v, _, patient_id);

VitalSigns1 = σ(heart_rate = 0)(S);

end: (VitalSigns2 v, _, patient_id);

VitalSigns2 = σ (heart_rate > 60)(S);

timeout: ∞;

}

A cardiac arrest situation can be represented as follows:

Emergency Policies Requirements

emergency: that has to trigger temporary access control policies activation/deactivation

temporary access control policy: to be activatedduring an emergency

Traditional Access Control Policy(sbj, obj, priv)

Emergency Access Control Policy (emg, sbj, obj, priv)

Automatically call an ambulance

Paramedics are allowed to access

patient EMR during the emergency

An audit log is created

Emergency Policy Requirements

In patient remote monitoring scenario:

EmergencyObligations

Subject and objectconstraints

Access ControlObligations

Emergency Policy

temporary access control policy template: is a tuple (sbj, obj, priv, exp, obl) when the contextexpression 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

An emergency policy is a pair (emg, ans) where emgis an emergency and ans is:

Emergency Policy Example

CardiacArrest emergency detection automatically call anambulance for the patient address.

Monitored patient is hospitalized at home and assisted byhis/her personal doctor who is allowed to read his/her EMRand to write prescriptions.

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 aparamedic accesses the patient EMR.

Emergency Policy CorrectnessWhen 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 theconsequent activation/deactivation of the corresponding temporary access control policy.

Validity Checks

Emergency Policy Enforcement

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)

EmergencyHandler

CEP Policies and Emergencies Repository

S

Enforcement Example

Init

(VitalSigns1 v,_, patient_id);VitalSigns1=σ(heart_rate=0)(S);

End

(VitalSigns2 v,_, patient_id);VitalSigns2=σ(heart_rate>60)(S);

CardiacArrest

CEP

Inithandler

Endhandler

e2.heart_rate=80e2.patient_id=2

Emergencyhandler

e1.heart_rate = 0e1.patient_id = 2

e1

e2o2

o1

Policies and EmergenciesRepository

Enforcement Example

id init end identifier timeout obligation

1 O1 O2 patient_id ∞ call(ambulance)

emergency_id policy_template_id

1 10

id sbj obj priv obligation

10 Paramedic.id = call.paramedic_id

EMR.id = emg.patient_id

read mailto(user)

emergency_id identifier

1 2

id sbj obj priv obligation

10 Paramedic.id = 12 EMR.id = 2 read mailto(user)

Policies and Emergency Repository

Emergencies

Emergency_policy

Temporary acp templates

Emergency instances

Temporary acp template instances

Inithandler

Endhandler

e2.heart_rate=80e2.patient_id=2

Emergencyhandler

o1

o2

e1.heart_rate = 0e1.patient_id = 2

e1

e2

Experiments and Results

Emergency retrieval time

Emergency instances retrieval time

Temporary access control template retrieval time

We implemented a prototype in Java, using the StreambaseCEP platform; the experiments were run on an Intel Core i7 2.00 GHz CPU machine with 4Gb RAM, running Windows 7.

Experiments and Results

02468

10121416

0 5000 10000 15000Em

erg

en

cy R

etr

iev

al

Tim

e (

ms)

Number of Emergencies

0

5

10

15

20

25

30

35

0 5000 10000 15000

Em

erg

en

cy i

nst

an

ce

retr

iev

al

tim

e (

ms)

Number of Emergency Instances

0

5

10

15

20

25

0 5000 10000 15000

Te

mp

ora

ry A

cce

ss

Co

ntr

ol

Te

mp

late

re

trie

va

l ti

me

(m

s)

Number of Temporary Access ControlTemplates

0

20

40

60

80

10 100 500 1000 2000 5000 10000Re

trie

va

l T

ime

(m

s)

Number of Emergency, Emergency Instances, Templates

Emergency

Emergency Instance

Temporary Access Control Template

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 ExtensionsWe 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