Implementing Security On a Prototype Hospital Database - CiteSeerX

Implementing Security On a Prototype Hospital Database Marie KHAIR (1), George PANGALOS (2), Foteini ANDRIA (2), Lefteris BOZIOS (3) (1) Computers Department, Faculty of Sciences, Notre Dame University, Zouk Mosbeh, PO Box 72, Zouk Mikael, Lebanon. (2) Computers Division, Faculty of Technology, General Department, Aristotle University of Thessaloniki, 540 06 Thessaloniki, Greece. (3) Information Technology Dept., AHEPA Hospital, 546 36 Thessaloniki, Greece. [email protected], [email protected], [email protected] Abstract. This paper describes the methodology used and the experience gained from the application of a new secure database design approach and database security policy in a real life hospital environment. The applicability of the proposed database security policy in a major Greek general hospital is demonstrated. Moreover, the security and quality assurance of the developed prototype secure database is examined, taking into consideration the results from the study of the user acceptance. Keywords database systems security, medical database security, secure database implementation, user acceptance study

1. Introduction A hospital is a typical case of a security critical environment. It is one of the few environments for example, in which a confidentiality breach, wrong information or even a relatively minor loss of access to information may be life-threatening. Security is therefore an important issue which encompasses all aspects of the organization, from patient and staff safety to deeply personal information about staff and patients that is distributed throughout the organization [3], [4]. Due to the widespread use of the database technology and its role and nature, database security plays today a significant role in the overall security of health care information systems [5]. The development of a secure database system requires an appropriate multiphase design methodology which will guide the steps of the development and will provide tools supporting the automatic execution of some steps [1]. Such a design methodology has been proposed in [4] and [5]. The proposed methodology and security policy helps ensure all three aspects of security (secrecy, confidentiality and availability), without introducing significant overheads. It is based on the integration of mandatory and discretionary security policies and takes security into consideration from the very first steps of the design [3],[4],[5]. In this paper we will focus on the problems related to the application of this methodology and the experience gained from its experiment implementation in a major Greek general hospital.

2. Overview of the proposed secure database design methodology

The choice of an appropriate security policy and a suitable secure database design methodology is crucial in health care environments [5]. The two most well known proposals for the database security policies are the mandatory and the discretionary ones [1]. Discretionary security policies govern the access of users to the information on the basis of the user’s identity and the rules specifying, for each user and each object in the system, the types of access the user is allowed on the object. Discretionary security policies are flexible and suitable for a variety of implementations (mainly commercial ones). However, they provide insufficient control of the information flow (e.g. they are vulnerable to malicious attacks such as the Trojan Horses). On the other hand, mandatory security policies provide a high level of certification for security, based on the use of unforgeable security labels, which are assigned both to users and data. Thus, they allow one to track the flow of information. They are however mainly suitable to certain kinds of environments where the users and the objects can be easily classified (i.e. the military one). As has been shown in [5], none of these two major policies are sufficient by itself to cover the security needs of the health care environments. Hence, it has been necessary to propose a new security policy, which has been based on the integration of mandatory and discretionary control policies ([4], [5]). In order to maximize the effectiveness and decrease the complexity of implementing this policy, a step by step design methodology with integrated security has been proposed. According to our methodology, every user role and every data item type is assigned a security label. In particular, the responsibility of the role in the application determines the security label (clearance) of the user role. The security label (classification) of the data represents its level of sensitivity [5]. The user roles are assigned a node at the user role hierarchy (URH). Then, beginning from the lower level of the hierarchy, the data items are assigned a security label equal to that of the users that must be cleared to access it. In the end, the security requirements are examined. This may lead to fragmentation of some relations and/or upgrading (since we support tuple level granularity). It must be noted that polyinstantiation - which is a characteristic of the multilevel security policy - is supported only in the form of cover stories. This is possible, due to the support of the write down mechanism (with no fear of inference), which is essential for the hospital environment. A detailed description of the proposed methodology can be found in [4] and [5].

