Database of Scriptum

The hospital database should be implemented on a relational DBMS that 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 DBMS 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, DBMS 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 DBMS. 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 DMBS (a group is an identifier that can be used to apply permissions to a list of DBMS
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 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, DBMS 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 database.

Users were allowed to have access to the data only trough predefined forms. An DBMS 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 security constraints defined earlier were implemented using rules and procedures written in SQL.

A hospital, with health care information systems is one case of a security critical environment. It is one of the few environments, 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. Due to the widespread use of the database technology, database security plays today a significant role in the overall security of health care information systems.

The development of a secure database for health care information 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. 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.
The choice of an appropriate security policy and a suitable secure database design methodology is crucial in each of health care environments. The two most well known proposals for the database security policies are the mandatory and the discretionary ones. 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. 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).
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. 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. 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. 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.