Criticality Aware Access Control Model for Pervasive Applications - PowerPoint PPT Presentation

Loading...

PPT – Criticality Aware Access Control Model for Pervasive Applications PowerPoint presentation | free to view - id: 7daf1-ZDc1Z



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Criticality Aware Access Control Model for Pervasive Applications

Description:

Criticality Aware Access Control Model for Pervasive Applications ... Critical events ... Tornado is a critical event for a smart-home. ... – PowerPoint PPT presentation

Number of Views:60
Avg rating:3.0/5.0
Slides: 32
Provided by: Asu57
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Criticality Aware Access Control Model for Pervasive Applications


1
Criticality Aware Access Control Model for
Pervasive Applications
  • Sandeep K. S. Gupta, T. Mukherjee, K.
    Venkatasubramanian
  • Impact Lab (http//impact.asu.edu)
  • Department of Computer Science Engineering
  • Ira A. Fulton School of Engineering
  • Arizona State University
  • Tempe, Arizona, USA
  • Supported in part by Mediserve Inc and US
    National Science Foundation

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

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

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

Emergency policy
Routine policy
Critical Events
Normal Situation
Emergency Situation
Mitigation
5
Characteristics of Critical Events
Normal actions
  • 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

Critical event
Exceptional actions
6
Temporal Requirement for Criticality
  • Every critical event has a Window of opportunity
    (Wo) to respond.
  • Value of Wo is criticality dependent.

Normal actions
Mitigative actions
Mitigation
Critical Event
Wo
Time
7
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
8
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

9
Criticality Aware Access Control (CAAC)
Patient Emergency (Doctor not available)
Patient (No Emergency)
Normal mode
In this mode, an alternate set of access
privileges are enforced for facilitating
mitigative actions
CAAC
CAAP mode
Allow another doctor to Access Patient Data
Treat Patient
10
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?

11
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
12
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)
13
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.

14
CAAC Architecture
  • 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.

15
Criticality Management Unit (CMU)
Queries specific context information during
normal mode (as in CA-RBAC)
Moves the system into CAAP-mode and informs other
components in the architecture about this
Determines the level of criticality and the
associated Wo based on the input from CI
Provides the access control meta-data to the CNU
for determining the policies for the CAAP-mode
Proactively monitors for the context
and intelligently detects the occurrence of
a critical event
16
CAAC Big Picture
Normal mode
CAAP is reverted when the criticality is mitigated
CAAP-mode
TEOC
Critical Event
Wo
Scenario 1
Time
Critical Event
Wo
CAAP is reverted after Wo expires
Scenario 2
Time
17
Domain of CAAC
Context Aware Access Control (Reactive)
Criticality Aware Access Control (Proactive)
Role Based Access Control
CA-RBAC (Reactive)
CAAC
Criticality Aware Access Control (non-role
based)
18
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
    subjects domain of work, surgeon in ED.

19
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
Criticality Detection
f
ACL
Privileges
Role
Role 1
Privileges for Role 1
Role 2
Privileges for Role 2
Privileges for Role N
Role N
20
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.

21
Access Control Specification
  • Promote Role elevates subjects privileges when
    criticality is detected (system goes into
    CAAP-mode)
  • Demote Role resets subjects privileges when
    criticality is mitigated (or Wo is expired).
  • Notify Critical
  • proactively monitors for critical events
  • determines the appropriate elevation/reset of
    subjects privileges using promoterole function.
  • Access Control Predicate (ACP)
  • Boolean condition that determines the access to
    resources when explicit access requests are made.

22
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

23
Demote Role
  • Step 1 For each resource reset the role of users
    back to their original space role.
  • Step 2 Update PRT accordingly.

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

25
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

26
Administrative Policies
  • Adding and removing Space Roles.
  • Adding and removing System Roles.
  • Role Accountability
  • examines activities during the period when
    subjects privileges are elevated.
  • checks the PRT.

27
Putting it all together
Notify Critical
Promote Role
Demote Role
Role Accountability
ACP
28
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
    subjects 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 subjects 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).

29
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

30
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?

31
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
About PowerShow.com