Download A Dynamic, Context-Aware Security Infrastructure

1
A Dynamic, Context-Aware Security Infrastructure
for Distributed Healthcare Applications
Junzhe Hu and Alfred C. Weaver
Department of Computer Science
University of Virginia
Charlottesville, VA 22904
Abstract
The rapid worldwide deployment of the Internet and
Web is the enabler of a new generation of ehealthcare applications, but the provision of a
security architecture that can ensure the privacy and
security of sensitive healthcare data is still an open
question. Mostly built on basic static RBAC model,
current solutions to this problem are application
dependent and not sufficient to address all those
intricate security requirements of healthcare
applications. Ideally, healthcare industry requires
flexible on-demand authentication, extensible
context-aware access control, and dynamic
authorization
enforcement.
With
on-demand
authentication, users only need to get authenticated
according to task-specific situation. And extensible
context-aware
access
control
can
enable
administrators to specify more precise and fine-grain
authorization polices for any kinds of applications. At
last, dynamic authorization enforcement can make
authorization decision dynamically based on runtime
parameters rather than only roles which users are
playing. Motivated by above points, in this paper we
describe a dynamic, context-aware security
infrastructure that can fulfill those security
requirements of healthcare applications and can also
be easily adapted to offer security supports to other
similar enterprise applications.
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, 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 new
data; medical records employees are required to
authenticate with an iris scan to delete any items from
a patient record.
In our system, it is also reasonable to let user perform
an operation with the minimum permission. For
example, an administrator can login with the
password to view some security data at the
beginning. And our system will ask for some higher
level authentication when later he/she wants to
execute some more restricted operations, such as
delete medical record. Otherwise, this administrator
may make some dangerous actions without intention.
In addition, from a generic view, user’s fingerprint,
iris and etc are also personal privacies that need to be
protected, just like credit card numbers. Users want
to get granted permissions with providing credential
information as least as they can. Therefore, above
authentication style, which we call on-demand
authentication, will benefit both sides (users and
system) of an application. Our security framework
2
can support multiple authentication technologies and
on-demand authentication based on trust-level.
Second, 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.
Assigned
Users
Granted
Roles
Permissions
Figure 1. Role-Based Access Control
.
However, even in our simple example above, RBAC
is not sufficiently powerful to enforce the concept of
a context-dependent constraint—namely that a
particular 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 (CBAC), whose core
idea is to associate context-related constraints with
every component of the RBAC model (see figure 2
[2])
Figure 2.Context-Based RBAC Model
Although CBAC helps the security infrastructure to
be aware of contextual information, there are still two
defections need to be eliminated. For the first, current
CBAC implementation is application dependent,
which means it only addresses the specific context
parameters related to a particular application. For
example, some application may only focus on
environment contexts, such as time and location,
while another application may rely on contextual
information like bank balance and credit history. So,
it is very hard to extend existing CBAC model to
apply arbitrary context related constraints in an
application. But our proposed extensible context
aware access control schema is available for any kind
of application to use. For the second, there is no
common specification to express context aware
access control polices, which means CBAC in
different applications is speaking different languages.
While nowadays healthcare providers prefer a
federated and trust distributed environment to help
their systems interacting seamless together, which
requires security framework in every party can talk to
each other. So, we propose our context aware access
control schema upon XML based WS-Policy
specification, which could give CBAC another
powerful support to be extended to any applications.
Third, the security requirements in our healthcare
systems require very dynamic and flexible policy
enforcement. Not only are there many intricate userdata relationship we could define when we design the
security framework, there are also many unexpected
emergency cases that are impossible to be predicated.
It is worthless to protect one patient’s medical data
very securely while he is going to die if the physician
can’t access those crucial data in an emergency. In
current CBAC models, policy enforcement part is
totally statically hard-coded within the application
implementation, and thus is not easy to change. But
in our proposed security infrastructure, the policy
enforcement mechanism is constructed in web
service mode, which is easy to be deployed and
separated from policy definition. So the application
designer need not know what access policies will be
used at application coding time; our infrastructure
will simply enforce at run-time whatever policies are
currently specified by administrators without any
extra cost.
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 ondemand 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 is presented in Sandhu et
al.’s seminal paper [15] where the main RBAC
components (users, roles, permissions, sessions) are
3
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 contextrelated 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 Security Framework
3.1 On-demand Authentication
The protection of medical records is motivated in part
by the new HIPAA [21] regulations that provide for
fines as high as $250,000 for the unauthorized release
of protected medical data. Authentication is the first
step to restrict access to sensitive patients’ medical
records. Our university hospital intends to
incorporate some more secure biometric technologies
into the healthcare system to improve its security
strength, for the reason that biometric credential is
hard to be stolen, faked and forgotten. These
biometric technologies include fingerprints, iris
scans, signature and voice recognition. Usually, iris is
regarded as the most secure authentication method
among all above four options, so it’s natural for
system administrators to specify that most restricted
operations, such as delete patients’ medical records,
require most secure authentication technology, i.e.
iris scan. But a user can still login with password at
first to do ordinary work, and later in case he wants
to perform some highly restricted operations that
require more secure authentication, he will be
demanded to provide that kind of credential
information by our system. Without on-demand
authentication, users will get full permissions even
they don’t actually need them at all, which may cause
unintended destruction to the whole system.
According to above on-demand authentication idea,
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
4
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.”
In this section, we introduce the formal definition of
our context aware access control schema. At first,
here are several terms that are used to describe the
concepts proposed in our schema:
3.2 Context-Aware Access Control
Data Type: A data type is a group of data objects
with the same attributes. For instance, all patients’
prescriptions in a hospital compose a data type of
“Prescription”. More general, a couple of data types
can combined together to define a complex data type,
such as patient medical record is composed of
“Diagnosis”, “Prescription”, “Clinical Note”,
“Demographic” and etc.
Healthcare systems have complex access rules
because of the many actors in the system and their
interlocking access privileges. And most of these
rules have to be context aware. A practical healthcare
IT system 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 oncall 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.2.1 Context-Aware Access Control Schema
Data Object: A data object is the smallest unit to be
accessed and protected in an application. For
example, one prescription, diagnosis and clinical note
are all typical data object in healthcare applications.
Data Set: Data set is the set of all data object of an
application.
User Set: User set the set of potential entities that
will access the data objects in the data set of an
application.
Definition 1 (Context Type): A context type is
defined as a property related to every participant in
an application when it is running. 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 that we discussed in previous section.
Based on context type, every application has its own
Context Set, which is defined as a set of context
type:
CS = {CT1, CT2 … CTn}, 1in,
By analyzing the system security requirements,
application designers determine which context types
will be used to specify access. For example, suppose
we have a security requirement saying attending
physician can only access data of patients who are
currently under his/her attendance. From this
requirement, we need a concept to describe if there is
an attending relation between physician A and patient
B, so we define a context type “Attending Relation”.
Although context set is made up before the
application implementation, system administrator is
still able to define new ones into context set.
In order to make abstract concept context type usable
when authorization decision needs to be made, it is
necessary to have context type evaluated by some
Context Implementation. A context implementation
5
of context type CT is defined as a function with n
inputs and gets value of CT.
CI: CT1 CT2  …  CTn  CT, where n  0
From above definition, we know there are some
context types could be evaluated without any inputs,
such as time and location. While the “Attending
Relation” context type needs to be evaluated by two
other context type, “Physician” and “Patient”.
framework is now aware of context information to
make authorization decision. The format for this type
of policy is shown in figure 3.
Definition 2 (Context Constraint): we define a
context constraint as a regular expression. Based on
this format, our access control schema is capable of
specifying any complex context related constraint to
describe all kinds of security requirements.
Context Constraint:=Clause1Clause2 …Clausei
Clause:= Condition1Condition2 … Conditionj
Condition:= <CT> <OP> <VALUE>, where
CT  CS; OP is a logical operator in set {>,
,,,,=} and this set can be extended to
accommodate user-defined operators as well;
VALUE is a specific value of CT.
Suppose we have a context set CS = {Time,
Location, Authentication Level}, and we have a
security rule like “physician can access patients’
medical data before 5:00pm and in the hospital or he
always gets access if login with any authentication
method higher than password”. Then we can define
such kind context constraint like following. (In this
constraint, “in” is a user-defined logical operator and
“hospital” is a valid value of context type Location.)
Context Constraint: = (Time < 5:00pm  Location in
hospital)  (Authentication Level > T(password))
Definition 3 (Authorization Policy): We define an
authorization policy as a triple, AP = (S, P, C) where
S: is the subject in this policy, which could be a
user or a role.
P: is the permission in this policy, which is
defined as a pair <M, O>, where M is operation
mode defined in {READ, APPEND, DELETE,
UPDATE} and O is a data object or data type.
C: is a context constraint in this policy. In our
schema, C could be empty in which case our
access control goes back to traditional RBAC.
In the conventional RBAC model, a typical
authorization policy only specifies the relationship
between subject S and permission P, like “role R has
permission P.” By attaching a context constraint to
original RBAC authorization policy, as “role R has
permission P given constraint C”, our security
Figure 3. RBAC with Constraints
Definition 4 (Data Access): We define data access as
a triple, DA = (U, P, RC) where
U: is a user in User Set who issues this data
access.
P: is the permission this user wants to acquire.
RC: is a set of values for every context type in
Context Set. That is RC = {v1 of CT1, v2 of CT2,
… vn of CTn}, where {CT1, CT2, … CTn} is
context set CS of the application.
A data access DA (U, P, RC) gets granted only if
there exists an authorization policy AP (S, P, C),
such that
U  S and
P = P and
C is evaluated as true under RC
Based upon the context type and its implementation,
the process to determine whether a data access is
authorized is:
1) Retrieve all authorization policies that should be
applied to the current data access, based on U
and P.
2) For each policy, extract the context constraint
associated with it.
3) For each clause 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) Compute the Boolean result of all context
conditions to determine whether the access
policy is satisfied.
5) If all the access policies are satisfied, data access
is authorized, otherwise it is denied.