A Dynamic, Context-Aware Security Infrastructure

1

A Security Infrastructurefor Distributed Healthcare Applications

Junzhe Hu and Alfred C. Weaver

Department of Computer Science

University of Virginia

Charlottesville, VA22904

1

Abstract

The rapid worldwide deployment of the Internet and Web is the enabler of a new generation of e-healthcare applications, but the provision of a security architecture that can ensure the privacy and security of sensitive healthcare data is still an open question. Healthcare applications require context-aware authorization, a flexible enforcement mechanism, and on-demand authentication.In this paper we describe a distributed, context-aware access control infrastructure that can fulfill those requirements.Our contribution is the extension of traditional role-based access control by attaching context-related constraints to access policies; authorization decisions are then made dynamically at run-time rather than statically at policy design time.In addition, our security infrastructure is implemented using a web services architecture so that it can be applied quickly to healthcare applications and other systems with similar security requirements.

1.Introduction

Many industries are extending their business operations to operate over the Web, and healthcare is no exception.Although most healthcare participants (e.g., hospitals, private physicians, insurance companies, pharmacies) already implement some type of computerized system to manage their business data, their implementations tend to be proprietary and interact loosely or not at all.A more integrated system that crosses the various healthcare boundaries would clearly be an advantage to the patient; imagine the economy of effort for the patient if he or she could schedule an appointment, retrieve the results of a diagnostic test, refill a prescription, and file an insurance claim from a single, integrated portal, rather than making four separate logins on four separate websites to conduct four separate transactions with four different entities.A web services approach has the potential to enable this single-portal scenario, but only if we can assure the privacy and security of patient data throughout the medical enterprise.To do that, we must first understand the security requirements of modern healthcare.

First, even within a single medical enterprise there can be an enormous variety of applications that require making complex access control decisions.For example, in our medical center, a medical student can not view a patient’s data unless that access is authorized by the patient’s attending physician.In the pre-computer era, access control was simple and binary – either the physician did or did not give the paper records to the student for review.In today’s computerized environment, such access is typically controlled by some form of role-based access control (RBAC), whose main idea is to characterize users (e.g., John Smith) by their roles (e.g., doctor), and then assign permissions to roles rather than to individuals as shown in figure 1.

.

However, even in our simple example above, RBAC is not sufficiently powerful to enforce the concept of a context-dependent constraint—namely that aparticular individual, acting in his/her role as a medical student, is to be given access permission if and only if the patient’s attending physician approves.This extension to RBAC is known as context-based access control.

While a precise definition of context is illusive, it can generally be defined as “any information that can be used to characterize the situation of an entity.An entity is a person, place or object that is considered relevant to the interaction between a user and an application” [7].Using this definition, “context” could be the time or location of data access, a sub-role requirement (e.g., not just a physician, but also a surgeon), some special relationship (e.g., not just an attending physician, but this particular patient’s attending physician), or some similar restriction.The core idea of context-based access control (CBAC) is to associate context-related constraints with every component of the RBAC model (see figure 2) such that authorization decisions can be made at run-time based upon dynamic context information, rather than at design time when an authorization policy is initially specified.Context-related constraints are usually represented as a sequence of Boolean conditions, with each condition defined as a predicate on some context information; retrieving and operating upon that context information is called context evaluation (explained and illustrated in section 3).

Figure 2. Context-Based RBAC Model

Second, the intricate user-data relationships in healthcare systems require flexible policy enforcement.Not only are there many actors (physicians, nurses, technologists, technicians, patients), there are also many providers (hospitals, clinics, private practices) and ancillary partners(pharmacy, insurance, billing).In current CBAC models all context evaluations are statically hard-coded within their applications and thus are not easy to change. In our system, policy definition and policy enforcement are independent. The application designer need not know at application coding time what access policies will be used; our infrastructure will simply enforce at run-time whatever policies are currently active.

Third, given the privacy and security requirements of the recent Health Insurance Portability and Accountability Act [21], healthcare services are turning to stronger authentication methods.Biometric methods (e.g., fingerprints, iris scans, signature and voice recognition) and non-biometric digital techniques (e.g., e-tokens, RFID, key fobs) are rapidly replacing passwords for authentication purposes.A practical and usable system must accommodate a range of identification technologies and their associated trust levels; see section 3 for details.For instance, hospital administration should be able to create access policies such as these: access to purely public data requires no authentication at all (e.g., browsing the hospital’s website); patients may access their own records using a password; physicians may access their own patient data with a password but a fingerprint is required to append newdata; medical records employees are required to authenticate with an iris scan to delete any items from a patient record. Our security framework can support multiple levels of authentication.

