Uniform and Modular Context-Based Access Control for Software Applications

KATHOLIEKE UNIVERSITEIT LEUVEN FACULTEIT INGENIEURSWETENSCHAPPEN DEPARTEMENT COMPUTERWETENSCHAPPEN AFDELING INFORMATICA Celestijnenlaan 200 A B-3001 Leuven Uniform and Modular Context-Based Access Control for Software Applications Promotoren : Prof. Dr. ir. F. PIESSENS Prof. Dr. ir. P. VERBAETEN Proefschrift voorgedragen tot het behalen van het doctoraat in de ingenieurswetenschappen door Tine VERHANNEMAN Maart 2007

KATHOLIEKE UNIVERSITEIT LEUVEN FACULTEIT INGENIEURSWETENSCHAPPEN DEPARTEMENT COMPUTERWETENSCHAPPEN AFDELING INFORMATICA Celestijnenlaan 200 A B-3001 Leuven Uniform and Modular Context-Based Access Control for Software Applications Jury : Prof. G. De Roeck, voorzitter Prof. F. Piessens, promotor Prof. P. Verbaeten, promotor Prof. W. Joosen Prof. E. Duval Prof. B. Van den Bosch Prof. J. Ligatti (University of South Florida, USA) Dr. B. De Win Proefschrift voorgedragen tot het behalen van het doctoraat in de ingenieurswetenschappen door Tine VERHANNEMAN U.D.C. 681.3 D46 Maart 2007

c Katholieke Universiteit Leuven Faculteit Ingenieurswetenschappen Arenbergkasteel, B-3001 Heverlee (Belgium) Alle rechten voorbehouden. Niets uit deze uitgave mag worden vermenigvuldigd en/of openbaar gemaakt worden door middel van druk, fotocopie, microfilm, elektronisch of op welke andere wijze ook zonder voorafgaande schriftelijke toestemming van de uitgever. All rights reserved. No part of the publication may be reproduced in any form by print, photoprint, microfilm or any other means without written permission from the publisher. D/2007/7515/12 ISBN 978-90-5682-780-9

Abstract The trend of an increased computerization in our society manifests itself, for instance, in the development of e-government and e-health applications. Not only does an increased computerization fulfill the promise of an improved automation and efficiency, it also entails a greater risk for abuse on a larger scale. This abuse can be prevented by enforcing that software applications are used correctly. This correct use is specified by means of a policy that captures when access to an asset should be granted or denied. This policy should be enforced by means of access control. The sensitivity of the data that is processed by these applications is usually so high that access should be restricted to a minimum number of authorized users. The enforcement of an expressive policy becomes even more crucial, as organizations increasingly open up their infrastructure to outsiders, such as customers and suppliers. To enforce expressive access policies, an access technology should support context-based access control by accounting for context information when taking access decisions. This context information may, for instance, include information concerning the state of the application, as well as the circumstances in which access to a sensitive resource is sought. Due to the complexity and scale of contemporary software systems, the integration of context-based access control constitutes a major engineering challenge. It is hard to obtain a uniform access control enforcement in (the large number of) applications that are deployed within an organization. This uniformity is even more jeopardized as access control evolves. Technologies should support evolution of access control, because the adaptability of policies and access control enforcement is a prerequisite to respond adequately to changing and new requirements. Based on an assessment of state-of-the-art access control technologies, we found that these technologies fail to reconcile these requirements because they fail to modularize the enforcement of context-based policies. The solution that we propose, can be described in terms of two contributions, namely (1) the definition of the concepts access interface and view connector and (2) the development of an access control service. An access interface enables a uniform and centralized enforcement of a contextbased access policy in a number of applications by representing a domain model i

ii that provides the information that is needed to formulate the access policy. It does this in terms of the abstractions that are common for access control, namely principal, object and action. For each application, a view connector is written to bind this access interface to the application. Secondly, based on these concepts we have developed an access control service that modularizes the enforcement of context-based policies by means of aspect orientation. We found that the support that Aspect-Oriented Software Development (AOSD) provides to modularize crosscutting concerns is useful and necessary to modularize the access control concern. This finding was substantiated by the development of two prototypes, respectively based on the aspect-oriented framework Java Aspect Components and the aspect-oriented language CaesarJ. As a third contribution, an extensive list of evaluation criteria has been drawn up that can be used to evaluate access control technologies. Based on these criteria, an assessment has been made of the proposed approach.

