A Thesis Entitled Efficient Isolation Enabled Role-Based Access

A Thesis entitled

Eﬃcient Isolation Enabled Role-Based Access Control for Database Systems

by Mohammad Rahat Helal

Submitted to the Graduate Faculty as partial fulﬁllment of the requirements for the Master of Science Degree in Engineering

Dr. Weiqing Sun, Committee Chair

Dr. Ahmad Y. Javaid, Committee Co-Chair

Dr. Mansoor Alam, Committee Member

Dr. Hong Wang, Committee Member

Dr. Amanda Bryant-Friedrich, Dean College of Graduate Studies

This document is copyrighted material. Under copyright law, no parts of this document may be reproduced without the expressed permission of the author. An Abstract of Eﬃcient Isolation Enabled Role-Based Access Control for Database Systems by Mohammad Rahat Helal

Submitted to the Graduate Faculty as partial fulﬁllment of the requirements for the Master of Science Degree in Engineering The University of Toledo August 2017

A user is denied access in a typical Role-Based Access Control (RBAC) system if the system recognizes the user as an unauthorized user. This situation could lead to delay in essential work to be performed in the case of an emergency or an unavoidable circumstance. In this thesis, we propose designing and implementing Isolation enabled

RBAC at the record level in a database. The concept involves integrating transaction isolation concepts of a relational database management system (RDBMS) into the

NIST RBAC model securely and eﬃciently. Our proposed system allows the user limited access to the system instead of complete denial. One such example being, the senior role could delegate restricted access to the junior role. Using this restricted access, the junior role can perform actions which are mandatory to be conducted on behalf of the senior role. The system has been designed in a way to keep it secure, eﬃcient, available and consistent. The proposed system enhances the security of and ease of access to the system in the absence of an authorized user by restricting unauthorized user access to only an isolated view of the database. Moreover, in that scope of access, he/she can perform actions that are isolated from other users. The thesis presents design and implementation of the concept and compares our work with the approach followed by other RBAC implementations.

iii To my father Mohammad Habibur Rahman, my mother Late Rafat Sultana and my sister Rehana Firdaus for their immense love, care and perseverance to raise me to this level and higher in all odds. Acknowledgments

I would like to express my gratitude towards every individual who has in some way helped me achieve my dream of completing Master’s degree. It has been a great academic journey here, especially when it started after a long gap of a break from studies. I would thank my adviser Dr. Weiqing Sun to provide me an opportunity to work with him and guide me at every step with patience and perseverance. I would also like to thank my co-adviser Dr. Ahmad Yazdan Javaid for his immense support for showing me the proper direction and encouraging me to take appropriate steps time to time.

I would like to thank Dr. Mansoor Alam, EECS and ET Department and my thesis committee member Dr. Hong Wang for taking time out from their busy sched- ule to serve on my thesis evaluation committee and provide valuable comments and suggestions to improve my work.

I would like to thank COGS for providing me graduate assistantship. It was a pleasure working with Dr. Amanda-Bryant Friedrich and all the COGS staﬀ. I feel honored to have worked with my supervisor Teresa Hayes, and co-workers Elaine

Coopshaw and Mary Main.

I would like to thank Quamar for motivating me at every step right from admission to choosing thesis. My gratitude would be incomplete without thanking my friends

Bhavana, Shahrukh, and Farid for memorable and learning experiences. And at last,

I would also like to thank my family and friends from undergraduate days and good old industry days for always motivating and supporting me.

v Contents

Abstract iii

Acknowledgments v

Contents vi

List of Tables viii

List of Figures ix

List of Abbreviations xi

1 Introduction 1

1.1 Role Based Access Control ...... 1

1.2 Transaction Isolation Levels in a database system ...... 5

1.3 Background and Motivation ...... 7

1.4 Related Works ...... 8

1.5 Research objective and contributions ...... 10

1.6 Dissertation Outline ...... 11

2 Isolation enabled Role Based Access Control 12

2.1 Deﬁnition of Isolated environment ...... 12

2.2 Implementation of Isolated system in a Health-care facility ...... 17

2.2.1 Purpose of using Isolated System ...... 17

2.2.2 Proposed Isolated system ...... 18

vi 3 System Design 22

3.1 Design Steps ...... 25

3.1.1 Design a basic RBAC model ...... 25

3.1.2 Design Isolated system layer ...... 26

3.1.3 Deﬁne Isolated system attributes ...... 26

3.1.4 Design scripts for handling records in both environments . . . 28

3.1.5 Post Isolated system changes ...... 30

4 System Implementation 31

4.1 Database Level Implementation ...... 32

4.2 Logic of data ﬂow ...... 36

4.3 Realization of Isolation at database level ...... 38

4.3.1 Scenario 1 ...... 39

4.3.2 Scenario 2 ...... 40

4.3.3 Scenario 3 ...... 42

5 Future Work and Conclusion 45

5.1 Future Works ...... 45

5.2 Conclusion ...... 46

References 47

vii List of Tables

4.1 Attributes in Isolated System ...... 38

4.2 Old vs New attribute values for record in Isolated System ...... 38

4.3 Parameters for latest record in Isolated System ...... 39

viii List of Figures

1-1 Core RBAC display [16] ...... 2

1-2 RBAC system process [18] ...... 3

2-1 I-RBAC process ﬂow-chart [18] ...... 14

2-2 A typical RBAC policy table ...... 16

2-3 Role table ...... 20

2-4 Permissions table ...... 20

2-5 Objects table ...... 20

2-6 I-RBAC Policy table ...... 20

3-1 System Design Flow Chart ...... 23

3-2 Isolated and Host Users handling records at Isolated and Host System . . 27

3-3 Scripts invocation and handling in both the environments ...... 28

4-1 Sample tables comprising the Host and Isolated system ...... 32

4-2 Snapshot of an unauthorized user logged into Isolated System ...... 35

4-3 Records to be approved, rejected or further reviewed ...... 36

4-4 First session unable to read the record inserted by second session . . . . 39

4-5 After commit operation, ﬁrst session can read the inserted record . . . . 40

4-6 Individual inserts in two sessions can be read in respective sessions only . 41

4-7 After commit, both sessions can read the committed records ...... 41

4-8 Second session trying to update the same record is in locked state . . . . 42

ix 4-9 Session 1 commits, so session 2’s statement gets executed, but the overall

state of database is inconsistent ...... 43

4-10 Consistent state of database after both sessions commit ...... 43

x List of Abbreviations

ABAC ...... Attribute based access control ACID ...... Atomicity, Consistency, Isolation, and Durability

BTG ...... Break the glass

I-RBAC ...... Isolation Enabled Role Based Access Control

NIST ...... National Institute of Standards and Technology

RBAC ...... Role Based Access Control RDBMS ...... Relational Database Management System

SRBAC ...... Spatial Role-based access control

TRBAC ...... Temporal Role Based Access Control

xi Chapter 1

Introduction

1.1 Role Based Access Control

Role-Based Access Control (RBAC) is an access control mechanism that is based on the functions that could be performed by the users in an organization [1]. The access permission cannot be transferred between the users at their will. It is concerned with access to functions and information contained in an organization. Therefore, the concept of Role and Permissions arises [16]. It offers the flexibility of adding users to an organization and associates the users with their respective roles, while permissions are assigned to objects based on their roles. Using the user and role information, the concept of “User Assignment” mapping is built. This maps the users to their roles in an organization. This segregates other functionalities offered by the system regarding adding and removing users. Similar to this mapping, the concept of “Permission Assignment” is introduced, where the permission on objects in any organization is mapped to the roles using elements such as roles, permissions, and objects. As is understood from the definitions of the two mappings, user assignment could be many-to-many, and similarly, permission assignment could be many-to-many.