3. Pilot Implementation of the Proposed Security Policy The AHEPA university hospital was used as a testbed for the implementation of our proposed secure database design methodology in a real life hospital environment. The AHEPA University Hospital is a general hospital (1000 beds), which is part of the Aristotelian University of Thessaloniki. There is a long-standing cooperation between the informatics laboratory and the EDP unit of the AHEPA hospital [2], [4], [5]. Following, we will describe briefly the information system of the hospital and the functions which the prototype secure hospital database SEC_AXEPA was designed to serve. 3.1. Overview of the prototype secure hospital database The integrated information system of AHEPA hospital covers the patient administration system (inpatient-outpatient), billing, financial, personal management and payroll. The system was developed mostly in-house. It has been running since 1990 and operates on an

inter network of distributed databases based on the client-server model. Users login through their terminals (or workstations) to ’clients’ (process servers) where application programs are executed. The location of stored data (two database servers connected to the backbone) is transparent to the end users. The application SEC_AXEPA has been developed in order to serve the in-patient administration purposes. This implementation will be used as a pilot for the subsequent implementation of the whole secure hospital information system. The input of patient information into the prototype secure database SEC_AXEPA begins as soon as a patient checks in the hospital (as an in-patient). Then, the following records are created: a. A record containing his/her personal information. This record is assigned the highest level of security. b. A record containing the information pertaining to the patient’s hospitalisation. This record contains among others the identification number of the patient and a patient serial number. During his/ her hospitalisation, the patient identification is based on a serial number assigned to him/her, when he/she checked in. After the above records are created, all medical treatment and the follow-up of the patient are carried out based on his/ her serial number. When a user accesses the database, a corresponding user interface is automatically presented to him/her, based on the user group where he/she belongs to (e.g. doctor or nurse). So when for example a doctor logs into the hospital database, he/she is given the following choices: to locate a certain patient, to browse the personal information of his/her patient, to insert/browse the diagnoses, to insert/browse the prescriptions, to insert/browse the lab test exams and to browse the vital signs of the patient. In order to further help the end user, every choice of a browse action offers the following subchoices: the choice of the last medical action, the choice of the medical actions between two dates and the choice of all the medical actions performed during the hospitalisation of the patient. When a nurse logs into the hospital database, he/she is given the following choices: to locate a certain patient, to browse the most recent diagnosis of a patient, to browse the most recent prescription of a patient, to browse the most recent lab-test request for a patient and to insert the vital signs of a patient. In our application, we support two user roles for the nurse group; the special nurse that is given a higher level of clearance and the normal nurse that is given a lower level of clearance. These two user roles have the same user interfaces in the application. However, a normal nurse can access only the confidential information, whereas a special nurse may also access secret information. This is made possible with the use of rules and procedures that create convenient cover stories, as it will be explained later. These rules and procedures reflect and implement the security constraints that have been defined for the specific secure application. For the better understanding of their implementation method we will describe below (section 3.3.1), first in informal and then in formal language, the processing methodology of the security constraints that have been applied to the secure prototype application SEC_AXEPA. 3.2. Implementation of the prototype secure hospital database SEC_AXEPA The prototype hospital database SEC_AXEPA was implemented on Ingres, a relational DBMS (since there was not a Trusted DBMS available). We have chosen Ingres among other reasons, because the databases on Ingres are protected from user access both by the permissions on directories containing the database files and the permissions on the database