Acknowledgements In retrospect, the most rewarding aspect to me is that this project crosscuts so many interesting research domains. This project started with listing the security requirements of the health care application domain, and ended up here, on this joinpoint of software and security engineering, access control policies and technologies, programming languages and middleware. For me, this has been a truly enriching experience, which would not have been possible without the help of many people. I am especially thankful to my advisor Prof. Frank Piessens who helped me to take the hurdles. I greatly appreciate his never-failing optimism and enthusiasm with which he guided me on a daily basis, and I will not forget how he countered my doubts with his everlasting motto no risk, no fun!. I am also grateful to Prof. Pierre Verbaeten for critically reviewing this thesis. Prof. Wouter Joosen s insights helped me to position this work in a broader perspective; Thank you for leading the way. I would like to express my gratitude to Prof. Erik Duval for his constructive feedback. This project builds upon the work of Dr. Bart De Win, who I would like to thank for contributing to this research, coauthoring papers, and proofreading this thesis. I also thank Dr. Eddy Truyen for all his ideas with respect to this work, and for introducing me to aspect-oriented software development. I would like to thank Prof. Jarred Ligatti from the University of South Florida and Prof. Bart Van den Bosch from U.Z. Leuven for accepting to be members of the jury, and Prof. Guido De Roeck for chairing the jury. I am indebted to the Institute for the Promotion of Innovation by Science and Technology in Flanders (IWT-Vlaanderen) for funding this research. The department has always felt like home to me, and I want to thank all my colleagues for creating this great atmosphere. The list of people is too long to completely enumerate here, but I would like to thank in particular my former office mates Kris Verlaenen, Liesbeth Jaco, Jan Smans, Bert Lagaisse, Johan Grégoire, as well as Yves Younan, Frans Sanen, Thomas Heyman, Dr. Riccardo Scandariato, and the SECDAM group for the interesting research-related discussions and inspiring breaks. Special thanks go to Dr. Lieven Desmet and Davy iii

iv Preuveneers. I would also like to thank the students who contributed to this work as part of their master s thesis. I am lucky to have a number of very good friends. I would like to thank them all for their continued support and all the joyful moments, such as the #ramsel weekends, the weekly tennis shots, the cw2002 gatherings and so much more. Finally, I would like to thank my parents and my brother Dries for their support and encouragements. Tine Verhanneman March 2007

Contents Contents List of Figures List of Acronyms v ix xi 1 Introduction 1 1.1 Access Control Challenges for Contemporary Distributed Applications 1 1.2 Separation of Concerns for Access Control Enforcement...... 3 1.3 Overview of the Chapters....................... 5 2 Context-Based Access Control for Medical Applications 7 2.1 Introduction............................... 8 2.2 Legislation................................ 8 2.2.1 European Data Privacy Directive............... 9 2.2.2 US Health Insurance Portability and Accountability Act.. 10 2.3 Security Principles and Challenges for Health Care Systems.... 11 2.3.1 Organizational Measures.................... 11 2.3.2 Technical Measures....................... 13 2.3.3 Authorization.......................... 16 2.3.4 Principles addressed in this Thesis.............. 17 2.4 A Representative Health Care Access Control Policy........ 18 2.5 Context-Based Access Control for Health Care........... 20 2.6 Conclusion............................... 22 3 Evaluation of State-of-the-Art Access Control Technologies 23 3.1 Access Control Policies and Models.................. 24 3.1.1 Access Control Policies.................... 24 3.1.2 Access Control Management................. 26 3.1.3 Access Control Information.................. 27 3.2 Access Control Architecture and Mechanism............. 29 v

vi CONTENTS 3.2.1 Access Control Functions................... 29 3.2.2 Access Control Software Decomposition........... 32 3.2.3 Overview of an Access Control Enforcement Architecture. 33 3.3 Evaluation Criteria for Access Control Technologies........ 34 3.3.1 Expressiveness......................... 34 3.3.2 Evolution............................ 36 3.3.3 Uniformity........................... 37 3.4 State-of-the-Art Access Control Technologies............ 38 3.4.1 Java Authentication and Authorization Service....... 38 3.4.2 Java 2 Enterprise Edition................... 41 3.4.3 COM+ and.net....................... 45 3.4.4 CORBA Security Service................... 46 3.4.5 Tivoli Access Manager..................... 51 3.4.6 Summary............................ 55 3.5 Conclusion............................... 56 4 Uniform Enforcement of Evolving Application-Domain-Specific Policies 59 4.1 Overview of the Approach....................... 60 4.2 Access Interface............................. 62 4.2.1 A Health Care-Specific Access Interface Example...... 62 4.2.2 Access Interface Syntax.................... 66 4.2.3 Access Interface Semantics.................. 66 4.3 View Connector............................. 68 4.3.1 View Connector for a Health Care Application....... 68 4.3.2 View Connector Specification Syntax............. 72 4.3.3 View Connector Semantics.................. 74 4.4 Discussion................................ 76 4.4.1 Evaluation........................... 76 4.4.2 Realization of the View Connector.............. 79 4.4.3 Implementation Alternatives and Extensions........ 79 4.5 Conclusion............................... 80 5 A Modular Access Control Service for Application-Domain- Specific Policies 81 5.1 Aspect-Oriented Software Development............... 82 5.2 Access Control Service Overview................... 83 5.3 Prototype Implementation in Java Aspect Components....... 86 5.3.1 Java Aspect Components................... 86 5.3.2 Design of the JAC Prototype................. 90 5.3.3 Discussion............................ 91 5.4 Prototype Implementation in CaesarJ................ 93 5.4.1 CaesarJ............................. 93

