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. 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 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, • Tais 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 subject’s 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 Criticality Detection Space Role 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 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.

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 subject’s 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 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 byRoleAccountability).

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