files themselves. Users cannot look at the files in the database except through Ingres and its protection scheme; that is users cannot access the database at the operating system level. Additional binary files with special format are included, making decoding of any information more difficult. Moreover, Ingres has a built-in hierarchical security system. The database administrator (D.B.A.) controls the types of access allowed to various levels of users using this system. The security labels which were defined during the secure conceptual design phase were implemented using the notions of roles and groups supported by Ingres. As we mentioned earlier, the user roles handled in our implementation are: doctor, normal nurse, and special nurse. The notion of user roles was implemented using the notion of user groups, provided by Ingres (a group is an identifier that can be used to apply permissions to a list of Ingres users associated with the identifier). After performing a study on the considered users roles, the following clearances were assigned to them: clearance level 3 to the user role doctor, clearance level 2 to the user role special nurse, and clearance level 1 to the user role normal nurse. The data sets loaded on the prototype hospital database are: the nurse record, the doctor record, the patient record, which contains the medical information, the laboratory information, the follow-up information and the personal patient information. Being a relational database management system, Ingres stores data in tables. The labelling of the data sets was described above. However, it can change dynamically, if one of the security constraints is satisfied, leading to upgrading and/or fragmentation. The classification level of each tuple of a table was implemented by adding at each table a column. This column contained the tuple classification; that is 1,2,3 instead of confidential, secret, top secret. Zero (0) indicates that the data contained in the tuple is cover story. Of course, the tuple class data was only visible to the D.B.A. Apart from that, an additional column was added to the related medical data tables, containing the flag ‘h’ (history) or ‘l’ (last). This flag was automatically updated, when new relevant data was inserted. This is one of the integrity constraints that were implemented in the prototype database. Users were allowed to have access to the data only trough predefined forms. An Ingres form is the electronic equivalent of a paper form; it is displayed on the computer screen and is used for data input and data display. Forms consist of trim, text that provides helpful information, and fields. The latter display the data and accept data entry. The access types supported from the secure prototype application are insert, read, update, execute, cancel. Thus, the possibility of deleting information is excluded. This was necessary, not only for reasons of better control of the information flow, but also for reducing the possibility of fatal mistakes. The main technical characteristics of the computer server used were: system IBM RISK 6000, operating system AIX, 32MB RAM memory and 2GB hard disk. The Information System of the AXEPA University hospital is not connected to the Internet for security reasons. The security constraints defined earlier were implemented using rules and procedures written in SQL. In the following section we will describe the methodology used for the definition of the security constraints that have been applied to the secure prototype application SEC_AXEPA and in the subsequent section the way each one type of them was implemented using SQL.

3.3. Security Constraints Processing 3.3.1. Definition of the security constraints Security classification constraints are application-dependent. They are specified by the database designer in co-operation with the users of the application [6]. Their application and processing may result to fragmentation and/or upgrading of the classification of some data sets in the medical database [5]. It must be noted that we will use the illness HIV (AIDS) as a representative of every sensitive illness. Also we will use the characterism VIP (Very Important Person) for the people whose medical record is considered sensitive (that is important people, hospital staff personnel, political, and other well known persons, etc.). Moreover we will represent the unclassified level by 1, the secret by 2, and the top secret by 3. Below we will define the security constraints that have been applied to the secure prototype application SEC_AXEPA. First we present them informally (as they were defined by the users), we categorise them and then we transform them into mathematical language . ♦ Constraint 1: The sensitivity level of the name determines the sensitivity level of all the patient personal information. Level-Based Constraint, LbC(PAT-PERS-INFO,{*},name). ♦ Constraint 2: The name of the patient is always considered top secret, so the personal information is always considered top secret. Simple Constraint, SiC(PAT-PERS-INFO,{name},3), then SiC(PAT-PERS-INFO,{*},3). stands for both constraints 1 and 2. ♦ Constraint 3: The data concerning the disease in the patient medical record is considered secret, if the disease is HIV. Content-Based Constraint, CbC(Diagnoses,{*},Diagnosis,’=‘,’HIV’,2). ♦ Constraint 4: If the lab result is HIV, then the information concerning the lab-test is considered secret. Complex Constraint, CoC(PAT-LAB-EXAMS,{*},LAB-EXAM-RESULT,’=‘,’HIV’,2). ♦ Constraint 5: If the lab result is HIV, then the information concerning the diagnosis is considered secret. Complex Constraint, CoC(Diagnoses,{Diagnosis),LAB-TEST-RESULT,Lab-exam-result,’=‘,’HIV’,2). ♦ Constraint 6: A nurse should always be able to look at the patient’s diagnosis (no matter what his/her status is). This is supported, in order he/she to be able to offer convenient care to the patient and at the same time take himself/herself suitable precautions. In the case of a sensitive diagnosis, (see constraint 5), a suitable cover story is created, which the normal nurse is enabled to access. ♦ Constraint 7: If the patient is a VIP, then whatever the diagnosis of this patient is, it is considered secret and a suitable cover story is created, in order to prevent normal nurses to infer sensitive information. Complex Constraint, CbC(Diagnoses,{Diagnosis}, PAT-PERS-INFO,P-status,’=‘,’1’,2) AND cover story. ♦ Constraint 8: The property ICD9-code of diagnosis is considered secret, while the values of ICD9-code without information as to whom they refer to are considered unclassified. Association-Based Constraint , AbC(Diagnoses, {ICD9-code}, 2).