CONTENTS vii 5.4.2 Pluggable Authentication Module Framework........ 97 5.4.3 Implementation of the Access Control Service........ 97 5.4.4 Discussion............................ 101 5.5 Conclusion............................... 103 6 Evaluation and Related Work 107 6.1 A Thorough Evaluation of the Access Control Service....... 107 6.1.1 Expressiveness......................... 108 6.1.2 Policy Management...................... 110 6.1.3 System Evolution........................ 116 6.1.4 Scalability............................ 117 6.1.5 Assurance............................ 118 6.1.6 Conclusion........................... 119 6.2 Applicability.............................. 121 6.3 Positioning in a Broader Perspective................. 121 6.3.1 Security Engineering...................... 121 6.3.2 Policy Languages and Frameworks.............. 122 6.3.3 AOSD and the Security Concern............... 123 6.3.4 Policy Enforcement Mechanisms............... 124 6.3.5 Context-Based Access Control................ 124 7 Conclusion 127 7.1 Contributions.............................. 128 7.2 Conclusion............................... 128 7.3 Future Work.............................. 129 Bibliography 131 List of Publications 141 Biography 143 Dutch Summary

viii CONTENTS

List of Figures 2.1 Sensitivity of Health Care Data (based on [DNdB04])....... 14 2.2 Compartmentation of Health Care Data (adopted from [And96a]). 15 2.3 Phases of a contact [Van96]...................... 19 3.1 XACML Dataflow [OASa]....................... 30 3.2 Access Control Criteria........................ 34 3.3 Relation between adaptability and software decomposition..... 37 3.4 JAAS Policy File............................ 39 3.5 A Custom Permission......................... 40 3.6 J2EE Deployment Descriptor (based on [BCE + 06])......... 43 3.7 Policy Configuration and Enforcement Subcontracts (from [Mon03]) 44 3.8 Declarative and Programmatic Access Control in.net...... 45 3.9 Access Control Model (from [Gro02b])................ 47 3.10 Access Decision Object......................... 48 3.11 CORBA Domain Access Policy (from [Gro02b])........... 48 3.12 Interface of the Attribute Retriever.................. 49 3.13 Object Security Attributes (from [Bez02b])............. 50 3.14 Resource Access Decision Facility (from [BDB + 99])......... 51 3.15 Protected Object Space (based on [Kar03])............. 52 3.16 AZN API................................ 53 3.17 Evaluation of State-of-the-Art Technologies............. 57 4.1 Top-down integration of an access control policy.......... 60 4.2 Realization with a centralized authorization engine......... 61 4.3 Policy Specification in Ponder..................... 63 4.4 Access Control Matrix......................... 64 4.5 Access Interface for the Health Care Domain............ 65 4.6 Access Interface EBNF notation................... 66 4.7 Pregnancy ICP............................. 69 4.8 ICP-application............................. 70 4.9 View Connector Specification..................... 71 ix

x LIST OF FIGURES 4.10 View Connector EBNF Syntax.................... 73 4.11 Alternative ICP View Connector................... 76 5.1 Access Control Service......................... 83 5.2 Collaboration Diagram......................... 85 5.3 Subject and Associated Principals.................. 85 5.4 Authentication Aspect Component Configuration.......... 88 5.5 JAC prototype: run-time....................... 90 5.6 PasswordModule Collaboration Interface............... 94 5.7 Generated Classes........................... 96 5.8 Pluggable Authentication Module Framework in CaesarJ...... 98 5.9 HealthCare Access Interface in CaesarJ............... 99 5.10 Authorization Engine......................... 99 5.11 Access Control Service in CaesarJ.................. 102 5.12 Summarizing Table: JAC and CaesarJ................ 105 5.13 Comparison of the two prototypes.................. 106 6.1 Access Control Criteria........................ 108 6.2 Evaluation of the Access Control Service............... 120

List of Acronyms ACI Access Control Information, 27 ACL Access Control List, 52 ADO Access Decision Object, 47 AOSD Aspect-Oriented Software Development, 82 AZN API Authorization Application Programming Interface, 53 COM+ Component Object Model plus, 45 CORBA Common Object Request Broker Architecture, 46 DAC Discretionary Access Control, 25 DAS Dynamic Attribute Service, 50 EAS External Authorization Server, 55 EJB Enterprise Java Bean, 42 FAF Flexible Authorization Framework, 123 GP General Practitioner, 62 HIPAA Health Insurance Portability and Accountability Act, 10 ICP Integrated Care Pathways, 68 J2EE Java 2 Enterprise Edition, 41 JAAS Java Authentication and Authorization Service, 38, 97 JAC Java Aspect Components, 86 JACC Java Authorization Contracts for Containers, 42 xi

