Criticality Aware Access Control Model for

Pervasive Applications

Sandeep K. S. Gupta, T. Mukherjee, K. VenkatasubramanianImpact Lab (http://impact.asu.edu)Department of Computer Science & EngineeringIra A. Fulton School of EngineeringArizona State UniversityTempe, Arizona, USA

Supported in part by Mediserve Inc and US National Science Foundation

Overview

Motivation Critical Events, Criticality Criticality Aware Access Control (CAAC) Challenges Architecture Specification Verification Conclusions and Future Work

Access Control in Smart Spaces Smart spaces – e.g. homes, hospitals – allow inhabitants

to physically interact with information-rich virtual entities. Access control necessary to prevent unauthorized

access for malicious use. How to balance access Flexibility and Security?

Stringent access control may prevent expedited mitigative actions in case of emergencies

Relaxing access control may invite malicious use Traditional access control models (mechanisms +

policies) are not suitable Mainly reactive and not designed to handle emergency (critical)

scenarios. Goal: To design a smart-space access control model

that provides necessary flexibility for handling access control in case of emergencies while minimizing security risks.

Critical events Events which cannot be responded to, using the routine

set of capabilities of the subjects.

Examples: Tornado is a critical event for a smart-home. Heart-attack is a critical event in a home environment.

Critical Events

Mitigation

Emergency SituationNormal Situation

Emergency policyRoutine policy

Characteristics of Critical Events Requires exceptional set of actions

for controlling the emergency – avoiding catastrophic failure.

Request based reactive context evaluation is inadequate.

Proactive context monitoring is required.

We define the term ‘Criticality’ as the measure of responsiveness

required for an emergency situation

Normal actions

Critical event

Exceptional actions

Temporal Requirement for Criticality

Every critical event has a Window of opportunity (Wo) to respond.

Value of Wo is criticality dependent.

WoCritical Event Mitigation

Time

Normal actions

Mitigative actions

Examples of Criticality and Wo

Heart attack - 1st one hour critical (golden hour).

Tornado – evacuation within 5 minutes of first warning. *

Data-center - 90 seconds after cooling failure.

Disaster Recovery – 30 days time. **

*http://www.fema.gov/pdf/rrr/ndis_rev_oct27.pdf **http://www.fema.gov/pdf/library/fema_apa_ch4.pdf

Goals of Criticality Aware Access Control

Facilitate timely mitigation of criticality May require change in access privileges Proactive – automatic and continuous context evaluation Duration of change in access privileges should be finite. If critical emergency,

choose users provide access

Traditional access control is inadequate Reactive – explicit request-based context evaluation If ok, provides access

Criticality Aware Access Control (CAAC)

CAAC

Allow another doctor toAccess Patient Data Treat Patient

Patient Emergency

(Doctor not available)

CAAP mode

Patient (NoEmergency)

Normal mode

In this mode, an alternate setof access privileges are enforcedfor facilitating mitigative actions

CAAC Challenges / Properties Responsiveness

How fast to react ?

Correctness How to evaluate context / detect criticality?

Liveness How long to impose CAAP-mode?

Non-Repudiability How to deter malicious behavior as a result of

privilege changes in CAAP-mode?

Responsiveness

Measures the speed with which the alternate set of policies is enforced after the occurrence of a critical event.

If, Ta is the time to take mitigative actions for a critical event D is the time to initiate the enforcement.

Then, The Critical Event can be successfully handled iff

D + Ta ≤ Wo

Liveness

The duration of policy changes (TCAAP), in response to critical events, should be: Finite Lasts only as long as needed

If, TEOC is the time instant when a criticality is controlled. TEU is the time instant when all the necessary mitigative steps for

a criticality have been taken.

Then, assuming criticality occurred at time 0,

TCAAP = min (TEOC, TEU, Wo)

Correctness and Non-Repudiability

Correctness CAAP-mode should only be initiated in response to a

critical event. Highly system dependent.

Non-Repudiability All system activities performed in the CAAP-mode,

should be monitored for ensuring accountability. Deters malicious use of system during criticality, when

alternate (possibly elevated) privileges are in place.

CAAC Architecture

Ac c es s C o n tr o l M eta- D ata ( AC M )

R o les P r iv ileg esS u b jec ts

C r it ic a lity M an ag em en t Un it( C M U)

Ac c o u n tab ilityM an ag em en t Un it

( AM U)

D y n a mic Co n te xtM a n a g e me n t U n it

(D CM U )

Co n te xt Ga th e rin gP la t fo rm (CGP )

A c c e s s Co n t ro l P o lic y M a n a g e me n t(A CP M )

R o le M an ag em en t Un it ( R M U)

• Extends Context Aware Role Based Access Control (CA-RBAC) by introducing CMU.

• CA-RBAC is an event with Wo = infinity

• Proactive context evaluation as opposed to reactive in CA-RBAC.

Criticality Management Unit (CMU)

C rit ica lity L e v e lD e te rm in a t io n Un it

(C L D )

C ritic ality N o tific atio nU n it (C N U )

N o n -c rit ic alC o n te x tH an d le r(N C H )

A c c e s s C o n tro lM e ta-d ata P ro v id e r(A C M P )

C o n te x t In te rp re te r (C I )

Proactively monitors for the context andintelligently detects the occurrence of acritical event

Determines the level of criticality and the associated Wo based on the input from CI

Moves the system into CAAP-modeand informs other components in thearchitecture about this

Provides the access control meta-datato the CNU for determining the policiesfor the CAAP-mode

Queries specific context information during normal mode (as in CA-RBAC)

CAAC – Big Picture

WoCritical Event TEOC

Time

Normal mode

CAAP-mode

WoCritical Event

Time

Sce

nario

1S

cena

rio 2

CAAP is reverted after

Wo expires

CAAP is reverted when the criticality is

mitigated

Domain of CAAC

Criticality AwareAccess Control (Proactive) Role Based

Access Control

CA-RBAC (Reactive)CAAC

Context Aware Access Control (Reactive)

Criticality Aware Access Control

(non-role based)

CAAC Model

Access to resources provided based on: Criticality Other contexts

Privileges given to subjects implemented using Role Based Access Control (RBAC) model.

Two types of roles:System Role (rsys): role assigned when subject joins the

system, doctor in hospital. Space Role (rspace): role assigned based on subject’s domain

of work, surgeon in ED.

CAAC Model (Contd..) Each resource maintains a list of roles

and associated privileges called Access Control List (ACL).

The function f maps the users’ space roles onto a corresponding role in the ACL.

The presence of criticality leads to the mapping of the users’ space role to a different one in the ACL.

Our sample specification, always promotes the users’ roles in the event of criticality. Promoted Role Table (PRT) is

maintained for accountability

Space Role

Role 1

Role 2

Role N

Privileges for Role 1

Privileges for Role 2

Privileges for Role N

f

CriticalityDetection

Role Privileges

ACL

CAAC- Policy Specifications Specify rules for accessing service provided by

resource.

Two types of policies: Administrative

Define the rules for administrative function within the system.

Access Control Define the rules based on which access is given to

subjects for both critical and non-critical situations.

Access Control Specification Promote Role – elevates subject’s privileges when criticality is detected

(system goes into CAAP-mode)

Demote Role – resets subject’s privileges when criticality is mitigated (or Wo is expired).

Notify Critical proactively monitors for critical events determines the appropriate elevation/reset of subject’s privileges

using promoterole function.

Access Control Predicate (ACP) Boolean condition that determines the access to resources when explicit

access requests are made.

Promote Role

Step 1: Determine the occurrence of Criticality

Step 2: If one found Determine Wo

Compute new Space Role with elevated privileges. Update PRT.

Step 3: Return the new space role

Demote Role

Step 1: For each resource reset the role of users back to their original space role.

Step 2: Update PRT accordingly.

Notify Critical Continuously monitor system for occurrence of criticality

If no criticality found AND system is in CAAP-mode (TEOC) Demote role Revert system to normal state

If criticality found AND system is in CAAP-mode, BUT Wo expired

Demote role Revert system to normal state

All mitigate steps have been taken (TEU) Demote role Revert system to normal state

If criticality found AND system is not in CAAP-mode Set system to CAAP-mode Find and notify appropriate users Promote their roles.

Access Control Predicate

Previous specifications catered for: Proactive context monitoring Automatic policy changes

ACP is used for providing access on explicit request from users, based on Current context Validity of the request Availability of required services

Administrative Policies

Adding and removing Space Roles.

Adding and removing System Roles.

Role Accountability examines activities during the period when

subject’s privileges are elevated. checks the PRT.

Putting it all togetherNotify Critical

Promote Role

Demote Role

ACPRole

Accountability

Verification of the specification

Correctness: The system can enter the CAAP-mode iff there is a critical event (ensured by Notify Critical).

Liveness: For a single critical event, a subject’s role is promoted for a maximum of Wo time (ensured by Notify Critical).

Responsiveness: When a critical event occurs: The subject is immediately notified (using Notify Critical) If required the subject’s access privileges are elevated (role promotion

using Promote Role) Any role promotion is active until either the criticality is controlled or it

cannot be controlled anymore (this is ensured by Notify Critical and Demote Role).

Non-repudiation: Malicious use of elevated privileges after the occurrence of a critical event is non-repudiable (ensured by Role Accountability).

Conclusions

Criticality Aware Access Control

Proactive context monitoring

Ideal for emergency management

Automated and flexible

Push based access

Traditional Access Control

Reactive context monitoring

Slower for emergency management

Manual and inflexible

Pull based access

Future Work

Studying the interdependencies among the different properties of CAAC e.g. how does fast response affects mitigation

capability?

Studying multiple simultaneous criticalities What policies to enforce in the CAAP mode? How to model the resulting emergency situation? What are the conditions for mitigation of all the

criticalities?

Reference F. Adelstein, S. K. S. Gupta, G. G. Richard and L. Schwiebert,

“Fundamentals of Mobile and Pervasive Computing'‘, McGraw Hill, 2005

R. Sandhu, E. Coyne, H. Feinstein and C. Youman, ``Role Based Access Control Models'‘, In IEEE Computer, Feb, 1996.pp 38-47

A. Kumar, N. Karnik and G. Chafle, ``Context Sensitivity in Role-based Access Control'‘, In ACM SIGOPS OS Review 36(3), July, 2002

Working Group on Natural Disaster Information Systems, ``Effective Disaster Warning'‘, November, 2000

G. Sampemane, P. Naldurg and R. Campbell, ``Access control for Active Spaces'‘, In Proc. of ACSAC, 2002