Other functionalities include user-role review and user-sessions. The user-role review helps determine roles assigned to a particular user and users assigned to a speciﬁc

1 role. User-sessions allow activation and deactivation of roles. Finally, users should

also be able to exercise permissions of multiple roles simultaneously.

Figure 1-1: Core RBAC display [16]

So, it can be summarized as shown in Fig 1-1 that core RBAC includes set of ﬁve

basic data elements called USERS, ROLES, objects (OBS), operations (OPS), and

permissions (PRMS). The deﬁnitions can be described as shown here [18]:

• UA: User Assignment ⊆ USERS × ROLES

• PA: Permission Assignment ⊆ PRMS × ROLES

• U-S: user sessions (u: USERS) →2SESSIONS

• S-R: session roles (s: SESSIONS) →2ROLES

• PRMS: 2(OPS×OBS), the set of permissions

The steps followed in a typical RBAC model could be shown in Fig. 1-2. If any user wants to access a particular resource in the system, he/she would first request the application service for access into the system. The credentials used by the user to access the system would be validated by the application service. If the user’s credentials are valid and the authentication service finds the user as authorized to access the system, he/she is granted the required level of access to the resources in the system, according to his/her role. Using the user’s role and permissions as 2 Figure 1-2: RBAC system process [18] parameters, the RBAC policy check is called by the authentication service. The policy check would return either True or False. The user is allowed access to the resource only if the policy check returns True, else the access request is terminated, and a message is sent to the user. If the user is unauthorized, his access would be denied into the system and a message displayed by the authentication service just after the user tries to access the system using his/her credentials. The application service could be a user interface or a website page and the resource requested by the user could be anything from a file to hardware such as a printer on a network. In a nutshell, only authorized users having authorized role can access the resources in the system and rest all combination of user credentials and roles/permissions are denied access to the system.

RBAC model supports three well-known security principles:

• Least privilege: This means that only those permissions required for the tasks

to be performed by the user are assigned to the role, i.e. the user is not given

3 privilege more than required to complete a given task. This has been described

as important for meeting integrity objectives [24].

• Separation of duties: In a system with multiple transactions happening,

this principle requires that all the transactions should not be carried out by

a single individual within a set. Invocation of the mutually exclusive roles

can be necessary to complete a sensitive task. This principle is an important

consideration in the real world [13] [28] [30]. The implementation varies based

on the application. For example, an online shopping website which authorizes

payment and which accepts selected products on a shopping cart would be

carried out in two separate transactions and hence separately handled.

• Data abstraction: This is supported using abstract permissions such as credit

and debit for an account object, instead of reading, write and execute per-

missions typically provided by the operating system. This principle is again

dependent on implementation and can vary with applications [29].

Overall, RBAC is a non-discretionary access control mechanism, where the organization has full control over what information should be accessed by its users.

Accordingly, they deploy security policies for the data they hold. Therefore, using

RBAC as compared to other access control systems oﬀers advantages such as implementing policies which are suited to their applications and displays the hierarchical structure of the organization correctly. It reduces complexity and is inexpensive to deploy. The maintenance of such a system is not painful in the long run because the policies once adopted rarely change over a period. Also, addition and removal of users into the system are quite easy as compared to mandatory and discretionary access control mechanisms [26] [15].

4 1.2 Transaction Isolation Levels in a database sys-

tem

Transaction isolation is one of the foundations of database processing [11]. Isola- tion is the I in the acronym ACID; the isolation level is the setting that ﬁne-tunes the balance between performance and reliability, consistency, and reproducibility of results when multiple transactions are making changes and performing queries at the same time.

Transaction isolation levels are a measure of the extent to which transaction isolation succeeds [10]. In particular, transaction isolation levels are deﬁned by the presence or absence of the following phenomena:

• Dirty Reads: A dirty read can occur when a transaction reads data that has

not been committed yet. For example, suppose one intern updates a record.

Another intern reads the updated record before the ﬁrst intern commits the

updated record. If the ﬁrst intern performs a rollback on the update operation,

the second intern will have read data which could be considered as never existed.

• Nonrepeatable Reads: A nonrepeatable read can occur when a transaction

reads the same record twice but gets diﬀerent results each time. For example,

suppose the ﬁrst intern reads a record and the second intern updates or deletes

that record and commits the update or delete operation. If the ﬁrst intern

rereads the record, it retrieves diﬀerent result or discovers that the record has

been removed.

• Phantoms: A phantom is a row that satisﬁes the search condition which is not

initially seen. For example, suppose the ﬁrst intern reads a set of records that

satisfy some search condition. The second intern generates a new record either

through an update or an insert operation that matches the search condition for 5 the ﬁrst intern. If the ﬁrst intern re-execute the query/statement that reads the

records, it gets a diﬀerent set of results.

The following describes simple ways that a database might implement the transaction isolation levels:

• Read Uncommitted: It is the lowest level of transaction isolation, and it

means that the database allows reading of records which have been created/written

by other transactions but are not committed. So, dirty reads, non-repeatable

reads, and phantom reads are all possible with this type of transaction, and it

allows high concurrency, and no locking happens [7].

• Read Committed: It is the next level of transaction isolation and allows

reading of records created/written by other transactions only after they have

been committed in the database. So, Non-Repeatable Reads or Phantoms are

both possible with this type of transaction, but Dirty Reads are not. This level

allows for a reasonably high level of concurrency and is considered safe if there

is only one SQL statement in the transaction [6].

• Repeatable Read: This is the next level of transaction isolation and most

preferred one for multi-statement transactions that involve “changes”. The non-

repeatable reads are discarded, and the concurrency drops. The locks cannot

be released before the transaction ends and a shared lock is put on every record

fetched by the database [8].

For example, if a transaction queries for some records then the transaction read-

locks those records as the application fetches them. If delete operation query is

issued, then the transaction write-locks the records as it deletes them.

• Serializable: This is the highest level of transaction isolation, and none of the

concurrency phenomena are allowed. It oﬀers the lowest level of concurrency,

6 and the database locks the entire table during the transaction. This results in

poor performance, and so it is least recommended by the vendor, though it is

default in standard SQL [9].

As mentioned, the entire table is locked in case of transactions happening.

So, if the transaction consists of a SQL statement SELECT * FROM Pre-

scription File, the range is the entire Prescription File table; the transaction

read-locks the table and does not allow any new records to be inserted into it.

Similarly, if a delete statement is issued, the records with the ﬁlter condition

(if the delete query has any) would be locked, and the transaction write-locks

all such records and does not allow any inserts or updates for records with that

ﬁlter condition.

This level is ideally suited for multiple select statements and oﬀers error-free

transactions at all times. For overlapping transactions, it produces the same

results irrespective of their order of execution.

The implementation of Transaction Isolation Levels have been explained in System

Implementation chapter. For the current implementation, we have used “Repeatable

Read” feature in MySQL.

1.3 Background and Motivation