xii List of Acronyms MAC Mandatory Access Control, 25 MDA Model-Driven Architecture, 121 MDSOC Multi Dimensional Separation Of Concerns, 123 ODM Object Domain Mapping, 49 OMG Object Management Group, 46 ORB Object Request Broker, 46 OSA Object Security Attributes, 49 PAM Pluggable Authentication Module, 97 PAP Policy Administration Point, 31 PDP Policy Decision Point, 31 PEP Policy Enforcement Point, 29 PIM Platform Independent Model, 122 PIP Policy Information Point, 31 PoET Policy Enforcement Toolkit, 124 POJO Plain Old Java Object, 86 POP Protected Object Policy, 52 PSM Platform Specific Model, 122 RAD Resource Access Decision (Facility), 49 RBAC Role-Based Access Control, 25 RTTI Run-time Type Information, 92 SAML Security Assertion Markup Language, 122 SDMM Security Domain Membership Management, 48 SecureUML Secure Unified Modelling Language, 122 TAM Tivoli Access Manager, 51 TRBAC Temporal Role-Based Access Contol, 27 VPL View Policy Language, 122 XACML extensible Access Control Markup Language, 29

Chapter 1 Introduction 1.1 Access Control Challenges for Contemporary Distributed Applications The security of software applications is crucial in the computerized society of today. Software applications are increasingly used to automate processes in a large number of application domains, such as for example e-commerce and health care. An access control policy needs to be in place to protect these applications from unauthorized access. Such a policy specifies the conditions that must hold for an access to be granted or denied. Access control is a widely used technique that verifies whether each access to an asset conforms to the applicable access control policy. Application domains, such as health care, have demanding security requirements, as they deal with highly sensitive data. According to the principle of least privilege [SS75], access to this data should be kept to a minimum. Relying solely on perimeter security (i.e. firewall and intrusion detection systems) does not suffice. The growing trend of sharing internal business processes with, for example, customers and suppliers, makes the distinction between inside and outside fuzzy. Web services for example require the exchange of XML messages through the firewall. Even if such a clear distinction can be made, it is highly recommendable to restrict the use by insiders (e.g., employees) to what is strictly necessary in order to prevent misuse. To meet this requirement, an access control technology should support the enforcement of expressive access control policies that account for context information when taking an access control decision. This decision is the outcome of the application of an access control policy to an access request. Typical examples of context information are the circumstances in which access to a sensitive resource is sought or the current state of this resource. The enforcement of context-based policies is referred to as context-based access control. 1

2 Introduction The key challenge in the design of a security infrastructure is the ongoing growth of distributed software systems in both scale and complexity. An organization has to secure a large number of applications, which may be deployed on heterogeneous systems. The policy that needs to be enforced within these applications is tailored to a particular organization or application domain and is detached from a specific application. In general, it is hard to keep the access control enforcement for all these applications uniform, the more so because access policies tend to be subject to change over time. This change may be triggered by requirements imposed by legislation, a changing deployment setting, or the observation that the current installed security system does not meet the expectations. In this thesis, we address the security of applications by providing access control enforcement on the application level. This application-level access control allows to protect fine-granular application resources. Application-level security complements network, operating system and database layer security in that it protects the application s assets. A number of technologies are already available that address application-level access control. However, we argue that they fall short: either their expressiveness is too limited so that they do not support context-based policies, or access control enforcement needs to be entangled in the application. The latter renders it hard to adapt the policy and its enforcement to changing requirements. At the basis of these shortcomings, lies the failure to modularize context-based access control enforcement. The Challenges Addressed in this Thesis. summarized by the following three challenges: The goal of this thesis can be 1. the enforcement of context-based access control policy to meet the high access control requirements of contemporary applications. 2. the support for the evolution of the access control policy and its enforcement, so that the system can cope with changes in the access policy, in the deployment environment and in the application. 3. the support for a uniform access control enforcement of one common access control policy to manage the complexity of keeping access control enforcement consistent across a number of applications and environments. Our solution should meet all of these three requirements. In the next section, we give an overview of our approach.

1.2 Separation of Concerns for Access Control Enforcement 3 1.2 Separation of Concerns for Access Control Enforcement Separation of Concerns for Security. The starting point of our approach is the observation that separation of concerns is an essential principle to build secure systems [DPJV02]. The term separation of concerns was used by Dijkstra in [Dij82]: Let me try to explain to you, what to my taste is characteristic for all intelligent thinking. It is, that one is willing to study in depth an aspect of one s subject matter in isolation for the sake of its own consistency, all the time knowing that one is occupying oneself only with one of the aspects. We know that a program must be correct and we can study it from that viewpoint only; we also know that it should be efficient and we can study its efficiency on another day, so to speak. In another mood we may ask ourselves whether, and if so: why, the program is desirable. But nothing is gained on the contrary! by tackling these various aspects simultaneously. It is what I sometimes have called the separation of concerns, which, even if not perfectly possible, is yet the only available technique for effective ordering of one s thoughts, that I know of. This is what I mean by focusing one s attention upon some aspect : it does not mean ignoring the other aspects, it is just doing justice to the fact that from this aspect s point of view, the other is irrelevant. It is being one- and multiple-track minded simultaneously. (On the role of scientific thought-30th August 1974) Separation of concerns lies at the basis of procedural programming and object orientation. Closely related is the statement by Parnas [Par72] that the decomposition into modules should be driven by information hiding such that modules hide the complex design decisions that are likely to change. In this thesis, the separation of concerns will be used in two senses, namely in terms of the delineation of the responsibilities between stakeholders (with their own viewpoint) involved in the development of the software system, and secondly (in terms of software decomposition) the encapsulation of the concerns of each of these stakeholders in well-defined and separated modules. Separation of concerns aims to reduce the complexity of the problem at hand. However, it is hard to modularize security due to its pervasive nature. According to De Win et al. [DPJV02] this pervasiveness manifests itself in two ways. 1. Secure Coding: Secure coding refers to the quality of the implementation of application functionality. Bugs such as buffer overflows, input validation in application code, can introduce severe security problems. Secure coding is

