Content uploaded by Eugenia Politou
Author content
All content in this area was uploaded by Eugenia Politou on Jan 30, 2018
Content may be subject to copyright.
SOFTWARE—PRACTICE AND EXPERIENCE
Softw. Pract. Exper. 2005; 35:857–871
Published online in Wiley InterScience (www.interscience.wiley.com). DOI: 10.1002/spe.692
Towards secure Grid-enabled
healthcare
D. J. Power, E. A. Politou, M. A. Slaymaker and A. C. Simpson∗,†
Oxford University Computing Laboratory, Wolfson Building, Parks Road, Oxford OX1 3QD, U.K.
SUMMARY
The primary focus of the UK e-Science Programme is the development of software architectures,
middleware and applications to support the end-user scientific community in the undertaking of large-
scale research. A significant subset of e-Science projects is concerned with the healthcare domain: as well as
satisfying the needs of the end users, such projects have to consider the legal, ethical and security constraints
associated with the use of sensitive patient data—these concerns are particularly relevant within the context
of the U.K.’s National Health Service (NHS). In this paper we present a vision for Grid-enabled healthcare
that is sensitive to the information security requirements both of the NHS and the projects themselves.
Although our motivation is principally derived from U.K.-based e-Health projects, this paper should be of
interest to the worldwide health Grid community. By restricting ourselves to information security, we do
not consider, for example, physical security or audit trail capabilities, which are outside the scope of this
paper. The vision we describe is grounded in terms of experience, and reflects the challenges faced by the
e-DiaMoND project team. Copyright c
2005 John Wiley & Sons, Ltd.
KEY WORDS: security; Grid computing; electronic healthcare
1. INTRODUCTION
e-DiaMoND [1] is an e-Science project, the primary focus of which is the development of a prototype
for a Grid-enabled national database of mammograms which is sympathetic to the work practices
employed within the U.K.’s National Health Service (NHS) Breast Screening Programme (BSP).
The generic issues faced by the e-DiaMoND project are similar to other U.K. e-Science projects
concerned with health applications in that, for example, the needs, requirements, and constraints
associated with the NHS are of tremendous importance if there is to be clinical buy-in. In this paper we
consider the ‘real-world’ requirements associated with systems such as e-DiaMoND, discuss possible
solutions, and identify technological gaps that will need to be addressed if the dream of secure Grid-
enabled healthcare is to become a reality within the U.K. The work described reflects the experiences
∗Correspondence to: Andrew Simpson, Oxford University Computing Library, Wolfson Building, Parks Road, Oxford
OX1 3QD, U.K.
†E-mail: andrew.simpson@comlab.ox.ac.uk
Copyright c
2005 John Wiley & Sons, Ltd.
Received 13 October 2004
Revised 7 January 2005
Accepted 11 February 2005
858 D. J. POWER ET AL.
and challenges faced by the e-DiaMoND project team. Although our motivation is principally derived
from U.K.-based e-Health projects, this paper should be of interest to the worldwide health Grid
community.
In this paper we focus exclusively upon information security: issues pertaining to, for example, audit
trail capabilities and the NHS firewall—although obviously of extreme importance—are not considered
here. (The wider e-Health security issues pertaining to systems such as e-DiaMoND are discussed in a
previous paper [2].) Although our views are necessarily informed by our experiences with e-DiaMoND,
we consider that the gap analysis and vision described should be of interest to the wider U.K. e-Health
community. It is in this spirit that this paper is presented.
The structure of the remainder of this paper is as follows. In Section 2, we provide some background
information: we discuss how the virtual organization that is the U.K.’s NHS represents a genuine real-
life Grid and briefly describe both the current e-DiaMoND architecture and an idealized health Grid
architecture. In Section 3, we present a number of typical use cases—based on the idealized architecture
presented in Section 2—that help motivate the technical discussions that follow in the later sections.
Section 4discusses the existing technologies that may be exploited to realize the use cases of Section 3.
Then, in Section 5, we present a gap analysis with respect to the use cases that addresses the limitations
of these existing technologies. Finally, in Section 6, we discuss the contribution of this paper and
identify some appropriate next steps in advancing the agenda presented.
2. A REAL-LIFE GRID
There are, of course, many definitions of what constitutes a Grid. What commonly runs through
each of these definitions is the notion of a virtual organization—many disparate logical and physical
entities that span different administrative domains coming together to form a single logical entity.
Any U.K.-based e-Science project concerned with healthcare has a particular virtual organization in
mind: the NHS. In this section, we first consider the legal and ethical obligations that such projects are
required to observe before briefly considering the e-DiaMoND architecture.
2.1. Legal and ethical obligations
U.K.-based e-Health projects are obliged to enforce the principles of the Data Protection Act of
1998 [3], which can be stated as follows.
1. Personal data shall be processed fairly and lawfully (and in accordance with certain conditions).
2. Personal data shall be obtained for one or more specified and lawful purposes, and shall not be
further processed in any manner incompatible with that purpose or those purposes.
3. Personal data shall be adequate, relevant and not excessive in relation to the purpose or purposes
for which they are processed.
4. Personal data shall be accurate and, where necessary, kept up to date.
5. Personal data processed for any purpose or purposes shall not be kept for longer than is necessary
for that purpose or those purposes.
6. Personal data shall be processed in accordance with the rights of data subjects under the Data
Protection Act.
Copyright c
2005 John Wiley & Sons, Ltd. Softw. Pract. Exper. 2005; 35:857–871
TOWARDS SECURE GRID-ENABLED HEALTHCARE 859
7. Appropriate technical and organizational measures shall be taken against unauthorized or
unlawful processing of personal data and against accidental loss or destruction of, or damage
to, personal data.
8. Personal data shall not be transferred to a country or territory outside the European Economic
Area unless that country or territory ensures an adequate level of protection for the rights and
freedoms of data subjects in relation to the processing of personal data.
The NHS comprises a number of independent legal entities know as hospital trusts. Each hospital
trust is legally responsible for the data held at its sites: these data are released only with respect to the
principles of the Caldicott Guardian, which are stated below [4].
1. Justify the purpose(s): every proposed use or transfer of patient-identifiable information within
or from an organization should be clearly defined and scrutinized, with continuing uses regularly
reviewed by an appropriate guardian.
2. Don’t use patient-identifiable information unless it is absolutely necessary: patient-identifiable
information items should not be used unless there is no alternative.
3. Use the minimum necessary patient-identifiable information: where use of patient-identifiable
information is considered to be essential, each individual item of information should be justified
with the aim of reducing identifiability.
4. Access to patient-identifiable information should be on a strict need-to-know basis: only those
individuals who need access to patient-identifiable information should have access to it, and they
should only have access to the information items that they need to see.
5. Everyone should be aware of their responsibilities: action should be taken to ensure that those
handling patient-identifiable information—both clinical and non-clinical staff—are aware of
their responsibilities and obligations to respect patient confidentiality.
6. Understand and comply with the law: every use of patient-identifiable information must be
lawful; someone in each organization should be responsible for ensuring that the organization
complies with legal requirements.
As each trust retains the ownership of all data located at its site, coupled with the fact that each trust
determines who can access its data (and under what circumstances), it is easy to conclude that the NHS
genuinely does constitute a virtual organization.
2.2. e-DiaMoND
The main aim of the e-DiaMoND project is to develop a prototypefor a Grid-enabled national database
of mammograms that is sympathetic to the work practices employed within the U.K.’s NHS BSP.
In this regard, e-DiaMoND is similar to two other projects—the EU-funded MammoGrid project [5]
and the University of Pennsylvania-based NDMA project [6]. The motivation for the project is derived
from the fact that a large database with fast access would provide an invaluable resource to the breast
imaging community by (amongst other things) aiding in the breast screening process, improving the
quality of training (see, for example, [7]), and providing a huge resource for epidemiological studies.
The e-DiaMoND project aims to deliver prototype applications supporting each of these areas.
The e-DiaMoND platform is concerned with the provision of functionality for several different
drivers drawn from the breast care arena, with epidemiological studies and person-centric healthcare
being prime examples.
Copyright c
2005 John Wiley & Sons, Ltd. Softw. Pract. Exper. 2005; 35:857–871
860 D. J. POWER ET AL.
With respect to the first of these examples, one might imagine a national repository of mammograms
and related patient data being an invaluable resource for studies of cancer trends. Having sought appro-
priate approval, a hospital might permit a clinician from a different part of the country to run queries
across a subset of its patient information. This permission might, perhaps, be given to a particular indi-
vidual under certain conditions—perhaps only access to those mammograms associated with smokers
over 70 who died between 1995 and 2000 will be granted. It is thus necessary to offer means both of
expressing this policy and enforcing it in a fashion that does not impact significantly upon performance.
With respect to the second of these examples, consider a woman who lives in West London—
where her hospital records are based—but travels daily to East London to work. It would be more
appropriate and convenient for the woman to attend for routine screening in East London—during
her lunch break—than it would in West London. Therefore, the West London hospital offering remote
access to that woman’s information to the East London hospital would offer benefits for that individual,
and would be exactly the kind of benefit one would expect from a national database that supported the
breast screening process. Again, specific secure access without a significant impact upon performance
is required.
The core e-DiaMoND system consists of middleware and a virtualized medical image store to
support the concept of a data Grid. The virtualized medical image store comprises physical databases,
with each being owned and managed by a Breast Care Unit (BCU). The e-DiaMoND Grid is formed
by participating BCUs coming together as a virtual organization and uniting their individual databases
as a single logical resource.
To motivate the use cases described in this paper we will use an abstract view of the e-DiaMoND
system, in which, rather than considering mammography-specific use cases and BCUs, we consider
hospitals and more generic realizations of these use cases.
At each node the services are grouped into internally and externally facing services and the
virtualization of the data sources is assumed to take place at the service level. This abstract view of
the e-DiaMoND architecture is presented in Figure 1. Here, we have two hospitals that come together
to form a virtual organization, both of which have externally facing services (E): it is these externally
facing services that facilitate communication between sites. In addition, each hospital has its own
locally owned database (Data), internal services (I), access control policies (P) and workstations (ws).
This architecture allows each hospital to retain full control of its data and to determine who can
access them (and when): this is, of course, in accordance with the principles of the Caldicott Guardian.
All user interactions with a hospital are made via the externally facing services, and it is only these
externally facing services that are required to present a consistent Grid interface.
3. SECURITY USE CASES
In [8], five classes of threat to consider for IT-based healthcare systems were identified:
•insiders making innocent mistakes, causing accidental disclosure of confidential information;
•insiders who abuse access privileges;
•insiders who knowingly access information through spite or for profit;
•an unauthorized physical intruder gains access to information; and
•vengeful employees and outsiders.
Copyright c
2005 John Wiley & Sons, Ltd. Softw. Pract. Exper. 2005; 35:857–871
TOWARDS SECURE GRID-ENABLED HEALTHCARE 861
Data
P1
I
E
ws1
Hospital 1
Data
P2
I
E
ws2
Hospital 2
Virtual Organization
Figure 1. Abstract view of the e-DiaMoND architecture.
Mindful of these classes, within e-DiaMoND, a threat analysis was conducted using the method
described in [9]. The team identified assets, threats to those assets, and countermeasures to secure
those assets from the threats. For each asset, the team identified the level of confidentiality, availability,
and integrity. Risks were measured thus.
•Essential: the system should not be implemented without the relevant security measures in place.
•High: there is a high risk to the project if we do not deploy the relevant countermeasures.
•Medium: there is an average risk to the asset if we do not deploy countermeasures.
•Low: there is very little risk to the asset so deploying security countermeasures to these assets is
low priority.
We do not propose to report the results of this threat analysis exercise here (the interested reader is
referred to [10] for relevant details). Rather, in this section we consider several security use cases
that have informed our thinking within the e-DiaMoND project and will be relevant to other projects
within the domain. We do not claim that the use cases are exhaustive—it would be impossible to
provide such a collection of use cases in the space available—but we would claim that the use cases we
present here are representative of the requirements that health Grids should satisfy. Furthermore, given
the space available, it is necessary to present these use cases at a relatively high level of abstraction.
It should be noted that these use cases are associated with an idealized health data Grid and, as such,
are complementary to the use cases of [11], which are focussed on computational Grids.
3.1. Distributed queries of patient data
This use case is illustrated in Figure 2.
Copyright c
2005 John Wiley & Sons, Ltd. Softw. Pract. Exper. 2005; 35:857–871
862 D. J. POWER ET AL.
Data
P1
I
E
ws1
Hospital 1
Data
P2
I
E
ws2
Hospital 2
u1
1
2
2a
3
4
5
6
7,9a
3a
7a 4a
5a
6a
8a
Virtual Organization
Figure2.Usecase1.
A user wishes to query the data held on a subset of the hospitals that form the health Grid.
Each hospital is allowed to choose its own policy for data access. The user should receive the combined
results containing only data that they are permitted to access.
In the first step, a request is sent from a workstation to an externally facing service at the local
hospital. The external service then forwards the request both to an internal service at the local hospital
and to a number of external services at other hospitals. These external services at the other hospitals
then pass the request to their local services. When an internal service receives a request it reads the
local policy, and uses it to decide if the user is authorized to access the data requested. At the local
hospital the user will probably have significantly higher access than at remote hospitals. If access to
the data is permitted the local service will retrieve it from the data source and return the data to the
external service; if permission is not granted, a message will still be returned to the external service.
The data are then returned to the external service at the local hospital which will combine them and
return them to the user.
3.2. Working at a remote hospital
This use case is illustrated in Figure 3.
A doctor is working at a remote hospital, which is part of the health Grid. The doctor should be able
to access data from their home hospital, though their request may be subject to a policy that differs
from the one used when they are at their home institution.
The first step is a request from the doctor being sent from a workstation at a remote hospital.
Although this request is for data from the doctor’s home hospital it is first sent to the external service,
which is local to the workstation. The external service will then forward the request to the external
service at the doctor’s home hospital. When the internal service receives the request, it will know the
Copyright c
2005 John Wiley & Sons, Ltd. Softw. Pract. Exper. 2005; 35:857–871
TOWARDS SECURE GRID-ENABLED HEALTHCARE 863
Data
P1
I
E
ws1
Hospital 1
Data
P2
I
E
ws2
Hospital 2
u1
9
8
3
4
5
6
7
2
1
Virtual Organization
Figure3.Usecase2.
request comes from a doctor who works at the local hospital and it will also know that the request
came from a workstation at a remote hospital: as such, it may apply a different policy with respect to
the user’s request.
3.3. Delegation of access permissions
This use case is illustrated in Figure 4.
A senior health professional would like to grant access to data to a colleague. This access should be
temporary, and could be granted to either a named individual or a group of people.
The first step is a request sent from the workstation to the external service at the local hospital. This is
then forwarded to the internal service in the same way as a request for data. The internal service will
then check the current policy to see if the user is allowed to modify the policy in the manner requested,
and, if the user is allowed to make the modification, the policy is changed and all subsequent access
requests will be subject to the new policy.
3.4. External access
This use case is illustrated in Figure 5.
Either a health professional working from home or an individual patient wishing to see their own
records should be able to access data in accordance with the local hospital’s access control policy.
The hospital would use a different policy for such external access than would be used for requests from
a remote hospital. This use case differs from the others as the request comes from outside of the current
virtual organization. The exact mechanism for authenticating the user is not specified, but it is vital that
the internal service is aware of the origin of the request.
Copyright c
2005 John Wiley & Sons, Ltd. Softw. Pract. Exper. 2005; 35:857–871
864 D. J. POWER ET AL.
Data
I
E
ws1
Hospital 1
Data
P2
I
E
ws2
Hospital 2
u1
1
2
3
6
5
P1
4
Virtual Organization
Figure4.Usecase3.
Data
P1
I
E
ws1
Hospital 1
Data
P2
I
E
ws2
Hospital 2
u1
2
3
1
6
4
5
7
Virtual Organization
Figure5.Usecase4.
Copyright c
2005 John Wiley & Sons, Ltd. Softw. Pract. Exper. 2005; 35:857–871
TOWARDS SECURE GRID-ENABLED HEALTHCARE 865
Data
P1
I
E
ws1
Hospital 1
Data
P2
I
E
ws2
Hospital 2
u1
1
2
3
4
5
8
6
7
Virtual Organization
Figure6.Usecase5.
3.5. Modification of data
This use case is illustrated in Figure 6.
Having made a clinical decision about a case, a doctor wishes to modify the data stored in the
health Grid. A doctor will only be able to modify data if a hospital’s policy allows it. Each hospital is
responsible for the data it stores and as such it should keep a record of all modifications made. This use
case is similar to the delegation of access permissions described above, with the only difference being
that the data—rather than the policy—are being changed.
3.6. Transferring patient records
Our final use case draws together aspects of each of the previous use cases. We include this as it
imposes an additional requirement that is not introduced by the more generic use cases.
In this use case a patient has moved and is now being treated at a new hospital. As the patient is
likely to stay at the new hospital for some time, it would make sense to move their data. To be able to
move the data they will first need to be read: this may involve a distributed query as data may already
be present at other hospitals. The data will then need to be deleted from one hospital and copied to
another—as the responsibility for the data has transferred. This will involve the modification of data.
Finally, the access policies at both of the hospitals may need to be changed to reflect the change of
ownership of the data.
If an error were to occur during this transfer process the system could be left in an unstable state.
To prevent this, a notion of transaction management must be used to ensure that all the steps have
occurred successfully before the modifications are committed.
Copyright c
2005 John Wiley & Sons, Ltd. Softw. Pract. Exper. 2005; 35:857–871
866 D. J. POWER ET AL.
3.7. Further use cases
Use case 6 combined several of the earlier use cases as well as imposing an additional requirement.
From the point of view of security requirements, virtually all of the other use cases that we could
provide are specializations of one, or subtle combinations of several, of the use cases detailed.
For example, the combination of use cases 2 and 3 is representative of a situation in which a clinician
wishes to update the access control policy from a remote hospital.
4. TECHNOLOGICAL SOLUTIONS
The e-DiaMoND prototype infrastructure has been developed using a number of currently available
technologies, with the primary focus of the project being twofold: to establish the feasibility of Grid-
enabled healthcare and to identify the key issues that would have to be solved to deploy such a solution
for real. Rather than concentrate on the architecture of the prototype system, in this section we consider
the second of the above points, with a view to advancing the health Grid security agenda. In particular,
we explore what current technologies are available to implement the idealized health Grid described in
Section 2that is also capable of supporting the use cases described in Section 3.
First and foremost an appropriate service-based infrastructure is needed. The current trend—which
appears set to continue—is towards using Web services for this purpose. It is, of course, possible to
build a Grid from the ground up using Web services and this approach has been used successfully in
many projects. It is also possible to use a toolkit such as the Globus Toolkit [12]—this has been the
approach taken in the development of the e-DiaMoND prototype.
There has been much work at standardizing Grids with the Open Grid Services Architecture
(OGSA) [13] being prominent in this regard. The current Globus Toolkit is built upon the Open Grid
Service Infrastructure (OGSI) [14], although future versions of the toolkit will be based upon the
emerging Web Service Resource Framework (WSRF) [15] standards.
In order to present a Grid interface to a data source such as a relational database, the e-DiaMoND
project uses the OGSA-DAI (Open Grid Services Architecture—Data Access and Integration)
distribution [16]. The OGSA-DAI distribution is also compatible with the OGSA-DQP (Open Grid
Services Architecture—Distributed Query Processor) distribution [17] which is capable of performing
joins between OGSA-DAI data sources.
Many of the differences between the use cases presented in Section 3are related to the identity of
the user and the location of the workstation that they are trying to access data from. To provide user
credentials, X509 certificates [18] can be used. Similarly, it would be possible to use X509 certificates
to identify the workstation that the request was sent from, although this introduces its own problems.
Support for X509 certificates is built into the Grid Security Infrastructure (GSI) [19], which is part of
the Globus Toolkit. An alternative approach to authentication is to use Kerberos [20], which differs
most prominently from the use of X509 certificates in that it uses symmetric temporary session keys,
with a trusted third party server issuing these session keys.
There are many mechanisms for the secure transfer of data between the hospitals, many of these are
based on SSL (Secure Sockets Layer) [21,22], which provides a secure channel. It is equally possible
to encrypt the data before transmission which can then be passed through an insecure channel.
Copyright c
2005 John Wiley & Sons, Ltd. Softw. Pract. Exper. 2005; 35:857–871
TOWARDS SECURE GRID-ENABLED HEALTHCARE 867
To describe access requests and access control policies, the eXtensible Access Control Markup
Language (XACML) [23] could be used. This can be used in conjunction within the Security Assertion
Markup Language (SAML) framework [24], which is a framework for exchanging authentication and
authorization information.
This is, of course, just one possible framework for controlling access to data. An example of
an alternative approach, using role-based access control, might be the utilization of the PERMIS
infrastructure [25].
5. A GAP ANALYSIS
Having identified the key constraints associated with health Grids, the use cases pertaining to
information security and the currently available technological solutions, we are now in a position
to present a gap analysis. In presenting this gap analysis we make a number of assumptions.
The justification for making these assumptions is that without certain fundamental aspects of a secure
distributed architecture being in place, the consideration of information security is relatively futile.
First, we assume the existence of an appropriate service-based infrastructure to facilitate the type
of distributed healthcare Grid with which we are concerned. Second, we assume that there is some
method for issuing credentials. Third, we assume that appropriate mechanisms are in place to ensure
the secure transfer of data between different members of the virtual organization. Fourth, and finally,
we assume that there is some means by which users can describe their requests. Specific technologies
that might be used to realize these assumptions were discussed in Section 4.
Given our use cases and constraints—as well as the above assumptions—we have identified five
gaps that must be addressed to ensure an appropriate level of information security for Grid-enabled
healthcare systems. We consider each in turn.
5.1. Describing policies
There is a need for each individual entity within the virtual organization to be able to describe the
access control policies associated with that site’s data: the utilization of the OASIS XACML [23]isa
partial solution to this problem. However, the verbosity and complexity of XACML descriptions makes
tool support essential for the language’s widespread adoption. Unfortunately such tools for writing and
processing XACML are still in their infancy.
If temporary access to data—as described in the delegation use case—is to be allowed, then either
the policies must contain time-based information, or a secondary process would have to change the
policies at the appropriate time.
The need to allow access to only those patient data that are absolutely necessary is stated in the
second and third principles of the Caldicott Guardian. It is also a requirement of the Data Protection
Act (in accordance with the second principle).
5.2. Describing denial of access
If doctors are performing distributed queries to find information about patients, they may find that they
are being denied access to certain data. If doctors are trying to make diagnoses it is important that they
Copyright c
2005 John Wiley & Sons, Ltd. Softw. Pract. Exper. 2005; 35:857–871
868 D. J. POWER ET AL.
know when their access has been denied. Likewise epidemiologists may draw false conclusions if they
are silently denied access to certain data about certain patients. This would suggest informing the user
when access has been denied.
However, there may be a case where access is denied because a patient does not wish certain aspects
of their data to be used for anything but primary care. In this case it would be relatively simple to deduce
much of the data from messages describing the denial of access: there is the potential for information
flow.
The suitable description of denial of access—to avoid both the drawing of false conclusions and the
potential for information flow—is a key issue.
5.3. Credentials (portability, propagation, and revoking)
If credentials are to be used to authenticate users in our vision of a health Grid, then several problems
need to be overcome. First, it is important that the credentials are portable: this is needed if doctors are
to be able to move around their own hospital or to access data when visiting other hospitals. It would
not be feasible for doctors to carry a computer with them at all times, so a more portable solution would
be needed.
Another problem associated with credentials is propagation: external services need to be trusted to
pass users’ credentials to other services. One method commonly employed for this task is a proxy
certificate; however, there is the problem that the user has to trust the intermediate services to use the
proxy certificate as was intended. Other solutions may involve the user signing a more specific request;
this however reduces the ability of an intermediatory to make useful decisions for the user.
Finally, it must be possible to revoke a set of credentials: this is especially important if doctors
are carrying their credentials around with them. Current systems often rely on the service actively
requesting lists of revoked certificates, leaving a window of opportunity for people to misuse the
credentials. Use of the Online Certificate Status Protocol (OCSP) [26] may reduce the window to a
minimum but this has the drawback of requiring frequent communication.
5.4. Transactions
If data are modified at a single hospital as in use cases 3 and 5, then it is possible to handle any
transactional requirements within an internal service. For more complicated use cases, such as the
transfer of patient records, transactional support is required that spans hospitals. As all communication
between hospitals is handled by the externally facing services, the transactions will need to take place
between these services. Although there have been some proposed standards for transactions between
Web services, at the time of writing these are not commonly supported.
5.5. Secure deletion of data
One of the requirements of the health Grid is that it should be possible to give temporary access to
data. It is important that people given temporary access do not make a copy of the data. In our idealized
health Grid, data would have a lifetime and would be deleted after use: if this were the case, it would
then be following the fifth principle of the Data Protection Act.
Copyright c
2005 John Wiley & Sons, Ltd. Softw. Pract. Exper. 2005; 35:857–871
TOWARDS SECURE GRID-ENABLED HEALTHCARE 869
6. DISCUSSION
In the previous section we identified a number of gaps that prevent the implementation of the idealized
secure health Grid that was characterized in Section 2. In this section we provide a brief overview of
the activities being conducted within the e-DiaMoND project to fill these gaps.
There have been many proposed systems for the description of access control policies, with the
typical approach employed by modern relational database management systems being the use of
roles and views to restrict access. For many applications, such an approach is sufficient and entirely
appropriate, but it does have drawbacks: for example, such approaches tend to be coarse-grained; for
more fine-grained access control, Access Control Lists (ACLs) are typically used (which have their
own limitations).
An alternative approach to using database views is to modify the query being made by the user.
Such an approach was used in early versions of the INGRES database management system (see [27]).
When combined with the capture of arbitrary complex sets of rules expressed in, for example,
XACML [23], an approach to query modification based on dynamic fine-grained access control policies
is feasible. By using this established language to describe access control policies, it is possible to take
advantage of existing freely available tools that utilize standard interfaces.
Of course, the fact that a particular query might be blocked gives rise to the potential for information
flow. Further, query modification—as described above—runs the risk of false conclusions being drawn
by the user. To be able to describe in a policy that users should or should not be informed that their
access to data has been partially or totally blocked requires significantly more than a simple yes/no
decision with respect to data access. In XACML it is possible to state such addition requirements using
obligation statements.
The above is an avenue that we have explored within e-DiaMoND, with preliminary results being
described in [28]. Some problems are less surmountable, however.
Certificates are often used to provide credentials for users and servers. Solving the problems
associated with certificates is an active area of research. There are many partial solutions to the
problems associated with certificates but, unfortunately, no complete solution currently exists.
Transactional support for Web services is still in its infancy; e-DiaMoND use cases have been
developed for the GGF transaction management research group in this respect.
It should be borne in mind that there are numerous Web service specifications which are designed to
be composed together to provide various aspects of security. However, very few have been ratified—
most are in varying stages of consultation, which means that they are susceptible to change. As such,
designing solutions based on such technologies is a difficult task. Furthermore, as these standards are
not ratified there are currently no containers that support all of the proposed security-related standards.
In general terms, there is no solution to the problem of users keeping copies of data which they
have been given temporary access to. However, if users are restricted to viewing data through certain
accredited applications, it should be possible to avoid accidental copying of data, and to increase the
difficulty of copying data. For an infrastructure such as e-DiaMoND, it is possible to determine exactly
which applications may ‘plug-in’; for a more generic health infrastructure, this may not be possible.
e-DiaMoND is one of a growing number of U.K.-based e-Science projects that are developing
health Grids, with all of these projects facing similar security concerns. The goal of this paper was
to document the generic information security needs of such projects—based on our experiences within
e-DiaMoND—with a view to identifying the deficiencies of current technologies in this respect.
Copyright c
2005 John Wiley & Sons, Ltd. Softw. Pract. Exper. 2005; 35:857–871
870 D. J. POWER ET AL.
This paper will hopefully serve as a roadmap for future work in this area, both for the e-DiaMoND
team in follow-on projects and for the wider community.
ACKNOWLEDGEMENTS
The authors wish to thank other members of the e-DiaMoND consortium for their input into, and comments on,
the work described in this paper. The authors wish to acknowledge the support provided by the funders of the
e-DiaMoND project: the U.K. Department of Trade and Industry, the EPSRC (ref no: GR/S20956/01), and IBM.
REFERENCES
1. Brady JM, Gavaghan DJ, Simpson AC, Mulet-Parada M, Highnam RP. e-DiaMoND: A grid-enabled federated database
of annotated mammograms. Grid Computing: Making the Global Infrastructure a Reality, Berman F, Fox GC, Hey AJG
(eds.). Wiley: New York, 2003; 923–943.
2. Slaymaker MA, Politou E, Power DJ, Lloyd S, Simpson AC. Security aspects of grid-enabled digital mammography.
Methods of Information in Medicine (in press).
3. Data Protection Act. 1998. http://www.hmso.gov.uk/acts/acts1998/19980029.htm [5 May 2005].
4. Medical ethics and law: Confidentiality, data protection, Caldicott principles, computer use and patient records. 2003.
http://www.addenbrookes.org.uk/advice/medethlaw/confidential1.html [5 May 2005].
5. Amedolia SR, Brady JM, McClatchey R, Mulet-Parada M, Odeh M, Solomonides T. Mammogrid: Large-scale distributed
mammogram analysis. Proceedings of the 18th Medical Informatics Conference (MIE 2003) (Studies in Health Technology
and Informatics, vol. 95), St Malo, France, 2003; 194–199.
6. National Digital Mammography Archive. http://www.i3archive.com [5 May 2005].
7. Soutter J, Campos J, Hartswood M, Jirotka M, Procter R, Slack R, Taylor P. Grid-based mammography training. Hospital
Radiologist 2003; 5(6).
8. Trust in Cyberspace. Computer Science and Telecommunications Board, Committee on Information Systems
Trustworthiness. National Research Council, 1999, 352 pp.
9. Flechais I, Sasse MA, Hailes SMV. Bringing security home: A process for developing secure and usable systems.
Proceedings of the ACM/SIGSAC New Security Paradigms Workshop, Ascona, Switzerland, August 2003. ACM Press:
New York, 2003; 49–57.
10. Slaymaker MA, Politou E, Power DJ, Lloyd S, Simpson AC. e-DiaMoND: Risk analysis. Proceedings of HealthGrid’04,
January 2004.
11. Humphrey M, Thompson M. Security implications of typical grid computing usage scenarios. Cluster Computing 2002;
5(3):257–264.
12. Globus Toolkit. http://www.globus.org/toolkit/ [5 May 2005].
13. Foster I, Kesselman C, Nick J, Tuecke S. The physiology of the grid: An open grid services architecture for distributed
systems integration, 2002. http://www.globus.org/research/papers/ogsa.pdf [5 May 2005].
14. Open Grid Services Infrastructure (OGSI) version 1.0, June 2003.
http://www-unix.globus.org/toolkit/draft-ggf-ogsi-gridservice-33 2003-06-27.pdf [5 May 2005].
15. OASIS WSRF TC, October 2004. http://www.oasis-open.org/committees/tc home.php?wg abbrev=wsrf.
16. Open Grid Services Architecture—Data Access and Integration, OGSA-DAI, September 2004.
http://www.ogsadai.org [5 May 2005].
17. Open Grid Services Architecture—Distributed Query Processor, OGSA-DQP, September 2004.
http://www.ogsadai.org/dqp/ [5 May 2005].
18. Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, April 2002.
http://www.ietf.org/rfc/rfc3280.txt [5 May 2005].
19. Grid Security Infrastructure Documentation, October 2004.
http://www-unix.globus.org/toolkit/docs/3.2/gsi/index.html [5 May 2005].
20. Kerberos: The Network Authentication Protocol, October 2004. http://web.mit.edu/kerberos/www/ [5 May 2005].
21. The SSL Protocol version 3.0, November 1996.
http://www21.ocn.ne.jp/∼k-west/SSLandTLS/draft302.txt [5 May 2005].
22. The TLS Protocol version 1.0, January 1999. http://www.ietf.org/rfc/rfc2246.txt [5 May 2005].
23. Godik S, Moses T. EXtensible Access Control Markup Language (XACML) version 1.1, committee specification, August
2003. http://www.oasis-open.org [5 May 2005].
Copyright c
2005 John Wiley & Sons, Ltd. Softw. Pract. Exper. 2005; 35:857–871
TOWARDS SECURE GRID-ENABLED HEALTHCARE 871
24. OASIS Security Services TC, October 2004.
http://www.oasis-open.org/committees/tc home.php?wg abbrev=security [5 May 2005].
25. Chadwick DW, Otenko A. RBAC policies in XML for X.509 based privilege management. Proceedings of the IFIP
TCII 17th International Conference on Information Security (SEC2002): Security in the Information Society: Visions and
Perspectives, Cairo, Egypt, May 2002. Kluwer Academic Publishers, 2002; 39–53.
26. Meyers M. RFC 2560—X.509 Internet Public Key Infrastructure Online Certificate Status Protocol—OCSP, June 1999.
http://www.faqs.org/rfcs/rfc2560.html [5 May 2005].
27. Date CJ. An Introduction to Database Systems (8th edn). Addison-Wesley: Reading, MA, 2004.
28. Power DJ, Slaymaker MA, Politou EA, Simpson AC. A secure wrapper for OGSA-DAI. European Grid Conference
(EGC2005), submitted.
Copyright c
2005 John Wiley & Sons, Ltd. Softw. Pract. Exper. 2005; 35:857–871