RBAC oﬀers robust security to the system in a way that it denies access to unauthorized user and grants access to authorized users only. Roles and permissions on objects are set up according to the rules, policies and business logic of any organization. Therefore, it could vary from organization to organization and sometimes within an organization as well. Access to a system should not be compromised at any time. However, we encounter certain situations when a particular user, say a senior role in the organization, is absent and an emergency demands him to access 7 the system. Although an employee in a junior role might be available to perform the operation, lack of access would prohibit the junior employee from updating/changing the system. There could also be real time scenarios where inter-departmental access of data is required in a limited way, such as in a health-care facility. In an IT service industry scenario, the junior developer roles can code and build in the development environment, with limited or no permission to migrate the code from development to other coding environments. These situations could lead to delay in essential work to be performed, resulting in a loss of the business or much-needed information not being available to the end user. Another example, in a health-care system, access control model to be set up should not deny access to a user in case of doubt, since the best possible care being provided to the patients is the primary goal there [27]. Therefore, a patients electronic record should be available for access across departments, with limited and appropriate access indeed, to tackle emergencies. In conclusion, such issues during emergencies, if not resolved quickly, could result in problems ranging from loss of human life to delay the delivery of a product.

We propose to design and implement Isolation enabled Role-Based Access Control

(I-RBAC) at the record level in a database. The idea could be applied to the way data is being stored in an organization, its retrieval, and manipulation and reporting.

The primary goal of this dissertation is to integrate isolation concepts in a database transaction into the RBAC model, and thereby, adding usability and eﬃciency to it.

1.4 Related Works

We have seen different models of access control systems derived from RBAC, each of them addressing different access related issues and improving upon them. While each of the access control system implementation is based on specific scenarios and logic, their complexities vary significantly regarding resource utilization, efficiency,

8 availability, integrity, and security of data and time management.

One of the latest implementation is Attribute based access control [14] (ABAC) where the central concept is to use labeled objects and user attributes instead of permissions to provide access ﬂexibly. This approach considers attributes such as time of the day and user location for granting access. Before this method, we have wit- nessed separate implementations of time and place based approach as discussed here.

These methods provide simpliﬁed and scenario speciﬁc implementation of RBAC and therefore, they have their set of advantages and disadvantages.

One such implementation is Temporal Role Based Access Control [12] (TRBAC) which implements RBAC for organizations where work/shift timings of resources are considered. For example, in a typical healthcare facility, nurses and intern doctors should be able to carry out the tasks meant to be performed by the doctors on night duty or shifts. Similarly, their access should be made unauthorized beyond the shift intervals. This process demands to enable or disable the accesses of the junior roles by some authorized personnel each time the shift changes or upon request by the senior oﬃcials.

Another model based on RBAC proposed is related in the context of the location of the user. This is referred to as Spatial Role-based access control [20] (SRBAC). If a doctor wants to access some patient record, which he must access in his/her cabin, then the doctor must refrain from using any mobile devices in public places. This requires the access model to be able to locate the user and allow required access to the system.

There is another model which is integrated into RBAC and allows the system to grant access to unauthorized users in a controlled manner. This was termed as

Break the glass [17] (BTG). This model is similar to the method adopted by us. It can handle emergency situations like our proposed model, but it requires a separate RBAC system to be built for unauthorized roles, which makes the entire implementation an

9 expensive and time-consuming approach.

By comparing these access control systems, we conclude that adoption of an isolated system as suggested by us is quite simple, inexpensive, eﬃcient and easily maintainable. The rules created for isolated system are provided by the organization, and they can be implemented without much hassle. The unauthorized users would be redirected to the isolated system always, thereby, maintaining the security of the system. Also, there would not be any timing constraints related to system access, resulting in eﬃcient access to resources at all times. The I-RBAC system can be implemented as a layer over the existing RBAC model as explained in this paper.

Therefore, on the one hand, it is easy to implement, and on the other hand, it is as secure. It takes care of system availability, eﬃciency, and integrity at all times.

1.5 Research objective and contributions

The primary objective of this dissertation is to exploit the features oﬀered by

Transaction Isolation concepts in RDBMS into Role Based Access Control deployed in an organization. While RBAC allows for secure access to a system in an organization, integrating it with transaction isolation concepts in RDBMS would make sure that the system is available to unauthorized users in times of emergency and critical scenarios.

There have been various types of RBAC implementation, but each suits a diﬀerent scenario with related costs involved and its set of advantages and disadvantages. We compare our idea with those applications and found that it could be quite straight- forward and inexpensive way to add an isolated layer over the existing RBAC layer.

We simply need to incorporate isolation execution functionality and deﬁne the isolation system policies for the application. The implementation of our model would not require any duplication of the existing system or begin from scratch.

As it would be explained in the System Design and Implementation chapters,

10 one can evaluate the simplicity of our application. This would signiﬁcantly reduce the investment in implementing our model. Also, this model would help in ensuring system availability at all times for all the users, simultaneously providing integrity and security to the system. The main advantage would be saving time and money in building a separate RBAC system for training of roles or access decisions based on time and location.

1.6 Dissertation Outline

The dissertation chapters are organized as follows:

In Chapter 1, we discussed introduction, background, and motivation of the thesis work. We reviewed literature, presented research objectives along with the organization of diﬀerent chapters.

Chapter 2 provides a detailed overview of Isolation Enabled Role-Based Access

Control system and how we plan to design and implement it.

In Chapter 3, we present the system design for proposed approach of implementing

Isolation-enabled RBAC.

Chapter 4 outlines System Implementation for the proposed Isolation-enabled

RBAC.

Chapter 5 provides limitations of our approach in a concise manner and then concludes our dissertation, oﬀering insights into the approach followed by us and future enhancements.

11 Chapter 2

Isolation enabled Role Based

Access Control

This chapter explains the Isolation-enabled RBAC model proposed by us. We describe the model which extends NIST RBAC model [29], [31] by adding an Iso- lation Environment over the Host environment (RBAC layer). Also, we explain the implementation of such an isolated system in a typical health-care system.

2.1 Deﬁnition of Isolated environment

The Isolation environment can be described as a closed environment which is separate than the host environment and activities/operations performed within the isolated system does not aﬀect the host system under any circumstance [23]. It is a layer over the host system and behaves similar to it, providing a working interface to the unauthorized users in the system. It handles the requests of the unauthorized users as if they have access to the host system itself. The advantage of such a system is that the possibilities of errors and mistakes caused by unauthorized users are diminished and therefore increases system-level security [21] [22]. The design and implementation of such a system are realized in later chapters where the deﬁnition

12 can be understood more clearly.

Fig. 2-1 shows the process ﬂowchart for the I-RBAC model proposed by us [18].

The Application Service could be a user login system which allows a user to login to the host or isolated system depending on the authorization rules. The Authentication

Service would validate the user credentials based on the details entered. In the case

of an authorized user, it gets access to the host system and performs operations on

the object based on his/her access level and rights assigned to the user on the objects.

If the user is unauthorized (based on its role) then automatically the role, operation,

and object are passed to the I-Policies check. The system veriﬁes whether the user

is allowed access to the isolated system, based on the policy checks in the isolated

environment. The I-Policies check would have these conditions deﬁned already while

designing the system. If the conditional checks are satisﬁed, then the user is allowed

to perform required operations on the isolated object(s). Once the session comes to

an end, a Security Check on Accumulated Modiﬁcations, would display any conﬂicts

in the consistency of the system after changes performed in the system. However, if

the I-Policies check does not satisfy the user, he/she is denied access to the system.

As it happens in a typical access control model, we assume that the access per-

missions are known in advance and rules have been set up correctly in the isolation

environment as well. For the formal deﬁnition of I-RBAC model, we add the following

elements to the NIST RBAC deﬁnition:

• Isolated Role (IR) is a package of permissions which could be executed in the

