Purpose engineering for Contextual Role-Based Access Control (C-RBAC)

Abstract

Distributed and ubiquitous computing environments have brought enormous efficiency to the collection, manipulation and distribution of information and services. Although this efficiency has revolutionized countless organizations but it has also increased the threats to individual’s privacy because the information stored within the collection of heterogeneous distributed components is sensitive and requires some form of access control. The way to protect privacy in this age of information technology requires such access control system that can accommodate organization requirements to protect privacy of individuals with ease in management and administration of resources. Among those requirements, purpose inference is one of the major problems as the total access control decision mainly relies on the user intentions/purposed. This work in this paper is an attempt to provide purpose engineering semantics that we use for the proposed contextual role-based access control model (C-RBAC) in order to comply with HIPAA.

Full text

Page 1

Muhammad Nabeel Tahir
International Journal of Engineering (IJE), Volume (2): Issue(3) 41
Purpose engineering for Contextual Role-Based Access Control
(C-RBAC)

Muhammad Nabeel Tahir
Multimedia University, Melaka
75450, Malaysia


m_nabeeltahir@hotmail.com

Abstract

Distributed and ubiquitous computing environments have brought enormous
efficiency to the collection, manipulation and distribution of information and
services. Although this efficiency has revolutionized countless organizations but it
has also increased the threats to individual’s privacy because the information
stored within the collection of heterogeneous distributed components is sensitive
and requires some form of access control. The way to protect privacy in this age
of information technology requires such access control system that can
accommodate organization requirements to protect privacy of individuals with
ease in management and administration of resources. Among those
requirements, purpose inference is one of the major problems as the total access
control decision mainly relies on the user intentions/purposed. This work in this
paper is an attempt to provide purpose engineering semantics that we use for the
proposed contextual role-based access control model (C-RBAC) in order to
comply with HIPAA.

Key words: Purpose Engineering, Intentions, C-RBAC, Purpose Hierarchy


1 INTRODUCTION
With the development of distributed healthcare systems and pervasive availability of information,
prevention of fraud and abuse has become an ever greater issue. The introduction of HIPAA law
provides a framework for ensuring the security of medical data especially the electronic versions
and maintaining patients’ privacy. Care is needed to ensure that every pervasive healthcare
system maintains the privacy of personal health information by implementing comprehensive
solutions that are both technically sound and legislatively compliant. On the other hand,
unauthorized disclosure of health information can have serious consequences including refusal of
prospective employment, difficulties in obtaining or continuing insurance contracts and loans, and
personal embarrassment [1]. Many studies resulted frameworks, languages, models to preserve
privacy of patients. Privacy in [2] has been defined as “The right of an individual to be secure from
unauthorized disclosure of information about oneself that is contained in documents”.

An access control model based on RBAC to protect privacy in a distributed health care
information systems, based on the notion of consent, has been presented in [3]. The authors
argued that constraints in RBAC do not provide an elegant solution especially with the role
hierarchies. For example if a constraint is applied to the role of a doctor, then its child role
(podiatrists) will also inherit the constraints of the role. Therefore it is not easy to execute a policy
of the form provide access to all doctors except Dr. X. In their work, a patient’s access policy
have been recorded and enforced through a consumer centric role called care-team role (CTR)
that consists of four main components: list of roles that has been allowed to access patient’s

Page 2

Muhammad Nabeel Tahir
International Journal of Engineering (IJE), Volume (2): Issue(3) 42
health information, list of roles that have been denied to access to patient’s health information,
the access privileges, and administrative information about the CTR such as its ID and
description. A similar approach has been proposed [4]. However, their work does not provide any
mechanism to ensure the mapping of patient formalized policies and consents into CTR. Overall
there has been no concrete framework of RBAC with privacy-based extensions. An extended
framework of RBAC with privacy based extensions to control information access in e-Health has
been presented [5]. Authors proposed an aggregation decision-making layer interacted with a set
of autonomous RBAC models to aggregate PHI in e-Health care informatics. Although semantic
definitions of role authorization with purposes, recipients, retentions and obligations as sets of
privacy-based entities has been provided, their work has not shown how these privacy-based
entities can be engineered and enforced into e-Health framework. The work also has not provided
any purpose driven approach, purpose hierarchies and relationships between subject roles and
purposes (spatial purpose role).

