Uniform and Modular Context-Based Access Control for Software Applications

(1)

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

(2)

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

(3)

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

toe-stemming 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

(4)

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 inte-gration 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 conceptsaccess interface andview connector and (2) the development of an access control service.

An access interface enables a uniform and centralized enforcement of a context-based access policy in a number of applications by representing a domain model

(5)

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.

(6)

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´egoire, 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

(7)

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

(8)

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]) . . . .} ₄₃

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]) . . . .} ₅₁

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

(13)

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

(14)

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 Inter-face, 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

(15)

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

(16)

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 require-ments, 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 ascontext-based access control.

(17)

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. The goal of this thesis can be summarized by the following three challenges:

1. the enforcement ofcontext-based access control policyto meet the high access control requirements of contemporary applications.

2. the support for theevolution 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.

(18)

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

(19)

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

(20)

1.3 Overview of the Chapters 5

context-based access control policies by taking into account application-domain-specific information, but at the same time abstracts from the details of a application-domain-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 aspect-oriented framework Java Aspect Components and the aspect-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.

(21)

(22)

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 ofcontext-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]

(23)

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.

(24)

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.

(25)

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

(26)

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

(27)

• 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. Cra-nor [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].

(28)

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,

(29)

[very low] public data [low] all caregivers [high] discretion required [very high] personal notes specialization [medium]

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.