isolation environment. These roles are assigned to the user who has been denied

access to the host environment. For example, we have taken an intern doctor

as an unauthorized role and created policies accordingly. An intern doctor who

does not have any access in the host environment would be able to access the

isolated system based on policies designed for the isolated system.

13 Figure 2-1: I-RBAC process ﬂow-chart [18]

• Isolation value (I) is either true or false. Only the operation by the role whose

isolation value is true is allowed access to the isolation environment.

• Isolation Policies (I-POLICIES) are conditions that are to be satisﬁed by the

role to enter into the isolation environment. The condition can be either the

role to be isolated or a particular operation of the role to be isolated. The

role, permission and object combination are set to either ‘Y’ or ‘N’ for allowing

access.

In this new model we assume that IR, I and I-POLICIES are predeﬁned based

14 on the requirements of the organization. The operation on the object is executed in

isolation if either of the following two conditions is satisﬁed:

• If role belongs to a set of Isolated Roles, then all the operations by that role

would be executed in isolation environment, for example: an intern doctor in

our case, or

• If Isolation value for the operation requested by the role is true, then the oper-

ation by the role is executed in isolation environment.

When the user accessing the isolation environment decides to end the session, a security check on the accumulated modifications is performed. This is a mandatory step for all the activities performed in the isolated system. If the checks are not satisfied, then another session is started notifying the user about it. There are various conditions specified as a part of security checks which varies according to the needs of the organization. For example, a security check could be performed which checks whether the record inserted by the intern has required consistency within the system regarding data-types of the fields and so it could be pushed to the host system after the doctor approves it. This is similar to performing Quality Checks after data loading

in an enterprise database. Also, an intern cannot delete the record in the system; the

system should soft-delete it, meaning the ﬁeld “Is Deleted” to be rendered “1” in the

case of expected deleted records.

An example of an RBAC system representing RBAC Policy containing Roles,

Permissions, Objects, and authorization could be shown in Fig. 2-2. The values

of attributes have been taken for a health-care facility, and common permissions

have been shown for the users accessing the system. The “Is Authorized” ﬁeld sets

the authorization over Role, Permission and Object combination. The value ‘Y’

would allow the user to access the host system while ‘N’ would further allow checking

the I-Policies. The I-Policies table is similar to the RBAC Policy and has rules for

15 unauthorized accesses. In a typical setup of such an access system, we assume that the access permissions are known in advance. While designing the system the organization describes the roles, permissions and related accesses to the system’s objects. They are then implemented into the system as-is. The concept of isolation also follows the same path. We gather information for unauthorized accesses: roles, permissions, objects, and build the I-Policies check table accordingly.

Figure 2-2: A typical RBAC policy table

16 2.2 Implementation of Isolated system in a Health-

care facility

2.2.1 Purpose of using Isolated System

Considering a typical health-care facility, we encounter several scenarios where

RBAC would not support expected functionalities. For example, in the absence of a doctor, an intern cannot add/modify details of a patient in the system because of limited access to resources. This could lead to panic situations in case of emergencies where access to a patient’s record is critical. While entering details into the system for a patient, the intern could make mistakes and errors, which if not checked and veriﬁed by the doctor, could lead to incorrect data being stored for the patients. This could cost the hospital its reputation and also a loss to patients as well. Employees at diﬀerent department need patient’s data to evaluate certain medical conditions, if they do not have proper access to data due to the access control mechanism in place, that could severely delay due processes and could lead to the unwanted situation.

A health-care system could be categorized as a critical security system; other such systems could be a nuclear power plant, air and rail traﬃc control systems, and banking systems which allow millions of transactions on a single day. Therefore, when we discuss access control mechanism for these systems, we should be giving much thought and importance to the system design and making it secure so that only authorized access is allowed into the system. In that regard, a healthcare system should be secure enough to allow only the authorized users to access the vast amount of information for a patient, but at the same time ensure best possible care for patients and information is available to appropriate medical personnel across departments and clinics. So, when the situation of doubt occurs, the system should allow unauthorized users to have access to the information of a patient who is undergoing care in a facility,

17 unlike in other security-critical systems which usually blocks the access even in case of slight doubt.

Looking at a healthcare system which handles patients with various medical conditions required to be diagnosed at diﬀerent departments, requires an access control mechanism which can transfer information among each of these departments without error and securely. A strictly implemented RBAC in such a scenario would be tough to manage, as the access to information would be according to a role, and it severely restricts inter-departmental access to the same patient’s record while the record itself undergoes a transformation with every transaction.

Summarizing the points mentioned above, we conclude that a typical access control mechanism cannot handle different scenarios altogether and would require a different approach to resolve such issues which would otherwise be tough to manage. In the case of isolated environment offered to such an access control system allows medical personnel to handle patient’s information in different scenarios in a way that it does not affect the host system at all. Also, we offer to add roles, permissions, and objects according to the requirements in different departments and providing accesses to the users and roles as per their need. This approach makes sure that information is available to end user in case of emergency situations irrespective of their department and also makes it secure enough not to indulge the host system data.

2.2.2 Proposed Isolated system

We have explained the detailed design and implementation of the Isolated system in a Health-care facility in the upcoming chapters. For a basic understanding, we have considered a Doctor and an Intern as two roles, with permissions such as View,

Create, Edit and Delete objects/resources such as Prescription Files in the Host and

Isolated system. We deﬁne the I-Policies and RBAC Policies which diﬀerentiates the two type of roles according to the access granted to them. For example, in absence

18 of a doctor, an intern can edit a prescription ﬁle in the Isolated system, which upon

veriﬁcation and approval by the doctor would be pushed to Host system. An intern

would not have edit access for the same ﬁle in Host system. While the intern is

logged into the Isolated system, he would have all the required information for a

patient similar to the Host system. According to the access granted to him, he can

add/modify information for that patient and commit the changes. He/she basically

takes up the role of the doctor in his absence and perform the required operations.

In any case, if the I-Policies are violated, a “Permission Denied” message is sent to

the user.

Basic tables used for implementation of I-RBAC are Roles, Permissions, Objects,

and IRBAC Policy. We have considered Roles such as “Doctor”, “Intern Doctor” and

“Pharmacist” in the system as shown in Fig. 2-3. While the doctor is a senior role having access to all objects in the system, the intern would be unauthorized for those set of objects.

The Permissions table would be established to show necessary permissions - “View”,

“Create”, “Edit” and “Delete” on the objects present in the system as shown in Fig.

2-4. The objects taken for implementation purpose are shown in Fig. 2-5. We have taken “Electronic Patient Record” and “Prescription File” as two objects for understanding the concept of isolation.

The I-RBAC policy table would set the role-permission-object authorization for

the unauthorized users accessing the isolated system as depicted in Fig. 2-6. The

policy table sets the rule such as a particular role having a certain permission set on

a speciﬁc object. If we observe this table, we can see that the intern does not have

right to delete a record even in the isolated system. As mentioned earlier, we propose

to soft-delete the records, so if the intern has to delete a record, the system would

internally maintain such a feature where the records are not completely lost from the

system. This has been taken care of by PHP-Mysqli scripting in the backend.

19 Figure 2-3: Role table

Figure 2-4: Permissions table

Figure 2-5: Objects table

Figure 2-6: I-RBAC Policy table

20 We have used PHP [4] for server side scripting and creating webpages for realization of a medical/health-care facility. Basic HTML and CSS have been used for webpage markup and structuring the webpages as per the content in them. MariaDB