The info space concept as the trust boundary and the privacy tag for privacy control in ubiquitous
systems has been presented in [6]. Jiang & Landay [7] discussed how the user can be notified
about data collection by sensors and how a policy can be negotiated. However these two privacy
frameworks referred to a general ubiquitous computing or context-aware computing environment
and have not been directly applicable to healthcare information systems. More relevantly, the
work [8] analyzed the dependability issues in U-Healthcare. Beckwith [9] discussed the
perception of privacy based on the case study of a sensor-rich, eldercare facility. The work in [10]
presents a method to control access to any sensor data recorded by a personal ubiquitous
healthcare system. Their approach has been based on the concept of mediator that logically sits
between a personal healthcare system used by the patient and any clinical system used by the
caregiver. However, their proposed architecture does not cope with such dynamic requirements
of ubiquitous environment. On the other hand, many information privacy and security laws
tailored their protections according to the purpose of the use or disclosure, rather than basing that
solely to the particular characteristics of the data itself. Purposes present user’s intentions for
which he/she requests access to use resources. Few definitions of purposes have been
described in the literature. For example, purpose “an anticipated outcome that is intended or that
guides your planned actions” [11]. Purpose in [12] has been described as the reason for which
organizations’ resources are used. P3P [13] defined the purpose as “the reason for data
collection and use” and specify a set of purposes including current, admin, contact, telemarketing
etc.

2 Purpose Context
There are several ways to capture purposes/intentions of the user who request to access
resources. First possible method is to register each application with an access purpose. As
applications have limited capabilities and can perform only specific tasks, it should be ensured
that data users use them to carry out only certain actions depending on the associated access
purposes. This method, however, cannot be used in distributed and ubiquitous environment for
applications as it may access various data and resources for multiple purposes. Another
possibility is to state access purpose(s) along with the requests to access organization resources
and confidential data. Although this method is simple and can be easily implemented however,
the overall privacy that the system is able to provide relies entirely on the users’ trustworthiness
as it requires complete trust on the users. Lastly, the access purposes can be dynamically
determined by the system based on the current context. For example, consider the case where
the user with the role DayDutyDoctor sends a request to access a patient record. From this
context (i.e., the job function, role, the nature of the data to be accessed, the application
identification, time of the request, location of doctor), the system can reasonably infer that the
purpose of the data access must be “routine checkup”. The advantage of this approach is that
many access purposes can be defined for the same values of context information in order to
provide a flexible way of making access control decisions. However the key challenge for
implementing this method is to engineer context information accurately and efficiently. This work
has defined purpose for C-RBAC model as:

Page 3

Muhammad Nabeel Tahir
International Journal of Engineering (IJE), Volume (2): Issue(3) 43

Definition 1 (Purpose): Purpose is the intention of the user that is computed based on the
contextual values of the user’s current environment through which the user is requesting access
to use resources.
Purpose p → SPR×T×LOC_ATR
where SPR ∈ Spatial purpose roles, T is time interval borrowed from Joshi, Bertino, Latif, &
Ghafoor [14, 15] and LOC_ATR is a set of attributes e.g. user motion direction, motion speed,
user location and distance from resource such that given the user session s, SLOC_ATR
(s:SESSION) represents the current contextual values for the session s activated by the user u.
LOC_ATR: ∪ SLOC_ATR(s)
s ∈ SESSION
The number of contextual variables and its values may vary based on the organizations’
requirements. For example, some organizations may consider time t, and role r, of the user u to
compute the purpose of the user. For example, if user u (Bob) with the role r (doctor) sends a
request to access a patient record pr of patient between 7am to 7pm, then the purpose p is
RoutineCheckup. Similarly, some organizations may consider time t, location l and role r of the
user u to compute the purpose of the user. For example, if user u (Bob) with the role r (doctor)
sends a request to access a patient record pr of patient from general ward where patient is
admitted then the purpose p is RoutineCheckup. In order to elaborate further, consider the
scenario in Figure 1 where there are four departments in a hospital: ICU Ward, General Ward,
Laboratory and X-Ray Department. Assume that Bob, a cardiologist doctor is assigned to ICU
ward. He is also attached to Laboratory as the Laboratory Head. When Bob login into the system,
the system will automatically enable the roles that are assigned to Bob depending on his location.
In this scenario, Bob will get all the roles that are assigned to him at the location of ICU Ward.
Assume that for some reason, either for a normal routine checkup or for emergency calls, he has
to go to the General Ward. When Bob walks to the General Ward, he will pass two other
departments, i.e. Laboratory and X-Ray Department. The system can easily get the physical
position of Bob through GPS (external), access points or sensors (internal) and computes the
logical location of Bob. If the relative location overlaps between two regions for example the
doctor’s logical location overlaps with the Laboratory and X-Ray Department, then all the roles
that are assigned to Bob will be enabled automatically although Bob is on his way to General
Ward. However, if the system is capable of monitoring the user movement direction then it can
easily infer that Bob’s intention is to go to the General Ward rather than Laboratory or X-Ray
Department.