4 Introduction pervasive, as it requires from the developer to exhibit a defensive attitude so that his code cannot be abused. Some of these problems can be removed by providing compiler or run-time support. 2. Crosscutting Security Concerns: This form of pervasiveness relates to logic that is introduced to implement security requirements. Examples are access control and audit. The pervasiveness lies in the specific way these concerns interact with the application. The implementation of these concerns typically leads to code that is scattered all over the application and that is moreover entangled in the business logic. This thesis aims at the development of separation-of-concern techniques for the latter, and in particular for crosscutting access control logic. The nature of the interaction between the access control concern and the application is such that it could be argued that the access control logic should be hard-coded in the application. The main drawback of this approach is that the access policy has to be known upfront and cannot be adapted to meet changing requirements afterwards. It also requires that the system is completely secure from the start. This objective is ambitious but not always realistic as demonstrated by numerous vulnerability reports. Thirdly, it requires from the application developer an extensive knowledge about the security concern. To our mind, complexity is reduced if each of the stakeholders can focus on his or her own domain of expertise. The Promise of Aspect-Oriented Software Development (AOSD). The separation of access logic from the application such that the policy can be externally specified is not a new idea. Most state-of-the-art access control technologies encapsulate the access decision logic in an authorization engine, or are implemented as an access control service for a particular component platform. These approaches either do not exhibit the desired level of separation of concerns or do not have the capability to enforce context-based access policies. Aspect orientation has been identified as a promising technique to support the evolution of crosscutting concerns in general and of crosscutting security concerns in particular [DS00]. The motivation for aspect orientation lies in the observation that well-established separation-of-concern techniques such as object orientation fall short in modularizing crosscutting concerns. This is due to the fact that these techniques only support the decomposition of software according to one concern (i.e. the application logic). As a result, the implementation of context-based access control is then spread over and entangled with the application, which precludes the evolution of access control. Aspect orientation offers support to modularize crosscutting concerns. Our Contributions. First, we propose an approach that introduces an access control viewpoint on the application. This viewpoint allows for the enforcement of

1.3 Overview of the Chapters 5 context-based access control policies by taking into account application-domainspecific information, but at the same time abstracts from the details of a specific application. This access control viewpoint introduces an abstraction layer that is crucial for the uniform enforcement of one common, organization-wide access control policy in a number of different applications that are deployed within an organization. It does this by providing a domain model that captures the information needed by the policy in terms of abstractions that are common to access control, namely principal, object and action. We will show how this approach naturally supports the separation of the concerns of the security officer (who writes down the policy), and the application deployer (who tunes the access logic to the application s needs). This separation of concerns improves the support for the evolution of the access policy and its enforcement. The enforcement of context-based policies is crosscutting due to its tight coupling with the application. As a second contribution, we demonstrate that aspect-oriented techniques are needed and how they can be used to implement access control enforcement in a modular way. This is done by the design of a modular access control service and the implementation of two prototypes, respectively based on the aspect-oriented framework Java Aspect Components (JAC) and the aspect-oriented language CaesarJ. Thirdly, we identify an extensive list of evaluation criteria that can be used to characterize access control technologies, and apply it to our approach. 1.3 Overview of the Chapters The remainder of this thesis is structured as follows. In Chapter 2, we motivate the problem statement by means of requirements that are elicited from the health care application domain. Chapter 3 explains access control terminology and contains an evaluation of current state-of-the-art technologies. The scope of this discussion is limited to those technologies that are employed widely in practice. The definition of an abstraction layer for access control that enables a uniform and centralized enforcement is the topic of Chapter 4. Chapter 5 presents a design of a modular access control service that is bound to the application by means of aspect orientation. Two prototype implementations respectively based on the aspectoriented framework Java Aspect Components and the aspect-oriented language CaesarJ serve as proof of concept. Chapter 6 evaluates our approach by applying an extensive list of evaluation criteria. This chapter also contains a discussion of related research. Chapter 7 concludes this thesis.

6 Introduction