♦ Constraint 9: The information of the prescription of a doctor to a certain patient is considered unclassified. However, the aggregation of the prescriptions given to a patient is considered secret, since it may indicate the changes of the patient’s health condition. Aggregation Constraint, AgC(Prescribes, {Doses}, ’3’, 2). ♦ Constraint 10: The laboratory exam results are considered unclassified. Thus, they can be accessed by the laboratory paramedical staff. However, in that way, a lab staff member can access all the results of the exams, even if they concern a sensitive disease (HIV). However, if that user accesses the corresponding diagnosis made for the same patient and realise that it is different from the HIV, he/she can infer the existence of cover stories. This problem is solved by the proposed methodology by assigning to users and data not only levels of sensitivity, but also disjoint categories. Inference Constraint, IfC(Diagnoses, {Diagnosis}, LAB-TEST-RESULT, {lab-exam-result}, corresponding category}. Since we support tuple-level granularity, level-based constraints always stand for all the properties of an entity. This means that the level-based constraints automatically undertake the entity integrity constraints. We must also note that apart from the security constraints, integrity constraints (like keeping the medical record of a patient updated) and availability constraints (like considering emergency cases when some access controls should be overpassed, in order a user to be able to access the necessary data) were also considered during the implementation. However, since we believe that they are rather typical of a hospital database, we have chosen not to refer to them in this paper. 3.3.2. Implementation of the Security Constraints using SQL For the implementation of the security constraints that were defined earlier for the hospital database, the security features, rules and procedures supported by Ingres were used. We have applied in our experimental implementation all the different kinds of security constraints to the prototype hospital database SEC_AXEPA. We will describe now a typical implementation of each one type of such a security constraint. We note that since we support tuple-level granularity, the level-based constraints and the entity integrity constraints are automatically satisfied. A simple security constraint (SiC) is implemented by creating a rule that is fired each time new data is inserted. This rule executes a procedure that sets the tuple class of the data inserted equal to the desired classification level. The implementation of the content-based constraints is similar. The following example also includes the implementation of the cover story created. Example implementation of a content-based security constraint and of a Cover Story SCL: CbC(Diagnoses,{*},Diagnosis,’=‘,’HIV’,2) AND cover story Rule 3: Create rule r_3 after insert of diagnoses execute procedure p_3 (pid = new.p_id, doctor = new.dr_code, diagdate= new.diag_date, diagnosis = new.diag); Procedure 3: Create procedure p_3 (pid integer4, drcode c(15), diagdate date, diagnosis c(500)) as begin if diagnosis = ‘HIV’ then update ‘marie’.diagnoses set tc = 2 where p_id = :pid and diag_date = :diagdate and dr_code = :drcode and diag = :diagnosis; message ‘All diagnose information are kept secret’; insert into ‘marie’.diagnoses(p_id, dr_code, diag_date, diag, icd9_code, diag_comm, fl, tc) values (:pid, :drcode, :diagdate, ‘Blood disease’, ‘222’, ‘Take care’, ‘l’, 0); message ‘Cover story successfully completed’; endif; end;

The complex-constraint implementation is executed in rather the same way.


Example implementation of a complex security constraint SCL: CoC(PAT-LAB-EXAMS,{*},LAB-EXAM-RESULT,’=‘,’HIV’,2) Rule 4: Create rule r_4 after insert of lab_test_res execute procedure p_4 (pid = new.p_id, labexams = new.lab_exam_res, resdate = new.res_date); Procedure 4: Create procedure p_4 (pid integer 4, labexamres c(100)) as begin if labexamres = ‘HIV’ then update ‘marie’.lab_test_res set tc = 2 where p_id = :pid; message ‘OK lab test results are kept secret’; endif; end;