Figure 1: Relative Location Overlapping.


ICU
Ward

General Ward

Laboratory
X-Ray
Department

Page 4

Muhammad Nabeel Tahir
International Journal of Engineering (IJE), Volume (2): Issue(3) 44
2.1 PURPOSE HIERARCHY
Like subject roles, purposes also have a hierarchical relationship among them. For instance, the
purposes MinorOperations and MajorOperations can be grouped together by a more general
purpose Operation. This suggests that purposes can be organized in hierarchical relationships to
simplify the management of the purposes. The hierarchical relationship among different purposes
is shown in figure 2 where each node represents the purpose and each edge represents the
parent/child relationship. The next definition formalizes the above discussion.



Figure 2: Purpose Hierarchy in C-RBAC.
Definition 2 (Purpose Hierarchy): Let P be a set of purposes defined within the system. A
hierarchical relationship is defined with ≤ between purposes such that pi ≤ pj means that pj is
child of pi or pi is a parent of pj.
Figure 2 shows an example of hierarchical relationship between purposes. MajorOperation ≤
Cardiothoracic means that purpose MajorOperation is a parent purpose of Cardiothoracic. In
another words, the subject role or location assigned to the purpose MajorOperation will also be
assigned automatically to Cardiothoracic.

Another novelty in this work has been the definition of relation between purposes and locations. A
notion of spatial purpose (SP) is introduced that is defined as a purpose in relation with location. It
must be noted that multiple spatial purposes can be defined at one particular location, LHS and
LHI level.

Definition 3 (Spatial Purpose): Spatial purpose is a purpose defined over a particular location
such that;
Spatial Purpose SP <sp, lloc, p>

where sp is spatial purpose name such that sp ∈ P (universal set of all spatial purposes defined
in a system) and lloc is a logical location such that lloc ∈ LLOC, defining the boundaries for sp
and p is a purpose such that p ∈ P.

Page 5

Muhammad Nabeel Tahir
International Journal of Engineering (IJE), Volume (2): Issue(3) 45









Figure 3: Spatial Purpose (SP) Relationship.
Figure 2 shows (a) hierarchical relation between purposes as defined in figure 3 and (b)
spatial purpose relation in which purpose EmergencyCheckup is defined over logical or
physical location.

2.2. SPATIAL PURPOSE WITH LHS AND LHI
In common business environments it is also possible to define spatial purposes for a group of
hierarchically organized locations. The proposed spatial purpose engineering is flexible enough to
allow security administrator to define spatial purposes for LHS in order to allow a group of users
to perform common departmental activities with generalized purposes. For example if the hospital
policy states that all medical staff in wards can check the availability of medical doctors in all
wards for the purpose of emergency checkup then a spatial purpose can be defined at LHS:Ward
level to allow all medical staff in wards to acquire EmergencyCheckup purpose. The advantage of
this approach is that spatial purposes can be defined only once and assigned to LHS that
propagates spatial purpose to all nodes of hierarchically organized logical locations. This reduces
the overhead of defining the same spatial purposes for different logical locations. It also eases the
management of spatial purposes especially in large organizations where a same purpose is
required at many different locations. As LHS can have many instances (LHI) [16]; each defined
with a unique name. This means that spatial purposes defined at LHS level will also be assigned
to all instances (LHI) instantiated through LHS. Additionally, spatial purposes can also be defined
at LHI level. This is a case where organizations want to allow users from some specific locations
to acquire purposes to perform activities. For example if the hospital management wants to allow
only those staff members who are on duty in surgical ward to check the availability of medical
doctors for emergency checkup then spatial purpose EmergencyCheckup will be defined at
LHI:SurgicalWard level only to allow staff in surgical ward only to acquire EmergencyCheckup
purpose.

Figure 3 shows spatial purposes defined at LHS:Ward and LHI:SurgicalWard level along with a
set of purposes (through hierarchical relationship) {MajorOperation, Scheduled, Operation and
GeneralPurpose} for all wards as <EmergencyCheckup, Ward> at LHS level and for surgical
ward only as <EmergencyCheckup, SurgicalWard> at LHI level.

Definition 4 (Spatial Purpose with LHS): Let lhs is location hierarchy schema and p is a
purpose such that p ∈ P and lhs ∈ LHS, spatial purpose with LHS is defined as:

Emergency
Checkup
Context Values
(b) Purpose Hierarchy
Location
Spatial
Purpose
Location
(a) Spatial Purpose Relation
LHS: Ward LHI: Surgical
Ward