Chapter 2 Context-Based Access Control for Medical Applications In the previous chapter, we briefly described the challenges that are associated with the enforcement of access control in contemporary distributed applications. In this chapter, we will motivate this further in the context of the health care application domain. In particular, we will argue that the health care application domain requires the enforcement of context-based access policies. Our motivation starts with a description of trends that call for an adequate protection of medical data in Section 2.1, and a brief summary of the legal and regulatory framework for privacy and security covering the legislation of both the European Union and the United States in Section 2.2. Section 2.3 lists a comprehensive set of security requirements medical organizations should comply with. Section 2.4 presents a representative access control policy. Section 2.5 gives a working definition of context-based access control and Section 2.6 concludes this chapter. The contents treated in this chapter, are based on the following paper [VJP + 03]: T. Verhanneman, L. Jaco, B. De Win, F. Piessens, and W. Joosen, Adaptable Access Control Policies for Medical Information Systems, Distributed Applications and Interoperable Systems, 4th IFIP WG 6.1 International Conference, DAIS 2003 [VJP + 03] 7

8 Context-Based Access Control for Medical Applications 2.1 Introduction The ever-growing application of information technology in the health care industry calls for the installation of a security policy that is adequate to protect medical resources. In the preamble of the Health Insurance Portability and Accountability Act (HIPAA) privacy rule [Sec02a], the following trends are identified: an increased use of interconnected electronic information systems for storing and transmitting health information, allowing to share a large number of medical data with a large number of people at a time. an increased number of people and organizations have access to health care data due to a rapid growth of integrated health care delivery systems, managed care and outsourcing. an increased ability to collect highly sensitive information about a person s current and future health status as a result of advances in scientific research, such as for example genetic information. The right for privacy is considered as the fundamental right to be left alone, including the freedom from intrusion or observation into one s private affairs, the right to maintain control over certain personal information, and the freedom to act without outside interference [BRR99]. Privacy is a sine qua non for the provision of high quality health care. Nowadays, there is an increasing public concern about the loss of privacy. This concern is reflected in several legislative initiatives, which will be discussed in the next section. 2.2 Legislation Current legislation actually provides for two kinds of rights and duties. First, the law prescribes the circumstances for medical data to be collected, stored and used, and the authorization rules to access the data. This is input for the access control policy that a health care organization should manage. The HIPAA Privacy Rule is the an example of such legislation [Sec02a]. Second, the law also sets some standards on how well the policy should be enforced. In other words, if a health care organization stores and processes medical data, and outsiders (or malicious insiders) manage to get unauthorized access to the data, the organization could still be prosecuted and convicted if it could be shown that the data was not appropriately protected against unauthorized access. Based on this legislation, health care institutions formulate policies, containing both organizational and technical security measures. The second kind of legislation in particular, is important from the point of view of the enforcement of an IT policy.

2.2 Legislation 9 The term IT policy is used to denote those measures that are to be enforced by the whole of hardware and software systems. In this section, a short survey is given of the relevant legislation. 2.2.1 European Data Privacy Directive Considering the protection of health information in the EU, the Data Protection Law (Directive 95/46/EC) should be mentioned first [EC95]. It does not only apply to personal identifiable data in general, but also to personal identifiable medical data, and to both automatic and manual processing. Article 17 requires: Member States shall provide that the controller must implement appropriate technical and organizational measures to protect personal data against accidental or unlawful destruction or accidental loss, alteration, unauthorized disclosure or access, in particular where the processing involves the transmission of data over a network, and against all other unlawful forms of processing. Having regard to the state of the art and the cost of their implementation, such measures shall ensure a level of security appropriate to the risks represented by the processing and the nature of the data to be protected. Recommendation R(97)5 of the Council of Europe ( on the Protection of Medical Data ) [Cou97] provides further guidance for health care providers. Recommendations have no legally binding character for the member states, but are incentives for certain behavior. The text of the recommendation contains the following part: 9.1 Appropriate technical and organizational measures shall be taken to protect personal data - processed in accordance with this recommendation - against accidental or illegal destruction, accidental loss, as well as against unauthorised access, alteration, communication or any other form of processing. Such measures shall ensure an appropriate level of security taking account, on the one hand, of the technical state of the art and, on the other hand, of the sensitive nature of medical data and the evaluation of potential risks. These measures shall be reviewed periodically. We argue that the emphasis on appropriate measures and periodical review necessitates flexibility and configurability of the IT enforced access control policy. The recommendation indicates that protection of personal data may need to be increased if the security technology becomes available.