[2], an open source variant of MySQL [3] has been used as database for the system. It has been used primarily because of it being easy to use, inexpensive and an industry standard RDBMS. Also, since it supports role creation in real time environment as per requirements, it makes the work of senior role easy when he/she tries to create junior roles and assign required permissions to them. Using PHP and Mysqli scripting

[5] for most part of coding the system, we have created php pages which differentiates the functionalities offered by our system in terms of Host and Isolated system. The aim has been to keep the system as simple as possible, so object oriented features has been used extensively, that facilitates code reuse, recycling, addition and removal of different components of the code as well. We have proposed, designed and implemented a generic solution and it can be applied to any available online health-care systems.

21 Chapter 3

System Design

The system that we are proposing would use RBAC layer, i.e. Host system, and an isolated layer over it, which is a copy of Host system, for allowing access to the unauthorized users [18]. The Host system could be deﬁned as the production environment of an organization which is accessed by the users and customers, to read and write information as required based on the access rights granted to them. The

Isolated system is like the Host system in terms of design and concept. Some of the diﬀerences being - the addition of attributes to the objects (database tables in our case) that diﬀerentiates both the systems, access policy checks/rules, i.e. authorization rules that distinguish the access to Host and Isolated system, control dependency of refreshing the Host system as and when required, etc. The system design consists of designing the front and back end of the proposed application. While it has been our goal to keep the overall design as simple as possible, implementing all the proposed features have been a priority for us.

We have taken a health-care facility as an example of our implementation, where a doctor is designated as a senior role, which has required access to all objects in the

Host system. And an intern doctor is a junior role, who has no or limited access to any object in the Host system [19]. Therefore, an intern doctor is granted access to the isolated system to perform required operations in the absence of the doctor. The

22 records created/manipulated by him/her have to go through security checks in the isolated system itself before they are reviewed by the doctor. Once reviewed by the doctor, the host system is refreshed with the new/modiﬁed records in the isolated system.

While the isolated system oﬀers an alternate approach to access the system, pre- serving the security of data is our primary goal. An intern is not able to manipulate host system records, he/she would be automatically redirected to the isolated system once he/she logs into the system as shown in Fig 3-1.

Figure 3-1: System Design Flow Chart

For the intern, roles and permissions on objects are limited to the isolated system only. We have added certain attributes to the custom tables for the patient record, prescription ﬁle, medication report, etc. in the database. These attributes are used to track diﬀerent operations in the isolated environment. The attributes are: “Record

Create Date”, “Record Last Update Date”, “Record Updated By User”, “Record Ver- sion Number” and “Active Indicator”. They are created alongside other attributes of custom tables and are populated according to the logic of addition/modiﬁcation

23 of records in the isolated system. Therefore, using them, we can track who/when created/modified a particular record in the isolated system. Also, if a patient record is undergoing changes multiple times, the highest version number of the record and a non-zero active indicator would tell us the most recent record. This also gives us a history of events associated with a particular record, e.g. editing certain fields to update by more than one intern. The security check is performed after addition/modification of records in the isolated system, which makes sure that accurately accumulated changes have been done in the system.

To capture database transactions capability in Isolation, when multiple users/sessions are trying to access the same table, we created two sessions and performed different types of transaction isolation in a relational database. For example, taking the default transaction isolation of “Repeatable Read” in MySQL, we observed that the second session could view the record of the first session only after the commit operation is performed by the first session, i.e. these two sessions would not be able to see the others changes. From the implementation perspective, if two interns are trying to access the same record, it would be “copy on write” for them, and future accesses would be redirected to this isolated copy for a consistent view. A copy of the record from host system would be created in the isolated system if it does not exist already, and this would be available for modifications by the intern. If there is more than one record in the isolated system for a given patient, then the most recent record would be fetched for the intern to work upon.

From a sound system design perspective, we have decided to go ahead with the creation of individual/separate scripts for diﬀerent operations such as Add, View,

Create and Delete objects from the system. These scripts should handle re-direction from requests made by the end-user in the system, for example: if an intern wants to create a prescription ﬁle for a patient, then the request should invoke create ﬁle script in the system. This maintains the object-oriented feature of the system and

24 any modiﬁcation needed in the logic for prescription ﬁle creation should be done in this script only. Similarly, there would be separate scripts to accept user login and implement security check features in the system. This has been done keeping in mind resolving error(s) if any, and easy debugging at the script level. Also, it facilitates implementing security features according to the operations being performed for objects.

So on one hand if delete record script would perform a soft-delete operation on the selected records, we can apply a security check that “Is deleted” should be updated for that record with value ‘1’ and the record is not removed from the system. And on the other hand, the add/edit record script would make sure that strings and date in the correct format are accepted to be included in the system.

3.1 Design Steps

The following steps were followed to design the proposed I-RBAC system:

3.1.1 Design a basic RBAC model

Design a basic level RBAC model which allows users (medical personnel) to view, edit, add and delete records in the system as per the permission assigned to their roles on diﬀerent objects.

• Create tables for USERS, ROLES, PERMISSIONS and OBJECTS.

• Using the USERS and ROLES tables, create USER ASSIGNMENT table. This

table assigns roles to users. When a new user needs to be added into the system,

he needs to be added into the USERS table. The USER ASSIGNMENT could

be updated with the role assigned to the user.

• Using the ROLE, PERMISSION and OBJECT tables to create PERMISSION

ASSIGNMENT table. The level of access granted to a role is deﬁned here. For

25 example: An intern has Read/View access to an electronic patient record and

no access to patients insurance information.

• Create RBAC Policy table to deﬁne authorization of users through Role, Per-

mission and Object combination. For example: An intern is authorized to

Read/View electronic patient record, but he/she is not authorized to delete the

record for a patient.

• Create custom tables for the electronic patient record and prescription ﬁle to

realize the basic implementation of the Isolation concepts.

3.1.2 Design Isolated system layer

Design Isolated system layer in conjunction with the RBAC layer that allows restricted access as per policy described in the Isolated system.

• Create a table for I-RBAC login, deﬁne user credentials having access to the

isolated environment.

• Create I-RBAC Policy table to deﬁne authorization of users through Role, Per-

mission and Object combination. For example: An intern is authorized to view,

edit, create an electronic patient record, but he/she is not authorized to delete

the record for a patient.

• Create the Isolated version/copy of the Host custom tables - electronic patient

record and prescription ﬁle, to copy the records to and from Host environment

before/after modiﬁcations.

3.1.3 Deﬁne Isolated system attributes

Define attributes and scenarios in the Isolated system which would differentiate the two environments and would be used to enter, update and retrieve records as per 26 different scenarios.

• While creating/replicating the custom tables, add the attributes - Record Load

Date, Record Last Updated Date, Record Version Number, Active Indicator and

Updated By (User) to the tables. These attributes would diﬀerentiate both the

environments. This has been explained in details in the System Implementation

section.

• These would be used to maintain and retrieve records from the isolated system.

For example: two interns can edit the same prescription ﬁle record and these

two records would be stored in the Isolated System. Fig. 3-2 shows two users

working on the same record in the Isolated System, followed by security checks

performed by Host user before the records are merged to Host System.

Figure 3-2: Isolated and Host Users handling records at Isolated and Host System

27 The Isolated users can retrieve the records for further set of operations and each

time they access the record, they would be redirected to the isolated copy of

the record created by them.

3.1.4 Design scripts for handling records in both environ-

ments

Design separate scripts to handle diﬀerent operations to be performed in both the

