Date post: | 02-Jul-2015 |
Category: |
Business |
Upload: | michele-guglielmi |
View: | 416 times |
Download: | 2 times |
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