Hospital administratorsdefine the trust levels required for critical operations.For example, assume that changes to personnel data are restricted to administrators who have authenticated with the trust level of an iris scan or higher.An administrator who has previously authenticated with an iris scan and then attempts to access personnel records will be granted access, whereas an administrator who haspreviously authenticated with a fingerprint would be temporarily denied, but would immediately be giventhe opportunity to raise his/her trust level by re-authenticating with an iris scan (this is on-demand authentication).

Motivated by the above requirements, this paper proposes a dynamic, context-aware security infrastructure for distributed healthcare applications.It offers system administrators the ability to specify context-aware policies, enforce arbitrary policies dynamically, and secure the target systems in an on-demand mode.The remainder of this paper is organized as follows.Section 2 examines the previously published work related to RBAC and CBAC.The overall architecture and components of our security infrastructure are presented in section 3.Section 4 provides implementation details.A description of how this model has been applied to our prototype distributed healthcare system is given in section 5.Finally, section 6 reviews our conclusions.

2.Related Work

Role-based access control ispresented in Sandhu et al.’s seminal paper[15] where the main RBAC components (users, roles, permissions, sessions) are systematically addressed.Using this model, efficiency is gained by associating permissions with roles rather than users.This model greatly simplifies security management for administrators, and many complex security policies can be applied easily.Bertino et al. [16] presents Temporal-RBAC which supports periodic role enabling and disabling and temporal dependencies among permissions by introducing time into the access control infrastructure.Covington et al. [3] extends the model beyond time by introducing location and system status as constraints.Moyer and Ahamad propose generalized RBAC in [17];GRBAC leverages and extends the power of traditional RBAC by incorporating subject roles, object roles, and environment roles into access control decisions.

Georgiadis and Mavridis [4] and Wang [5] both present a team-based access control model that is aware of contextual information associated with activities in applications.Kumar et al. [2] summarizes previous work and formally proposes a context-sensitive RBAC model.Their model enables traditional RBAC to enforce more complicated security policies that are dependent on the context of an attempted operation; however, this model does not provide a mechanism for automatically merging new context types into existing access policies, which limits its application in distributed scenarios.McDaniel [1] gives a more generic view of contexts, suggesting that a context should be defined by its implementation.Neumann and Strembeck [6] and Lei et al. [7] also discuss some research issues in context-related security applications.

Meanwhile, approaches to applying the RBAC model to applications distributed over the Internet have also been proposed.Taylor and Murty [12] and Joshi et al. [14] describe a security model for authentication and access in distributed systems, while Kang et al. [11] addresses how to separate inter-organizational workflow from concrete organizational-level security enforcement; however, none of these give much consideration to integrating context data with their models.Bonatti and Samarati [13] propose an approach for regulating service access and information disclosure on the Web, which can be adopted in our system when equivalent organizations all have independent access control infrastructures.

There are also some papers on security issues in distributed healthcare systems.Weaver et al. [8,22] propose a federated, secure trust network for distributed healthcare systems, which is the motivation for this paper.Zhang et al. [10] presents a delegation framework that can be used within the security framework of healthcare applications.Wilikens et al. [9] discusses how to apply CBAC to healthcare, but the model is static and not able to handle arbitrary context-dependent authorization policies.

3.Dynamic, Context-Aware Access Control

3.1Authentication

The protection of medical records is motivated in part by the new HIPAA [21] regulations which provide for fines as high as $250,000 for the unauthorized release of protected medical data.Our system divides access to protected data into two parts: (1) authentication–who is this person who is trying to perform a protected operation, and how much do we trust theauthentication of this user’s identity? (2) authorization—now that this person is identified (with some associated trust level), is this person, evaluated in light of the current context, authorized to perform the requested action?

In our system, each authentication technology is assigned a trust level T() based upon its perceived reliability.In the abstract, these trust levels are ordered based upon the number of degrees of freedom inherent to the underlying identification technology.For example, there is general agreement [23] that T(retina) > T(iris) > T(fingerprint) > T(password).However, in practice, the trust level of any particular product must be determined by experimentation to quantify its false acceptance and false rejection rates (the false acceptance rate is the percentage of authentication attempts by a person other than the enrolled individual which are nevertheless successful; the false rejection rate is the percentage of authentication attempts by the enrolled individual which are nevertheless rejected).In our system, hospital administration defines the trust level of each identification technology based upon its general perception of reliability, its manufacturer’s data on false acceptance and false rejection rates, and our own experimental evidence from testing the devices in our lab.The numerical values assigned to the trust levels T() are arbitrary; it is their relative ordering that is important because administrators want to issue a rule such as “access requires authentication at the level of T(fingerprint) or higher.”