environments - Host and Isolated. These scripts should be invoked once the user has

been granted access to the system and he can choose the required operations to be

performed on the objects. Fig. 3-3 shows a basic ﬂow of scripts being invoked by

the users in two environments. For example: an intern chooses to view prescription

ﬁle for a patient in the isolated system, then the View Record Script in the isolated system should redirect the intern to appropriate page containing the patient’s record he wants to view. These required scripts to handle operations and object combination can be explained more as shown here:

Figure 3-3: Scripts invocation and handling in both the environments

• View Record Script - Script to handle viewing of records in Host and Isolated

systems. The “record” could be Prescription File or Electronic Patient Record,

28 depending on the selection by the end user. For realizing the basic isolation

features, we have taken the prescription ﬁle of a patient as the object extensively.

• Add Record Script - Script to add/insert records into the system (Host and

Isolated). While adding records into the isolated system we have incorporated

the logic of adding isolated system attributes (explained earlier) which would

diﬀerentiate the records in the two environments.

• Edit Record Script - Script to edit/update records in the system. This would

ﬁrst call the View Record Script to view the patient record and show it to the

end user, who then updates the required ﬁeld(s). In the case of the isolated

system, the active record having highest version number would be selected and

presented to the end user for edit purposes.

• Delete Record Script - Script to delete records from the system. In Isolated

system we propose to soft-delete the record (updating the “Is deleted” ﬁeld

to “1”) instead of completely removing the record, so that there is no loss of

information for any patient.

• User Login Script - Script to handle user login into the system and redirect

users to next page.

• Miscellaneous Scripts - Scripts to perform policy and security checks after the

system has been modiﬁed in the isolated environment.

All the scripts as mentioned above need to be created in PHP using the Mysqli feature to connect with database and carry out the required operation. For example, the View Record Script would involve PHP and Mysqli to connect to the database and then query it for the patient’s record taken as input from the end-user.

29 3.1.5 Post Isolated system changes

Refresh the Host system with the modiﬁcations performed in the isolated system after getting them approved by the authorized personnel/user.

• The system would perform post policy checks and security checks on the modi-

ﬁed records and validate them at the database level, based on the rules deﬁned

for the records. For example, an intern can delete only the prescription ﬁle which

was created by him/her. Create a table for performing quality checks on the

records modiﬁed by the user. The table should have rules in the form of SQLs,

which should run against the modiﬁed records once the user has completed the

changes and performed commit operation.

• The modiﬁcations performed in the isolated system by the intern would be

pushed to the Host system after veriﬁcations and validations by the senior

employee. Create a window on the login page of the host system which should

show the modiﬁed records to be veriﬁed and validated by the senior resource

after he/she logs into the host system. At the back-end of the application, a

query should run and fetch all those records which need to be approved.

30 Chapter 4

System Implementation

The implementation of the overall system consists of creating the Host and Isolated system for RBAC and I-RBAC systems. We have created both the systems on a Linux machine and displayed as web pages instead of a standalone application. The front end is a simplified version of a conventional health-care information system where a user can login using his credentials and choose required actions to be performed. The back-end is a database which executes the queries accordingly. The interactive web pages have been created using PHP-HTML-CSS and scripting to connect and perform operations on a database have been done using PHP-MySQLi constructs. For the realization of RBAC and I-RBAC system implementation, we propose to create both the systems under one database only, i.e. different tables of the two systems would be created in the same database, and the Isolated System tables would be prefixed with

Isolation System parameter. So, if PRESCRIPTION FILE table holds information of patient’s prescription ﬁles in Host System, then I PRESCRIPTION FILE would contain the data of the same patient in Isolated System. We have used Program- ming Language PHP for server side scripting (HTML used for markup and client-side scripting). The database used is MariaDB (an open source variant of MySQL).

The scripts created for diﬀerent activities in the system have been created and uploaded to the server (/var/www/html/) on Linux machine. Separate directories

31 created for Host and Isolated systems, to have scripts perform speciﬁc tasks in these systems.

4.1 Database Level Implementation

As mentioned in the System Design section, tables created for the realization of

RBAC system are shown in Fig. 4-1. Tables created in the Host System has been shown on the left side, in a rectangle, while tables speciﬁcally for Isolated System are shown in oval outline. The diﬀerent tables used to support Users, Roles, Permis- sions, Objects, User Assignment, Permission Assignment and other system tables are described as follows:

Figure 4-1: Sample tables comprising the Host and Isolated system

• USER LOGIN - Holds login information of all users (username and password).

• USER RBAC - Extended version of Login table which holds information such

32 as Last Name, First Name, and Address, etc.

• ROLE RBAC - Consists of Roles and Role Description, currently we have taken

Doctor and Intern Doctor as two roles.

• PERMISSION RBAC - Consists of Permissions and its description, currently

we have taken View, Edit, Create and Delete as permissions.

• OBJECTS - Holds information of diﬀerent objects available to the user, such

as Prescription ﬁle and Patient Record.

• USER ASSIGNMENT - Holds information of mapping of Users and their re-

spective Roles.

• PERMISSION ASSIGNMENT - Holds information of Roles and related per-

missions on the objects assigned to the roles.

• RBAC POLICY - This table would deﬁne rules for users to be authorized/unauthorized

to access the RBAC system and access to the OBJECTS.

• IRBAC LOGIN - The login information present for users who are deﬁned as

isolated users, intern doctors in our case.

• IRBAC POLICY - The rules for users in the isolated system deﬁned in this

table.

• PRESCRIPTION FILE - An organization speciﬁc table containing information

for patients prescription ﬁles in our case.

• I PRESCRIPTION FILE - The version of patient’s prescription ﬁle contained

in the Isolated System.

33 As mentioned in the System Design section, in addition to the ﬁelds in the Host

environment table (for example: PRESCRIPTION FILE), a few new ﬁelds would be

added when the same table is copied/cloned in the Isolated System.

• RCRD LOAD DATE - A date ﬁeld. Whenever a record is inserted into the

Isolated System, this ﬁeld would take the current date and time for that record

in the isolated system.

• RCRD LAST UPDATED - An auto generated date-time ﬁeld. Whenever any

user updates a record in the Isolated System, this ﬁeld would get updated for

that record.

• RCRD VRSN NUM - A SMALLINT ﬁeld. As the user performs any update

on existing record, a version number would be assigned to it, which would be

assigned in an incremental fashion. Initially all records copied from Host table

would have a value of 1, but after a particular record gets updated, the version

number for that record increases by 1.

• ACTV IND - A TINYINT ﬁeld. The purpose is to indicate only one record as

active at a given time. As the record is updated it would have Active Indica-

tor ACTV IND = 1, and the previous version of the same record would have

ACTV IND = 0.

• RCRD UPDT BY - The identiﬁcation of the user who works on the particular

record, this would be used while retrieving the record for each user.

Once the unauthorized user logs into the system, he/she is redirected to the Iso- lated System. In our case, we have taken “Intern Doctor” as an unauthorized role.

The web page displays the User’s Role, his/her authorized (access to Host system) and unauthorized (access to Isolated System) access/permissions on the objects and records on the right side of the screen depicting the records created/modiﬁed in the 34 Isolated System. Fig. 4-2 displays results for one such intern doctor. For this user,

there are no authorized roles and permissions, and he/she can perform his/her oper-

ations in the Isolated System.

Figure 4-2: Snapshot of an unauthorized user logged into Isolated System