(30)

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 recordAmay only be appended to record B if the persons who can access recordB, are also authorized to access recordA[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

(31)

information cannot be deleted until an appropriate time period has expired, and that information is updated by appending a new version [And96c, Principle 5].

Both Principle 1 and 3 require that information is protected while electronically transmitted:

Principle 4 Transmission Security — During transmission, data should be protected against unauthorized access and modification ([BRR99, Principle 23] and [BJH+_{04, Section 4.18]).}

Principle 5 Audit and Notification — All access to health care data should be recorded, by capturing all necessary information about the access, such as the user’s name and access time ([BJH+_{04, Section 4.15] and [And96c, Principle 6]).}

Both access control (Principle 1) and audit (Principle 5) rely on a correct attribution of a particular access to a person:

Principle 6 Authentication — Implement procedures to verify that a person or entity seeking access to electronic protected health information is the one claimed (adopted from [BJH+_{04, Section 4.17]).}

2.3.3 Authorization

A major challenge is to strike a balance between theavailabilityand theprotection of data, all the more so because data also needs to be protected against abuse by insiders, such as personnel. By and large, access should be granted based on the need-to-know or the minimum necessary principle. Reasonable effort must be made to limit access to information to the minimum necessary to accomplish the intended purpose or disclosure [Sec02a]. However, the need-to-know principle is hard to approximate by an access policy [Van96] and even if this is realized, “legitimate access does not entail legitimate use” [Van96].

According to Anderson [And96c] the principle of need-to-know is not an acceptable basis for access control decisions. It is the patient’s consent that matters. This is merely an application of the Hippocratic oath, which states that personal information that is learned in the course of professional activities is not passed on, unless the patient agrees [And96c].

In the next paragraphs, a number of possible uses of health information are discussed.

The Patient. Individuals hold the right to access, amend and correct their own health information. A patient can assign a confidant, whose identity is recorded. In some cases, the right to inspect medical data can be exercised by other persons, e.g. the guardian of an under aged patient or relatives of a deceased person.

In general, the subject of the medical data has access to his entire record, excluding a physician’s personal notes (Section 2.3.2), unless, for example,

(32)

the right to inspect the data is exercised through a physician who acts as a confidant [DNdB04]. A physician can also withhold information from the patient, if, for example, its release would obviously cause harm to the patient’s health condition, the patient appeals to the rightnot-to-know, or the physician awaits the next contact to provide explanation. According to Anderson [And96c, Principle 4], a patient should also be able to gain insight in who can access his data and by whom it has been accessed. An individual should be able to exercise control on the access to his data by withholding information from electronic format, segregating information from shared records, specifying limits on the period of time and purpose of use, and modifying default assigned sensitivity levels to health care data.

Treatment. The HIPAA Privacy Rule [Sec02a] requires the need for the patient’s consent to use or disclose health information for treatment or payment purposes. It is not always possible to obtain this consent, e.g. in emergency situations. In these cases, treatment is provided as necessitated by the health condition of the patient.

Research. In general, there is consensus that aggregation of medical data should be allowed for the purposes of research and audit, as long as the information is anonymized so that individuals cannot be identified.

Other Uses. In some cases, health care information may be released without prior consent of the patient, for example in the case of law enforcement or for the reporting of public health information on communicable diseases.

2.3.4 Principles addressed in this Thesis

A health care organization is required to have a security policy in place to adequately protect medical data (organizational measure 1). In the remainder of this thesis, we limit the discussion to the specification of an organization-wide access control policy. An access control policy specifies a series of authorizations. As discussed in Section 2.3.3, an authorization may be based on the (treatment)relationship between the patient and the authorized user, a particular use, and circumstance. It may also depend on the characteristics of the data to which access is granted, such as its sensitivity (technical measure 2).

In this thesis, we are primarily concerned with the enforcement of this access control policy (technical measure 1), and with the ability to review both the access policy and its enforcement (organizational measure 6). In the course of this thesis a number of the other principles will be treated to a lesser extent. Access control enforcement can be used to safeguard data from unauthorized modification (technical measure 3). Access control relies on authentication to attribute an

(33)

access request to a user (technical measure 6), and possibly on audit (technical measure 5) to keep an access trail.

2.4 A Representative Health Care Access Control

Policy

In this section, an example health care policy is given that will serve as an illustration for the remainder of this thesis. The policy is based on the description of the design and development of the hospital information system of U.Z. Leuven in the Ph.D. thesis of Van den Bosch [Van96]. Section 6.3 on access control has served as the main source of inspiration to obtain a representative health care policy. First, the overall system is described and afterwards an access policy is formulated.

Contacts. The system is centered oncontacts, which are essentially workflows. A description [Van96, p 95-96] is given below:

A contact is a medical logical unit that can be an outpatient visit, a hospitalization, a surgery, a chemotherapy treatment. A contact is not directly linked with a patient’s movements, including admission, discharge and transfers: one contact can have many admissions and one admission can have several (simultaneous contacts). For example, a renal dialysis treatment contains an admission for each time a patient is dialyzed.

A contact may result in a report after going through the following phases (Figure 2.3):

1. Reception: The patient and the department is associated with the contact. 2. Assignment: The contact is assigned to a physician and a supervisor. 3. Report Generation: The assigned physician generates the report, which is

then placed on the work list of the supervisor for validation.

4. Report Validation: The assigned supervisor validates the report. This also closes the contact.

The assigned physician may also close the contact by an explicit statement that no report is necessary.

Services. A physician can address a service request to another physician, to carry out, for instance, nursing acts, radiology or laboratory tests. The requesting physician may cancel this request. The addressed physician performs the service and closes it upon termination.

(34)

2.4 A Representative Health Care Access Control Policy 19

Reception Assignment

No report necessary

Report Validation

Figure 2.3: Phases of a contact [Van96]

Appointments. The system allows users to associate appointments with a contact. An electronic book keeps track of all the appointments for a particular physician, a location (e.g. a theater), or a resource. Each electronic book is assigned to a book owner. Only this owner can view the list of patients that have an appointment.

Patient and User Tracking. The system is equipped with a tracking system, which keeps track where (which ward or department) the patient resides at each point and to which wards a staff member currently has access.

Referring Physicians. In the context of the LISA1_{, (external) general} practi-tioners (GP) are able to view their patients’ hospital records, so that they are kept informed of the health condition of their patients. This access is comprehensive, but excludes access to highly sensitive data including psychiatric and genetic records. The GP only gains access provided that the patient has signed an informed consent form.

The Access Control Policy

The data that needs to be protected encompasses the contact and all the service results, and reports that are associated with the contact. All these documents are below referred to aspatient data.

1. The first access rule states that a user can only view patient data that originated within one of the departments this user is assigned to. All users can view patient data, of which the department field is left blank. — Compartmentation

2. Physicians who are assigned to a contact, either as supervisor or executing physician, are granted access to patient data related to that contact, until 30 days after the contact was closed. —Assigned Physicians

(35)

3. There are no time constraints on the access rights of the general practitioner of the patient. A general practitioner retains his access rights as long as he remains registered as the patient’s general practitioner. —General Practitioner

4. A user is granted view access to a patient’s data if the patient resides or resided less than two weeks ago on a ward to which the user currently has access. —User Tracking

5. A physician can overrule an access denial, provided that a detailed reason is specified. This reason, the access time, user name and terminal ID are logged. —Overrule Access

6. Not only these overrule accesses are carefully monitored, but also all accesses to data of so-called monitored patients. In case treatment is provided to celebrities or personnel, a supervisor of a contact can indicate that accesses need to be monitored. —Monitoring

7. Users can designate other users as stand-in, e.g. when they are on holiday. This stand-in then temporally obtains the privileges of the delegating user. —Delegation

8. System administrators can view the version history of patient data, but not its actual contents. The information department can retrieve all versions of a piece of data. —System Administration

2.5 Context-Based Access Control for Health Care

Although omitted in the final HIPAA security rule, the implementation of appropriate access control calls for either user-based, role-based or context-based access control. The principles in Section 2.3 and the presented access policy in Section 2.4 require the implementation of the last option. Role-based (RBAC96 [SCFY96]) and user-Role-based access control cannot take context information into account, such as the presence of a relationship (e.g., Section 2.4 rule 2 & 3) or special circumstances (e.g., the emergency access in rule 5). The implementation of context-based access control can be done by, for example, extending user- or role-based access control with the ability to account for context information. In this section, a working definition is given of context-based access control.

Access Control. We refer to attempts to access functionality or data in a software system asaccess requests. An access request typically involves anobject, anaction and aprincipal. An object is the resource for which access is requested, such as for example health care information. The action (or sometimes operation)

(36)

2.5 Context-Based Access Control for Health Care 21

refers to the kind of access that is requested. Typical examples of actions are “read” and “write”. The principal is the source of the access request, and may represent a user, a group, a machine, or a role. An access control policy specifies which actions a principal is allowed to perform on an object. Access control enforcement can be divided into three subtasks, namely (1) the interception of each access request, (2) the evaluation of an intercepted access request with respect to the access control policy, and (3) the enforcement of the access decision. Usually a so-called reference monitor, which acts as the guard of the object, performs these tasks. The information that this reference monitor has at its disposal is typically limited to the target object, the requested action, and the requesting principal.

Context-Based Access Control. To enforce expressive policies, context information is often required to make an access decision. Besides taking into account the principal, the target object and the action, context-based access control also requires information regarding the context in which the access is requested. This context includes the context of objects, principals and the access request itself. In Section 3.1.3 we will give an overview of different kinds of context information. Below, a number of examples are given in the domain of health care:

1. Context of the Access Request: Common examples are time and location of the user who requests access (e.g., Section 2.4 rule 4). A physician is provided with the capability to overrule an access denial if access is requested in the context of an emergency situation (Section 2.4 rule 5).

2. Relationship between User and Patient: Basing authorization on the ex-istence of a particular relationship between the principal of an access request and the patient for whose data access is requested, is also endorsed by Beznosov [Bez00]. In [Smi01] the following types of relationships are distinguished:

(a) Identity: the patient himself.

(b) Surrogacy: a user authorized to act on behalf of the patient.

(c) Treatment: a caregiver of the patient, who can be the primary, referring, consulting care provider.

(d) Employment: a sponsor of a health plan that covers the patient. (e) Underwriting: an insurer of the patient.

3. Application-domain-specific attributes of objects and principals: This in-formation can be subdivided in security-related and non-security-related attributes [BDB+_99]. _{Security-related attributes are attributes that are} introduced to implement security and include, for example, the user’s identity, role assignment and group membership or sensitivity for objects

(37)

(as discussed in principle 2 in Section 2.3.2). Non-security-related attributes are attributes that initially have been introduced for other reasons than security, but that turn out to be relevant for the evaluation of access requests. Examples are the age of a patient, and the ward a physician is assigned to. The need for context-based access control has been acknowledged and ad-dressed by other researchers. In the context of health care, the DRIVE RBAC model [WFSM02] is particularly interesting since it extends Role-Based Access Control (RBAC) [FSG+_{01, FK92], with the notion of trust constituency and} time constraints to describe context. A trust constituency defines the rights and obligations of the actors in a business process to a certain type of asset and may, for example, state that identifiable clinical data should only be handled in clinical activities. This approach introduces two types of contexts: The working context determines which roles can be activated by the user in a session, for example, the role on-call physician can only be activated during the nights and weekends. The permissions assigned to a particular role can vary according to the user context, which for example includes the location of the user requesting access. For example, access permissions may be reduced if the request originates from outside the ward a physician is associated with.

2.6 Conclusion

A health care organization is required to specify and enforce an access control policy to prevent unauthorized access to medical data. In Section 2.4, we have presented an example policy that calls for the inclusion of context information in the access control policy. Support for context-based access control allows, for example, to authorize access based on the existence of a relationship between a physician and the patient whose data is being accessed. This context-based policy and its implementation should be reviewed periodically to evaluate its effectiveness, to respond to changing requirements, and to adopt new security technologies. In the remainder of this thesis, this principle is referred to as the support for evolution.

(38)

Chapter 3

Evaluation of

State-of-the-Art Access

Control Technologies

In this thesis, we aim at the enforcement of a context-based access policy in the applications deployed within an organization. The protection of application resources calls for application-level access control enforcement. Hereby, we focus on the enforcement of access control in oriented systems, such as object-oriented middleware. Examples of resources that need to be access controlled are object instances, and the invocation of a method. The scope of technologies that provide application-level access control encompasses both access services offered by a middleware platform, and access control libraries or frameworks that can be integrated in an application. Embedding access control logic in the application is also an alternative to implement application-level access control.

We present a set of evaluation criteria that can be used to evaluate these access control technologies. From this list, we focus on three criteria that are important to implement access control in an application domain with demanding security requirements, such as the health care application domain, which was discussed in the previous chapter. The security requirements in these application domains mandate support for the enforcement of (1) context-based access control policies. In order to respond to changing requirements, changes in the organization and application, (2) the evolution of the access control policy and its enforcement should be supported. The evolvability is related with the adherence to the separation-of-concerns principle, which states that the responsibilities between stakeholders should be clearly separated. The evolving organization’s access control policy needs to be enforced (3) uniformly in the applications deployed within the organization. We opted to focus on these requirements based on

(39)

the observation that these criteria are badly supported by state-of-the-art access control technologies. This chapter substantiates this observation by evaluating access control technologies with respect to these three requirements. For this evaluation, we have classified the technologies based on their architecture, and more specifically, on the way in which the access control functionality is decomposed into modules.

The outline of this chapter is as follows. Sections 3.1-3.2 introduce some terminology by means of working definitions. This discussion is divided in two parts. The first part (Section 3.1) discusses the specification of what should be enforced, and the second part (Section 3.2) focuses on how access control is to be enforced. Section 3.3 discusses the evaluation criteria, by means of which state-of-the-art technologies are evaluated in Section 3.4. Conclusions are drawn in Section 3.5.

3.1 Access Control Policies and Models

A security policy objective can be characterized as a statement to protect an identified resource from unauthorized use [Ste91]. The resources to be protected are tangible assets, e.g. information or property. Unauthorized use refers to active human threats.

3.1.1 Access Control Policies

Access control is regulated according to an access control policy. Damianou distinguishes three levels of access control policies [Dam02]:

1. High-level abstract policies (also organizational security policy [Ste91]) are sets of laws, rules, and practices that regulate how an organization manages, protects, and distributes resources to achieve specified security policy objectives [Ste91]. This computer-independent view includes for example procedures such as document sensitivity labeling. These rules are typically formulated in a natural language. In order to be enforceable, they should be more refined into specification-level and low-level policies.

2. Specification-level policies (high-level policy or automated security policy): Sterne [Ste91] defines an automated security policy asthe set of restrictions and properties that specify how a computing system prevents information and computing resources from being used to violate an organizational security policy. These policies typically abstract low-level policies and can therefore be formulated by human security officers. Nonetheless, their enforcement can be automated, as these policies are formulated in a precise format and relate to specific resources. In the remainder of the thesis, this type of policies is referred to as a high-level policy.

Uniform and Modular Context-Based Access Control for Software Applications

FACULTEIT INGENIEURSWETENSCHAPPEN

DEPARTEMENT COMPUTERWETENSCHAPPEN

AFDELING INFORMATICA

Celestijnenlaan 200 A — B-3001 Leuven

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

∗

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

toe-stemming 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

Abstract

Acknowledgements

Contents

List of Figures

List of Acronyms

Chapter 1

Introduction

1.1

Access Control Challenges for Contemporary

Distributed Applications

1.2

Separation of Concerns for Access Control

Enforcement

1.3

Overview of the Chapters

Chapter 2

Context-Based Access

Control for Medical

Applications

2.1

Introduction

2.2

Legislation

2.2.1

European Data Privacy Directive

2.2.2

US Health Insurance Portability and Accountability

Act

2.3

Security Principles and Challenges for Health

Care Systems

2.3.1

Organizational Measures

2.3.2

Technical Measures

A B C D E

2.3.3

Authorization

2.3.4

Principles addressed in this Thesis

2.4

A Representative Health Care Access Control

Policy

2.5

Context-Based Access Control for Health Care

2.6

Conclusion

Chapter 3

Evaluation of

State-of-the-Art Access

Control Technologies

3.1

Access Control Policies and Models

3.1.1

Access Control Policies