10 Context-Based Access Control for Medical Applications 2.2.2 US Health Insurance Portability and Accountability Act Contrary to the European Union, in the US there is no explicit constitutional recognition of privacy. Therefore, there is no comprehensive legislation, but rather a patchwork of laws, each directed to a certain domain. Drawback of this approach is the large amount of laws enacted, advantage is that specific issues of a certain domain are dealt with in their very own way. The specific law concerning the protection of individually identifiable health information is included in the Health Insurance Portability and Accountability Act of 1996, also known as HIPAA. HIPAA is considered the most significant health care legislation passed in years. The law contains several sections, including rules on electronic transactions, national identifiers, patient privacy, and data security. It obliges health care organizations to use information and communication technology to increase efficiency, but it also addresses the problems of deploying these technologies. Therefore all health care organizations that maintain or transmit electronic health information must comply, and there are severe civil and criminal penalties for those that do not. In the context of this thesis, two rules of the comprehensive HIPAA regulation are important, namely the Privacy Rule [Sec02a] and Security Rule [Sec02b]. The Security Rule applies to protected health information in electronic form only, whereas the Privacy Rule applies to protected health information in any form. The latter sets forth which uses and disclosures are authorized or required and which rights patients have with respect to their health information. The relationship between the Privacy Rule and the Security Rule can be summarized by saying that the former sets the policy to which personal health information should be subjected, while the latter specifies which implementation is obligatory for the enforcement of this policy and which reasonable efforts should be made. It describes the necessity for standards at all stages of transmission and storage of electronic health care information to ensure integrity and confidentiality of the records at all phases of the process, before, during and after electronic transmission. It defines administrative, physical and technical safeguards to protect the confidentiality, integrity and availability of electronic protected health information. Regarding access control, a rewording in the Final Security Rule [Sec02b] in comparison with the Proposed Rule [Sec00] can be noticed: There was no intent to limit the implementation features to the named technologies and this final rule has been reworded to make it clear that use of any appropriate access control mechanism is allowed. Proposed implementation features titled Context-based access, Role-based access, and User-based access have been

2.3 Security Principles and Challenges for Health Care Systems 11 deleted and the access control standard at Sec. 164.312(a)(1) states the general requirement. Features such as context-based, role-based and user-based access control are no longer explicitly mentioned in the rule. Instead, the requirement is that appropriate access control should be provided. As in the European legislation, the emphasis is on the fact that technical enforcement should be appropriate with respect to risk. 2.3 Security Principles and Challenges for Health Care Systems All regulations state that appropriate technical and organizational measures need to be in place to protect against unauthorized access. Security practitioners, researchers and federal agencies have formulated security principles to guide an organization in the implementation of these legislative rules. In this section we will give a comprehensive compilation of principles that were presented by Anderson [And96c, And96b], Buckovich et al. [BRR99] and the National Institute of Standards and Technology (NIST) [BJH + 04]. These principles are subdivided in three groups. Section 2.3.1 lists the principles that relate to organizational measures. The technical measures that should be in place are discussed in Section 2.3.2. Section 2.3.3 groups the principles that form the basis of authorization. In Section 2.3.4 we will narrow the scope by highlighting the principles that are addressed in this thesis. 2.3.1 Organizational Measures Principle 1 Security/privacy/confidentiality policies, procedures, regulations and sanctions should be in place for all entities with exposure or access to individual health information (adopted from [BRR99, Principle 26]). Regarding this principle, the NIST guideline [BJH + 04] on the implementation of the HIPAA Security Rule [Sec02b] encompasses among its administrative safeguards policies and procedures: to prevent, detect, contain, and correct security violations, resulting from an extensive assessments of the risks, ranging from computer viruses to natural disasters [BJH + 04, Section 4.1]. to ensure that all personnel have appropriate access and to prevent those that are not authorized, from obtaining access to health care data [BJH + 04, Section 4.3].

12 Context-Based Access Control for Medical Applications to authorize access consistently, e.g. by deciding how and on which basis access is granted to users [BJH + 04, Section 4.4]. Section 2.3.3 elaborates on the appropriateness of access. to address security incidents [BJH + 04, Section 4.6]. to respond to emergency or other occurrence (e.g. fire, vandalism, system failures, and natural disaster), i.e. a contingency plan [BJH + 04, Section 4.7]. The definition of a workable policy is challenging due to inconsistent policies between organizations that exchange health care data, and demands on time and financial resources [Kal02]. For example, the introduction of smart card technology adds a considerable overhead to each transaction, i.e. for the insertion of the smart card and the PIN, and the calculation of a signature [DNdB04]. Also ignorance of health care staff towards security measures impedes their introduction [Kal02]. Implementing security awareness and training is therefore crucial [BJH + 04, Section 4.5], as stated by the following principles: Principle 2 All entities involved with health care information have a responsibility to educate themselves, their staff, and consumers on issues related to these principles (adopted from [BRR99, Principle 25]). This principle is also important from the perspective of usability. Cranor [Cra05] identifies the following three approaches to make security more usable: (1) invisible security or (2) intuitive and visible security, and (3) training. Principle 3 The introduction of policies and procedures require the assignment of persons who are held responsible for their implementation [BJH + 04, Section 4.2]. A security official should be assigned who is held responsible for the overall development and implementation of the required procedures. For each medical record, one of the physicians on the care team should take the responsibility to control access to that record [And96c, Principle 3]. This responsible physician, for example, determines by whom the data may be accessed, and notifies the patient of any changes in this set of people. Another example is that a person or entity is held responsible for the integrity of the data they create, maintain, use, transmit, collect or disseminate [BRR99, Principle 7]. According to Anderson [And96a], the likelihood that information will be improperly disclosed depends on two things: its value, and the number of people who have access to it. As the computerization of health records facilitates the aggregation of a large number of data at a time, this opens the avenue to abuses such as the advertisement of products to a particular group of patients. There is also a concern that this aggregate data can be used against an individual in employment, in access to care, and in applying for insurance [BRR99, Principle 18].