After the unauthorized user (intern in our case) completes his work in the isolated environment, his changes are marked for approval, rejection or further review by the senior resource (doctor in our case), before the host system is refreshed with the modiﬁed records. Fig. 4-3 shows how the interface would display those records (in red colored rectangle) to the doctor after he logs into the system. The “Approve”,

“Reject” and “Review” options are links to respective web pages, which on being clicked/selected would redirect the doctor to take appropriate decisions after selection.

This largely constitutes the policy checks on accumulated modiﬁcations in the isolated system.

35 Figure 4-3: Records to be approved, rejected or further reviewed

4.2 Logic of data ﬂow

The logic for the operations to be performed and the considerations for an object

such as a Prescription ﬁle, in the Isolated System could be summarized as below:

• The Host environment would have only one record for a patient that is the

source of truth for both the environments.

• The Isolated environment can have more than one record; it depends on the

number of times it has been modiﬁed by the unauthorized users.

The conditions for viewing the prescription ﬁle for any operation to be performed by the intern in the Isolated System:

• Condition 1 : The ﬁle is in Isolated, but not in Host, which means it was created

by the Intern Doctor (unauthorized role) and now it needs to be approved and

36 pushed to Host by the Doctor.

• Condition 2 : The ﬁle is in Host but not in Isolated, which means it needs to be

copied to the Isolated system from Host and the Intern would perform required

operations on it.

• Condition 3 : Only one copy of the ﬁle is present in both the environments,

ideally they both should be the same. When the user accesses the ﬁle, he/she

should be directed to the isolated record and he/she is required to make any

changes as per requirements.

• Condition 4 : One copy of the ﬁle is in Host and multiple copies of that ﬁle are

in Isolated, i.e. the ﬁle has undergone changes several times by diﬀerent users

at diﬀerent times. Therefore, the most recent and active record in the Isolated

System would be shown to the intern for any operations to be performed.

Algorithm 1: Above conditions for a particular record: Variables deﬁned: Count Host=CountOf(record in Host) Count Isolated=CountOf(record in Isolated) begin if Count Host > 0 then if Count Isolated == 0 then INSERT RECORD FROM HOST TO ISOLATED if Count Isolated == 1 then SELECT RECORD FROM ISOLATED if Count Isolated > 1 then SELECT ALL RECORDS FROM ISOLATED ORDER BY CREATED DT DESC OR APPROPRIATE ISOLATED CONDITIONS else if Count Host == 0 then if Count Isolated == 0 then Print “No records for the patient available in the system” if Count Isolated >= 1 then INSERT RECORD FROM ISOLATED TO HOST AFTER SECURITY CHECK AND APPROVAL

37 Table 4.1: Attributes in Isolated System Load Date = SYSDATE Last Updated Date = SYSDATE Record Version Number = 1 Active Indicator = 1 Updated By = CURRENT USER

Table 4.2: Old vs New attribute values for record in Isolated System Old record New Record Load Date = No change Load Date = SYSDATE (copied from old record) Last Updated Date = SYSDATE Last Updated Date = SYSDATE (new) Record Version Number = 1 Record Version Number = 2 Active Indicator = 0 Active Indicator = 1 Record Updated By User = CUR- Record Updated By User = CUR- RENT USER RENT USER

Note: The above mentioned conditions for retrieving records from Isolated Sys- tem are applied while copying the record from Host to Isolated and updating the records in Isolated System as well.

When a user copies a record from Host or retrieves a record in Isolated System to update, initially the Isolated System speciﬁc attributes for the record are as shown in Table 4.1. In the Isolated System, when the record is retrieved for any update, the attribute values for the old and new record are as shown in Table 4.2. At any given time, the parameters in Table 4.3 would show the latest record to be accessed.

4.3 Realization of Isolation at database level

We have used the default transaction isolation “Repeatable Read” in MySQL for easy and eﬃcient implementation. As mentioned in MySQL documentation about

Repeatable Read: All consistent reads within the same transaction read the snapshot established by the ﬁrst such read in that transaction. To get a fresher snapshot of

38 Table 4.3: Parameters for latest record in Isolated System Last Updated Date (new record) > Last Updated Date (old record) Record Version Number (new record) > Record Version Number (old record) Active Indicator = 1

Figure 4-4: First session unable to read the record inserted by second session queries we need to commit the current transaction after issuing new queries [11]. For realization of isolation, we took diﬀerent scenarios from two session’s perspective to understand.

4.3.1 Scenario 1

When first session inserts a record into a table, the second session is able to view that record only after commit operation is performed in the first session. The first session can see the records read at the beginning of the session. If the second session inserts a record into the table, the first session is unable to read it until the sessions perform commit. This has been shown in the Fig. 4-4 and Fig. 4-5 respectively.

This scenario provides isolation to both the sessions in a way that the second

39 Figure 4-5: After commit operation, ﬁrst session can read the inserted record session is unable to view the record inserted by the ﬁrst one, since it is still not committed.

4.3.2 Scenario 2

When both the sessions are inserting records into the same table at the same time, i.e. overlapping sessions. In this case, both the sessions would be able to view the records inserted by the other session only when commit is performed in both the sessions. Individual inserts could be viewed in individual session windows, but until both the sessions perform a commit, the database is not in a consistent state. Only after both the sessions commit, they would be able to see the newly inserted records.

The operations have been shown in Fig. 4-6 and Fig. 4-7 respectively.

This scenario depicts the situation when multiple interns are adding records into the same table, isolation system ensures that they are not able to view the records inserted by the other, until they all have committed and queried the system for all patients information in a table.

40 Figure 4-6: Individual inserts in two sessions can be read in respective sessions only

Figure 4-7: After commit, both sessions can read the committed records

41 Figure 4-8: Second session trying to update the same record is in locked state

4.3.3 Scenario 3

When both the sessions perform an Update operation on the same record: In this case, if the transaction is aﬀecting the same rows then those rows/records get locked.

When the first session performs update on a record, the second session is in locked state until the first session commits that update. As soon as first session commits the transaction, the update operation in the second session gets performed. Fig. 4-8 and Fig. 4-9 depicts this situation.

The transactions get queued up at this point, the order of execution follows the sequence or serialization order, in order of occurrence/changes performed. Until the lock is released, the commands have to wait - type of FIFO operation.

Only after both the sessions commit, one can view a consistent state of the database as shown in Fig. 4-10.

We tested remaining Isolation transactions levels available in MySQL - Read Com- mitted, Read Uncommitted, Serializable - at the session and server levels, to completely understand their functioning and eﬃciency. We observed and calculated that

“Repeatable Read” isolation at both session and server level is best suited to our 42 Figure 4-9: Session 1 commits, so session 2’s statement gets executed, but the overall state of database is inconsistent

Figure 4-10: Consistent state of database after both sessions commit

43 proposed design. If many users are accessing the system simultaneously, we do not want the risk of them being blocked due to a lock caused by a transaction writing to a table. And at the same time we want database performance to be good. While we want data concurrency in the system, we want data to be consistent as well. Consid- ering all this, we decided to go ahead with the optimized method of repeatable read in our proposed system.

44 Chapter 5

Future Work and Conclusion

5.1 Future Works

As we are dealing with a database system for the implementation of our model, there are a few related limitations of this approach. When the model is deployed for a large-scale organization which has many users, say in millions, then such a system gets tough to manage. Though the database is capable of handling multiple transactions at the same time, sometime it may be diﬃcult to handle complicated scenarios. Such scenarios could be related to database server, handling locks on data during multiple simultaneous transactions, infrastructure or network related issues.