An association-based security constraint implemented on Ingres is equivalent to an aggregation constraint, since column-level control is supported only in the update access mode in Ingres. An aggregation constraint is implemented by setting a limit to the data the user is able to retrieve. Finally, the inference constraints implementation is carried out by assigning different categories to the data, so that a user can not access certain data and infer sensitive information. 





4. Study of the User Acceptance As part of the experimental implementation, we also studied the user acceptance of the system. The main objectives were to study : • the user’s attitude towards health care systems’ security implementation in general, • the opinion and reaction of the users towards the specific experimental secure database. The first general conclusion is that most hospital users agreed that security is a factor that has to be preserved with priority at a hospital. They would also prefer to use a somehow more complex but more secure information system to an easier and less secure one, provided that they would be trained properly. They defined, however, the notion of database security in several ways. The main idea was that security is excluding some “non relevant types” of users from having access to the medical data. However, the specification of the “relevant type” of users was subjective (it ranged from all the nurses, to some of the nurses, to the director of the hospital). Moreover, they believed that confidentiality and integrity contribute most to the security of a hospital database; availability was found less important. As far as the specific secure hospital database SEC_AXEPA is concerned, most doctors and nurses thought that using a secure database would significantly improve their work. Additionally, they found SEC_AXEPA easy to use and satisfyingly secure. Most of them thought that all three aspects of security (confidentiality, integrity and availability) were well preserved. Some of them proposed some additional measures that had to be taken in order to maximise the availability of the database. For example, it was suggested that the special nurses should be able to access the diagnosis data of the patient, since they have to make decisions on several cases on their own on the patient’s medication. The support of cover stories, the user role hierarchy and the main security characteristics of the prototype hospital database, were found rather complex, but important and necessary for a hospital database. The users also believe that such a secure hospital database doesn’t completely fit in the current environment of the Greek hospitals. This is due to the lack of a specific (legal) definition of the user role hierarchy and of the necessary security measures to be followed.

They all agreed however that it is important to define soon the various types of data sets and user roles in a hospital. To conclude, almost all the users of the SEC_AXEPA hospital database were positive towards the support of the proposed security environment and the prototype secure hospital database itself.

5. Conclusions The implementation of the prototype hospital database has shown that the proposed secure database design methodology can be successfully applied at a complex real-life hospital environment. It has also been shown that in the prototype hospital database all the three aspects of security (secrecy, confidentiality and availability) were ensured with no significant overheads. More specifically, the secrecy (confidentiality) was preserved by allowing only the doctors to access the patient’s personal data and by creating cover stories for important people, for people who suffer from a sensitive disease, the hospital staff, etc.. Integrity was also preserved by providing for the users with the least possible privileges by forbidding every access to all the users and then allowing certain access types to certain users depending on their work at the hospital and with the use of security levels, which forbid the users to retrieve data, unless they are cleared for them. Finally, availability was also well preserved, since the performance overheads were relatively low, priority was assigned to the user transactions, depending on the user’s role in the hospital and the use of flags which allowed the users to have direct access to the most recent medical data (diagnoses, prescription, lab exam results, etc.). We believe therefore that the lessons learned from the implementation of the prototype secure hospital database SEC_AXEPA will be useful to other database designers, who will attempt a similar task in the future.

6. References [1] S. Castano, M. Fugini, G. Martella, P. Samarati, Database security, Addison Wesley publishing company, 1994. [2] G. Pangalos, M. Khair, L. Bozios, Enhancing medical database security, In: Journal of medical systems, USA, 1994. [3] G. Pangalos S. Katsikas, and D. Gritzalis, Medical database security guidelines, In: Computers and security journal, 1994. [4] G. Pangalos, M. Khair, L. Bozios, An integrated secure design of a medical database system, In: MEDINFO’95, The 8th world congress on medical informatics, Canada, 1995. [5] G. Pangalos, M. Khair, Design of secure medical database systems, In: IFIP/SEC’96, 12th international information security conference, 1996. [6] G. Pernul, Database security, Academic Press Inc., 1994.