2.3 Security Principles and Challenges for Health Care Systems 13 Principle 4 Measures should be taken to prevent the aggregation of large amounts of data [And96c, Principle 8]. Nowadays, a large number of parties are involved in the care giving process or in the processing of health care information. Health care organizations may, for instance, outsource billing or rely on vendors to provide system support. This distribution of medical data renders securing the data even harder, and calls for the following principle: Principle 5 A business associate, a health care organization appeals to, may receive, maintain and transmit health information on the organization s behalf, provided that the latter has assurances that the data is safeguarded appropriately [BJH + 04, Section 4.9]. Last but not least, appropriate security is necessarily dynamic. Reviewing the policies, procedures and their implementation is necessary to evaluate their effectiveness [And96c, Principle 9], and to respond to changes in environment and operation [BJH + 04, Section 4.8]. This also includes a continual incorporation of new technologies [BRR99, Principle 27]. Principle 6 Policies and procedures should be reviewed periodically. 2.3.2 Technical Measures Because of the increased specialization of care providers, and the increased complexity of care procedures, the size of the team of care providers that deals with one patient grows, e.g. teams of ten to fifty are fairly common. Also, health care data can be decentralized and accessed remotely, whereby communication networks outside the physical boundaries of the health care facility are used to share information. This requires that the organizational measures presented in Section 2.3.1 are backed up by technical measures. The following discussion includes both physical safeguards and safeguards that are integrated in the information system. Principle 1 Access Control Technical procedures and policies need to be in place to prevent unauthorized access to health care data. Firstly, physical access to the facilities housing electronic information should be restricted [BJH + 04, Section 4.10]. In a hospital, a large number of devices and workstations are located in the health care facilities, which can be freely accessed by patients and visitors. Care should be taken that health care data cannot be viewed by unauthorized persons, by for example installing counters, limiting the functions that can be performed from that workstation, and by ensuring that only registered users (personnel) can access these devices [BJH + 04,

14 Context-Based Access Control for Medical Applications [medium] [very high] personal notes specialization [very low] public data [low] all caregivers [high] discretion required Figure 2.1: Sensitivity of Health Care Data (based on [DNdB04]) Section 4.11-12]. Electronic media containing health care data should be protected from unauthorized access and destroyed properly at disposal [BJH + 04, Section 4.13]. Also the internal network of a health care organization requires adequate protection. Besides the implementation of these physical access restrictions, access control needs to be enforced on the electronic information system, so that only authorized persons and software programs are allowed to access a particular application, business function or data [BJH + 04, Section 4.14]. Health care data are often labeled according to their sensitivity, as stated by the following principle: Principle 2 Data Sensitivity and Information Flow Health care data is labeled with its sensitivity level, which should also be observed as the data flows through the health care organization. In [DNdB04, Dam04], medical data is classified according to the sensitivity levels that are shown in Figure 2.1: 1. very low: administrative data. 2. low: data that is only accessible for health care professionals, e.g. allergies. 3. medium: data that is only accessible for health care professionals with the same specialization. 4. high: data under restricted access. The patient is allowed to view everything up to this level. 5. very high: a physician s personal notes, including private recordings of observations, opinions, and impressions. These notes may be shared with colleague specialists.

2.3 Security Principles and Challenges for Health Care Systems 15 A B C D E shared data Figure 2.2: Compartmentation of Health Care Data (adopted from [And96a]) The last level may also encompass the recordings, observations, opinions and impressions of which the release is potentially harmful for a patient [BRR99, Principle 12]. Kalra [Kal02, p 246] also indicates the need for the association of sensitivity levels to data. His classification proposes the following five sensitivity levels: (1) administrative data, (2) data for audit, research and teaching, (3) clinical data, data that can be accessed by (4) the core/emergency care team and by (5) personal clinicians. In [And96a] the need for compartmentation of data (Figure 2.2) is advocated to keep information within the department within which it originated, to prevent information flow across the system. Only a subset of information is shared between the departments. Information flow involves that information that is derived from sensitive data should also be labeled as sensitive. With respect to accessibility, this principle can be rephrased as follows: Information derived from record A may only be appended to record B if the persons who can access record B, are also authorized to access record A [And96c, Principle 7]. When withholding information from a physician, it should be taken into account that the absence of information (e.g. an HIV-flag) may actually leak information about the patient. A discrete flag can be used to indicate that certain information is missing [And96c], so that a physician may, for example, ask the patient to confide this information to him or overrule the access denial, if this information may be relevant for the treatment. Clinical information serves as the basis for medical decisions. Therefore, individuals are entitled to the integrity of their health care data. Principle 3 Integrity Implement policies and procedures to protect electronic protected health information from improper alteration or destruction [BJH + 04, Section 4.16]. Safeguarding the integrity of data relates to the first principle in the sense that only authorized persons should be able to modify data. It also implies that clinical