We have not tested our approach for such large scale user database in any of these categories. While the Isolated System keeps on growing day after day, it would be necessary to archive or purge the historic data on regular intervals. Since, we would be interested in keeping history, the database architect should consider the options carefully while designing such a system.

Even in a simple implementation involving a few million records in the isolated system, it becomes necessary to index the tables, gather statistics, create and query views rather than underlying tables, and tune complex queries for report generation.

All these tasks demand proper steps to be taken while designing the software itself.

45 The data architect should give proper attention to detail of each of the subject tables and its integrity with other tables in the system.

5.2 Conclusion

In this paper, we have suggested an alternate approach to understand and implement RBAC policies. The model proposed by us integrates and implements the isolation principles of database into RBAC model at record level and allows access to unauthorized user to objects in Isolated System. The changes performed by the unauthorized user in Isolated System are posted to the Host System only after they undergo Security Policy Checks and is approved by the authorized user or a senior official in the organization. We incorporate several attributes which are specific to the Isolated System for identification of records. In addition, we identified different scenarios of performing database operations on the records in Isolated System. The transaction capability of database in isolation ensures secure and efficient handling of data in the Isolated System. The method proposed by us strives to resolve the access related issues faced in adopting other implementations of RBAC. The implementation results in robust and efficient system which provides data security in the Host as well as the Isolated System. We have published our research in [25].

46 References

[1] An Introduction to Role-Based Access Control NIST/ITL Bulletin. http://

csrc.nist.gov/rbac/NIST-ITL-RBAC-bulletin.html Accessed July 13, 2017.

[2] MariaDB database. https://mariadb.org/ Accessed July 13, 2017.

[3] MySQL database. https://www.mysql.com/products/enterprise/database/ Accessed July 13, 2017.

[4] PHP Manual. http://php.net/manual/en/intro-whatis.php Accessed July 13, 2017.

[5] PHP MySQLi. http://php.net/manual/en/book.mysqli.php Accessed July 13, 2017.

[6] Read Committed. https://mariadb.com/kb/en/sql-99/read-committed/ Accessed July 7, 2017.

[7] Read Uncommitted. https://mariadb.com/kb/en/sql-99/

read-uncommitted/ Accessed July 7, 2017.

[8] Repeatable Read. https://mariadb.com/kb/en/sql-99/repeatable-read/ Accessed July 7, 2017.

[9] Serializable. https://mariadb.com/kb/en/sql-99/serializable/ Accessed July 7, 2017.

47 [10] Transaction Isolation Levels - Microsoft Docs. https://docs.microsoft.com/

en-us/sql/odbc/reference/develop-app/transaction-isolation-levels Accessed June 10, 2017.

[11] Transaction Isolation Levels - MySQL InnoDB. https://dev.mysql.com/doc/

refman/5.7/en/innodb-transaction-isolation-levels.html Accessed May 12, 2017.

[12] Elisa Bertino, Piero Andrea Bonatti, and Elena Ferrari. TRBAC: A Temporal

Role-based Access Control Model. ACM Trans. Inf. Syst. Secur., 4(3):191–233,

August 2001.

[13] David D Clark and David R Wilson. A comparison of commercial and military

computer security policies. In Security and Privacy, 1987 IEEE Symposium on,

pages 184–184. IEEE, 1987.

[14] E. Coyne and T. R. Weil. ABAC and RBAC: Scalable, Flexible, and Auditable

Access Management. IT Professional, 15(3):14–16, May 2013.

[15] Stephen Dranger, Robert H Sloan, and Jon A Solworth. The complexity of

discretionary access control. In International Workshop on Security, pages 405–

420. Springer, 2006.

[16] David F. Ferraiolo, Ravi Sandhu, Serban Gavrila, D. Richard Kuhn, and Ra-

maswamy Chandramouli. Proposed NIST Standard for Role-based Access Con-

trol. ACM Trans. Inf. Syst. Secur., 4(3):224–274, August 2001.

[17] A. Ferreira, D. Chadwick, P. Farinha, R. Correia, G. Zao, R. Chilro, and L. An-

tunes. How to Securely Break into RBAC: The BTG-RBAC Model. In 2009

Annual Computer Security Applications Conference, pages 23–31, Dec 2009.

48 [18] N. Gunti, W. Sun, and M. Niamat. I-RBAC: Isolation Enabled Role-based Access

Control. In 2011 Ninth Annual International Conference on Privacy, Security

and Trust, pages 79–86, July 2011.

[19] Nagajyothi Gunti, Weiqing Sun, Mingzhe Xu, Zidong Liu, Mohammed Niamat,

and Mansoor Alam. A Healthcare Information System with Augmented Access

Controls, pages 792–795. Springer Berlin Heidelberg, Berlin, Heidelberg, 2012.

[20] F. Hansen and V. Oleshchuk. Spatial Role-based Access Control Model for

Wireless Networks. In 2003 IEEE 58th Vehicular Technology Conference. VTC

2003-Fall (IEEE Cat. No.03CH37484), volume 3, pages 2093–2097 Vol.3, Oct

2003.

[21] Sushil Jajodia, Peng Liu, and Catherine D McCollum. Application-level Isola-

tion to cope with malicious database users. In Computer Security Applications

Conference, 1998. Proceedings. 14th Annual, pages 73–82. IEEE, 1998.

[22] Zhenkai Liang, Weiqing Sun, VN Venkatakrishnan, and R Sekar. Alcatraz: An

isolated environment for experimenting with untrusted software. ACM Transac-

tions on Information and System Security (TISSEC), 12(3):14, 2009.

[23] Peng Liu, Sushil Jajodia, and Catherine D McCollum. Intrusion conﬁnement by

isolation in information systems. Journal of Computer Security, 8(4):243–279,

2000.

[24] Terry Mayﬁeld, J Eric Roskos, Stephen R Welke, John M Boone, and Cather-

ine W McDonald. Integrity in automated information systems. Technical report,

DTIC Document, 1991.

[25] Mohammad Rahat Helal, Weiqing Sun, and Ahmad Y Javaid. Eﬃcient Isola-

tion Enabled Role-Based Access Control for Database Systems. 2017 Interna-

tional Conference on Security and Management (SAM’17), July 2017. http:// 49 csce.ucmss.com/cr/books/2017/LFS/CSREA2017/SAM9725.pdf Accessed July 25, 2017.

[26] Sylvia Osborn, Ravi Sandhu, and Qamar Munawer. Conﬁguring Role-based

Access Control to enforce Mandatory and Discretionary Access Control Policies.

ACM Transactions on Information and System Security (TISSEC), 3(2):85–106,

2000.

[27] Lillian Røstad. Access control in Healthcare Information Systems. PhD thesis,

Norwegian University of Science and Technology, 2008.

[28] Ravi Sandhu. Transaction control expressions for separation of duties. In

Aerospace Computer Security Applications Conference, 1988., Fourth, pages 282–

286. IEEE, 1988.

[29] Ravi S Sandhu, Edward J Coyne, Hal L Feinstein, and Charles E Youman. Role-

based Access Control Models. Computer, 29(2):38–47, 1996.

[30] William R Shockley. A9 IMPLEMENTING THE CLARK/WILSON IN-

TEGRITY POLICY USING CURRENT TECHNOLOGY. Computer Science

and Technology, 1(11):1, 1989.

[31] Hazen A Weber. Role-based Access Control: the NIST Solution. SANS institute

InfoSec Reading Room, 2003.