3.2Authorization

Healthcare systems have complex access rules because of the many actors in the system and their interlocking access privileges.A practical healthcare IT systems must support hundreds or thousands of users, roles, objects, and permissions.

A system must be capable of representing a wide variety of access rules. Some examples:

• An attending physician may view and append data to any record.
• A medical fellow, resident, or student may view a given patient’s record only if the patient’s attending physician has given permission to do so.
• A patient may see all of his own medical record, except his psychological profile.
• Technologists can view and input data related to their own specialty, but not to other specialties.For instance, an ultrasound technologist in cardiology has access to cardiology data but not to ultrasound examinations originating from internal medicine.
• Any M.D. may write a prescription for a patient, but it must first be approved by the patient’s attending physician.

• Dr. Smith is the attending physician for Mr. Jones, but while Dr. Smith is on vacation his permissions are temporarily exported to his on-call replacement, whoever that might be at the time of the call.
• Ms. Knight’s mammogram can be interpreted by any radiologist who is a board-certified mammographer.

To further complicate matters, we must also allow for exceptions during times of crisis such as public health emergencies; HIPAA permits access to patient data if the patient’s life is in jeopardy.

3.3Context-Aware Authorization Schema

In the conventional RBAC model, a typical authorization policy is represented as “User U in role R has permission P.”However, to make our access control infrastructure aware of context information, it is necessary to define context-related constraints in authorization policies.We extend the original authorization policy by attaching a context-based constraint to it, as in “User U in role R who satisfies constraint C has permission P.”The format for this type of policy is shown in figure 3.The idea of “constraint” comes from the grammar of“condition clauses” in natural languages where they are used to limit the applicability of the primary statement.

Here, a constraint is defined as a restriction that can be applied by the authorization policy: permission P is granted to role R if and only ifconstraint C is satisfied.A rule about patient access to his own patient data might be stated as “User U in role Patient has permission P to view patient data if U is the owner of that patient data.”Numerous types of contexts are possible, but we are mainly concerned with the context of the current access request: the status of the user making a request;the status of the object being requested;when and where the request originated.By adding context-based constraints to the authorization policy, authorization is determined dynamically based upon the current context of the request, rather than just the role of the user.

As shown in figure 3, a constraint is composed of multiple restrictions, called context conditions.A context condition is defined as a predicate on some context type, the value of which determines whether a particular condition is satisfied.The context condition is normally stated as a Boolean expression (e.g., time > 14:30, IPAddress = 128.45.18.3).To simplify that expression we introduce two new terms: context type and context implementation.

Figure 3.RBAC with Constraints

• A context type is defined to be a property of the situation under which the access request is issued.In simple cases, context type may be a concrete property familiar in everyday life, such as time or location.In a more complex scenario, context type can also be used to describe an abstract concept such as authentication trust level; this would allows us to add a context constraint such as “trust level of user authentication > T(password).”
• The context implementation of a context type is defined as a program or function that can evaluate the value of the context type.A context implementation can be a local function call, a program execution, or some remote service as long as it can determine the value of the current context type.Because context type can be an abstraction, there is no limitation on how it should be evaluated.For example, for a context type of time, it could be evaluated using a local time function, or by using a standard time service on a remote server.(We use web services to evaluate context types; see section 4.) Computing the value of a context type is called context evaluation.

Based upon the context type and its implementation, the process to determine whether a data access is authorized is:

1)Retrieve all access control policies that should be applied to the current data access.

2)For each policy, extract all constraint information associated with it.

3)For each context condition in the constraint, first evaluate each context type via its implementation, then return that value to the predicate, and finally evaluate the context condition (Boolean).

4)Computethe Boolean result of all context conditions to determine whether the access policy is satisfied.

5)If the access policy is satisfied, data access is authorized, otherwise it is denied.

3.4Components of the Security Infrastructure

Figure 4 depicts the essential system architecture of our proposed distributed healthcare IT system.There are three main components: authentication engine, authorization engine, and context service.The authentication engine is responsible for issuing authentication tokens to users and establishing the authentication level (trust level) forthat token.The authorization engine monitors all data access requests coming from the web service interface.If the issuer of the data request has permission to access that data (as determined by applying the authorization rules to the issuer’s identityand any context-dependent information), then access is granted and results are returned to the issuer.The context service, usingour extensions to the RBAC model, records all pre-defined context types, evaluates them dynamically, and reports its results to the authorization engine.